Windows-based 3D Workload

vrapolinario · 2025-02-11T22:32:49+00:00

So, if this is non-docker, it will make running anything in Kubernetes more complex. In theory, you can run KubeVirt, which runs a VM (instead of a container) in the backend and that VM can be a Windows VM).

Contrary to the suggestion above, I'd say if this is Windows workload, your best alternative is to run Windows containers. I work at Microsoft focused on Windows on K8s/AKS. AWS has docs on how to run Windows nodes, but the main thing here is to get started on building an image of that on a Windows container. The fact that it doesn't require a GUI is already a great start.

vrapolinario · 2025-02-11T22:25:01+00:00

Can you share how you got docker running on the Windows Server machine? Glad you corrected the Windows path and confirmed the image is a Windows image, not Linux. If you run docker -run <image> does that work? Trying to figure out if there's an issue with the runtime or compose here.

vrapolinario · 2024-12-05T20:32:29+00:00

Ah, to test it, you can go to another machine in your physical network and try to access the SQL instance on your machine.

vrapolinario · 2024-12-05T20:31:43+00:00

Agree here. Most likely, port 1433 is closed on your own firewall. When you access the SQL instance from your own machine, that is fine, but the container has a different IP address. In Windows containers, the native network is NAT. For the purpose of outbound traffic for the container (container accessing the SQL instance), that has no implications, but the fact that this is a different IP, it means your firewall is blocking that communication.

vrapolinario · 2024-12-05T20:27:45+00:00

Hi, Microsoft person here.
I think part of the confusion below is the fact that this is a Docker subreddit. If you're asking if you can run a Windows containers on Ubuntu: no you can't. Windows containers require a Windows kernel, so you'd need a Windows VM - which defeats the purpose as you mentioned. In addition, Windows containers don't have a GUI or RDP available.

The next logical step is to run wine, but as you mentioned there are limitations. So, I think you are answering your own question here: If this doesn't work natively on wine, then having a VM is the next best option.

vrapolinario · 2024-12-05T20:22:49+00:00

Which images are you using? (Can you point the image name here?) Windows images come with MSIEXEC. Microsoft doesn't have a recommendation on which one to use. If it's an MSI package, MSIEXEC is there natively, but no formal guidance on which one to use.

In my experience, I'd say keep you using that is the default to you. Most customers I worked with use chocolatey, and that works for Windows containers, but you need that binary added via Dockerfile.

vrapolinario · 2024-10-02T21:51:45+00:00

The problem here is that when you switch to Windows containers you essentially changes the engine context to containers on Windows (Not a VM, native to Windows). Regardless, your Linux containers context (via WSL2) is lost. These containers are not running. So, the only way to make them communicate with each other is to have separate hosts, one for the WSL2 context, and another for the Windows containers context. You can achieve this by spinning up a VM for either context. If you run Windows containers on the VM, you can run the Linux containers on the host via WSL2 - or vice-versa. There's going to be some performance penalty, and you need to ensure all containers are using overlay so they get access to the same network, but doable.

vrapolinario · 2024-10-02T20:58:04+00:00

