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

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