6:51 p.m.
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(a)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(a)googlemail.com> wrote:
> 2014-04-16 3:26 GMT+02:00 vikhyath reddy <reddy.vikhyath(a)gmail.com>:
> > 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(a)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
> process
> >> the filter. The filter might be missing or it might be invalid. Change
> the
> >> 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
> 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
>
4:17 p.m.
New subject: [libvirt] libvirt Hyper-v 2012 r2 fix
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
7:39 p.m.
New subject: [libvirt] libvirt Hyper-v 2012 r2 fix
*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.*
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
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(a)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
3867
days inactive
3873
days old
2 comments
2 participants
participants (2)
-
Eric Blake -
vikhyath reddy