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
