cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vijayendra Bhamidipati <>
Subject Re: Review Request 13008: Fix usage of vm.instancename.flag when generating VM names on ESX hypervisor
Date Mon, 29 Jul 2013 04:11:39 GMT

My patch was intended for the 4.2 branch and not for master (it won't apply cleanly on master)
– looks like jenkins is trying to patch this against the master branch and I'm seeing this
failure – do I need to do something here? I can create a patch for master but I need this
to go into 4.2 as well. Please advise.

Also, I specified that the branch was 4.2 in the branch field of the review request – won't
your scripts pick that up??


From: "Jenkins" <<>>
Reply-To: "Jenkins" <<>>
Date: Sunday, July 28, 2013 8:59 PM
To: Kelven Yang <<>>, Sateesh
Chodapuneedi <<>>,
Will Chan <<>>, Chip Childers <<>>,
Alex Huang <<>>
Cc: Vijayendra Bhamidipati <<>>,
"<>" <<>>,
"Jenkins" <<>>
Subject: Re: Review Request 13008: Fix usage of vm.instancename.flag when generating VM names
on ESX hypervisor

This is an automatically generated e-mail. To reply, visit:

Review 13008 failed the build test : FAILURE
The url of build cloudstack-master-with-patch #65 is :

- Jenkins

On July 29th, 2013, 1:55 a.m. UTC, Venkata Siva Vijayendra Bhamidipati wrote:

Review request for cloudstack, Alex Huang, Chip Childers, Kelven Yang, Sateesh Chodapuneedi,
and William Chan.
By Venkata Siva Vijayendra Bhamidipati.

Updated July 29, 2013, 1:55 a.m.

Repository: cloudstack-git

The vminstancename flag has been incorrectly used to simply append the displayname to the
internal VM name that shows up on vCenter in vmware deployments. It was intended to show the
actual name supplied as hostname, on the hypervisor. This helps admins and deployers to quickly
identify VMs and resolve issues related to those VMs. Its usage is very limited as it stands
now. This fix corrects it to ensure that the name of the VM on the hypervisor matches the
hostname if it is supplied, and if the vm.instancename.flag is set to true.


Post this change, all major VM operations, namely creation/destruction/expunging/start/stop/reboot
of the VM have been tested and observed to work correctly. Part of this patch also puts in
a fix for VMSync operations where the CS mgmt server doesn't detect that a guest VM is down,
if the guest VM has been shut down/powered off in vCenter. Other operations such as VM snapshot,
volume snapshots of disks belonging to the VM, volume migration across primaries, volume attach/detach
have also been tested and they are working as expected. This is a functional change, and completely
transparent to any of cloudstack's existing functionalities and all the test cases that cover
the above code paths and APIs - all existing tests should and do pass - no new tests are necessary.


  *   engine/orchestration/src/org/apache/cloudstack/platform/orchestration/
  *   plugins/hypervisors/vmware/src/com/cloud/hypervisor/guru/ (d1392c4)
  *   plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/manager/
  *   plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/
  *   plugins/hypervisors/vmware/src/com/cloud/storage/resource/
  *   server/src/com/cloud/ha/ (25c5a04)
  *   server/src/com/cloud/hypervisor/ (ec68529)
  *   server/src/com/cloud/vm/ (3831f88)
  *   server/src/com/cloud/vm/ (a3187ba)
  *   vmware-base/src/com/cloud/hypervisor/vmware/mo/ (04ef0f8)
  *   vmware-base/src/com/cloud/hypervisor/vmware/mo/ (2735fb0)
  *   vmware-base/src/com/cloud/hypervisor/vmware/mo/ (dd0f889)
  *   vmware-base/src/com/cloud/hypervisor/vmware/mo/ (e2dd789)
  *   vmware-base/src/com/cloud/hypervisor/vmware/mo/ (ac14328)

View Diff<>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message