Proposal: drop support for Hyper-V 2008R2
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? -- Matt
On 10/30/20 7:02 AM, Matt Coleman wrote:
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?
Not sure if this is still the case but I found different capabilities between different license levels of the same product. This was years ago so the details are vague now but in essence the problem I ran into was differences between SMB handling of certain events. The problem systems had been licensed with a clustering feature enabled. So Windows 2012 my not operate the same between all licensing options. -- Alvin Starr || land: (647)478-6285 Netvel Inc. || Cell: (416)806-0133 alvin@netvel.net ||
On Oct 30, 2020, at 8:09 AM, Alvin Starr <alvin@netvel.net> wrote:
Not sure if this is still the case but I found different capabilities between different license levels of the same product. This was years ago so the details are vague now but in essence the problem I ran into was differences between SMB handling of certain events. The problem systems had been licensed with a clustering feature enabled.
So Windows 2012 my not operate the same between all licensing options.
Interesting, I haven't come across any differences due to licensing options yet. I'll keep that in mind as I continue to work on this code. Thanks! The differences I was referring to are things like a function parameter taking completely differently-formatted values in 2008R2 vs. 2012, such as WMI object selectors in some functions. Microsoft's documentation will only describe one of the variants, and it varies from function to function whether it describes 2008R2 or 2012. Based on this thread and a discussion on IRC today, I think I should entirely remove support for the V1 API. Since 2012's V2 support is incomplete, that would effectively mean dropping support for both 2008R2 and 2012, leaving 2012R2 and newer fully supported. -- Matt
On Fri, Oct 30, 2020 at 07:02:33AM -0400, Matt Coleman wrote:
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?
It gets my vote, as our high level aim is to never try to support a product which is EOL by its own vendor. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Fri, 2020-10-30 at 07:02 -0400, Matt Coleman wrote:
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.
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? [1] https://libvirt.org/platforms.html [2] https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions#Server_vers... -- Andrea Bolognani / Red Hat / Virtualization
On Oct 30, 2020, at 11:54 AM, Andrea Bolognani <abologna@redhat.com> 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. -- Matt
On Fri, Oct 30, 2020 at 07:34:47PM -0400, Matt Coleman wrote:
On Oct 30, 2020, at 11:54 AM, Andrea Bolognani <abologna@redhat.com> 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. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Mon, 2020-11-02 at 09:15 +0000, Daniel P. Berrangé wrote:
On Fri, Oct 30, 2020 at 07:34:47PM -0400, Matt Coleman wrote:
On Oct 30, 2020, at 11:54 AM, Andrea Bolognani <abologna@redhat.com> 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.
Sounds good to me as well. -- Andrea Bolognani / Red Hat / Virtualization
participants (4)
-
Alvin Starr -
Andrea Bolognani -
Daniel P. Berrangé -
Matt Coleman