iainwb's Posts

That prevents suspension, but now shutdown powers off the VM in an unsafe state. What I'm looking for is the VM preventing the host shutting down, so that I can cancel shutdown and then shut the VMs down manually.

I'll cancel the host shutdown and shut them down manually, as I always have. The application that they run doesn't survive a suspend and it takes me far longer to recover from suspended VMs than to restart them.

It looks possible. dadtransmits=0 to disable duplicate address checking might be the needed magic. I searched high and low for that. Last week we replaced my notebook. After Dell replaced the motherboard I had several issues with it, so I'm migrating to a new machine so we can figure out what to report and get the old one back to Dell. The new machine has the same WiFi adapter (Intel(R) Centrino(R) Ultimate-N 6300 AGN) but the problem appears to have vanished. Whether it is updated hardware, updated WiFi drivers, or the fact that I've updated VMWare and VMWare tools, I have no idea. I plan to test with the old notebook after I've finished my transfer.

I ran the same test on my old notebook with the same guest VM (Intel 5100 AGN wifi card). There is no echoed ARP request, and no decline. I really don't think that I should be seeing the request from the adapter's ethernet address in the guest; I think that's what's killing the DHCP setup. Interestingly, though, there's only a single ARP request for 192.168.34.1. I have no idea whether that's significant.

More info. I ran wireshark on the host specifically looking for ARP requests. I see an ARP request for the gateway, which is answered (two request/reply pairs for some reason) and an ARP request for the assigned address with no reply, as expected, but followed by the DHCPDECLINE. Then I ran the same on the guest VM with similar but subtly different results, and I'm not sure if the differences are as expected or are a problem. Comments and observations: * I have disabled everything I can in the adapter properties on Win7, including IPv6 and Microsoft networking. The only checkbox enabled is IPv4. * I have no idea what the IGMP traffic is setting up or if it could be a problem. It seems unlikely. * I haven't expanded the DHCP Offer/Ack, but I've walked through several other transactions, and it appears correct. In this case it was assigned 192.168.34.131. * There are two requests by the VMware ethernet address (Vmware_8e:2c:04) for the address of the router, 192.168.34.1. Both get a reply from the Linksys router (Cisco-Li_f6:46:8e) * There is an ARP request by the VMware ethernet address for 192.168.34.131. This should have no reply, because that would mean the address already exists on the LAN. * There is a subsequent ARP request by the Wifi adapter's address (IntelCor_85:1b:a4) for 192.168.34.131. * There is no reply to either of those ARP requests (as expected) * Immediately after these requests is the DHCPDECLINE. Differences on the host side: I'm not going to post a screenshot because they would be for different transactions and misleading, but: * All ARP requests originate from the Intel address * The Linksys router replies to the Intel address (which becomes the VMware device in the guest) * There is only one request for 192.138.34.131 on the host side, originating from the Intel address, still with no reply, of course. So a couple of options present themselves: * The ARP who-has issued by the guest is getting an invisible reply; something in the driver layer recognizes the address as assigned to the wifi adapter and is answering without the traffic being visible to Wireshark. This seems unlikely, but it could be a bug in virtualization code. * The call to send the who-has is not behaving precisely in the virtual driver as it would be for the host talking directly to the card, and Windows is finding an error. (On reflection, both of these are bogus. The adapter, virtualized or not, is on the other side of Wireshark's monitoring from the Windows IP stack. What's causing the failure has to be visible to Wireshark.) * The ARP who-has issued by the Intel device for its own address is being seen as a separate device claiming ownership of that address. What makes me suspect this is that the ARP requests for the router's address are not visible to the guest. It doesn't see the requests, only the translated replies. However the ARP request from IntelCor_85:1b:a4 for 192.168.34.131 is visible to Wireshark. Perhaps the Windows ethernet layer sees that request, considers that there is another device requesting the same IP address and bombs out. I've googled several references to a related problem in Win7/Vista. This final ARP who-has is apparently new behaviour. In one case the router was replying to that who-has, and it wasn't possible to get an IP address. I haven't found precisely what I'm seeing here, though, which is a decline after no ARP reply or a different device's ARP request. I've also found references to "disabling Windows address conflict detection," but nowhere that would tell me how, if it's even possible. All I could find was a router setting, not client-side.

