Is there any training on creating Windows VMs using unattended installation files within Openshift?

[Gerrard]

Hello, 
I am new to working in Openshift virtualization, and I am struggling to get an automated process to build a Windows VM, (setting a static IP address, patching the machines, etc.)
Is there any training to assist with this process?  Seems very different to redhat VMs.

[Travis · Accepted solution]

@Gerrard -

So we need to break this down into several pieces. First, the easy answer is we don't currently have nor do we currently provide training on building Windows VMs or automating this process using OpenShift Virtualization. 

In terms of how things work, conceptually it should be no different from building and automating Windows on other platforms (with a few minor exceptions). I haven't actually automated Windows VMs on OCPVirt at an enterprise-level but I used to do this all the time when I worked in consulting and used Red Hat Virtualization (again - concepts are the same).

The automation, patching, and entire process will differ based on the other enterprise services you have available, but using SCCM or SystemCenter or something like that you can have the OSD Task sequences built and have either an OSD ISO image in OCPVirt or allow PXE booting. This would automate the installation components of Windows (or could be what does that process). As for patching SCCM or SystemCenter or WSUS would be what you would use for patching. All of those items would be really outside the scope of what Red Hat would be providing for training as that is a significant amount of architecture to setup and get working.

That being said, one of the things that could be done is creating a master image template of the Windows VM and leveraging that as a base image template for any new Windows VMs. Using this approach, what you would do is to leverage cloud-init and SYSPREP (unattended) file settings for some of the customizations and other infrastructure pieces like DHCP servers with MAC address to IP address mapping (assuming you have those components). 

The reason we are able to easily show RHEL is that we can provide the image streams and we can also leverage all the power of cloud-init because that is built-in as part of our OS and we are fully licensed and available to run as many RHEL systems as we want. Leveraging other software and training on other products is often difficult as special licensing must be secured and there would need to be a great enough demand for the content to make it a priority to develop a course or any content. 

Assuming you are coming from some other type of virtualization, I would first ask myself the following questions ...

1. In my current environment, how do I deploy Windows virtual machines?
2. What is in place that allows me to deploy Windows VMs?
   • SCCM / System Center?
   • PXE-Boot or boot disks?
   • Specialized provisioning networks?
   • Firewall rules?
   • DHCP/DNS services - where and how are these provided?
   • NTP services?
   • Networking?
3. Can I use the existing infrastructure with modification for connection to the OCP environment?
4. What pieces might I be missing and would need to be added, reconfigured, or changed in order to connect to the OCP environment?

The answers to these questions should give you a starting point down a path on enterprise deployments of Windows VMs using OCP Virt.

[88508101]

As you pointed out we are coming from VMWare, and to be completely honest appears far simpler the Openshift Virtualization at this point.
Within VMWare, we have a custom site (written by another team) which collects the machine name, Network, IP, Gateway, Subnet, template name, etc and submits those values to the VMWare API as I understand it.  Vmware packages this up into a unattend.xml file and pushes it into the preprepared template (fully patched, some apps preinstalled, additonal hardening scripts etc.)
5-15 minutes later we have a VM up and running and accessible to our users.

I can not figure out how to do something similar in Openshift.  The best I have managed to do is build a base Windows VM.  If I put the unattend.xml file in the c:\windows\panther\ directory prior to running the sysprep command, this is honoured, then the IP and further settings are configured.  However, we need this outside the sysprepped image so that we can automate the builds of windows machines (different names, IPs, disk sizes etc.)  If I place the unattend.xml file in a Configmap, it is added as a CDROM to the system, but not used during the build.

Now as far as our current environment.
- SCCM/System Center we don't use it
- PCE-Boot we don't use, we have a pre-configured template which is sysprepped
- Specialized provisioning network we don't use
- Firewall rules, local firewall is disabled
- DHCP not used, we have static IP addresses for all systems
- DNS (combination AD integrated for internal names and a LInux based BIND system for public)
- NTP is served by our Domain Controllers
- Networks are shared on both the OCP and VMWare systems.

So this really doesn't help with any direction.

[Travis]

So it would seem like you are using some additional items layered into the VMWare current workflow. Based on the amount of time it is taking to build, I would imagine VMWare is using a Windows VM template to provision and providing the SYSPREP unattended file that the other team wrote as part of the workflow. 

While I haven't done it on OCP Virtualization, like I said, I have done this multiple times within RHV and using other things. OCP Virt still utilizes KVM and other technologies (including cloud-init). I believe the course still shows you a little about using cloud-init to "customize" a RHEL instance that is being deployed, but cloud-init can also be used for the SYSPREP or unattend.xml for Windows machines.

Basically from a high-level, if you have an unattend file, you can create a Kubernetes ConfigMap to hold this file and present it as a volume to the VM for cloudInit to mount and allow it to be used as the OOBE process that Windows is currently using in your current VM building process. In fact, since we have all these pieces, that other team could most likely redirect the backend of the custom site to make that resource available on OCP.

For the VM definition of your Windows machine, you would then just make sure you have your cloud-init disk defined and your configMap pointing to the resource that contains the correct unattended.xml file.

Again, this answer is likely a gross oversimplification of the process, but given you have a bunch of the other items in place, it is highly likely that the customization pieces are coming from the template and the unattend.xml file. Cloud-init is the special sauce that allows the configMap to be used and you need to ensure that it is named correctly and setup correctly, otherwise, the process isn't run as you've mentioned above.

So simply mounting the volume isn't good enough, cloudInit must be aware to kick that process off. 

Hope that helps