All of lore.kernel.org
 help / color / mirror / Atom feed
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [patch] xen udev rule interfering with openvpn
Date: Wed, 23 May 2012 22:54:40 +0800	[thread overview]
Message-ID: <CAEwRVpO-Vs3QTV8x04EN14=ZyAnjbchxyu=mP-qENNN+e2-utg@mail.gmail.com> (raw)
In-Reply-To: <CAEwRVpPu=8h-M30RO0J1OYg0e6ZR9QA_NTOogoh0M6dg_Yj-Zg@mail.gmail.com>

On Wed, May 23, 2012 at 9:04 PM, Teck Choon Giam
<giamteckchoon@gmail.com> wrote:
> On Wed, May 23, 2012 at 5:37 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> On Wed, 2012-05-23 at 03:22 +0100, Teck Choon Giam wrote:
>>
>>> >
>>> > I think the reason this effects xm and not xl is that libxl uses
>>> > script=none to disable qemu-ifup while xend does not and instead ends up
>>> > using qemu-ifup which does some fiddling with the device too, including
>>> > bringing it up.
>>>
>>> Ok, so default for xend is using script=qemu-ifup if script is not
>>> set?  Am I right about this?
>>
>> Yes.
>
> Thanks for clarifying.
>
>>
>>> > The proper fix is probably to change xend, I'm a bit wary of this,
>>> > especially for a 4.1 backport, but the following looks right and works
>>> > for me. It's a bit more complex since in libxl we seem to only do this
>>> > for Linux (i.e. not NetBSD) and I guess we should do the same in xend
>>> > too.
>>>
>>> Err... if we are going to change default behaviour will we be
>>> affecting those users who is upgrading from xen-4.1 to xen-4.2?
>>
>> This was already a deliberate change made in xl, it does not effect the
>> guest config, only the mechanisms by which that configuration is
>> achieved. I think extending this to xend in order not to break xend in
>> 4.2 is worthwhile.
>
> Noted.
>
>>
>> I don't think we should be backporting any of this to 4.1 though.
>
> You mean your tap to -emu patch series including the latest fix patch
> you posted shouldn't be backporting to 4.1?  If this is so, I am fine
> since there isn't much difference for me as personally I kept few
> custom patches in own xen packages.  Of course whatever get into
> upstream is better though :p

Just an update.  I have run my tests with your fix patch in
xen-unstable changeset 25386:340062faf298 and all are working fine.

Thanks again.

Kindest regards,
Giam Teck Choon


