F16 KVM - Very flaky networking with WinXP guest

[Robert2]

Hi,

I have a F16 x86-64 installation with the latest updates, with two windows guests. A Win7 x64 and a WinXP SP3 guest. Both guests are setup for default NAT networking as configured by Fedora.

These issues did not change with the batch of KVM/QEMU updates that came through in the last days.

On the Win7 x64 guest, networking just works. I have tried both the default rtl8139 device, and the virtio drivers.

But on the WinXP guest I have tried almost every virtual network device, I just cannot get a usable network connection.

With the default rtl8139, pcnet or virtio device, windows shows link, but generally does not manage to get a network address. Generally, because there is the occasional exception where it does manage to get a network address, but typically that is where things stop working. If I'm lucky I might get a few pings through before things seem to stop working completely.

With the ne2k_pci driver, I manage to get a network address most of the time, but the connection is pretty much unusable. For instance pinging a server, that from the host has a 0% packet loss will instead have 50-70% loss. And typically loss comes in batches, so it is able to get a few pings through and then it stops working again for a while. I have had on a few occasions that the network would work for a minute or two before it dropped out, and I cannot even ping the default gateway any more.

I have not tried the e1000 yet, as that driver apparently did not ship with WinXP and I would need to go find the driver, but considering the issues with all the other devices seem related I don't think it will make a difference anyway.

I would love to hear some suggestions, or if anyone has been able to get WinXP SP3 working properly in KVM on Fedora 16.

[David Becker]

It's probably not due to the particular network driver, rather something having to do with the MTU. You could try to start pinging your host's (virbr0) IP address with "ping -f -l 1472" and then do the same for addreses located upstream. Also, check the settings for mtu and path mtu discovery in the registry.

David

[stevea]

Hmm - haven't tried this yet - but if there is a similar result from two different interfaces i's most likely in the virtualization framework and deserves a bug report. Tho' it could be MTU that seems a wild stab in the dark - not a reasoned approach to diagnosis.

[David Becker]

Originally Posted by stevea

Hmm - haven't tried this yet - but if there is a similar result from two different interfaces i's most likely in the virtualization framework and deserves a bug report. Tho' it could be MTU that seems a wild stab in the dark - not a reasoned approach to diagnosis.

If Windows 7 is working fine while XP SP3 is not (with several NIC drivers) than it's probably not due to the virtualization framework (or NIC drivers).

A common issue with XP is that connections to the local network work fine while connections going over the internet don't, the latter described by the OP. This frequently has to do with PMTU (discovery or black hole detection) settings. That's why I suggested to execute aforementioned ping to the virbr0 IP address first and then to upstream hosts.

Maybe your "reasoned" approach of submitting a bug report to those responsible for the virtualization framework is better.

David

[Robert2]

Originally Posted by David Becker

If Windows 7 is working fine while XP SP3 is not (with several NIC drivers) than it's probably not due to the virtualization framework (or NIC drivers).

A common issue with XP is that connections to the local network work fine while connections going over the internet don't, the latter described by the OP. This frequently has to do with PMTU (discovery or black hole detection) settings. That's why I suggested to execute aforementioned ping to the virbr0 IP address first and then to upstream hosts.

Maybe your "reasoned" approach of submitting a bug report to those responsible for the virtualization framework is better.

David

Unfortunately ping with a smaller MTU size makes no difference. And if the issue was the MTU size, then why does the networking work after a boot for just long enough to get a network address from the DHCP server and perhaps a few pings? If the issue was MTU I would not expect any packets to get through. Also when the issue occurs, I cannot even ping the host any more on the 192.168.122.1 address that is defined as the default GW.

But I am starting to suspect something is wrong with this particular image. A friend had me try his WinXP SP3 image and it worked, although he was using the e1000 driver which I had not yet tried. But changing it in his VM to Realtek still worked. Both images seemed to be using the same basic network stacks.

Unfortunately I cannot just create a new image, as its a corporate image with a bunch of stuff loaded in it.

[David Becker]

Originally Posted by Robert2

Unfortunately ping with a smaller MTU size makes no difference.

The idea was to ping with a larger packet size together with the DF bit set.

Originally Posted by Robert2

And if the issue was the MTU size, then why does the networking work after a boot for just long enough to get a network address from the DHCP server and perhaps a few pings? If the issue was MTU I would not expect any packets to get through.

With PMTU discovery, the mtu may change dynamically per host/route.

Originally Posted by Robert2

Also when the issue occurs, I cannot even ping the host any more on the 192.168.122.1 address that is defined as the default GW.

Check the arp tables on the host. Are you runing Windows firewall? Can you ping the guest from the host?

David

[Robert2]

Just want to report that a colleague figured out the problem. The issue is that the windows XP image had the computer type in windows set to "Standard PC", instead of the more common "ACPI Uni/Multiprocessor". This is something you cannot change without reinstalling windows.

This is apparently a known issue with QEMU that is fixed in the newer 1.0 version. But there does not seem to be any intention to provide QEMU 1.0 in Fedora 16

So I can either wait for F17, or provide my own QEMU 1.0 for F16.