I'm seeing an odd behavior with my Fedora guest install. Any initial / manual DHCP activation works fine; but when the lease time is up, it's not able to successfully renew the lease, and NetworkManager eventually gives up and disables the interface. The root cause seems to be some odd ARP interactions: when dhclient attempts to renew the license, it sends targeted DHCPREQUEST packets to the original DHCP server. After that fails for a while, it then tries to send DHCPREQUEST to the local broadcast address (255.255.255.255). When that fails, it gives up. As soon as I initiate a new manual connection, a proper sequence of DHCP DISCOVER / OFFER / REQUEST / ACK takes place. Tracing ARP packets shows that when my guest (192.168.1.168) tries to find the DHCP server (192.168.1.1), the conversation goes something like this: 14:57:20.739590 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 tell 192.168.1.168, length 28 14:57:20.742301 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.1 is-at 00:24:b2:d6:d1:1e, length 28 That's good so far. But when the server (at .1) tries to get the address for the client (at .168), things go pear-shaped: 14:58:14.252355 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.168 tell 192.168.1.1, length 28 14:58:14.252897 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.168 is-at 00:26:bb:03:78:0d, length 28 This is a problem, because the MAC addresses are wrong. Within the guest, I have: linux$ ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:1C:42:A1:79:83 inet addr:192.168.1.168 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::21c:42ff:fea1:7983/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1223683 errors:0 dropped:0 overruns:0 frame:0 TX packets:682783 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1599379892 (1.4 GiB) TX bytes:109207918 (104.1 MiB) Interrupt:10 Base address:0x8400 But the MAC address for the guest eth1 (.168) is 00:1C:42:A1:79:83 -- but the ARP response is giving 00:26:bb:03:78:0d, which is the MAC address of the host (which is actually at 192.168.1.153): mac$ ifconfig en1 en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:26:bb:03:78:0d inet6 fe80::226:bbff:fe03:780d%en1 prefixlen 64 scopeid 0x6 inet 192.168.1.153 netmask 0xffffff00 broadcast 192.168.1.255 media: <unknown subtype> status: active This configuration used to work flawlessly; this problem started only after I temporarily changed the VM networking to be "host-only". I have since changed it back to "bridged", but it's still disconnecting me every 24 hours or so. (That's the result of about 10 hours lease time, then 10 hours sending DHCPREQUEST to 192.168.1.1, then another hour or two sending DHCPREQUEST to 255.255.255.255, before giving up and disabling eth1.) Anyone have any ideas? At this point, it's mostly just an inconvenience -- but I'd like to get it working stably again. Thanks!
What if you delete the network adapter device from the hardware list in the virtual machine configuration. Then add a new network adapter device? That should remove whatever happened when you temporarily changed the VM networking to be "host-only". You could save the config.pvs file in the .pvm before and after the change and compare them to see if anything actually changed.