>
>>
>>> If your fix patch is going into xen-unstable for sure, I will re-run
>>> my tests by then.  I hope it doesn't affect current domUs
>>> configuration (I mean we shouldn't need to change domU configuration)
>>> especially when users prefer to use xm then xl in xen-4.2.
>>
>> There should be no guest config change necessary.
>
> Noted.
>
>>
>> Ian.
>
> Thanks for taking time to provide fix and responses.
>
> Kindest regards,
> Giam Teck Choon
>
>
>
>>
>>>
>>> Thanks.
>>>
>>> Kindest regards,
>>> Giam Teck Choon
>>>
>>>
>>> >
>>> > Ian
>>> >
>>> > # HG changeset patch
>>> > # User Ian Campbell <ian.campbell@citrix.com>
>>> > # Date 1337692747 -3600
>>> > # Node ID 426bbf58cea4559464b6e5d3ff0f65324a5f5926
>>> > # Parent  72ca5bc4eb6b91fa8dff51d439bd05f5586179df
>>> > xend: do not run a hotplug script from qemu on Linux
>>> >
>>> > The current vif-hotplug-common.sh for renaming the tap device is failing
>>> > because it is racing with this script and therefore the device is unexpectedly
>>> > up when we come to rename it.
>>> >
>>> > Fix this in the same way as libxl does, by disabling the script (only on
>>> > Linux).
>>> >
>>> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>>> >
>>> > diff -r 72ca5bc4eb6b -r 426bbf58cea4 tools/python/xen/xend/image.py
>>> > --- a/tools/python/xen/xend/image.py    Tue May 22 11:29:50 2012 +0100
>>> > +++ b/tools/python/xen/xend/image.py    Tue May 22 14:19:07 2012 +0100
>>> > @@ -919,8 +919,13 @@ class HVMImageHandler(ImageHandler):
>>> >                        (nics, mac, model))
>>> >             vifname = "vif%d.%d-emu" % (self.vm.getDomid(), nics-1)
>>> >             ret.append("-net")
>>> > -            ret.append("tap,vlan=%d,ifname=%s,bridge=%s" %
>>> > -                       (nics, vifname, bridge))
>>> > +            if osdep.tapif_script is not None:
>>> > +                script=",script=%s,downscript=%s" % \
>>> > +                        (osdep.tapif_script, osdep.tapif_script)
>>> > +            else:
>>> > +                script=""
>>> > +            ret.append("tap,vlan=%d,ifname=%s,bridge=%s%s" %
>>> > +                       (nics, vifname, bridge, script))
>>> >
>>> >         if nics == 0:
>>> >             ret.append("-net")
>>> > diff -r 72ca5bc4eb6b -r 426bbf58cea4 tools/python/xen/xend/osdep.py
>>> > --- a/tools/python/xen/xend/osdep.py    Tue May 22 11:29:50 2012 +0100
>>> > +++ b/tools/python/xen/xend/osdep.py    Tue May 22 14:19:07 2012 +0100
>>> > @@ -30,6 +30,10 @@ _vif_script = {
>>> >     "SunOS": "vif-vnic"
>>> >  }
>>> >
>>> > +_tapif_script = {
>>> > +    "Linux": "no",
>>> > +}
>>> > +
>>> >  PROC_XEN_BALLOON = '/proc/xen/balloon'
>>> >  SYSFS_XEN_MEMORY = '/sys/devices/system/xen_memory/xen_memory0'
>>> >
>>> > @@ -257,6 +261,7 @@ def _get(var, default=None):
>>> >
>>> >  xend_autorestart = _get(_xend_autorestart)
>>> >  vif_script = _get(_vif_script, "vif-bridge")
>>> > +tapif_script = _get(_tapif_script)
>>> >  lookup_balloon_stat = _get(_balloon_stat, _linux_balloon_stat)
>>> >  get_cpuinfo = _get(_get_cpuinfo, _linux_get_cpuinfo)
>>> >  prefork = _get(_get_prefork, _default_prefork)
>>> >
>>> >
>>
>>

  reply	other threads:[~2012-05-23 14:54 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-16 19:03 [patch] xen udev rule interfering with openvpn M A Young
2012-04-17 10:26 ` Ian Campbell
2012-04-17 13:08   ` Roger Pau Monne
2012-04-18 18:25   ` Teck Choon Giam
2012-04-19  6:39     ` Ian Campbell
2012-04-20  9:03       ` Ian Campbell
2012-04-20 10:38         ` Ian Jackson
2012-04-20 10:48           ` Ian Campbell
2012-04-20 10:55             ` Ian Jackson
2012-04-20 11:00               ` Ian Campbell
2012-04-20 11:04                 ` Ian Jackson
2012-04-20 13:21                   ` Ian Campbell
2012-04-20 15:26                     ` Teck Choon Giam
2012-04-20 15:38                       ` Ian Campbell
2012-04-20 16:34                         ` Teck Choon Giam
2012-04-25  9:59                   ` Ian Campbell
2012-04-25 10:11                     ` Ian Jackson
2012-04-25 10:14                       ` Ian Campbell
2012-04-25 12:58                         ` Ian Campbell
2012-04-25 13:16                           ` Roger Pau Monne
2012-04-25 13:38                             ` Ian Campbell
2012-05-11 14:53                           ` Ian Jackson
2012-05-11 23:53                             ` Teck Choon Giam
2012-05-12  7:29                               ` Teck Choon Giam
2012-05-12 22:00                                 ` Teck Choon Giam
2012-05-12 22:30                                   ` Ian Campbell
2012-05-12 23:37                                     ` Teck Choon Giam
2012-05-13  0:39                                       ` Teck Choon Giam
2012-05-21 12:31                                         ` Ian Campbell
2012-05-21 12:51                                           ` Teck Choon Giam
2012-05-21 13:04                                             ` Ian Campbell
2012-05-21 13:16                                               ` Teck Choon Giam
2012-05-22 13:19                                                 ` Ian Campbell
2012-05-23  2:22                                                   ` Teck Choon Giam
2012-05-23  9:37                                                     ` Ian Campbell
2012-05-23 13:04                                                       ` Teck Choon Giam
2012-05-23 14:54                                                         ` Teck Choon Giam [this message]
2012-05-21 12:24                                       ` Teck Choon Giam
2012-05-21 12:49                                         ` Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAEwRVpO-Vs3QTV8x04EN14=ZyAnjbchxyu=mP-qENNN+e2-utg@mail.gmail.com' \
    --to=giamteckchoon@gmail.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=m.a.young@durham.ac.uk \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.