Hello, I've been getting familiar with Hyper-V recently and have gotten stymied by inconsistencies in its API. While Hyper-V has V1 and V2 APIs, neither one is consistent between Windows versions. For example... * Windows 2012 only supports a subset of the V2 API * Windows 2012 implements some V1 functions differently than 2008R2 * Windows 2016 broke compatibility with 2012R2 by replacing some classes Some of these differences are undocumented, too, which is just lovely. Most of these changes are relatively easy to handle, but the differences between 2008R2's and 2012's implementations of the V1 API result in libvirt code with a lot of conditionals containing obscure format strings in the 2008R2 blocks. Windows 2008R2's extended support ended January 14, 2020: https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2008-r2 Windows 2012's mainstream support ended in 2018, but it still has extended support through October 10, 2023: https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2012 Since 2008R2 is no longer supported by Microsoft, I propose removing support for it from libvirt. Thoughts?

Hello, I've been getting familiar with Hyper-V recently and have gotten stymied by inconsistencies in its API. While Hyper-V has V1 and V2 APIs, neither one is consistent between Windows versions. For example... * Windows 2012 only supports a subset of the V2 API * Windows 2012 implements some V1 functions differently than 2008R2 * Windows 2016 broke compatibility with 2012R2 by replacing some classes Some of these differences are undocumented, too, which is just lovely. Most of these changes are relatively easy to handle, but the differences between 2008R2's and 2012's implementations of the V1 API result in libvirt code with a lot of conditionals containing obscure format strings in the 2008R2 blocks. Windows 2008R2's extended support ended January 14, 2020: https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2008-r2 Windows 2012's mainstream support ended in 2018, but it still has extended support through October 10, 2023: https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2012 Since 2008R2 is no longer supported by Microsoft, I propose removing support for it from libvirt. Thoughts?

On Oct 30, 2020, at 11:54 AM, Andrea Bolognani <abologna(a)redhat.com&gt; wrote: Dropping 2008R2 support is a no-brainer. Can we got further? Our policy[1] for Linux is The project aims to support the most recent major version at all times. Support for the previous major version will be dropped 2 years after the new major version is released or when the vendor itself drops support, whichever comes first. If we adopted the same policy for Windows Server[2], then we could drop support for 2012R2 today and support for 2016 in the next release. Is there a good reason why we should *not* do that?

On Fri, Oct 30, 2020 at 07:34:47PM -0400, Matt Coleman wrote: > On Oct 30, 2020, at 11:54 AM, Andrea Bolognani <abologna(a)redhat.com&gt; wrote: > > Dropping 2008R2 support is a no-brainer. > > > > Can we got further? Our policy[1] for Linux is > > > > The project aims to support the most recent major version at all > > times. Support for the previous major version will be dropped 2 > > years after the new major version is released or when the vendor > > itself drops support, whichever comes first. > > > > If we adopted the same policy for Windows Server[2], then we could > > drop support for 2012R2 today and support for 2016 in the next > > release. > > > > Is there a good reason why we should *not* do that? > > We need 2012R2 support at Datto, so I'd like to keep it in there for > the time being. This is for integration with our customers' systems, so > we don't have control over the OS version. It still accounts for a > significant portion of our customer base. Given that Datto is the only org to make significant contributions to the HyperV driver in years, I'm fine with us keeping 2012R2. Our support policy is basically written to suit the needs of the people who are taking on the maintainership, so its fine to evolve it. I simply ask that the docs/platforms.rst and/or drvhyperv.html.in pages be updated to reflect what we're doing wrt HyperV support.