Re: [Xen-users] xl and vifname

Re: [Xen-users] xl and vifname

[Pasi Kärkkäinen]

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

Re: [Xen-users] xl and vifname

[chris]

[-- Attachment #1.1: Type: text/plain, Size: 1825 bytes --]

+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
>

[-- Attachment #1.2: Type: text/html, Size: 2488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [Xen-users] xl and vifname

[Andy Smith]

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

Re: [Xen-users] xl and vifname

[Wei Liu]

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

Re: [Xen-users] xl and vifname

[Andy Smith]

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

Re: [Xen-users] xl and vifname

[Andy Smith]

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.

Re: [Xen-users] xl and vifname

[Wei Liu]

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.

Re: [Xen-users] xl and vifname

[Andy Smith]

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

Re: [Xen-users] xl and vifname

[Wei Liu]

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

Re: [Xen-users] xl and vifname

[Stefano Stabellini]

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.

Re: [Xen-users] xl and vifname

[Stefano Stabellini]

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!