[libvirt] libvirt Hyper-v 2012 r2 fix

[vikhyath reddy]

*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 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140421/f2a732d8/attachment-0001.htm>