Windows Image Management - BYUHPC/7lbd GitHub Wiki

Below is a revised version with corrections and improvements:

7lbd simplifies Windows management by utilizing a single base image with temporary, job-specific overlays. This approach ensures that all production Windows VMs start from an identical state, while individual user changes made during a job are stored in a separate overlay file within the /tmp directory.

Creating Overlay Files

When executed through Open OnDemand, the following command runs within each Slurm job immediately before VM startup:

qemu-img create -f qcow2 -b /apps/directory/containing/symlink_to_windows_image.qcow2 -F qcow2 /temp/location/for/overlay_image.qcow2

This overlay file starts out very small and will grow as a user makes changes to the VM or copies files to the VM's local hard drive.

Base Image File Management

The Windows image referenced in the qemu-img command above should be a symbolic link. This approach enables base image updates without disrupting active VM sessions. QEMU only reads the base image file descriptor when qemu-kvm initializes, meaning:

  • Existing sessions continue unaffected when the base image is updated.
  • New sessions automatically use the latest image version.
  • Previous versions of the base image must be retained until all VMs using them have terminated.

Can Overlay Files Span Jobs?

While users could technically create persistent overlay files for use across multiple jobs, this practice is not compatible with the simple, default VM management strategy used in 7lbd. A VM overlay file can only be used reliably with the exact read-only base image from which it was created. If the base image of an overlay file is updated, merging the contents of an old overlay file with the altered base image is likely to result in corruption.

This corruption is not possible with one-time, job-specific overlay files when the base image is implemented as a symlink. When QEMU launches, it follows the symlink to the base image’s file descriptor. The running QEMU process retains that file descriptor and does not reference the symlink again. Therefore, the symlink can be updated without affecting running instances of QEMU. QEMU VMs can be rebooted, and since the rebooted VM continues to use the same QEMU process, it retains the same base image file that matches the user’s overlay. If a VM is shut down, Open OnDemand will end the job, and a new job will follow the updated symlink to the new base image. That is why the qemu-kvm command is placed at the end of the script.sh.erb OnDemand script. Once the qemu-kvm process ends, the job is terminated.

Also note that using a temporary overlay file means there are no repercussions for terminating a job running a VM, as long as all work has been saved to a network drive. There will be no corruption of the OS image when skipping a graceful shutdown and simply killing the qemu-kvm process.

How to Maintain the VM Image

If the image is read-only, how do I perform maintenance on it? See this article: Creating-a-maintenance-OOD-application.