[Tenant] Volume creation fails after renaming the default tenant.

[ashahi1]

Steps:

1. Make sure you only see _DEFAULT tenant
2. Create a volume.
3. Rename the _DEFAULT tenant.
4. Again try creating a volume. 
    Operation failed -  Error response from daemon: create TestVol2: VolumeDriver.Create: VM    ubuntu-VM0.3 does not belong to any vm-group

---

Steps and their output are as follows:

1. Only default tenant is present

[root@sc-rdops-vm16-dhcp-235-79:~] /usr/lib/vmware/vmdkops/bin/vmdkops_admin.py vm-group ls
Uuid                                  Name      Description                 Default_datastore  VM_list
------------------------------------  --------  --------------------------  -----------------  -------
11111111-1111-1111-1111-111111111111  _DEFAULT  This is a default vm-group

2. Created a volume

root@sc-rdops-vm02-dhcp-52-237:~# docker volume create --driver=vsphere --name=TestVol1 -o size=400mb
TestVol1
root@sc-rdops-vm02-dhcp-52-237:~# docker volume ls
DRIVER              VOLUME NAME
vsphere             TestVol1@sharedVmfs-0
root@sc-rdops-vm02-dhcp-52-237:~#


[root@sc-rdops-vm16-dhcp-235-79:~] /usr/lib/vmware/vmdkops/bin/vmdkops_admin.py volume ls
Volume    Datastore     VM-Group  Capacity  Used  Filesystem  Policy  Disk Format  Attached-to  Access      Attach-as               Created By    Created Date
--------  ------------  --------  --------  ----  ----------  ------  -----------  -----------  ----------  ----------------------  ------------  ------------------------
TestVol1  sharedVmfs-0  _DEFAULT  400MB     23MB  ext4        N/A     thin         detached     read-write  independent_persistent  ubuntu-VM0.3  Mon Mar 27 01:58:09 2017

[root@sc-rdops-vm16-dhcp-235-79:~]

3. Renamed the _DEFAULT tenant

[root@sc-rdops-vm16-dhcp-235-79:~] /usr/lib/vmware/vmdkops/bin/vmdkops_admin.py vm-group update --name=_DEFAULT --description="Renaming default tenant to vm-group1" --new-name=new-vm-group1
vm-group modify succeeded
[root@sc-rdops-vm16-dhcp-235-79:~] /usr/lib/vmware/vmdkops/bin/vmdkops_admin.py vm-group ls
Uuid                                  Name           Description                           Default_datastore  VM_list
------------------------------------  -------------  ------------------------------------  -----------------  -------
11111111-1111-1111-1111-111111111111  new-vm-group1  Renaming default tenant to vm-group1

[root@sc-rdops-vm16-dhcp-235-79:~]

4. Tried creating another volume but failed.

root@sc-rdops-vm02-dhcp-52-237:~# docker volume ls
list vsphere: VolumeDriver.List: VM ubuntu-VM0.3 does not belong to any vm-group
DRIVER              VOLUME NAME
vsphere             TestVol1
root@sc-rdops-vm02-dhcp-52-237:~# docker volume create --driver=vsphere --name=TestVol2 -o size=400mb
Error response from daemon: create TestVol2: VolumeDriver.Create: VM ubuntu-VM0.3 does not belong to any vm-group
root@sc-rdops-vm02-dhcp-52-237:~#

Logs:
docker-volume-vsphere.txt
vmdk_ops.txt

[govint]

Tried this out and the issue doesn't repro if the vm-group rename is done back and forth (_DEFAULT to new name and then back). The error was reported once and when the vm-group name is changed back and forth the issue doesn't repro thereafter,

$ docker volume create --driver=vsphere --name=TestVol2 -o size=400mb
Error response from daemon: create TestVol2: VolumeDriver.Create: VM 2 does not belong to any vm-group

  vm-group name is reverted back to _DEFAULT

$ docker volume create --driver=vsphere --name=TestVol2 -o size=400mb
TestVol2

 vm-group name is again changed to a different name

$ docker volume create --driver=vsphere --name=TestVol3 -o size=400mb
TestVol3

$ docker volume create --driver=vsphere --name=TestVol4 -o size=400mb
TestVol4

[govint]

The issue is like this,

1. No VM is explicitly added to the _DEFAULT vm group. If a VM isn't in a specific group then its part of the default group. Per the admin CLI,

/usr/lib/vmware/vmdkops/bin/vmdkops_admin.py vm-group vm ls --name _DEFAULT
_DEFAULT tenant contains all VMs which were not added to other tenants

2. When the default group is renamed, the VMs are effectively not in any vm-group which breaks the assumption of (1).

3. The rename op allowed in (2) breaks (1). Renaming the default tenant shouldn't be allowed. Will post the PR for this.