Re: [Xen-devel] [libvirt] [FOR 1.3.0 PATCH] conf: add net device prefix for Xen

["Daniel P. Berrange" <berrange@xxxxxxxxxx>]

On Mon, Dec 07, 2015 at 10:59:32PM -0700, Jim Fehlig wrote:
> On 12/07/2015 11:52 AM, Daniel P. Berrange wrote:
> > On Mon, Dec 07, 2015 at 09:42:21AM -0700, Jim Fehlig wrote:
> >> In commit d2e5538b1, the libxl driver was changed to copy interface
> >> names autogenerated by libxl to the corresponding network def in the
> >> domain's virDomainDef object. The copied name is freed when the domain
> >> transitions to the shutoff state. But when migrating a domain, the
> >> autogenerated name is included in the XML sent to the destination host.
> >> It is possible an interface with the same name already exists on the
> >> destination host, causing migration to fail. Indeed the Xen project's
> >> OSSTEST CI already encountered such a failure.
> >>
> >> This patch defines another VIR_NET_GENERATED_PREFIX for Xen, allowing
> >> the autogenerated names to be excluded when parsing and formatting
> >> inactive config.
> >>
> >> Signed-off-by: Jim Fehlig <jfehlig@xxxxxxxx>
> >> ---
> >>
> >> This is an alternative approach to Joao's fix for this regression
> >>
> >> https://www.redhat.com/archives/libvir-list/2015-December/msg00197.html
> >>
> >> I think it is the same approach used by the qemu driver. My only
> >> reservation is that it expands the potential for clashes with
> >> user-defined names. I.e. with this change both 'vnet' and 'vif' are
> >> reserved prefixes.
> > Hmm, yes, tricky one.
> >
> > If we only care about XML parsing, then you could register a post
> > parse callback instead to do this.
> 
> AFAIK, XML parsing is all that's in play here.
> 
> > I'm not clear why we also have it in the virDomainNetDefFormat
> > method - and we can't solve that with a post-parse callback.
> >
> >
> > The other option would be to make the reserved prefix be a
> > capability that the parser/formatter could read.
> 
> This seems like the best option, since a post-parse callback doesn't solve the
> problem in virDomainNetDefFormat. It also has the upshot of making the prefix
> visible and known to users. But I doubt such a change is suitable during 1.3.0
> freeze.  With the freeze in mind, seems the best solution to the libxl 
> migration
> regression is revert d2e5538b1. It can be added again post-1.3.0 release, 
> after
> adding the prefix to capabilities.
> 
> DV, since you may be making the release soon, feel free to revert d2e5538b1 if
> you agree.

Yeah, just go ahead & revert it Jim,  DV isn't doing the releae until
tomorrow morning

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel