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

Re: [libvirt] Hyper-V driver API version support



2013/8/9  <surface me is-a-linux-user org>:
>> On Fri, Aug 09, 2013 at 10:13:03AM +0200, surface 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.

-- 
Matthias Bolte
http://photron.blogspot.com


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