Daniel P. Berrange wrote: > 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 I've pushed the revert. Joao, sorry for yanking this for 1.3.0. We can get it in 1.3.1, after exposing the prefix in capabilities. Regards, Jim -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list