Okay, so I just deleted a huge long reply that I was answering point-by-point. I think you're right on all counts, except that the 192.168.32.5 is actually the DHCP server, not the VM host. The host is at .80. I had forgotten that at one point I tried to use a static address and also failed. I don't see why a static address would make a DHCP request but it does make an ARP who-has request to ensure that the address is not in use. Perhaps the reason for the DHCP DECLINE is that there's an ARP who-has after the offer and prior to committing to it. After typing all of that up (the long version), I realized that might be exactly what's going on, if the stuff below is true: What I might be missing is this: >> On each guest VM I changed the network settings from "Bridged: Connected  directly to the physical network" to "Custom: specific virtual network"  and they are all now working! << If that's something that you do with the administrative policy that you added, then bingo. I'm not doing that because I don't understand it . I wouldn't have expected that Windows would be aware of bridging. I would have thought it simply saw a virtual NIC that appeared to be connected directly to an ethernet cable. If both Windows and VMWare are setting up bridging, that could cause conflicts. I could certainly believe that Windows is issuing an ARP who-has to its bridged device, and the VMWare bridged device is replying "here I am." Since that would be entirely internal, I would probably not even see that on the wire. Anyway, if that is what you mean by that sentence I will definitely need to PM you for help with MMC. Google has not been my friend there, nor has the MMC help which appears to assume you already know what you're doing . Unfortunately, I'm without the notebook now for a few days; likely I'll have it back Friday this week or Monday next.

Start - Run - type "MMC" - Enter File - Add/Remove Snap-in - Group Policy Object for local computer. Computer Configuration/Windows Settings/Security Settings/Network List Manager Policies Under Unidentified Networks Properties, select Private and Uses can change location. Exited out of that and then from a command prompt did a gpedit /force On each guest VM I changed the network settings from "Bridged: Connected directly to the physical network" to "Custom: specific virtual network" and they are all now working! Haven't tried changing the NIC to use DHCP as I want these to be all static, so if someone does that let us know. I am also not sure if you can just configure the Group Policy and use the original VMnet0 networking option. Since the failure I'm experiencing is specifically with DHCP, it seems like this would be a different problem. I did try tweaking group policy with no effect - but then I have no idea what I'm doing . Still, I can't survive with a static IP because of the number of wifi networks I need to use. I do already have the adapter set to custom and tied to the wifi NIC. To be able to work I've switched to using NAT for now, which works for 90% of what I need, but sometimes I do also need to have that VM visible from the net, and then NAT won't work.

er650 wrote: This is possibily cause by the wireless router is unable to assign multiple IP to the same physical wireless NIC. Unfortunately, that's not the case here, as I have used all of these wifi networks with multiple IPs on the same NIC, and still can on this problem NIC if I'm running XP rather than Windows 7.

So it seems like the common factor is the NIC, although not completely identical model numbers. Intel Centrino advanced/ultimate 6200/6300 series. (Likely identical drivers, however.) Is there any way to submit a bug report? I guess I don't have the free month's support with the upgrade that I had when first buying VMWare

What physical device is this, and is it wifi or wired? Given that my wired (and NAT and host only) connections are working perfectly, and this VM also functions just fine on another machine, I have to believe it's some kind of problem between the IP stack and the Intel wifi card, most probably in the VMWare driver. Since it's the same with e1000 and vmxnet3 emulation, that's probably a fairly small and very hardware-specific layer, so it might be useful to find out where else the failure occurs.

I've already removed the devices and let the OS re-install, and I've tried four completely isolated class C networks. I can ping 127.0.0.1. netsh might be useful, if I knew how to drive it :/. I've used it to reinitialize the IP stack a couple of times; beyond that I'm not sure what I'd accomplish with it.