cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kelven Yang" <>
Subject Re: Review Request 13008: Fix usage of vm.instancename.flag when generating VM names on ESX hypervisor
Date Mon, 29 Jul 2013 20:52:13 GMT

> On July 29, 2013, 3:59 a.m., Jenkins wrote:
> > Review 13008 failed the build test : FAILURE
> > The url of build cloudstack-master-with-patch #65 is :
> Venkata Siva Vijayendra Bhamidipati wrote:
>     This patch is for 4.2 and has been tested on 4.2 as described - the patch will not
apply on the master branch. The above failure message is for master branch. Requesting reviewers
to review patch for 4.2.

It would be better to use existing custom field facility to tag attributes to vCenter objects.
Since content of object annotation in vCenter is plain string leterals, we can't store information
there in a structural way, which will lead us to add additional logic to enable sharing annotation
field from mulitple sources.

Another problem with using annotation is that since the field in vCenter is designed to allow
vCenter administrators to label object with custom comments, it is editable in vCenter UI,
if we use it for special control purpose, it will open a door for people to mess up CloudStack
meta information stored in vCenter.

I would suggest to change to custom field facility

- Kelven

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

On July 29, 2013, 1:55 a.m., Venkata Siva Vijayendra Bhamidipati wrote:
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> -----------------------------------------------------------
> (Updated July 29, 2013, 1:55 a.m.)
> Review request for cloudstack, Alex Huang, Chip Childers, Kelven Yang, Sateesh Chodapuneedi,
and William Chan.
> Bugs: CLOUDSTACK-3886
> Repository: cloudstack-git
> Description
> -------
> 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.
> Diffs
> -----
>   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 
> Diff:
> Testing
> -------
> 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.
> Thanks,
> Venkata Siva Vijayendra Bhamidipati

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