Hello, While using xen 4.1-testing.hg (r23202) I noticed that the ''vifname'' config value is not handled by xl, but is handled by xm. Is there a workaround or patch for this? My firewall and scripts depend on static vifnames. XM works good - it adds multiple interfaces to multiple bridges and configures them appropriately. But with xl it differs -- here only tap devices are added to a bridge instead of the interface pairs. The tap devices /can/ be added to multiple bridges, so that''s a good start. Example of a use case: * dom0 has bridge br0, br1, br2, br3. * the (HVM) configuration contains this vif configuration: vif = [ ''script=vif-bridge, vifname=foo0, mac=00:16:3e:00:00:00, bridge=br0, model=e1000, type=ioemu'', ''script=vif-bridge, vifname=foo1, mac=00:16:3e:00:00:01, bridge=br1, model=e1000, type=ioemu'', ''script=vif-bridge, vifname=foo2, mac=00:16:3e:00:00:02, bridge=br2, model=e1000, type=ioemu'', ''script=vif-bridge, vifname=foo3, mac=00:16:3e:00:00:03, bridge=br3, model=e1000, type=ioemu'', ] (^note: in the past vifnames did work when an entry contained something like ''script=vif-bridge vifname=foo0'' i.e. without the comma. But this works no longer) * xl start creates these interfaces, ignoring vifname: * * vif53.0, vif53.1, vif53.2, vif53.3 * * tap53.0, tap53.1, tap53.2, tap53.3 * tap53.0 - tap53.3 are added to br0 - br3 and are upped; * vif53.0 - vif53.3 are not added to the bridge and are /not/ upped; * the domU host does show me the correct mac addresses. A paravirtualised linux domU shows me the same scenario. And to reiterate: this behaviour /only/ happens when I use xl. With xm everything works as I want it to. Excuse me for the above line length of 105 chars, it improved readability unless mailman or something else rewraps the lines. Thanks for helping, - Mark.
Hi, 2011/12/17 <mark@internecto.net>:> While using xen 4.1-testing.hg (r23202) I noticed that the ''vifname'' > config value is not handled by xl, but is handled by xm. Is there a > workaround or patch for this? My firewall and scripts depend on static > vifnames.xl does not support vifname as of now. Except for one type of HVM domU, where it does support vifname. You might want to communicate to xen-devel that you rely on it and all that. I also think I need vifname support - it''s unbearable to work without vifnames if you run a setup with potentially many 100 vifs + vlans + brides + bonds. (I guess thats how the whole UUID disaster in XenServer happened) I said "think I need" because I DO rely on them, but maybe something happens that makes me suddenly understand that it''s better to script against some API to get the information reliably without any problem by changing domIDs and always being up-to-date. Oh wait, that would be like setting vifname and just looking at the ifconfig output :) Florian -- the purpose of libvirt is to provide an abstraction layer hiding all xen features added since 2006 until they were finally understood and copied by the kvm devs.
On Mon, Dec 19, 2011 at 12:57:43PM +0100, Florian Heigl wrote:> Hi, >Hello,> 2011/12/17 <mark@internecto.net>: > > While using xen 4.1-testing.hg (r23202) I noticed that the ''vifname'' > > config value is not handled by xl, but is handled by xm. Is there a > > workaround or patch for this? My firewall and scripts depend on static > > vifnames. > > xl does not support vifname as of now. > Except for one type of HVM domU, where it does support vifname. > > You might want to communicate to xen-devel that you rely on it and all that. >Added xen-devel to CC list ..> I also think I need vifname support - it''s unbearable to work without > vifnames if you run a setup with potentially many 100 vifs + vlans + > brides + bonds. > (I guess thats how the whole UUID disaster in XenServer happened) > > I said "think I need" because I DO rely on them, but maybe something > happens that makes me suddenly understand that it''s better to script > against some API to get the information reliably without any problem > by changing domIDs and always being up-to-date. > Oh wait, that would be like setting vifname and just looking at the > ifconfig output :) > > > Florian > > -- > the purpose of libvirt is to provide an abstraction layer hiding all > xen features added since 2006 until they were finally understood and > copied by the kvm devs. >-- Pasi
+1 to using vifname pretty heavily, sure you can get the job done without but why suffer needlessly? :) On Wed, Dec 28, 2011 at 6:19 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:> On Mon, Dec 19, 2011 at 12:57:43PM +0100, Florian Heigl wrote: > > Hi, > > > > Hello, > > > 2011/12/17 <mark@internecto.net>: > > > While using xen 4.1-testing.hg (r23202) I noticed that the ''vifname'' > > > config value is not handled by xl, but is handled by xm. Is there a > > > workaround or patch for this? My firewall and scripts depend on static > > > vifnames. > > > > xl does not support vifname as of now. > > Except for one type of HVM domU, where it does support vifname. > > > > You might want to communicate to xen-devel that you rely on it and all > that. > > > > Added xen-devel to CC list .. > > > I also think I need vifname support - it''s unbearable to work without > > vifnames if you run a setup with potentially many 100 vifs + vlans + > > brides + bonds. > > (I guess thats how the whole UUID disaster in XenServer happened) > > > > I said "think I need" because I DO rely on them, but maybe something > > happens that makes me suddenly understand that it''s better to script > > against some API to get the information reliably without any problem > > by changing domIDs and always being up-to-date. > > Oh wait, that would be like setting vifname and just looking at the > > ifconfig output :) > > > > > > Florian > > > > -- > > the purpose of libvirt is to provide an abstraction layer hiding all > > xen features added since 2006 until they were finally understood and > > copied by the kvm devs. > > > > -- Pasi > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hello, On Wed, Dec 28, 2011 at 01:19:18PM +0200, Pasi Kärkkäinen wrote:> On Mon, Dec 19, 2011 at 12:57:43PM +0100, Florian Heigl wrote: > > xl does not support vifname as of now. > > Except for one type of HVM domU, where it does support vifname. > > > > You might want to communicate to xen-devel that you rely on it and all that.Ditto here, being able to give a vif a specific name is required. Cheers, Andy
On Wed, 2011-12-28 at 14:31 +0000, Andy Smith wrote:> Hello, > > On Wed, Dec 28, 2011 at 01:19:18PM +0200, Pasi Kärkkäinen wrote: > > On Mon, Dec 19, 2011 at 12:57:43PM +0100, Florian Heigl wrote: > > > xl does not support vifname as of now. > > > Except for one type of HVM domU, where it does support vifname. > > > > > > You might want to communicate to xen-devel that you rely on it and all that. > > Ditto here, being able to give a vif a specific name is required.I'm a bit confused. xl parses 'vif' names for both HVM and PV guest. I think you're using QEMU as network backend when you run HVM guest? Well if backend is netback, the vif name is hardcoded as "vif%d.%d" -- see $KERNEL/drivers/net/xen-netback/interface.c:xenvif_alloc. xl has nothing to do with this because the creation of vif is automatically done when FE connects to BE. A possible solution is that we write user-specified vifname in xenstore entry then BE retrieve the value and use the value as vif name. Wei. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi Wei, On Wed, Dec 28, 2011 at 03:02:12PM +0000, Wei Liu wrote:> On Wed, 2011-12-28 at 14:31 +0000, Andy Smith wrote: > > Ditto here, being able to give a vif a specific name is required. > > I''m a bit confused. xl parses ''vif'' names for both HVM and PV guest. I > think you''re using QEMU as network backend when you run HVM guest? > > Well if backend is netback, the vif name is hardcoded as "vif%d.%d" -- > see $KERNEL/drivers/net/xen-netback/interface.c:xenvif_alloc. xl has > nothing to do with this because the creation of vif is automatically > done when FE connects to BE.I haven''t followed the thread; I just saw it here on xen-devel that: "You might want to communicate to xen-devel that you rely on [vifname support]" Currently we use xm and xend, specify vifname in the PV guest''s config in order to get a dom0 network interface of a given name. That functionality is required for us. If I misunderstood then I apologise; it seemed that it was being indicated that this functionality didn''t exist with xm and there were no plans to provide it. Cheers, Andy
On Wed, Dec 28, 2011 at 03:10:54PM +0000, Andy Smith wrote:> If I misunderstood then I apologise; it seemed that it was being > indicated that this functionality didn''t exist with xm and there^^xl> were no plans to provide it.sigh. :) Cheers, Andy, nursing a post Christmas cold.
On Wed, 2011-12-28 at 15:10 +0000, Andy Smith wrote:> Hi Wei, > > On Wed, Dec 28, 2011 at 03:02:12PM +0000, Wei Liu wrote: > > On Wed, 2011-12-28 at 14:31 +0000, Andy Smith wrote: > > > Ditto here, being able to give a vif a specific name is required. > > > > I''m a bit confused. xl parses ''vif'' names for both HVM and PV guest. I > > think you''re using QEMU as network backend when you run HVM guest? > > > > Well if backend is netback, the vif name is hardcoded as "vif%d.%d" -- > > see $KERNEL/drivers/net/xen-netback/interface.c:xenvif_alloc. xl has > > nothing to do with this because the creation of vif is automatically > > done when FE connects to BE. > > I haven''t followed the thread; I just saw it here on xen-devel that: > > "You might want to communicate to xen-devel that you rely on > [vifname support]" > > Currently we use xm and xend, specify vifname in the PV guest''s > config in order to get a dom0 network interface of a given name. > That functionality is required for us. >(Well I''m not very familiar with xm code.) Does xm serve your purpose -- specifying dom0 network interface of a given name (rather then using vifX.X)? If it can serve you purpose, can you verify which network backend you are using by running following command: $ ps aux | egrep ''(qemu|net)'' If you get qemu-dm in the result, you''re running QEMU. If you get netback/0 in the result, you''re running netback. If you''re running netback and you can use you preferred name for the interface, then a similar fix for xl should be possible.> If I misunderstood then I apologise; it seemed that it was being > indicated that this functionality didn''t exist with xm and there > were no plans to provide it. >I guess "xm" should be "xl". :) I''m not a toolstack maintainer, I''m only trying to help. Maybe we can wait for a proper answer from the maintainer. Wei.
Hi Wei, On Wed, Dec 28, 2011 at 03:25:57PM +0000, Wei Liu wrote:> Does xm serve your purpose -- specifying dom0 network interface of a > given name (rather then using vifX.X)?Yes. We need to statically configure the vif names in order to have them be the same every time, and to know which virtual machine configuration they belong to. Not have them change every time the VM is restarted. (Yes I am aware that it would be possible to translate the vifX.Y string into a domU name and go from there, but that adds a lot of complexity)> If it can serve you purpose, can you verify which network backend you > are using by running following command: > > $ ps aux | egrep ''(qemu|net)''This didn''t match anything. These are PV domUs and there isn''t a process in dom0 for each domU''s netback. This is 4.0.1 on Debian stable.> If you''re running netback and you can use you preferred name for the > interface, then a similar fix for xl should be possible.Something like: vif = [ "mac=00:16:3e:8e:ac:0a, ip=192.168.82.198, vifname=vm-85" ] has worked for us for ~5 years through Xen 3.x and 4.x. Cheers, Andy
On Wed, 2011-12-28 at 15:37 +0000, Andy Smith wrote:> Hi Wei, > > On Wed, Dec 28, 2011 at 03:25:57PM +0000, Wei Liu wrote: > > Does xm serve your purpose -- specifying dom0 network interface of a > > given name (rather then using vifX.X)? > > Yes. We need to statically configure the vif names in order to have > them be the same every time, and to know which virtual machine > configuration they belong to. Not have them change every time the VM > is restarted. > > (Yes I am aware that it would be possible to translate the vifX.Y > string into a domU name and go from there, but that adds a lot of > complexity) > > > If it can serve you purpose, can you verify which network backend you > > are using by running following command: > > > > $ ps aux | egrep ''(qemu|net)'' > > This didn''t match anything. These are PV domUs and there isn''t a > process in dom0 for each domU''s netback. This is 4.0.1 on Debian > stable. >What''s your dom0 kernel version? The newer kernel (2.6.32 3.X) should have something like netback/0. However, historical kernel doesn''t have that. Hmm... Maybe I misunderstood something here. I skimmed code from 2.6.18 to 3.0, it all hardcodes vif names. Maybe the toolstack alters interface name after creation. I will spend some time on this and get back to you later.> > If you''re running netback and you can use you preferred name for the > > interface, then a similar fix for xl should be possible. > > Something like: > > vif = [ "mac=00:16:3e:8e:ac:0a, ip=192.168.82.198, vifname=vm-85" ] > > has worked for us for ~5 years through Xen 3.x and 4.x. >Alright, got it. Wei.> Cheers, > Andy > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel
On Wed, 28 Dec 2011, Wei Liu wrote:> On Wed, 2011-12-28 at 15:37 +0000, Andy Smith wrote: > > Hi Wei, > > > > On Wed, Dec 28, 2011 at 03:25:57PM +0000, Wei Liu wrote: > > > Does xm serve your purpose -- specifying dom0 network interface of a > > > given name (rather then using vifX.X)? > > > > Yes. We need to statically configure the vif names in order to have > > them be the same every time, and to know which virtual machine > > configuration they belong to. Not have them change every time the VM > > is restarted. > > > > (Yes I am aware that it would be possible to translate the vifX.Y > > string into a domU name and go from there, but that adds a lot of > > complexity) > > > > > If it can serve you purpose, can you verify which network backend you > > > are using by running following command: > > > > > > $ ps aux | egrep ''(qemu|net)'' > > > > This didn''t match anything. These are PV domUs and there isn''t a > > process in dom0 for each domU''s netback. This is 4.0.1 on Debian > > stable. > > > > What''s your dom0 kernel version? The newer kernel (2.6.32 3.X) should > have something like netback/0. However, historical kernel doesn''t have > that. > > Hmm... Maybe I misunderstood something here. I skimmed code from 2.6.18 > to 3.0, it all hardcodes vif names. Maybe the toolstack alters interface > name after creation. > > I will spend some time on this and get back to you later.My guess is that xend used to write a "vifname" node on xenstore in the network backend path with the name of the vif, and the 2.8.16 netback would set the vif name based on that. However you are right saying that modern pvops kernels are unable to do it. I think there is no harm in writing the vifname node to xenstore in libxl, that should solve the problem.> > > If you''re running netback and you can use you preferred name for the > > > interface, then a similar fix for xl should be possible. > > > > Something like: > > > > vif = [ "mac=00:16:3e:8e:ac:0a, ip=192.168.82.198, vifname=vm-85" ] > > > > has worked for us for ~5 years through Xen 3.x and 4.x. > > > > Alright, got it.
On Thu, 5 Jan 2012, Stefano Stabellini wrote:> My guess is that xend used to write a "vifname" node on xenstore in the > network backend path with the name of the vif, and the 2.8.16 netback > would set the vif name based on that. > However you are right saying that modern pvops kernels are unable to do > it. > I think there is no harm in writing the vifname node to xenstore in > libxl, that should solve the problem.Oops, I have just seen that you have fixed this already!