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

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

 



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 :)

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

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




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]