I have been using VMware Player for some time to host Fedora VMware images on Windows XP. I have been using Fedora 11 and 12 (both 32 and 64 bit) and recently started to use Fedora 13.

I use as a base the images provided by thoughtpolice. http://www.thoughtpolice.co.uk/

I usually install VMware tools and also keep the images updated (yum update) which sometimes changes the kernel.

I have recently had problems with the snapshots not having a network when I restore them. So far I don't have the problem with Fedora 11 and do have it with Fedora 12 (but used not to). I do have it with Fedora 13.

In each case the problem goes away when I uninstall the VMware tools and comes back when I install them again.

One of the symptoms is that SElinux complains about not being able to do something with /var/run/vmware-active-nics.

It looks to me that something is incorrect in the actions being taken when the snapshot is being restored. It does not happen every time and sometimes the network restores itself.

The network can be restored by rebooting the image.

I am sorry to have gone on at some length, but there is quite a lot to this. Please advise if this should have been in a different forum.

Thanks

Un-installing and re-installing something to "fix" something shouldn't be necessary.


Please be specific: what is missing and how did you diagnose things? No modules loaded? No device available? No routes? Is it wireless or wired? Does it use DHCP? Host-based NAT or bridge? What does /var/log/messages say? And the VMware guest logs? And ifconfig?


Please post the complete actual message instead of a description.

1 members found this post helpful.

Thank you for your comments. I was hoping that someone had already seen similar symptoms. I can appreciate you wanting some more details.

This is a diagnosis report - i.e. that something in VMware tools is causing it. I notice that on CentOS there are precompiled binaries for some of the elements and the problem does not occur. For Fedora some elements need to be compiled using the kernel headers. I suspect that at some point in time something has changed in the kernel headers to cause the problem.

Diagnosis:
(1) Icon shows network inactive and reports network inactive
(2) ifconfig reports only loopback (ifconfig.before.txt and ifconfig.after.txt attached)

This is the connection between the host (Windows XP) and the guest (Fedora 12). Imitating wired not wireless. When it works it uses DHCP to aquire an IP no from the host. It uses NAT.

Log of the SElinux report also attached, although I am not convinced this causes the problem, as it has been occuring for some time.

Thank you for the suggestion of looking in /var/log/messages. I am having a look at that and will report further.

Where will I find the VMware guest logs?

Thanks for your help

Attached Files

	ifconfig.before.txt (928 Bytes, 39 views)
	ifconfig.after.txt (395 Bytes, 42 views)
	SElinux report.txt (3.8 KB, 33 views)

Here is some further information from /var/log/messages.

I have extracted the messages relating to the network connection.

I did a reboot and can see the network being set up.
When I do a snapshot it is taken down and not rebuilt when the snapshot is reopened.

I compared that with another image without WMware tools installed (Fedora 13). In that case there were no messages at all on taking and restoring a snapshot. I don't have a duplicate of Fedora 12 and would have to take VMware tools out of this one to test this, but it seems as though the problem is that the network is shut down when the snapshot is taken.

I can compare this with the CentOS and Fedora 11 images I have where this does not happen.

Attached Files

messages.txt (5.4 KB, 36 views)

Yet more information. This one is from taking a snapshot and restarting Fedora 11 with VMware tools, which does work.

In this case the message logs show that the network was shut down and restarted.

Attached Files

messsages2.txt (6.4 KB, 29 views)

You're referring to the vmdesched, vmhgfs, vmmemctl and vmxnet kernel modules none of which you would need for fixing this.


There seems to be a discrepancy as SELinux tagged it with a vmware_host_pid_t context but it was created with a initrc_var_run_t context (probably denoting the process was run at startup). IIRC /var/run/vmware-active-nics is created by /etc/vmware/suspend-vm-default echoing the ethernet devices into it on suspend (you're talking suspend, not snapshot) so either /etc/vmware/suspend-vm-default should have a line modified to 'save_active_NIC_list && chcon vmware_host_pid_t /var/run/vmware-active-nics' (good) or ifconfig should be allowed to access initrc_var_run_t (can't see why).

I run VMware Server and for me the guest logs are in the directory the guest files reside in. The VMware proces itself has a log too (vmware-serverd here).


In the guest open 'vmware-toolbox' and see if under the "Scripts" tab the resume and suspend operations explicitly use "Custom script" (leave the values themselves alone). For me running '/etc/vmware/resume-vm-default' manually as root didn't lead to the desired effect until I had modprobed the devices module first.

1 members found this post helpful.

One issue here is that the file /var/run/vmware-active-nics does not exist. I have seen other reports of this.


Thanks. I have found the logs.

I tried running '/etc/vmware/resume-vm-default' manually and it didn't change things, even running modprobe on pcnet32.

What I have done is to note the kernel numbers and dates as follows:

