Question

W2k19 Image and cloning it for sysprep - patch monthly


Badge

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 ?

TIA

-S


This topic has been closed for comments

11 replies

Userlevel 6
Badge +5

Hi SeanG,

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.

Badge

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.

Hi @SeanG

Is your process fully-automated or do you do it manually ? If it’s automated, could you share your method/script ?

Matthieu

Badge

Manual at the moment

-Sean

Userlevel 6
Badge +5

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.

Badge

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. “

  • When I deploy a VM from an image I am using the Nutanix AHV Image Service. I have uploaded a disk file into that service. I am not “cloning” a image(VM). Therefore does that apply above ?

Thanks this is helpful, I really appreciate your daily attention to this matter !

-SeanG

Badge

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 ) ?

 

 

Userlevel 6
Badge +5

When I deploy a VM from an image I am using the Nutanix AHV Image Service. I have uploaded a disk file into that service. I am not “cloning” a image(VM). Therefore does that apply above ?

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?

 

I do understand you can DEL the original and the clone should be fine, right ?

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.

 

Badge

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.

Thanks again

-Sean

Userlevel 6
Badge +5

Roughly, yes:) You got it:)

Userlevel 2
Badge +2

@SeanG 

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.

Import-Module "C:\Program Files\Microsoft Deployment Toolkit\bin\MicrosoftDeploymentToolkit.psd1"
$date = (Get-Date -Format yyyyMMdd)
$CurrentOSMedia = (Get-OSMedia -Newest -OSInstallationType Server -OSReleaseId 1607).Name

Set-MpPreference -DisableRealtimeMonitoring $true
Update-OSMedia -Name $CurrentOSMedia -Download -Execute -SkipComponentCleanup -SkipUpdatesPE
New-OSBuild -Download -Execute -SkipUpdatesPE -SkipTask -Name $CurrentOSMedia -HideCleanupProgress
New-PSDrive -Name "DS001" -PSProvider MDTProvider -Root "E:\MDTDS"
import-mdtoperatingsystem -path "DS001:\Operating Systems\Windows 2016" -SourceFile "E:\OSDeploy\OSBuilds\$CurrentOSMedia\OS\sources\install.wim" -DestinationFolder "Win2016Std$date" -Verbose

Here is the script that clones the BuildVM vDisk to the Image Service.

$ntnxpsLoaded = Get-PSSnapin -Name NutanixCmdletsPSSnapin -ErrorAction SilentlyContinue | %($_.Name)
if($ntnxpsLoaded -eq $null) {
Add-PSSnapin -Name NutanixCmdletsPSSnapin
}
Connect-NTNXCluster -Server your.prism.ip -UserName (Get-StoredCredential -Target NTNX).UserName -Password (Get-StoredCredential -Target NTNX).Password -ForcedConnection | Format-Table -Property name,version | Out-Null
$imagecreatespec = New-NTNXObject -Name ImageImportSpecDTO
$containerID = (Get-NTNXContainer -SearchString "<Storage Container you want the Disk Image to reside>").Id
$imagecreatespec.containerId = $containerID.Substring($containerID.IndexOf(":")+2)
$diskId = (Get-NTNXVMDisk -Vmid (Get-ntnxvm -SearchString "<The name of your BuildVM>").vmId -BusType scsi).vmDiskUuid
$imagecreatespec.url = "nfs://127.0.0.1/<Storage Container where BuildVM resides>/.acropolis/vmdisk/$diskId"
$date = (Get-Date -Format yyyyMMdd)
New-NTNXImage -Name "<Name of Image>" -Annotation "<Whatever>" -ImageType DISK_IMAGE -ImageImportSpec $imagecreatespec

Hope some of this is useful.

EDIT: Sorry the code is word wrapping which makes it hard to read. Feature request for the forum.