On Wed, Jun 12, 2013 at 08:26:48AM -0600, Jim Fehlig wrote:
> 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>
My bad, indeed virConnectGetSysinfo is not the right call to carry
this. On the other hand virConnectGetCapabilities()
"Provides capabilities of the hypervisor / driver"
is the right API for this, since it returns XML we can extend the amount
of details without risk of incompatibilities. But that would also
requires some tweaking as it is all based on virCapabilitiesFormatXML()
which currently just dumps virCaps into a full capabilities block.
This could be extended by passing arguments about the driver type and
driver versions which the various drivers could pass (or ignore):
<capabilities driver="libxl" version="4.10">
<host>
....
</host>
<guest>
...
</guest>
</capabilities>
and have drivers where the informations are not available drop the
attributes.
That sounds one way to expose the informations without leading to the
problem exposed by OpenStack ...
Daniel
--
Daniel Veillard | Open Source and Standards, Red Hat
veillard@xxxxxxxxxx | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | virtualization library http://libvirt.org/
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list