<div dir="ltr"><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">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. 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: <a href="http://technet.microsoft.com/en-us/library/dn303411.aspx">http://technet.microsoft.com/en-us/library/dn303411.aspx</a> [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. </blockquote></div><div class="gmail_extra"> <div class="gmail_quote">On Mon, Apr 21, 2014 at 2:17 PM, Eric Blake <<a href="mailto:eblake@redhat.com" target="_blank">eblake@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">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. </div>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 <a href="tel:%2B1-919-301-3266" value="+19193013266">+1-919-301-3266</a> Libvirt virtualization library <a href="http://libvirt.org" target="_blank">http://libvirt.org</a> </blockquote></div> </div>