Dear Binaurus, Many thanks for your in-depth reply, it helped me to understand things a lot better. I partially solved the problem by upgrading the Linux kernels of the guest machines from 2.6.5/2.6.7 to 2.6.23. (2.6.22 did not work). After that upgrade, the machines had network access again. (Duplicate MAC Addresses seem not to be the case as everything is assigned properly) However, when transferring huge amounts of data the network was gone again. Rebooting the machine did not help, but stopping / starting (and thus recreating the tap-interface did help. I now changed the driver in the guest kernel from RTL8193 to Intel E1000 (module 8239too -> e1000) - and it seems that the network access is stable. So, to me this really smells like some kind of kernel bug (hardware incompatibility?) - possibly at the host side, no clue, however. I found some links to people who had the same problem, unfortunately without solutions: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1694625 https://www.centos.org/forums/viewtopic.php?f=47&t=59614&sid=7b5cd81b80a6806cb4ae322715bb7766&start=10 https://bugs.centos.org/view.php?id=5526 Anyway, thanks for help, I keep my fingers crossed that the problem is gone. Best Regards, Hermann Am 22.01.2018 um 09:54 schrieb Binarus: > On 21.01.2018 13:30, Hermann Himmelbauer wrote: > >> Thank you for your quick reply, I did not (yet) solve the problem, but I >> unfortunately don't fully understand this "tap" device. > > You could imagine a tap device to be a NIC at the host side which is > completely realized in software (as opposed to the many NIC card types > which are passed to the VM as hardware device (which is emulated or > para-virtualized, but that doesn't matter in this context)). > >> I start my virtual machines via libvirt (virt-manage / virsh). However, >> looking at the command line, the virtual machine is started like this: >> qemu-system-x86_64 -enable-kvm -name guest=horn,debug-threads=on -S >> -object >> secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-11-horn/master-key.aes >> -machine pc-1.1,accel=kvm,usb=off,dump-guest-core=off >> -cpu qemu32 -m 1024 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 >> -uuid af3996ca-e192-65f0-4318-bd5054311d42 -no-user-config -nodefaults >> -chardev >> socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-11-horn/monitor.sock,server,nowait >> -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc >> -no-shutdown -boot strict=on >> -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 >> -drive file=/dev/gaia_data1/horn,format=raw,if=none,id=drive-ide0-0-0 >> -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 >> -netdev tap,fd=34,id=hostnet0 >> -device >> rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:9a:db:c6,bus=pci.0,addr=0x3 >> -chardev pty,id=charserial0 -device >> isa-serial,chardev=charserial0,id=serial0 >> -vnc 127.0.0.1:0 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 >> -device intel-hda,id=sound0,bus=pci.0,addr=0x4 >> -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 >> -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on >> >> So, the MAC-Address is assigend fixed. However, doing a "ip tuntap" >> shows the following: >> >> vnet8: tap >> vnet6: tap vnet_hdr >> vnet4: tap vnet_hdr >> vnet2: tap >> vnet0: tap vnet_hdr >> vnet9: tap vnet_hdr >> vnet7: tap vnet_hdr >> vnet5: tap vnet_hdr >> vnet3: tap vnet_hdr >> vnet1: tap vnet_hdr >> >> vnet2 / vnet8 are exactly the machines that have no network access. > > This is a whole lot of options, among them many I have never used. > > Nevertheless, as you already have seen yourself, the MAC address is > assigned explicitly. So the next thing I would do is checking if both of > the two VMs in question are being assigned the *same* MAC address by > accident (I don't know how libvirt and friends calculate / select MAC > addresses, but I could imagine that such accidents happen from time to > time). If that doesn't solve the problem, you may try the suggestion below. > >> So, I wonder if my problem has something to do with VLANs? I read >> somewhere that only virtio support VLANs, the rtl8139 does not. I do not >> use VLANs in any way, but perhaps there's something misconfigured? > > First, the rtl8139 device does support the vlan parameter, at least on > my systems: > > root@cerberus:~/qemu-kvm# qemu-system-x86_64 -device rtl8139,help > rtl8139.rombar=uint32 > rtl8139.x-pcie-lnksta-dllla=bool (on/off) > rtl8139.bootindex=int32 > rtl8139.multifunction=bool (on/off) > rtl8139.romfile=str > rtl8139.vlan=int32 (Integer VLAN id to connect to) > rtl8139.command_serr_enable=bool (on/off) > rtl8139.addr=int32 (Slot and optional function number, example: 06.0 or 06) > rtl8139.mac=str (Ethernet 6-byte MAC Address, example: 52:54:00:12:34:56) > rtl8139.netdev=str (ID of a netdev to use as a backend) > > Please note the sixth line of the output. > > Regarding the VLANs in general: > > You usually have one NIC which belongs to the VM side. This NIC is > hardware from the VM's point of view (the fact that it is emulated or > para-virtualized doesn't matter here). Secondly, you have another NIC > (the TAP device) which belongs to the host and which is realized in > software. > > Now you need a way to connect those two; otherwise, you can't pass > network traffic between them. One possible method to connect them are > VLANs. By passing the parameter ",vlan=n" to both NICs, you are > connecting them (of course, n is the same for both NICs). > > Don't be worried when you see examples where this is not done > explicitly. There are default values for the "vlan=n" parameter for > network devices. Please refer to your qemu man page if you'd like to > know more about that subject. > > Another method to connect the host NIC with the VM NIC is the method > your command line shows: The "netdev=" option of the rtl8139 determines > which host network device should be used as the "backend" for the > emulated hardware. > > Since the latter method does not seem to work in your case, you could do > the following for testing purposes: > > Copy the command line you have shown into a file, make it executable and > make the following changes: > > Replace -netdev tap[...] by > > -net > tap,vlan=29,ifname=spock0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifup > > (you probably already have this script, but maybe at another location, > and see the comments at the end) > (I have chosen a random weird VLAN number to make sure it doesn't crash > with a VLAN from you other VMs) > (Instead of spock0, you can choose another arbitrary name for the interface) > > Then replace -device rtl8139[...] by > > -device rtl8139,vlan=29,macaddr=<YOUR_MAC_HERE>,bus=pci.0,addr=0x3 > > Then shut down the VM in question and try to start it from the command > line by executing the file you have just created. > > Please note that I can't test this at the moment, so it might refuse to > start and emit error messages. If this is the case, please report. > >> What I do not know is how these "vnetX" - devices are created - you >> mentioned two scripts - what do they do? Are the MAC addresses somehow >> assigned to the "ventX" - devices, and if yes, how? > > The vnetX devices seem to be the tap devices in your case. The qemu > manual tells us that the O/S chooses a name for the tap device if none > is given explicitly. These devices are created automatically (by qemu) > when starting the respective VM (provided you have defined a tap device > for the VM). > > According to qemu's manual, there is no option for a tap device to > assign a MAC, and I never have seen such an example. I haven't read the > source code, and thus I don't know if a tap device uses an own MAC > address internally (I don't think that, though), but in every case this > should not matter here. What does matter is the MAC address you have > assigned to the emulated / para-virtualized NIC which is passed to the VM. > > Regarding the scripts: After having connected the VM's NIC and the > host's (tap) NIC, you are not done yet. What you have so far is a street > with two ends (the host and the VM), but no additional crossroads which > would enable you to discover the world. > > To do that, you usually connect the tap device to a bridge which is also > connected to the real hardware NIC of your host (if desired), to the > other tap devices from the other VMs (if desired) and so on. > > Please note that there are other methods, too (for example, you could > define a virtual network switch, and there are even other methods), but > I have found bridging to be easy to understand, efficient and scalable. > Of course, you can define as many bridges a you want and separate your > VMs that way. > > In my case, as I wrote in my previous message, the script just adds the > tap device to a bridge (I have only one since my setup is simple: each > of my VMs should see the full network traffic). It is not worth showing > the contents of that script because it is the default one delivered with > qemu, so you should have it already. > > As a final hint, you probably don't need that script: > > a) There is an option ",br=bridge" to -net tap. I suppose that this > connects the tap device to the respective bridge immediately when it is > created, and thus I didn't need the script if I would use this option. > But please note that I did not try this yet, so I might be wrong. > > b) There is a parameter "-net > bridge[,vlan=n][,name=name][,br=bridge][...]" which seems to meant for > connecting a vlan to a bridge directly; this would make using the script > unnecessary as well. Please note that I didn't try that either, so I > might be wrong again. > > In general, to solve your problem, I would recommend you to play around > with the command line. To get the right feeling, you might want to read > qemu's man page; this will lead to a deeper understanding of what > libvirt and friends are doing behind the scenes. > > By the way, I never managed to damage a VM by giving the wrong > parameters to qemu. But if you are concerned about this, just make a > backup copy of the image the respective VM boots from. Then, nothing > will stop you from playing around :-) > > Regards, > > Binarus > -- hermann@xxxxxxx PGP/GPG: 299893C7 (on keyservers)
