vSphere 8.0 Update 2 was just announced last week at VMware Explore and it brings a lot of exciting new capabilities, check out this What's New in vSphere 8.0 Update 2 and What's New in vSAN 8.0 Update 2 blog posts for a nice summary of all the new features.
While doing some testing in my vSphere 8.0 Update 2 lab, I came to learn about a really cool feature that has been requested by customers over the years, which is the ability to configure a read-only virtual disk (VMDK). The most common use case for this feature is being able to share a single VMDK across multiple Virtual Machines and prevent any changes to the original data, a common scenario for VMware App Volumes or VMware Horizon environments.
I could also see this capability get leveraged by users as a way to distribute and install software where traditional application management systems are unavailable but still ensuring that workloads can not manipulate or modify the original files, definitely opens the door for some interesting capabilities.
In vSphere 8.0 Update 2, a new vSphere API property called guestReadOnly has been introduced to the Virtual Disk specification which specifies whether a VMDK will be presented in R/W (default) or RO mode from the ESXi Hypervisor.
While some guest operating systems (GOS) can provide a similiar behavior, it is not consistent across all operating systems and it can easily be disabled from within the GOS. The benefit of this new property is that it is exposed at the virtual disk layer, so it can not be disabled or tampered from within the GOS, which makes this a much better and scalable implementation.
The new guestReadOnly property is only configurable when using the vSphere API and it does have a few requirements:
- vCenter and ESXi running the upcoming vSphere 8.0 Update 2 release
- VM configured with 8.0 Update 2 VM Compatibility (vHW21)
- Only SCSI-based adapters are supported (no NVME or SATA)
- VM must be powered off for reconfiguration
Here is a PowerCLI example that demonstrates how to reconfigure a VM to update the second VMDK with the read-only property configured to true. In my setup, I have deployed a PhotonOS VM that contains two VMDK, the first for the OS and the second with standard ext3 filesystem (/data) which I can write to by default.
$vcname = "192.168.30.159" $vcuser = "administrator[at]vsphere.local" $vcpass = "VMware1!" $vmName = "VM-With-RO-VMDK" $diskName = "Hard disk 2" $guestReadonlyFlag = $true #### DO NOT EDIT BEYOND HERE #### Connect-VIServer -Server $vcname -User $vcuser -Password $vcpass # Retrieve VM $vm = Get-VM $vmName $diskDevice = (Get-VM $vmName | Get-HardDisk | where {$_.Name -eq $diskName}).ExtensionData $diskDeviceBacking = $diskDevice.backing # Create VM Config Spec and update existing VMDK with guestReadOnly = $true $spec = New-Object VMware.Vim.VirtualMachineConfigSpec $spec.deviceChange = New-Object VMware.Vim.VirtualDeviceConfigSpec $spec.deviceChange[0].operation = 'edit' $spec.deviceChange[0].device = New-Object VMware.Vim.VirtualDisk $spec.deviceChange[0].device = $diskDevice $spec.DeviceChange[0].device.backing = New-Object VMware.Vim.VirtualDiskFlatVer2BackingInfo $spec.DeviceChange[0].device.backing = $diskDeviceBacking $spec.DeviceChange[0].device.guestReadOnly = $guestReadonlyFlag Write-Host "`nUpdating guestReadOnly flag on $diskName with ${guestReadonlyFlag} on $vmName ..." $task = $vm.ExtensionData.ReconfigVM_Task($spec) $task1 = Get-Task -Id ("Task-$($task.value)") $task1 | Wait-Task | out-null Disconnect-VIServer * -Confirm:$false
Note: A new version of PowerCLI that supports vSphere 8.0 Update 2 will be required before you can use run the following snippet of code.
If the operation was successful, you should not see any errors after the reconfiguration.
If we re-query our VM, we can now see that the second VMDK has the read-only property set to true.
When we power on the VM, we should no longer be able to perform any writes to that volume as shown in the screenshot below.
Lars Day says
Is the download for Vsphere Update 2 available now?
William Lam says
Not yet
Lars Day says
VCSA8 Update 2 New Upgrade/Update Process not working. Used the steps delineated by VMWARE to try the New Upgrade Process using VCSA update tab and received various error messages when starting the process. So we just logged into the VCSA Appliance Management using the URL:5480 and used the standard update process which worked perfectly. Would be nice to see how this new upgrade process works and how long the process actually takes.