| 2013-12-02 19:51:28 |
Shawn Hartsock |
bug |
|
|
added bug |
| 2013-12-02 20:10:49 |
Shawn Hartsock |
nova: assignee |
|
Sidharth Surana (ssurana) |
|
| 2013-12-02 23:45:01 |
OpenStack Infra |
nova: status |
New |
In Progress |
|
| 2013-12-03 17:29:19 |
Shawn Hartsock |
nova: importance |
Undecided |
Medium |
|
| 2013-12-03 17:29:30 |
Shawn Hartsock |
nova: milestone |
|
icehouse-2 |
|
| 2013-12-03 17:29:51 |
Shawn Hartsock |
bug task added |
|
openstack-vmwareapi-team |
|
| 2013-12-03 17:29:59 |
Shawn Hartsock |
openstack-vmwareapi-team: status |
New |
In Progress |
|
| 2013-12-03 17:30:02 |
Shawn Hartsock |
openstack-vmwareapi-team: importance |
Undecided |
High |
|
| 2013-12-03 17:30:19 |
Shawn Hartsock |
openstack-vmwareapi-team: assignee |
|
Sidharth Surana (ssurana) |
|
| 2013-12-05 16:53:07 |
Shawn Hartsock |
description |
Currently the VMware Nova Driver relies on the VM name in vCenter/ESX to match the UUID in Nova. The name can be easily edited by vCenter administrators and break Nova administration of VMs. A better solution should be found allowing the Nova Compute Driver for vSphere to look up VMs by a less volatile and publicly visible mechanism. |
Currently the VMware Nova Driver relies on the VM name in vCenter/ESX to match the UUID in Nova. The name can be easily edited by vCenter administrators and break Nova administration of VMs. A better solution should be found allowing the Nova Compute Driver for vSphere to look up VMs by a less volatile and publicly visible mechanism.
EDIT:
A fix would make the link between vSphere and Nova more solid and involve using a vSphere metadata value that cannot be easily edited. Currently the UUID is stored as an extra config metadata property inside vSphere and
this value is not easy to accidentally change. That would make the link much more robust. |
|
| 2013-12-05 16:54:02 |
Shawn Hartsock |
description |
Currently the VMware Nova Driver relies on the VM name in vCenter/ESX to match the UUID in Nova. The name can be easily edited by vCenter administrators and break Nova administration of VMs. A better solution should be found allowing the Nova Compute Driver for vSphere to look up VMs by a less volatile and publicly visible mechanism.
EDIT:
A fix would make the link between vSphere and Nova more solid and involve using a vSphere metadata value that cannot be easily edited. Currently the UUID is stored as an extra config metadata property inside vSphere and
this value is not easy to accidentally change. That would make the link much more robust. |
Currently the VMware Nova Driver relies on the VM name in vCenter/ESX to match the UUID in Nova. The name can be easily edited by vCenter administrators and break Nova administration of VMs. A better solution should be found allowing the Nova Compute Driver for vSphere to look up VMs by a less volatile and publicly visible mechanism.
EDIT:
A fix would make the link between vSphere and Nova more solid and involve using a vSphere metadata value that cannot be easily edited. Currently the UUID is stored as an extra config metadata property inside vSphere (associated with the instance's virtual-machine) and
this value is not easy to accidentally change. That would make the link much more robust. |
|
| 2013-12-11 17:58:06 |
Tracy Jones |
tags |
vmware |
grizzly-backport-potential havana-backport-potential vmware |
|
| 2014-01-22 20:21:30 |
Thierry Carrez |
nova: milestone |
icehouse-2 |
icehouse-3 |
|
| 2014-02-26 23:23:42 |
OpenStack Infra |
nova: status |
In Progress |
Fix Committed |
|
| 2014-02-26 23:25:07 |
Sidharth Surana |
openstack-vmwareapi-team: status |
In Progress |
Fix Committed |
|
| 2014-03-05 13:11:19 |
Thierry Carrez |
nova: status |
Fix Committed |
Fix Released |
|
| 2014-03-21 12:13:56 |
Alan Pevec |
tags |
grizzly-backport-potential havana-backport-potential vmware |
havana-backport-potential vmware |
|
| 2014-04-17 09:07:09 |
Thierry Carrez |
nova: milestone |
icehouse-3 |
2014.1 |
|
