On Fri, Aug 09, 2013 at 06:08:38PM +0200, Matthias Bolte wrote:
> 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.
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 :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list