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

[Joao Martins <joao.m.martins@xxxxxxxxxx>]

On 02/24/2016 04:31 AM, Jim Fehlig wrote:
> On 02/22/2016 04:15 PM, Joao Martins wrote:
>>
>> On 12/08/2015 04:06 PM, Jim Fehlig wrote:
>>> 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.
>>>
>> Hey Jim,
>>
>> I had the impression we had pushed this back in (i.e. cherry-picking d2e5538)
>> but I was double checking and that's doesn't seem to be case. In adding 
>> support
>> for the prefix in capabilities I found out one issue on the migration failure
>> path leading to dereferencing a NULL pointer on the destination. If you agree
>> could we squash the following chunk in addition to the cherry-pick of 
>> d2e5538:
>>
>> diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
>> index 63c5b24..f73bfb3 100644
>> --- a/src/libxl/libxl_domain.c
>> +++ b/src/libxl/libxl_domain.c
>> @@ -768,7 +768,7 @@ libxlDomainCleanup(libxlDriverPrivatePtr driver,
>>          for (i = 0; i < vm->def->nnets; i++) {
>>              virDomainNetDefPtr net = vm->def->nets[i];
>>
>> -            if (STRPREFIX(net->ifname, "vif"))
>> +            if (net->ifname && STRPREFIX(net->ifname, "vif"))
>>                  VIR_FREE(net->ifname);
>>          }
>>      }
>> diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
>> index 3f4457f..5479441 100644
>> --- a/src/libxl/libxl_driver.c
>> +++ b/src/libxl/libxl_driver.c
>> @@ -5590,7 +5590,7 @@ static virHypervisorDriver libxlHypervisorDriver = {
>>      .domainGetJobStats = libxlDomainGetJobStats, /* 1.3.1 */
>>      .domainMemoryStats = libxlDomainMemoryStats, /* 1.3.0 */
>>      .domainGetCPUStats = libxlDomainGetCPUStats, /* 1.3.0 */
>> -    .domainInterfaceStats = libxlDomainInterfaceStats, /* 1.3.0 */
>> +    .domainInterfaceStats = libxlDomainInterfaceStats, /* 1.3.2 */
>>      .connectDomainEventRegister = libxlConnectDomainEventRegister, /* 0.9.0 
>> */
>>      .connectDomainEventDeregister = libxlConnectDomainEventDeregister, /* 
>> 0.9.0 */
>>      .domainManagedSave = libxlDomainManagedSave, /* 0.9.2 */
>>
>>
>> Or do you think it should be deferred to 1.3.3 ?
> 
> I wanted to ask you about this on the recent Xen+libvirt+OpenStack sync. 
> Thanks
> for checking. It would be a shame if this patch didn't make 1.3.2 since all of
> your prerequisite work is in, but perhaps a new patch is best given the 
> changes?
> 
Yeap, I just sent a new patch with these changes.

Thanks!

Joao

> --
> libvir-list mailing list
> libvir-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/libvir-list
> 

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