- Vmware esxi 6.7 clone vm command line software upgrade#
- Vmware esxi 6.7 clone vm command line Offline#
z -createrdmpassthru /vmfs/devices/disks/.IT sector is continuously developing at a rapid speed and is making things smarter and smaller day by day. Oh, did I mention that, if you rename the VM, the Storage vMotion will rename all the files too, if the VM will be moved around? Handy feature, isn’t it? And a little vmkfstools referenceĪs for your support, please see the help output of vmkfstools below. So all files (VMX, VMDK etc.) are on the same place / in the same folder. To clean up that little mess we’ve just created, you can move all files to the same folder (you probably have to remove the VM from inventory and register it again later), and you have to edit the VMX file for sure because the path to the VMDK file changed. Now as you have cloned the VMDK file (and committed the snapshot) into a new folder, you can either create an empty shell VM with the exact configuration as the source VM, add the cloned VMDK as an existing disk, or you can remove the source disk from the source VM configuration and add it there as existing disk. At the end you can specify the target disk format with “-d” (like for example thin-provisioned). During the cloning process the snapshot will be consolidated / committed with the target VMDK.
With the one-liner above you’re going now to clone the VMDK file with a snapshot from the source VM to another folder and name the target file. The actual syntax of the vmkfstools is: vmkfstools -i source_path destination_path -d disk_ format In our example this is “vmname-000001.vmdk”.Įxecute the vmkfstools command and let the magic happen: vmkfstools -i /vmfs/volumes/vsanDatastore/vmfolder_source/vmname-000001.vmdk /vmfs/volumes/vsanDatastore/newvm/newvm.vmdk -d thin What we should use here as a source file is the descriptor file that points to our snapshot. When you’re in the source folder, make sure you get the correct disk / descriptor file. If you do a “ls- lah” within the folder (that command shows you a list of files and the filesize in a human-readable format) you will see all vmdk disk files, flat vmdk’s, delta vmdk’s and the vmdk descriptor files.
And as you’re doing a disk clone locally on the ESXi host with “vmkfstools” and not withing vCenter, there shouldn’t be a timeout either. During the cloning of a disk file the snapshot will be consolidated. Some research and again having a chat with VMware support led us towards cloning the disk files.
“Error communicating with the host” isn’t very helpful in that moment. Consolidation timed at around 96%, not sure why. What a bummer! So we scheduled another maintenance window to consolidate that snapshot. We found out that this snapshot was about 400 GB in size. The VM came back online but with the known “Disk Consolidation Needed status”. Together with VMware support we were able to stop the snapshot deletion.
Vmware esxi 6.7 clone vm command line Offline#
But the VM not only went offline for some time, but unexpectedly for hours. That could happen, depending on snapshot size and storage system. The VM went offline because of disk consolidation. So we scheduled a maintenance window to delete the snapshot. Faster said than done. We weren’t able to add disk space because of that snapshot. We found out that there is a snapshot when the VM or service owner requested some additional disk space. So this snapshot was growing and growing.
Vmware esxi 6.7 clone vm command line software upgrade#
But someone created that snapshot before a software upgrade and forget to delete it. That by itself isn’t an issue, a snapshot is nothing special. We had one virtual machine with a snapshot. Recently we had a weird issue in our office.
0 kommentar(er)
