Using Set-HardDisk to "Inflate" a Thin-Provisioned Virtual Harddisk ("VM must be in the following state: PoweredOff" Error)

[drmabuse]

Hi,

I've written a script to go through our VMware environment and inflate any thin-provisioned virtual harddisks.

As of yesterday, this seemed to be working fine, by just excuting a command similar to this:

Set-HardDisk -HardDisk $harddisk -Inflate -Confirm:$false

The script discovered virtual machines and checked for all harddisks with the "thin provisioned" backing set to true.

The problem was, I discovered that once this operation was completed, the status of the volume was still set to thin, even though the volume was obviously not.  The script (when re-run) would try to re-inflate volumes which already were thick!

I discovered that by reloading the VM ($vm_view.reload()), this seemed to fix the issue.  So I thought it would be clever to "reload" the VM, before and after going through the available harddisks.

Since then, all systems I discover with thin provisioned harddisks can no longer be "inflated" - the command demands that the VM must be in a powered off state!

From the PowerCLI command-line:

PowerCLI U:\> Get-HardDisk -VM aumel-dfs02 -Name "Hard Disk 1" | Set-HardDisk -Inflate -Confirm:$false

Set-HardDisk : 22/07/2016 1:47:06 PM    Set-HardDisk        The VM must be in the following state: PoweredOff.

At line:1 char:52

+ ... mel-dfs02 -Name "Hard Disk 1" | Set-HardDisk -Inflate -Confirm:$false

+                                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : InvalidOperation: (PoweredOn:PowerState) [Set-HardDisk], ViError

    + FullyQualifiedErrorId : Common_SharedParameterHelper_VerifyVmIsInState_VmNotInState,VMware.VimAutomation.ViCore.Cmdlets.Commands.VirtualDevice.SetHardDisk

Since then, I tried to make a new VM - a scratch one and it seems to work ok:

PowerCLI U:\> Get-HardDisk -VM test-dra -Name "Hard Disk 1" | Set-HardDisk -Inflate -Confirm:$false

CapacityGB      Persistence                                                    Filename

----------      -----------                                                    --------

40.000          Persistent                     [general-current] test-dra/test-dra.vmdk

It too, is being "reloaded" but does not error out the same way.

What is going on here?  Clearly something about the state of my VMs has changed that is preventing this operation from succeeding.

I wonder if there is a way to compare and/or dump any critical settings/variables associated with these VMs that could be influencing this operation?

Any help here would be greatly appreciated!

Regards,

Daniel

[LucD]

Not sure what is happening in your environment, but the PowerOff message is the "normal" behaviour when using the Inflate switch.

Strange that you don't get the message on a freshly cloned VM. That VM is powered on I assume?

Does that show when you do a Get-VM on that VM?

Btw, the Reload method, is primarily intended to sync what is in your VMX file and what vSphere "thinks" is configured.

This discrepancy is primarily caused when you change the content of the VMX file via external means, in other words not through the client or a CLI.

[drmabuse]

Not sure what is happening in your environment, but the PowerOff message is the "normal" behaviour when using the Inflate switch.

Strange that you don't get the message on a freshly cloned VM. That VM is powered on I assume?

It was working on VMs that were powered off.  I just assumed that the ones it was working on yesterday were powered on as well, this forced me to check.  You know what they say about assumptions!

Gosh, I feel like such an idiot now! :smileyconfused:

Do you know of any way to do this with the VMs powered on?

The environment is vCenter & ESXi 6...

[LucD]

No problem, it's not as if something similar never happened to me :smileygrin:

The only way, that I know, to do this with a powered on VM, is through a svMotion (Move-VM with the Datastore and DiskStorageFormat parameter).

The drawback is that you will need extra free space on the datastores.

[drmabuse]

The only way, that I know, to do this with a powered on VM, is through a svMotion (Move-VM with the Datastore and DiskStorageFormat parameter).

Ah yes, I see that.  I tried using the -StorageFormat parameter with Set-HardDisk and it seems this is deprecated...

e.g. "Get-HardDisk -VM aumel-dfs02 -Name "Hard Disk 1" | Set-HardDisk -Datastore general-01 -StorageFormat thick -Confirm:$false;" results in:

WARNING: Parameter 'Datastore' is obsolete. 'Datastore' parameter is obsolete. To move hard disk to another datastore and change it's storage format, use 'Move-HardDisk' cmdlet

instead.

WARNING: Parameter 'StorageFormat' is obsolete. 'StorageFormat' parameter is obsolete. To move hard disk to another datastore and change it's storage format, use 'Move-HardDisk'

cmdlet instead.

And nothing is changed of course.  It looks like something is working (you see activity in the Tasks list) but the format of the disk definitely doesn't change.  Oh well.

I'll give the Move-VM method a shot.  Thanks for your help!

Daniel

[LucD]

I think that only works with Move-Harddisk

Did you try that?

[drmabuse]

Hmm, it doesn't seem to change the format.

The command actually works ok (no errors), you even get a progress bar (and "tasks" shows something is happening) but the format hasn't changed.  The command I used was:

Get-HardDisk -VM aumel-dfs02 -Name "Hard Disk 1" | Move-HardDisk -Datastore general-01 -StorageFormat thick -Confirm:$false

When I reload the VM and list the format, it's still thin.

The Datastore I specified there is the one it currently resides on.  I'm guessing I might have better luck if I moved it to another Datastore?

[LucD]

Yes, you'll need another datastore, won't work in-place afaik.