bug cloning a running VM in 6.5u2

[GalNeb]

When cloning a running VM and choosing Customize Virtual Hardware, there is a major problem.  The only change I am making is to change the NIC Portgroup.  But instead of only changing the portgroup, it also changes the drive backing of all the hard disks to point to the original VM's .vmdk files.  With the original VM running, you can not power on the new VM due to the locks on the files.  If you have powered off the original before powering on the clone, then you can be royally messed up.  The drives are being cloned and are in the clones folder, but once the file copies are complete, the new VM is being modified.  In the event viewer of the cloned VM there is a huge entry where it is changing the drive config as well as several other settings.

For full disclosure, I am cloning a VM with multiple hard disks between two different clusters with different distributed switches and VLANs.  So it is necessary to change the port group.  We are cloning VMs between test and production clusters.  This is fully repeatable on every VM that we have tested so it is not a configuration or environmental problem.  It is bug.

I do understand that the Customize Virtual hardware option is and has been forever marked as "Experimental", but this is an expected use of the option that should work.  The program should only be changing those options that are modified in the wizard, it should not be changing anything else.    This is not an acceptable situation.  I have used this wizard for years to add drives, change CPU and Memory settings and it has always worked fine until now.

[InsaneOne]

Hi, GalNeb!

Do you have any feedback about this bug?

I've got it right now, and it was a very unpleasant. = (

[bryanvaneeden]

We are also having the same issue!

I just cloned some VM's from within the HTML5 UI, only thing I changed was the portgroup.

Thank god I noticed this before I started the cloned VM's.

Please be careful when cleaning these virtual machines, because if you delete them from disk, they either get deleted with the original VM, or the job fails. I couldn't actually try this so I just removed the VM's from the inventory and manually cleaned the datastores containing the configuration and swap files.

I'll create a case tomorrow!

EDIT 16-11-2018:

Tested numerous situations but I can't seem to replicate this behaviour except for the original VM's which were affected. Below the situations I tested:

- Made new VM (with identical virtual machine configurations and disks) -> Cloned it (online and offline and on ESXi 6.5 and 6.0), all good.

- Made new VM but with v9 VM hardware instead of 11 - Cloned it (online and offline and on ESXi 6.5 and 6.0), all good.

- Tested all situations above in the HTML5 and Flash web client, all good.

- Cloned one the original habitants of the cluster (online in the HTML5 client), doesn't work -> get original VM disks as reference inside the VM config. I can also see the edit event which reconfigures the locations of the VMDK's.

- Cloned one the original habitants of the cluster (online in the Flex client), does work -> all good.

Conclusion thus far (about 50 clones into this): Cloning in the Flash client works (with changes to the hardware), cloning in the HTML5 client works (with changes to the hardware) but only on "new" VM's. The original VM's in the cluster are apparently not working correctly within the HTML5 UI. Strangely I re-created the virtual machine and made it 100% identical to the one that is giving this behaviour but am still not able to reproduce this issue.

EDIT: 2019-01-08

Still no response from VMware, this is taking pretty long now. Still having the issue when using the methods I talked about. Will try to keep this updated.

[bryanvaneeden]

Update on this:

Case is closed by VMware. We are still having issues with this on one particular cluster. VMware basically gave up and said "You are using the "experimental" feature in the webclient, since it is experimental we cannot proceed further.". This is complete nonsense ofcourse because this feature has been experimental for a decade... To be continued.

[LeffeB]

There is still a problem with this in vcenter 7.0
Maybe not the same background since the html5 client is now the one and only webclient.

See below article for "workaround"

https://kb.vmware.com/s/article/78399?lang=en_US

sometimes it is not possible to power off source VM when cloning, so there is no workaround available there.