[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.