[libvirt] Hyper-V driver API version support

[Daniel P. Berrange]

On Fri, Aug 09, 2013 at 06:08:38PM +0200, Matthias Bolte wrote:
> 2013/8/9  <surface at me.is-a-linux-user.org>:
> >> On Fri, Aug 09, 2013 at 10:13:03AM +0200, surface at me.is-a-linux-user.org
> >> wrote:
> >>>
> >>> Hello
> >>>
> >>> The "version" function is not supported by the hyperv driver:
> >>> $ virsh --connect=hyperv://hypervhost version
> >>> Compiled against library: libvirt 1.1.1
> >>> Using library: libvirt 1.1.1
> >>> Using API: Hyper-V 1.1.1
> >>> error: failed to get the hypervisor version
> >>> error: this function is not supported by the connection driver:
> >>> virConnectGetVersion
> >>>
> >>> But we need this funtion for the "external/libvirt" stonith plugin
> >>> of clusterglue:
> >>>
> >>> $ cat /usr/lib/stonith/plugins/libvirt | more
> >>> # get status of stonith device (*NOT* of the domain).
> >>> # If we can retrieve some info from the hypervisor
> >>> # the stonith device is OK.
> >>> libvirt_status() {
> >>>     out=$($VIRSH -c $hypervisor_uri version 2>&1)
> >>>     if [ $? -eq 0 ]
> >>>     then
> >>>         out=`echo "$out" | tail -1`
> >>>         ha_log.sh notice "$hypervisor_uri: $out"
> >>>         return 0
> >>>     fi
> >>>
> >>>     ha_log.sh err "Failed to get status for $hypervisor_uri"
> >>>     ha_log.sh err "$out"
> >>>     return 1
> >>> }
> >>>
> >>> So, we can't implement libvirt stonith with hyperv support in our
> >>> corosync/pacemaker cluster. Is it possible to implement the
> >>> "version" function for hyperv into virConnectGetVersion? Or exist
> >>> any workaround for this problem?
> >>
> >>
> >> I'm sure its possible, but it needs someone with knowledge of the
> >> Hyper-V apis to write a patch and there's only a couple of people
> >> in libvirt comunity who can do that. Patches welcome from any able
> >> person...
> >>
> >> Daniel
> >
> >
> > Hi Daniel
> >
> > I don't know which api is used for the driver handling, maybe you mean this
> > one here: http://msdn.microsoft.com/en-us/library/aa155227.aspx
> >
> > I tested the following command on our micro$oft server:
> > PS C:\Users\administrator> gwmi -namespace "root\virtualization"
> > Msvm_VirtualSystemManagementService
> >
> >
> > __GENUS                 : 2
> > __CLASS                 : Msvm_VirtualSystemManagementService
> > __SUPERCLASS            : CIM_VirtualSystemManagementService
> > __DYNASTY               : CIM_ManagedElement
> > __RELPATH               :
> > Msvm_VirtualSystemManagementService.CreationClassName="Msvm_VirtualSystemManagementService",N
> >
> > ame="vmms",SystemCreationClassName="Msvm_ComputerSystem",SystemName="VSRV1"
> > __PROPERTY_COUNT        : 21
> > __DERIVATION            : {CIM_VirtualSystemManagementService, CIM_Service,
> > CIM_EnabledLogicalElement,
> >                           CIM_LogicalElement...}
> > __SERVER                : VSRV1
> > __NAMESPACE             : root\virtualization
> > __PATH                  :
> > \\VSRV1\root\virtualization:Msvm_VirtualSystemManagementService.CreationClassName="Msvm_
> >
> > VirtualSystemManagementService",Name="vmms",SystemCreationClassName="Msvm_ComputerSystem",Sys
> >                           temName="VSRV1"
> > Caption                 : Hyper-V Virtual System Management Service
> > CreationClassName       : Msvm_VirtualSystemManagementService
> > Description             : Service for creating, manipulating, and managing
> > virtual systems
> > ElementName             : Hyper-V Virtual System Management Service
> > EnabledDefault          : 2
> > EnabledState            : 2
> > HealthState             : 5
> > InstallDate             : 20130717120539.000000-000
> > Name                    : vmms
> > OperationalStatus       : {2}
> > OtherEnabledState       :
> > PrimaryOwnerContact     :
> > PrimaryOwnerName        :
> > RequestedState          : 12
> > Started                 : True
> > StartMode               :
> > Status                  : OK
> > StatusDescriptions      : {The service is running normally}
> > SystemCreationClassName : Msvm_ComputerSystem
> > SystemName              : VSRV1
> > TimeOfLastStateChange   : 20130801095437.000000-000
> > PSComputerName          : VSRV1
> >
> > so I think we can query the state like this:
> > PS C:\Users\administrator> gwmi -namespace "root\virtualization"
> > Msvm_VirtualSystemManagementService | select Status
> >
> >
> > Status
> > ------
> > OK
> >
> > It's not the version, but we need something to let libvirt stonith know,
> > that the stonith device can connect to hyperv and the hyperv service is
> > running..
> 
> The Hyper-V driver in libvirt already checks if the host has the
> Hyper-V role installed on connect. It does this by checking for the
> existance of an Msvm_ComputerSystem object, if there is non then
> "virsh connect" fails. This means if "virsh connect" succeeds then the
> URI you specified points to an Hyper-V server. No need to abuse the
> version command for such a check.
> 
> If you think that it is useful to check that an
> Msvm_VirtualSystemManagementService object exists on the host then
> this could be done in addition to the existing checks.

What they really want, per the first mail, is for 

  virConnectGetVersion

to be implemented for hyper-v

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|