Bug#702428: [Pkg-xen-devel] Bug#702428: HVM networking tap/vif bug (Debian bug 702428)
On 21/03/13 02:47, Ian Campbell wrote: On Wed, 2013-03-20 at 23:32 +0100, Daniel Pocock wrote: Should the script be using the ovs-vsctl command instead of brctl? As a general rule one should be using the ovs tools directly wherever possible and not the brctl compat layer. Or have I misconfigured something and the wrong script is being run? This is something which AFAIR differs between upstream Xen and XCP. With upstream Xen we disable the qemu script explicitly and expect the xen vif hotplug scripts (which handle Xen tap devices too) to do the job, that is the scripts under /etc/xen/scripts/vif-foo (for foo in bridge, openvswitch etc) As you explained earlier, my dom0 had both a tap20.0 and a vif20.0 for the HVM domU I noticed that the vif20.0 interface was successfully added to the bridge during VM creation, presumably the script responsible for that used the ovs command instead of brctl While I could add some permanent hack to the script I modified above, and this might be important to include in the wheezy release, I don't want to second-guess the strategic way of sorting this out, would you know who is maintaining this part of XCP and how we can get some direction on this? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702428: [Pkg-xen-devel] Bug#702428: HVM networking tap/vif bug (Debian bug 702428)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 17/03/13 18:49, Ian Campbell wrote: On Sun, 2013-03-17 at 18:44 +0100, Daniel Pocock wrote: On 17/03/13 18:38, Ian Campbell wrote: I'm afraid I don't know about the issue you are seeing but I can comment on one part: On Sun, 2013-03-17 at 15:02 +0100, Daniel Pocock wrote: while the output from dmesg suggests that the interface vif10.0 was created. It appears there is confusion between the vifX.Y and tapX.Y naming schemes. An HVM guest with a network device should get *both* vifX.Y and tapX.Y, they are kind of two faces of the same device. The tapX.Y is the emulated NIC (rtl8169 or e1000 or something) while the vifX.Y is the PV NIC which the guest can choose to switch over too (for increased perf etc) if it has a suitable driver (e.g. Linux PVHVM support, PV drivers for Windows etc etc). As to why tapX.Y cannot be added to a bridge, I've no idea, sorry. Are you using bridge or vswitch? Can you manually enslave the tap device to the bridge? I'm using Open vSwitch I wonder if something might be logged by ovs about why it is refusing this operation? I think OVS has pretty extensive logging capabilities too so you might be able to increase the verbosity. Ok, I played with it some more, there is definite progress but I still believe something is wrong in one of the scripts: I notice this in syslog: domid: 19 -c config qemu network with xen bridge for tap19.0 xapi1 can't add tap19.0 to bridge xapi1: Operation not supported /etc/xen/scripts/qemu-ifup: could not launch network script Could not initialize device 'tap' After seeing that, I decided to look inside the script mentioned there, /etc/xen/scripts/qemu-ifup I found the brctl command in the script brctl addif $2 $1 Commented out that line so the script now returns 0 (success) Booted the VM - it boots successfully, but without network connectivity. It has a VIF, but no ping Looking at `brctl show xapi1' and I see vif20.0 is in there, but tap20.0 is not Manually run the command ovs-vsctl add-port xapi1 tap20.0 Now it is possible to ping the running HVM domU Should the script be using the ovs-vsctl command instead of brctl? Or have I misconfigured something and the wrong script is being run? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJRSjkEAAoJEOm1uwJp1aqDw8EP/3Er1BTtGmfZn16kndFzklUl gU901PTVtNOaLODI9c+ecE4Z+vBMWebPhwwXeiDEjCS32xlufJAeSBG5hf31lHt2 mhPjHMzO8MjvIicC4zqN85soNIYz0T57bjWJhUoYhPvZCnwFSoi7vegteE9der+C J1xfh3BzdyUHNMphDsuHPuZSninEpUrZT4Ez9jRKM585UpNgM75tIMoHzzm+j/Ek qwTZKISyc+0sd/QGwCzet3/P3lUkKXhZ296SjsBcPjqq0IHkO391xD9jCX4XMLxR 2lQMfVlvW+KciZwnKsvPWQC9NsyhtnTBZ9sSof9e/WYYsxZ9PWRDZ60QPn8RIHrg pP0WwYbfGvs1cGj5Gu7kjq0ikhRQ4HLcE/b3S8Y8knv4/LyIZj98D+RAiIbPuq48 MF8BHFZw5QjLPPe24Dhq7684YiFUpInFvHx1i7PBJdv1RwxA32pmauPNUHLOg232 qoBjoY5IjEUJI3+OwV772DF38WqsZru25ANwbNXh4PSs4PVnCt6eXc/w70UQeNEG 7OEEkQ7qyPG4iAWQvaFlvrOnwS47g1E9ARMnLhjPGKXwU88PMawmqMf0pVlaR499 199GIc28lAnTkLJHfNs6FdJlGvp8xl0BzhGK7BSPgEm0Y83PV/COwvDFpDNLXNng MDh3YrAb/VHQxzTnNmzj =zyPi -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702428: [Pkg-xen-devel] Bug#702428: HVM networking tap/vif bug (Debian bug 702428)
On Wed, 2013-03-20 at 23:32 +0100, Daniel Pocock wrote: Should the script be using the ovs-vsctl command instead of brctl? As a general rule one should be using the ovs tools directly wherever possible and not the brctl compat layer. Or have I misconfigured something and the wrong script is being run? This is something which AFAIR differs between upstream Xen and XCP. With upstream Xen we disable the qemu script explicitly and expect the xen vif hotplug scripts (which handle Xen tap devices too) to do the job, that is the scripts under /etc/xen/scripts/vif-foo (for foo in bridge, openvswitch etc) Ian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702428: HVM networking tap/vif bug (Debian bug 702428)
Hi, I've been testing the Debian packages ahead of the Debian 7 release (which is very imminent) I believe this is a serious bug[1] in the package, as it appears that HVM networking is broken, or at the very least, requires some undocumented configuration step Specifically: - I can start the HVM domU without any vif - if I attach a vif, the domU will not start Looking at /var/log/daemon.log, I notice: xcp-fe: qemu-dm-10[9169]: can't add tap10.0 to bridge xapi1: Operation not supported while the output from dmesg suggests that the interface vif10.0 was created. It appears there is confusion between the vifX.Y and tapX.Y naming schemes. Can anybody comment on this? Is this hardcoded into some config that I should inspect? Is it hard coded in the qemu-dm scripts? It would be very desirable to fix this before the wheezy release so that people don't have a bad impression of XCP with HVM. Regards, Daniel 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702428 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702428: [Pkg-xen-devel] Bug#702428: HVM networking tap/vif bug (Debian bug 702428)
I'm afraid I don't know about the issue you are seeing but I can comment on one part: On Sun, 2013-03-17 at 15:02 +0100, Daniel Pocock wrote: while the output from dmesg suggests that the interface vif10.0 was created. It appears there is confusion between the vifX.Y and tapX.Y naming schemes. An HVM guest with a network device should get *both* vifX.Y and tapX.Y, they are kind of two faces of the same device. The tapX.Y is the emulated NIC (rtl8169 or e1000 or something) while the vifX.Y is the PV NIC which the guest can choose to switch over too (for increased perf etc) if it has a suitable driver (e.g. Linux PVHVM support, PV drivers for Windows etc etc). As to why tapX.Y cannot be added to a bridge, I've no idea, sorry. Are you using bridge or vswitch? Can you manually enslave the tap device to the bridge? Ian. -- Ian Campbell Put your brain in gear before starting your mouth in motion. signature.asc Description: This is a digitally signed message part
Bug#702428: [Pkg-xen-devel] Bug#702428: HVM networking tap/vif bug (Debian bug 702428)
On Sun, 2013-03-17 at 15:02 +0100, Daniel Pocock wrote: xcp-fe: qemu-dm-10[9169]: can't add tap10.0 to bridge xapi1: Operation not supported A google search for linux add tap to bridge operation not supported shows lots of people having this sort issue (often in the absence of Xen) although none of the links I followed contained a solution :-(. Ian. -- Ian Campbell Expect a letter from a friend who will ask a favor of you. signature.asc Description: This is a digitally signed message part
Bug#702428: [Pkg-xen-devel] Bug#702428: HVM networking tap/vif bug (Debian bug 702428)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 17/03/13 18:38, Ian Campbell wrote: I'm afraid I don't know about the issue you are seeing but I can comment on one part: On Sun, 2013-03-17 at 15:02 +0100, Daniel Pocock wrote: while the output from dmesg suggests that the interface vif10.0 was created. It appears there is confusion between the vifX.Y and tapX.Y naming schemes. An HVM guest with a network device should get *both* vifX.Y and tapX.Y, they are kind of two faces of the same device. The tapX.Y is the emulated NIC (rtl8169 or e1000 or something) while the vifX.Y is the PV NIC which the guest can choose to switch over too (for increased perf etc) if it has a suitable driver (e.g. Linux PVHVM support, PV drivers for Windows etc etc). As to why tapX.Y cannot be added to a bridge, I've no idea, sorry. Are you using bridge or vswitch? Can you manually enslave the tap device to the bridge? I'm using Open vSwitch It halts the domU too quickly for me to try and manually add it to the bridge Do you have a wheezy environment where you can reproduce the problem and verify it is not just my system? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJRRgDzAAoJEOm1uwJp1aqDmkIP/1oQAT0/OGyusk7dNdePlgbc yUZkMCPaZ4+1oBpatcNIyQKqt89RWf4BNj20KepnRUmiqImBMDY8DPvVOsVHDvy5 leaWVJngAYl9RcEwn/+vyW05xYLUDNu+c00RKMIzWtJgcKOunUVuViSaXxDbAl/U 7gp4bWEepKgjmHxGOYnX5B/dmMDwNAPvbg5xMNpcnPxN9gy2ceYNAIBGTHHFZlOY Ov1wJku2N1EPQEfmYPsgthF2m+ll86PFkHqyDTmBo8+oat52s7vNEoXGlTbTTzL4 oPp24z2ccYkUCz9NgrN2rcWeXDJrWvjAbz+q6FWfckz1yB+DxlFjY6S6jgELZ4UA OPuVnGFXu55hM0RKWGTjCrcy+pvkoTG4O/k4TohV4T81hKAGDmTscjym+3f6Ix5W XM8zlMNtOq3KpEa9ZITSAg9CF8hWf+tVL/2j2Vv/U8pVka6e5EZiQmcuvlPyIfSl Y1MLz9oJ89O2LSBxu0Q4Rf92MXs58tfrR5SpTQBRSIeNd8S2Ez9uGJaHP/dDP3I2 9l909Kx+HphYfc5ULe8B8aYM7s039E4NhbNKZL0ztguMq8UkmfAGRxRW4J0RWdXT puokiE7j/EgAoAeeAE5Q83d4JIc72TB/i5gHHS5UOfKtGZUaG5h9qqUShIqGeVxz TaevGhz2/c/jJHD5aCgz =ucax -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702428: [Pkg-xen-devel] Bug#702428: HVM networking tap/vif bug (Debian bug 702428)
On Sun, 2013-03-17 at 18:44 +0100, Daniel Pocock wrote: On 17/03/13 18:38, Ian Campbell wrote: I'm afraid I don't know about the issue you are seeing but I can comment on one part: On Sun, 2013-03-17 at 15:02 +0100, Daniel Pocock wrote: while the output from dmesg suggests that the interface vif10.0 was created. It appears there is confusion between the vifX.Y and tapX.Y naming schemes. An HVM guest with a network device should get *both* vifX.Y and tapX.Y, they are kind of two faces of the same device. The tapX.Y is the emulated NIC (rtl8169 or e1000 or something) while the vifX.Y is the PV NIC which the guest can choose to switch over too (for increased perf etc) if it has a suitable driver (e.g. Linux PVHVM support, PV drivers for Windows etc etc). As to why tapX.Y cannot be added to a bridge, I've no idea, sorry. Are you using bridge or vswitch? Can you manually enslave the tap device to the bridge? I'm using Open vSwitch I wonder if something might be logged by ovs about why it is refusing this operation? I think OVS has pretty extensive logging capabilities too so you might be able to increase the verbosity. It halts the domU too quickly for me to try and manually add it to the bridge IIRC there are some VM metadata fields about what to do on crash, restart etc which you can set to things like preserve, reboot etc. You could try setting them to preserve and see if this class of error counts as a crash/restart etc. Do you have a wheezy environment where you can reproduce the problem and verify it is not just my system? Unfortunately not. -- Ian Campbell I B M U B M We all B M For I B M -- H.A.R.L.I.E. signature.asc Description: This is a digitally signed message part