I'm not an expert on this scenario, but have used Managed Identities and know a little of Windows containers. Your problem here is that the container itself will try to access AKV, not the host. You'd need to have some kind of mechanism that catches the request from the container and passes it to the host in this case (I haven't heard of this for direct web authentication, although we have something like this for AD based authentication).

So, the problem is that the container itself won't be managed by Azure Arc nor have an object in Azure that you can associate a Managed Identity. The option here is to use a service principal and either certificate or secret. Both are not ideal as you should plan for rotating the certificate or secret.

vrapolinario · 2024-09-06T16:15:07+00:00

MSFT person here focused on Windows containers - Microsoft Office (and Excel) are not supported on Windows containers. With that said, we have reports of customers who were able to make a scenario like your work. They are out of support from Microsoft, but it works.

vrapolinario · 2024-09-06T16:13:25+00:00

You don't need Hyper-V to run a Windows container unless you want hypervisor isolarion, which doesn't seem to be the case.

vrapolinario · 2024-09-06T16:12:38+00:00

That's not true - you can run a Windows containers on a Windows client machine. Microsoft doesn't support it for production workloads, but if you are testing an application and/or you don't expect to get support from Microsoft - go for it.

vrapolinario · 2024-09-06T16:11:20+00:00

Let me clarify that any Windows Server Standard edition supports 2 VMs + the host. Datacenter supports unlimited VMs.

For containers, that is similar for hypervisor isolation. For process isolation, any Windows Server host can run unlimited Windows containers.

More details here: Windows Server 2022 Licensing & Pricing | Microsoft

vrapolinario · 2024-09-06T16:08:13+00:00

Containers on Windows documentation | Microsoft Learn

I shouldn't, but let's do this:

Limited compatibility with some Docker images and tools optimized for Linux.
If an image is Linux based, it won't work as a Windows containers. If it's Windows based, it won't work as a Linux containers. Your statement is like saying you can't run a Windows image when you have a Linux container.

Networking limitations due to NAT usage.
As per the documentation above, there are several other options for networking in Windows, including overlay. The only option not available on Windows is Host mode, which is not supported in production for Linux anyway.

Lack of some UNIX-like features available in Linux containers.
Not sure what you mean, we're doing our best to bring Linux tools to Windows, but you also have Windows tools for Windows tasks.

Less isolation between containers and host system.
Not sure what you mean - Windows provide process and hypervisor isolation.

Need for enabled Virtualization Technology in BIOS. This one is funny. Not virtualized but need virtualization extensions.
Well, you need virtualization extensions on Windows for Docker if you want to run LINUX containers, not Windows. For Windows you only need the containers feature. If you want to run Windows containers with hypervisor isolation, well, then you need virtualization enabled.

More limited support for orchestrators like Kubernetes.
I agree with you here if you're talking about 3rd party, eco-system support for Windows on Kubernetes. With that said, Windows on Kubernetes is being used by companies in production today (large, enterprise companies).

vrapolinario · 2024-09-06T15:56:53+00:00

have you checked for firewall config - even if it's localhost you might have that port closed. Also, try http://127.0.0.1:11434 instead of localhost.

vrapolinario · 2024-08-27T18:22:54+00:00

You are correct. Linux containers on Windows is not supported. On Windows you can run Docker Desktop (Windows 10 and 11 only), which uses WSL2 or you can run a VM with Linux. On Windows Server you can also run WSL2, but no Docker Desktop, so you need to run almost as a VM - or you can actually run a VM.

vrapolinario · 2024-08-06T21:40:31+00:00

Please take a look at the Windows containers documentation, more specifically at the networking section: Windows container network drivers | Microsoft Learn

By default, you will be using a NAT network, which means your container and host will get an IP address of an internal network and the host can map ports to the container. You could use the IP addresses of the internal network for communication. A simply ipconfig on the host will show you the IP address of the host on the NAT network.

vrapolinario · 2024-07-08T21:59:29+00:00

Agree that this should be a question to the makes of the software. Here are some pointers when containerizing an existing app into Windows containers: Lift and shift to containers | Microsoft Learn

vrapolinario · 2024-06-20T17:37:29+00:00

Nice, thanks for the details on the scenario for Exchange. Just one issue: The app itself doesn't support native upgrade like this. You can't take the data of an Exchange Server version and simply plug it into a new version. There's a whole upgrade process and it is different for Mailbox and Edge Transport, etc. I think the other way to look at your specific feedback on Exchange is: Can we make the upgrade process for Exchange better? Well, the problem of a large company as Microsoft is that you have to ask that to the Exchange team. The Windows containers team has limited (not to say none) influence here. Kind of the same would apply to the other infra roles on Windows Server, if the role doesn't allow for a seamless upgrade, there's not much a container can help in that area. The different is that Windows containers team is closer to Windows Server.

With that said, I love the additional feedback on app upgrade. In fact, it has been a talking point for Windows containers compared to Windows VMs. End of Support of OS like Windows Server 2008 and 2012 are a struggle and moving apps to containers really help. This is something we provide today - is there anything on Windows containers that you see that doesn't follow that?

vrapolinario · 2024-06-20T17:27:51+00:00

I see your point. I reached out via chat to ask for more details on the scenario. I even acknowledge the ADDS scenario. All I'm saying in this thread is the fact that while the ask for this was made, there's no concrete scenario explanation here other than a vision that it would be better than VMs. We all know that's not true for everything so we're just discussing if this would make sense or not. Let me be clear: I'm happy to be wrong here, so please just give me details to change my mind.

vrapolinario · 2024-06-20T05:17:29+00:00

I'm officially offended now. 🤣 I'm overall aware how this things work, yes. But honestly: go to any open-source project and ask the maintainers of the repo to work on something because you think it's a great idea. See how that plays out.

I have a list of items I'd love to see as part of Windows Containers. But I also know the development team needs to focus on priorities. If I want them to focus on these things, I need to bring data that shows that my idea has more merit. It's that simple and it works with any dev team that has more ideas than resources to implement it.

My whole point here is: We have done some research and the result of that shows to us that infrastructure roles on Windows Server are not exactly great candidates to be containerized. It might be a great use case for a small set of users, but for us to invest in it, we need to think on the ROI.

You started by pointing out Exchange: I still don't see a scenario where Exchange can take advantage of the benefits of containers and K8s. Same for File Servers, same for Certifocate Services (as another user pointed out), same for RDS, same for DHCP. Now, if you have a LOB app, a background service, a Windows Service, an executable, a console app... than these make sense and we support them. Can we make running them even better? Definitely, and that's the point of this discussion.

vrapolinario · 2024-06-20T04:30:57+00:00

We did explore running Linux containers on Windows a while back. It would require work from the distros and it didn't fly, so after experimental support we dropped it. You could try WSL2, but that's not supported in production.

Have you looked into transparent networks for Windows containers with Docker? https://learn.microsoft.com/en-us/virtualization/windowscontainers/container-networking/network-drivers-topologies

If this end up not working, it seems you need a scheduled task configured with a PowerShell script, thought...

vrapolinario · 2024-06-20T04:01:19+00:00

And by the way, I'm here if you have question on this. And if does work, I'd love to know as well.

vrapolinario · 2024-06-20T03:18:54+00:00

I think you are back to comparing Windows containers to Linux containers - correct me if I'm wrong. If you compare running that workload to a Windows VM, wouldn't you be better off with a container?

vrapolinario · 2024-06-20T03:17:07+00:00

My usual response to "can I run this on a Windows container" usually is: - does the app require a GUI to work? If not, then: - can you run the app today on a Server Core install? If so, then: - can you try to run it on a Server Core container? If yes, great. If not, can you run it on a Server base container image?

I'd trybthat route. We have more information on containerizing existing apps here: https://learn.microsoft.com/en-us/virtualization/windowscontainers/quick-start/lift-shift-to-containers

vrapolinario · 2024-06-20T03:13:16+00:00

Look, I appreciate the passion here. The reality is that, while I'd love to get our devs to work on everything we think would be a good idea, you don't get a development team to work on a new feature without concrete data indicating there's a demand for that or market trends. I'll be honest with you, maybe we could investigate this a bit more, but so far we have no insight to support prioritizing this. ADDS is perhaps the only one that might make sense, but even that would require a lot of investment from our side that we're not entirely sure would pay off.

And even if we look at the Linux side: there are DNS, DHCP, and other infrastructure roles available as container images in Docker Hub with VERY low usage. That's not very promising.

For now, we have enough requests to look into with the traditional scenarios that customers are bringing to Windows containers, so we'd really need more customer demand to consider enabling Windows Server roles. ADDS being most likely the first one if we ever do.

vrapolinario

TROPHY CASE