[libvirt] Hyper-V driver API version support
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? Regards Rocco
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 -- |: 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 :|
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..
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
On Fri, Aug 09, 2013 at 06:08:38PM +0200, Matthias Bolte wrote:
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.
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 :|
2013/8/9 Daniel P. Berrange <berrange@redhat.com>:
On Fri, Aug 09, 2013 at 06:08:38PM +0200, Matthias Bolte wrote:
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.
What they really want, per the first mail, is for
virConnectGetVersion
to be implemented for hyper-v
I understood that :) But he doesn't actually need the version information, as far as I understood his problem. The point is to say hello to the Hyper-V server to see if it waves back indicating that it's still alive. My point is that a successful "virsh connect" already provides this aliveness information. Also there is virConnectIsAlive that is meant for this purpose, but it's not wired up directly as command in virsh. If one really insists on having more communication with the Hyper-V server then "virsh nodeinfo" can be used instead of the currently not implemented "virsh version" command for Hyper-V. If the version information is really necessary in this case then that can be implemented, but IIRC I didn't implemented this yet, because I hadn't figure out where in the WMI data the required version information is to be found. -- Matthias Bolte http://photron.blogspot.com
participants (3)
-
Daniel P. Berrange -
Matthias Bolte -
surface＠me.is-a-linux-user.org