Windows Server Container cross-version host compatibility

[agowa]

Windows containers are currently more or less strictly version bound to the same version as the host (process isolation).
I do not count Hyper-V isolation, as that is in my opinion just another kind of VM hosting and has nothing to do with containers.

Dependencies can be viewed here: https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility?tabs=windows-server-2004%2Cwindows-10-2004

It would be very useful if windows userland could work independent of the kernel version.
E.g. a 2004 kernel being able to start a container with 1903 userland and vice verse.

As a developer bundling applications I want to be able to have a single container being able to run on multiple windows host (kernel) versions, so that I do not have to create the container for all windows versions that a customer might be running (maybe even on outdated versions because of other containers not being packaged against newer ones).

As a operator I do not want to consider containers when updating the host operating system so that I can install updates (maybe even automatically) when I want to.

As a user I do not want engage with the server operator to deploy an older host for some application container so that I can just "docker run" the application without having to consider the windows version it was build against.

As a security engineer I do not want operators holding back with installing windows updates (e.g. because of compatibility issues or the container not being available for the new version) so that all systems can be kept up to date without service impact.

[biiiipy]

This is one of those issues, that will seriously hinder the usage of windows containers. It's a huge issue for us.
This is not a issue only to those that stick to LTSC versions until the end of (extended) support (or universe's heat death), and those places are exactly the ones that don't adopt new tech like containers.

[brasmith-ms]

Hi all, thank you for this perspective! This is something that we have been aware of for a some time now and are in the midst of working on a solution to fix it.

I want to note that patch-level versions are compatible with one another, and this is mostly an issue across major versions. Security patches also apply to both user and kernel mode binaries and thus need to be updated accordingly (hence the requirement to rebuild container images). If you have run across scenarios where this is not the case, feel free to contact me directly.

I understand the desire to decouple the container version from the host OS and ensure stronger levels of compatibility. We are working hard to push in this direction. I will keep this thread updated with our progress as we move forward.

[ghost]

This issue has been open for 30 days with no updates.
@brasmith-ms, please provide an update or close this issue.

[ghost]

This issue has been open for 30 days with no updates.
@brasmith-ms, please provide an update or close this issue.

[ghost]

This issue has been open for 30 days with no updates.
@brasmith-ms, please provide an update or close this issue.

[ghost]

This issue has been open for 30 days with no updates.
@brasmith-ms, please provide an update or close this issue.

[ghost]

This issue has been open for 30 days with no updates.
@brasmith-ms, please provide an update or close this issue.

[ghost]

This issue has been open for 90 days with no updates.
@brasmith-ms, please provide an update or close this issue.

[brasmith-ms]

Hi folks, just wanted to update this thread on our progress here. This is absolutely a high priority item and we are working on adding support for it in the future. This is a top issue for Windows containers and we are listening closely to your feedback on this. Cross-version compatibility demands a lot from the fundamental design of the Windows OS and enabling support for this is by no means trivial. Because of this it's likely that cross-version compatibility will not be supported for WS2019 images, and we will release communications on our plan for WS2022 and onwards as we get closer to a solution.

For now I'm going to close this issue, but we will continue to work hard on it and release communications on the subject when ready. As always, feel free to reach out to me with specific concerns.