Re: [patch] xen udev rule interfering with openvpn

[Ian Campbell <Ian.Campbell@citrix.com>]

On Sun, 2012-05-13 at 01:39 +0100, Teck Choon Giam wrote:
> On Sun, May 13, 2012 at 7:37 AM, Teck Choon Giam
> <giamteckchoon@gmail.com> wrote:
> > On Sun, May 13, 2012 at 6:30 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> On Sat, 2012-05-12 at 23:00 +0100, Teck Choon Giam wrote:
> >>> On Sat, May 12, 2012 at 3:29 PM, Teck Choon Giam
> >>> <giamteckchoon@gmail.com> wrote:
> >>> > On Sat, May 12, 2012 at 7:53 AM, Teck Choon Giam
> >>> > <giamteckchoon@gmail.com> wrote:
> >>> >> On Fri, May 11, 2012 at 10:53 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> >>> >>> Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering with openvpn"):
> >>> >>>> libxl/xend: name tap devices vifX.Y-emu
> >>> >>>
> >>> >>> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
> >>> >>
> >>> >> This is my backport version which excludes the following:
> >>> >>
> >>> >> Lastly also move libxl__device_* to a better place in the header, otherwise the
> >>> >> comment about evgen stuff isn't next to the associated functions (noticed jsut
> >>> >> because I was going to add nic_devname near to the setdefault functions)
> >>> >>
> >>> >> I have tested with xm and xl with and without vifname set in domU
> >>> >> config for hvmdomain and pvdomain.
> >>> >
> >>> > Sorry, when re-test one of the test case failed... xm create hvmdomain
> >>> > with vifname set.  I must have missed certain test case :(
> >>>
> >>> The same test case failed for xen unstable latest changeset 25326:cd4dd23a831d.
> >>
> >> Oh dear.
> >>
> >>> My tests as below:
> >>
> >> Which ones fail?
> >>
> >>> 1. xm create pvdomain without vifname set
> >>> 2. xl create pvdomain without vifname set
> >>> 3. xm create hvmdomain without vifname set
> >>> 4. xl create hvmdomain without vifname set
> >>> 5. xm create pvdomain with vifname set
> >>> 6. xl create pvdomain with vifname set
> >>> 7. xm create hvmdomain with vifname set
> >
> > xm create hvmdomain with vifname set
> >
> >
> > I track down the problem already.  It happens that xm and xl behave
> > differently when creating $dev device?
> >
> > In short, just set $dev down before:
> > do_or_die ip link set "$dev" name "$vifname"
> > Then set $vifname up after the above fix my problem.
> >
> > Is the above suitable in upstream/unstable?  If yes, can you fix that
> > in xen-unstable or you need me to submit a patch for review for
> > xen-unstable?
> >
> > With the below partial of my latest backport patch fix the problem but
> > I have to re-run all tests to double confirm all are fix and good to
> > go :p
> 
> Attached is my final backport for xen-4.1-testing which passed all my
> tests as stated below:
> 
> 1. xm create pvdomain without vifname set
> 2. xl create pvdomain without vifname set
> 3. xm create hvmdomain without vifname set
> 4. xl create hvmdomain without vifname set
> 5. xm create pvdomain with vifname set
> 6. xl create pvdomain with vifname set
> 7. xm create hvmdomain with vifname set
> 8. xl create hvmdomain with vifname set
> 
> My initial backport patch failed for test no. 7 and when I perform
> test for all the above in latest xen-unstable it failed in test no. 7
> as well.

OK, can we concentrate on the xen-unstable failure first, hopefully
addressing that will naturally fix 4.1 too but I don't wan't to get
confused between the two.

How does case #7 fail? Do you get both devices created but not placed on
the bridge or something else?

What names do the devices end up with? ("ifconfig -a", while guest is
running, "brctl show" also useful)

What is the qemu command line? (from ps, while guest is running)

What is the name in xenstore? ("xenstore-ls -fp", again while guest is
running)

Thanks, sorry for the delay in responding to this one.

Ian.