Daniel Veillard wrote:
> On Tue, Jun 11, 2013 at 10:27:37AM -0600, Jim Fehlig wrote:
>
>> 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.
>>>
>
> Yes, the main service that libvirt provide for a given hypervisor
> stack is hide the inevitable changes that the evolution of the
> underlying technology implies. When the libxl driver was introduced
> it was then normal to try to minimize the impact on existing Xen users,
> and I still think that's the right approach, especially if there have
> been report of breakages in the field.
> If we really want to expose a way to differenciate a xen from libxl
> (or future) then virConnectGetSysinfo which is a structured kind of
> reply is a better way to carry this. virConnectGetType is better left
> undifferencied in those cases.
>
> So to me ACK to the patch. Jim if you have the evironment to test
> both it might be interesting to compare the 2 outputs returned from
> virConnectGetSysinfo and see if infrastructure code can still make a
> difference from both environment with it.
>
Unfortunately, connectGetSysinfo is not implemented in the legacy xen or
libxl drivers :(. I created a trivial patch for the libxl driver based
on the qemu impl, but as expected only get the smbios info provided by
virSysinfoRead(), which doesn't include anything to differentiate
between libxl vs old xen toolstack.
Daniel, I too would like a way for users to know if their libvirt is
talking to libxl or the old toolstack, and would like to explore your
virConnectGetSysinfo() suggestion. Currently, virConnectGetSysinfo()
returns a bunch of smbios info within <sysinfo type='smbios'> ...
</sysinfo>. Adding some info about which hypervisor toolstack is in use
under the smbios sysinfo doesn't seem right, since it really isn't
smbios info. Were you thinking of augmenting the current info with
something like
<sysinfo type='hypervisor'>
<version>x.y.z</version>
<api>libxl 4.2.x</api>
...
</sysinfo>
Regards,
Jim
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list