I have a W2k19 VM I created as a patched image. Idea is to patch it monthly. Shut it down and clone it. Then sysprep the clone and copy the disk to the Image Service. Then I can create VM’s off of it. I will repeat the colne after patching the ~master image monthly in order to keep a patched disk ready to spin up VM’s from.
We are using AHV, version 5.10.
Mt question is the “CLONE” a full, independant copy of the VM ?
The clone is not a full nor independent copy of the VM. The source and the clone share original storage blocks. You can delete the source VM at any time nonetheless.
The video below explains the cloning process
Let me know if that helps.
So how would one make a “copy” that’s independent of the original ? (or can I copy the Clones disk without issues)?
I would like to keep the original image to bring up and patch every month, then copy it and sysprep it to distribute the Syspreped Image to the Image Service on all our AHV clusters. Then I have a Syspreped image I can roll out VM’s with.
Is your process fully-automated or do you do it manually ? If it’s automated, could you share your method/script ?
Manual at the moment
Let me break down the process into several steps and explain them individually.
Creating an image from an existing VM disk does not lock the original VM’s files hence the VM and the image have independent storage blocks.
Deploying a VM from an image, however, does trigger images’ storage blocks being marked as immutable and thus causes storage data of the image and all VMs that are deployed from it to be shared or linked.
You then upload the image to the PC and distribute it across the clusters which is a benign file copy process.
Once you chose to deploy a VM from an image in a new location the same process as described in the previous paragraph takes place per storage container of each image location meaning shared blocks only occur between the image and VMs that are deployed off that image.
To the best of my knowledge, there is nothing one could do to avoid sharing storage blocks when deploying a VM from the image apart from deleting the image itself.
Let me know if the above makes sense or if you have further questions.
When you say “ Deploying a VM from an image, however, does trigger images’ storage blocks being marked as immutable and thus causes storage data of the image and all VMs that are deployed from it to be shared or linked. “
Thanks this is helpful, I really appreciate your daily attention to this matter !
How about this method ?
1. create a windows VM and patch it, shutdown.
2.clone it, bring up clone and sysprep it, shutdown
3.Identify the disk (how… name =uuid) and use WINSCP to copy it down to local box which is on a CVM network.
4.copy it back up to image service on same cluster (to roll out new VMs from)
5.copy it to other clusters for same reason/method.
Although I dont totally understand the hooks a clone has to a original, I do understand you can DEL the original and the clone should be fine, right ? So once its copied down to local machine is the clone now a standalone with no hooks in the original and could be copied back up as a new box (or Image Service in the case ) ?
Yes, yes it does. That’s the thing. Similarly to snapshot and clones, storage blocks of the image disk are locked for changes.
May I ask why having them linked is an issue?
Yes, that’s right.
The plan above would make the re-uploaded file to be treated as a standalone entity and thus lose its link to the original, yes.
In summary: So a clone has hooks into the VM it was cloned from, however the clone can be considered a standalone VM as the VM it was cloned from can be Deleted and the clone will be unaffected.
As well the clone can be downloaded and uploaded to another cluster (into Image Service) to use as a ~golden image~. It can even be downloaded from its original cluster, and uploaded back into its (original cluster) Image Service, and operate as if it were a standalone VM.
Pardon my drawn out thread but I got corn-fused with naming conventions of VM’s and wanted to make sure I understood the process deeply.
Roughly, yes:) You got it:)
Have you tried using Microsoft MDT and OSDBuilder PoSH module within the cluster to avoid having to upload the image? I’m trying to find an alternative to MDT for a specific use case but it could help in your situation. I have the 2016 or 2019 WIM file update monthly through OSDBuilder with a script which gets imported into MDT and a task runs to deploy to an AHV VM with various software. Then I use Nutanix PoSH Cmdlets (When are the modules coming?) to clone the vDisk to the image service.
Here is the script that updates the OS wim and imports it into MDT. This module could also create an ISO and during the New-OSBuild command, it can enable Windows Features, and regkeys, files/folders, or anything you can conjure with PoSH.
Here is the script that clones the BuildVM vDisk to the Image Service.
Hope some of this is useful.
EDIT: Sorry the code is word wrapping which makes it hard to read. Feature request for the forum.