[libvirt] [PATCH 1/2] libxl: Report connect type as Xen

[Jim Fehlig]

Michal Privoznik wrote:
> On 11.06.2013 16:12, Jim Fehlig wrote:
>   
>> Michal Privoznik wrote:
>>     
>>> On 10.06.2013 22:21, Jim Fehlig wrote:
>>>   
>>>       
>>>> Currently, the libxl driver reports a connection type of "xenlight".
>>>> To be compatible with the legacy Xen driver, it should return "Xen".
>>>>
>>>> Note: I noticed this while testing the libxl driver on OpenStack.
>>>> After switching my Xen compute nodes to use the libxl stack, I
>>>> could no longer launch instances on those nodes since
>>>> hypervisor_type was reported as "xenlight" instead of "xen".
>>>> ---
>>>>  src/libxl/libxl_driver.c |    2 +-
>>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
>>>> index 3990354..935919b 100644
>>>> --- a/src/libxl/libxl_driver.c
>>>> +++ b/src/libxl/libxl_driver.c
>>>> @@ -1405,7 +1405,7 @@ libxlConnectClose(virConnectPtr conn ATTRIBUTE_UNUSED)
>>>>  static const char *
>>>>  libxlConnectGetType(virConnectPtr conn ATTRIBUTE_UNUSED)
>>>>  {
>>>> -    return "xenlight";
>>>> +    return "Xen";
>>>>  }
>>>>  
>>>>  static int
>>>>
>>>>     
>>>>         
>>> I am not so convinced about this one. I think there exist some
>>> applications which want to distinguish between "Xen" and "xenlight".
>>>       
>> If that was the case, we would have went with a libxl:// URI.  In fact,
>> the original libxl driver patch introduced a libxl:// URI, but Daniel V.
>> pointed out that approach conflicted with libvirt's goal of minimizing
>> the impact on application stacks as the lower layers churn
>>
>> https://www.redhat.com/archives/libvir-list/2011-March/msg00449.html
>>     
>
> Right, you certainly got a point there. But I'd like to see DV's input
> in here then.
>
>   
>>>  If
>>> a application (like Openstack) doesn't want, nothing is easier than:
>>>
>>> type = virConnectGetType(conn);
>>> if (!strcmp(type, "Xen") || !strcmp(type, "xenlight")) {
>>>    DoTheMagic();
>>> } else {
>>>    ReportError("XEN not supported);
>>> }
>>>   
>>>       
>> Yes, but every app would have to do that, all because some lower layer
>> tool was reworked.
>>     
>
> It wasn't reworked. It's here from initial introduction of libxl :)
>   

I meant the reworking of xen tools, e.g. the replacement of xm/xend with
xl/libxl.  libvirt apps should be insulated from these types of
infrastructure changes at the lower levels.  I'd expect my libvirt apps
to continue working after a Xen upgrade, similar to how they continue to
work after installing a new qemu.

Regards,
Jim