Re: [libvirt] libvirt Hyper-v 2012 r2 fix
Bringing the discussion back online... Okay so figured out what was going on (to see what the actual error was, please read the latest email in the conversation). Classes in hyperv/hyperv_wmi_generator.input a) Msvm_MemorySettingData b) Msvm_ProcessorSettingData c) Msvm_VirtualSystemSettingData Have been upgraded to the definitions found at the new v2 doc http://msdn.microsoft.com/en-us/library/hh850176(v=vs.85).aspx, I put in this note at the beginning of the hyperv/hyperv_wmi_generator.input file. With these changes and a few other minor ones, I can confirm that the functionality mimics the hyperv 2008 version. That is, we get the same functionality (supported vs non-supported drivers). However, this might also mean the end of support of Hyper-V 2008 if it is just a replace of the existing classes. What do you guys think? Should we continue to support 2008 (~6 years old) OR is it OK to assume that Hyperv-V 2012 will be the default standard moving forward. Thanks, Vik. On Wed, Apr 16, 2014 at 10:23 AM, vikhyath reddy <reddy.vikhyath@gmail.com>wrote:
Taking this offline...
Hi Matthias,
Well... from more testing what I found is that openwsman breaks during serialization.
When I run against hyper-v 2012 r2
---------------------------------------------
virsh # list --all
*1984 testing-1 running* ---------------------------------------------
virsh # dumpxml testing-1
*2014-04-16 16:53:54.049+0000: 10693: info : libvirt version: 1.2.3*
*2014-04-16 16:53:54.049+0000: 10693: error : hypervDebugHandler:1403 : openwsman error: not enough (0 < 1) instances of element SystemName*
*2014-04-16 16:53:54.049+0000: 10693: error : hypervDebugHandler:1403 : openwsman error: handling of element "**SystemName**" failed = -3*
*2014-04-16 16:53:54.049+0000: 10693: error : hypervDebugHandler:1403 : openwsman error: size of 1 structures "Msvm_VirtualSystemSettingData" exceeds stopper (0x7fb86a4c5d18 > (nil))*
*2014-04-16 16:53:54.049+0000: 10693: error : hypervDebugHandler:1403 : openwsman error: Error during serialization*
*error: internal error: Could not deserialize pull response item*
*-------------------------------------------------*
I was also looking at http://www.redhat.com/archives/libvir-list/2011-July/msg00768.html and found that you submitted a patch. It looks like from class
class Msvm_VirtualSystemSettingData
property *SystemName*
is being returned NULL or is is non existent in the pull response. Any pointers as to how can I check what is being returned in the pull response (if any)?
Thanks!
Vik.
On Wed, Apr 16, 2014 at 1:35 AM, Matthias Bolte < matthias.bolte@googlemail.com> wrote:
Update,
I tried adding root\virtualization\v2 to the namespace in libvirt source code for hyperv. I ran some tests and it seems to work. I get the same functionality (supported vs non-supported drivers) as hyper-v 2008.
Do you guys want me to submit the patch? If yes, what all do I need to update to get the patch in?
Thanks, Vik.
On Tue, Apr 15, 2014 at 5:26 PM, vikhyath reddy < reddy.vikhyath@gmail.com> wrote:
Hello everyone,
Thanks for libvirt. I did see on the libvirt page that hyper-v 2008 is supported (which it does). So I tried running it on Hyper-v 2012 r2 but virsh fails to connect by an error that says
"error: internal error: SOAP fault during enumeration: code 's:Sender', subcode 'n:CannotProcessFilter', reason 'The data source could not
the filter. The filter might be missing or it might be invalid. Change
filter and try the request again. ', detail '500The specified class does not exist in the given namespace. HRESULT 0x8033801a0052150858778HRESULTThe specified class does not exist in the given namespace. ' "
Upon looking into the Hyper-v 2012 r2 server event logs, I found that
2014-04-16 3:26 GMT+02:00 vikhyath reddy <reddy.vikhyath@gmail.com>: process the this
is going on
[ Source: WMI-Activity Event ID: 5898 Microsoft-Windows-WMI-Activity/Operational ]
Id = {62D480B2-58EF-0000-E580-D462EF58CF01}; ClientMachine = VIKHYPERV; User = VIKHYPERV\Administrator; ClientProcessId = 884; Component = Unknown; Operation = Start IWbemServices::ExecQuery - root\virtualization : select * from Msvm_ComputerSystem where Description = "Microsoft Hosting Computer System" ; ResultCode = 0x80041010; PossibleCause = Unknown
Note that Msvm_ComputerSystem is missing in the namespace root\virtualization. Upon further investigation, I found that the new namespace where Msvm_ComputerSystem is located is at root\virtualization\v2
Is (it possible?) there some way I can know where in the source code, libvirt is specifying the namespace so that I can try patching it up and see if it fixes things?
Thanks for all your help, Vik.
Yes, send a patch for this.
To get your patch in, you need to send it to this list for review. After a successful review it'll be pushed to the git repo by someone with commit access.
See http://libvirt.org/hacking.html for more details about working on the source and submitting patches.
-- Matthias Bolte http://photron.blogspot.com
On 04/16/2014 05:51 PM, vikhyath reddy wrote:
With these changes and a few other minor ones, I can confirm that the functionality mimics the hyperv 2008 version. That is, we get the same functionality (supported vs non-supported drivers).
However, this might also mean the end of support of Hyper-V 2008 if it is just a replace of the existing classes. What do you guys think? Should we continue to support 2008 (~6 years old) OR is it OK to assume that Hyperv-V 2012 will be the default standard moving forward.
At least for qemu and xen, we try hard to support any version of a hypervisor that is still actively supported by at least one vendor (that is, RHEL 5 is our current limit of how far back we try and support). On the other hand, free software is somewhat easier to support than proprietary software (we have access to the source code, and can make decisions about how to work around old constructs or even see how newer versions changed in relation to older versions - a luxury not available when targetting something where only the interface is public but the source code is hidden). I'm not sure how far back Microsoft supports old versions of Hyper-V, especially given the recent media attention to the fact that they explicitly no longer support Windows XP. Although Hyper-V 2008 is 6 years old, if it is still actively supported (where I could buy a license today and still get support for the product), then libvirt should still consider targetting it. On the other hand, patches speak louder than words - anyone interested enough to actually post a patch, even if it actively excludes an older version of the hypervisor, has more clout than someone like me that has never even used Hyper-V :) So I guess that means it is your call on whether it is easier to drop support for old versions for the sake of making maintenance easier. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
From what I have seen, Microsoft supports hyperv 2008 management via windows 7 and hyperv 2012 via windows 8.1 (note that the reverse is not
*At least for qemu and xen, we try hard to support any version of a hypervisor that is still actively supported by at least one vendor (thatis, RHEL 5 is our current limit of how far back we try and support). On the other hand, free software is somewhat easier to support thanproprietary software (we have access to the source code, and can make decisions about how to work around old constructs or even see how newerversions changed in relation to older versions - a luxury not available when targetting something where only the interface is public but thesource code is hidden). I'm not sure how far back Microsoft supports old versions of Hyper-V,especially given the recent media attention to the fact that they explicitly no longer support Windows XP. Although Hyper-V 2008 is 6years old, if it is still actively supported (where I could buy a license today and still get support for the product), then libvirtshould still consider targetting it. On the other hand, patches speak louder than words - anyone interested enough to actually post a patch,even if it actively excludes an older version of the hypervisor, has more clout than someone like me that has never even used Hyper-V :) SoI guess that means it is your call on whether it is easier to drop **support for old versions for the sake of making maintenance easier.* true, that is, win 7 cannot manage hyperv 2012 and win 8.1 cannot manage hyperv 2008). I *think* they wanted to keep the application code separate, in the sense that one manages the old namespace and the new one manages the new v2 namespace. The difference between the two namespaces is not great either, sadly, both of them have same class names but with different field types (int, string etc.) which have been separated by the namespace root/virtualization vs root/virtualization/v2 I am not a big fan of patching up things without backward compatibility. In hyperv 2012, there is no v1 namespace to provide backward compatibility: http://technet.microsoft.com/en-us/library/dn303411.aspx [WMI root\virtualization namespace v1 (in Hyper-V) has been dropped.] So, I am not sure :) but if you ask me to pick a choice, In the spirit of encouraging code contributions and make maintenance simpler, I would like to drop off 2008 support, with either asking users to use an older version of libvirt <= 1.4.2 (since new hyperv 2008 drivers wont be contributed to libvirt anyway, so it is not like the users will be missing on features) and that all future contributions to libvirt hyperv driver support 2012 version and beyond. This split seems a bit odd but Microsoft has done it too with win 7 vs win 8.1 :) You guys are the libivirt masters, I put my thoughts in, take a shot and let me know :) Thanks, Vik. On Mon, Apr 21, 2014 at 2:17 PM, Eric Blake <eblake@redhat.com> wrote:
On 04/16/2014 05:51 PM, vikhyath reddy wrote:
With these changes and a few other minor ones, I can confirm that the functionality mimics the hyperv 2008 version. That is, we get the same functionality (supported vs non-supported drivers).
However, this might also mean the end of support of Hyper-V 2008 if it is just a replace of the existing classes. What do you guys think? Should we continue to support 2008 (~6 years old) OR is it OK to assume that Hyperv-V 2012 will be the default standard moving forward.
At least for qemu and xen, we try hard to support any version of a hypervisor that is still actively supported by at least one vendor (that is, RHEL 5 is our current limit of how far back we try and support). On the other hand, free software is somewhat easier to support than proprietary software (we have access to the source code, and can make decisions about how to work around old constructs or even see how newer versions changed in relation to older versions - a luxury not available when targetting something where only the interface is public but the source code is hidden).
I'm not sure how far back Microsoft supports old versions of Hyper-V, especially given the recent media attention to the fact that they explicitly no longer support Windows XP. Although Hyper-V 2008 is 6 years old, if it is still actively supported (where I could buy a license today and still get support for the product), then libvirt should still consider targetting it. On the other hand, patches speak louder than words - anyone interested enough to actually post a patch, even if it actively excludes an older version of the hypervisor, has more clout than someone like me that has never even used Hyper-V :) So I guess that means it is your call on whether it is easier to drop support for old versions for the sake of making maintenance easier.
-- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
participants (2)
-
Eric Blake -
vikhyath reddy