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

[Jim Fehlig]

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

>  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.

Regards,
Jim