CentOS 5.5 2.6.18-194.17.1.el5 (Sep 29 2010) no problem
Fedora 11 i386 2.6.30.10-105.2.23.fc11.i686 (Feb 11 2010) no problem
Fedora 12 i386 2.6.32.21-168.fc12.i686.PAE (Sep 15 2010) problem
Fedora 13 i386 2.6.34.7-56.fc13.i686 (Sep 15 2010) problem

One thought I had was to try to get a Fedora 12 which does not have the latest kernel. One way would be to extract a copy of the base file I have and install VMware tools without doing a kernel update.

I also attach the extract from /var/log/messages produced by installing and configuring VMware tools on Fedora 13. I have sent the whole log as it contains some error messages relating to network configuration.

I think there is a mismatch somewhere between Fedora and VMware in the naming of the network interface as the names eth0 eth1 and sometimes eth2 get used and sometimes names eth1 and eth0 are referring to the same connection. I have not been able to track down how this comes about.

My aim is to understand this well enough to patch the systems so that they work properly.

Thank you for your help, unSpawn.

Attached Files

messages3.txt (15.1 KB, 27 views)

This morning I suggested an experiment as follows:

I have now carried out something like it as follows.

I started with the base version of Fedora 12 i386 which uses the PAE kernel. I did have to update the kernel to the following to get a consistent set of headers and kernel-devel.

Fedora 12 i386 2.6.32.21-168.fc12.i686.PAE (Sep 15 2010) problem

I tried very hard to update as little as possible but did install gcc gcc-c++ and also needed mkinitrd to install VMware tools.

At each stage I shut it down and restored it to check for any problem.

It does that without loosing the network connection as mentioned above.
I think this means that some of the other updates are causing the network failure. I suspect the NetworkManager software because of some of the error messages I reported previously.

The system proposes an update of NetworkManager from version 1:0.7.996-6.git20091021.fc12 to version 1:0.8.1-6.git20100831.fc12

There is one component of VMware tools which is not working on the current Fedora 12 system. It is the full screen mode and resizing of the window. I have the same issue on a copy of CentOS 5.5 which is otherwise not showing any problems. I thought of that as a separate problem which I was going to report separately but now think these problems could be linked.

I appreciate very much the help from unSpawn without which I could not have got to here. I don't regard this as a solution, as what is needed is a fix for both Fedora 12 and Fedora 13. I don't know how to achieve that as I have seen it written that VMware do not support Fedora as a guest system.

/var/run/vmware-active-nics is only created when /etc/vmware/suspend-vm-default is run.


The main "magic" AFAIK is in the scripts that get called from /etc/init.d/vmware-tools if enabled to run on boot. BTW thanks for posting your /var/log/messages but I can't see where the guest gets suspended and resumed.


They may well be (manually running 'vmware-user' inside the guest gets me a filled viewport of the guest inside my local VMware app) but I'd rather concentrate on one issue at a time.


In ye aulden days you didn't have or needed Avahi, HAL, udev, D-BUS or nm. You only needed the right kernel module to access the ethernet device, some network-related configuration files and a DHCP client like dhcpcd, pump or dhclient to get a working network connection. So my line of thinking would be (knowing tools, like some of the ones in /etc/sysconfig/network-scripts/, use allow for hooks to signal to other applications they need to Do Something) to disable all "convenience" applications and see if resuming will work and if it doesn't then find the right hook to trigger setting up a network connection again. If I get that to work then I'd see if a trigger can be delivered via HAL, udev or D-BUS to nm or whatever. For that I think the /etc/vmware tools should be used as they get (or should be) triggered by the VMware host on guest resume. I think it's an interesting problem to diagnose but it'll take me some time to test things myself as I'm rather busy this week.

1 members found this post helpful.

I'll do some annotation as to what is happening when. It will be this evening (8 a.m. now for me).

Here is a fresh set of messages from my Fedora 13 with Vmware tools as message4.txt.

It shows a reboot (up to time stamp 23.45.53) and then a suspend and restore. At that point the fault occurs.

The only other thing to report is on my experiment with Fedora 12 without full updates. I updated NetworkManager and all dependencies. I expected that this would make the network fail on restore. It does that but immediately runs a process which restores it. I want to explore what else wrecks that on update. I have a long list of what it wants to do (yum list update) and would post that as well but at the moment drag and drop is not working from that image. So I am left with a guessing game.

Attached Files

messages4.txt (107.2 KB, 48 views)

Something I meant to add. When I did the update of NetworkManger in the course of the update I had this message which I had not seen before in many yum updates and installs:

Warning: RPMDB has been altered since the last yum transaction.

I have seen it before on another Fedora 12 but not on Fedora 13. I report this as a possible clue.

I have not done anything to the RPM database, except through yum.

I have come back to this and done a full update on the Fedora 12 which I reported on last.

This does not have the problem - it knows how to restart the network but it won't do full screen. It seems to me that there are some problems here resulting from VMware not supporting Fedora (and vice versa?)