2013/8/9 <surface@xxxxxxxxxxxxxxxxxxxxxx>:
>> On Fri, Aug 09, 2013 at 10:13:03AM +0200, surface@xxxxxxxxxxxxxxxxxxxxxx
>> 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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list