Write-Same vs XCopy when using Storage vMotion

I had a question last week about Storage vMotion and when Write-same vs XCopy was used. I was confident I knew the answer, but I figured I would do some testing. So what was the question exactly and the scenario I tested?

Imagine you have a virtual machine with a “lazy zero thick disk” and an “eager zero thick” disk. When initiating a Storage vMotion while preserving the disk format, would the pre-initialized blocks in the “eager zero thick” disk be copied through XCopy or would “write-same” (aka zero out) be used?

So that is what I tested. I created this virtual machine with two disks of which one being thick and about half filled and the other “eager zero thick”. I did a Storage vMotion to a different datastore (same format as source) and checked esxtop while the migration was on going:

CLONE_WR = 21943
ZERO = 2

In other words, when preserving the disk format the “XCopy” command (CLONE_WR) is issued by the hypervisor. The reason for this is when doing a SvMotion and keeping the disk formats the same the copy command is initiated for a chunk but the hypervisor doesn’t read the block before the command is initiated to the array. Hence the reason the hypervisor doesn’t know these are “zero” blocks in the “eager zero thick” disk and goes through the process of copy offload to the array.

Of course it would interesting to see what happens if I tell during the migration that all disks will need to become “eager zero thick”, remember one of the disks was “lazy zero thick”:

CLONE_WR = 21928
ZERO = 35247

It is clear that in this case it does zero out the blocks (ZERO). As there is a range of blocks which aren’t used by the virtual machine yet the hypervisor ensures these blocks are zeroed so that they can be used immediately when the virtual machine wants to… as that is what the admin requested “eager zero thick” aka pre-zeroed.

For those who want to play around with this, check esxtop and then the VAAI stats. I described how-to in this article.

Storage vMotion does not rename files?

A while back I posted that 5.0 U2 re-introduced the renaming behavior for VM file names. I was just informed by our excellent Support Team that unfortunately the release notes missed something crucial and Storage vMotion does not rename files by default. In order to get the renaming behavior you will have to set an advanced setting within vCenter.. This is how you do it:

  • Go to “Administration”
  • Click on “vCenter Server Settings”
  • Click “Advanced Settings”
  • Add the key “provisioning.relocate.enableRename” with value “true” and click “add”
  • Restart vCenter service or vCenter Server

Now the renaming of the files during the SvMotion process should work again!
All of you who need this functionality, please make sure to add this advanced setting.

storage vmotion does not rename files

Renaming virtual machine files using SvMotion back in 5.0 U2

I have been pushing for this heavily internally together with Frank Denneman and it pleases me to say that it is finally back… You can rename your virtual machine files again using Storage vMotion as of 5.0 u2.

vSphere 5 Storage vMotion is unable to rename virtual machine files on completing migration
In vCenter Server , when you rename a virtual machine in the vSphere Client, the vmdk disks are not renamed following a successful Storage vMotion task. When you perform a Storage vMotion of the virtual machine to have its folder and associated files renamed to match the new name. The virtual machine folder name changes, but the virtual machine file names do not change.

This issue is resolved in this release

src: https://www.vmware.com/support/vsphere5/doc/vsp_vc50_u2_rel_notes.html#resolvedissues

Those who want to know what else is fixed, you can find the full release notes here of both ESXi 5.0 U2 and vCenter 5.0 U2:

** do note that this fix is not part of 5.1 yet **

vMotion enhancement in vSphere 5.1

There’s a nice new enhancement to vMotion in vSphere 5.1. (and no, it doesn’t have specific name :-)) With vSphere 5.1 you can migrate virtual machines live without needing “shared storage”. In other words you can vMotion virtual machines between ESXi hosts with only local storage. It is very simple:

  • Open the vSphere Web Client
  • Click “VMs and Templates”
  • Right click the VM you want to migrate
  • Select “Change both host and datastore”

I am sure Frank Denneman is going to dive in to this soon so I won’t elaborate on how the process it self works. There’s already a blogpost out by Sreekant Setty which has some more details and which points to a nice white paper about vMotion / SvMotion performance.