On 05/21/2015 03:20 PM, Mathieu Gagné wrote:
On 2015-05-21 3:13 AM, Daniel P. Berrange wrote:
On Thu, May 21, 2015 at 09:34:20PM +1200, Xav Paice wrote:
On 21/05/15 21:23, Daniel P. Berrange wrote:
On Wed, May 20, 2015 at 03:01:50PM -0700, Michael Still wrote:
I note that we use instance.name to lookup the libvirt domain a bunch
in the driver. I'm wondering why we don't just use instance.uuid all
the time -- the code for that already exists. Is there a good reason
to not move to always using the uuid?
I ask because instance.name is not guaranteed to be unique depending
on how weird the nova deployment is.
Agreed, there's no benefit to using name - internally libvirt will always
prefer to use the UUID itself too.
These days though, there is only a single place in nova libvirt driver
that needs updating - the nova.virt.libvirt.host.Host class get_domain()
method just needs to be switched to use uuid.
Just a comment from an ops point of view - it would be miles easier when
trying to troubleshoot, if the instance name was the uuid anyway. I
totally agree on using instance.uuid, just to comment that I find it a
little painful sometimes that instance names don't match the uuid of the
instance, but the directory structure does. Just a bit of confusion to
avoid at 2am when something isn't working.
You do know you can configure the instance name used...
eg in nova.conf
instance_name_template='inst-%(uuid)s'
Please note that you CANNOT change instance_name_template ones instances
are created otherwise they become unmanageable by Nova. This is because
Nova tries to find the libvirt instance by its name instead of its UUID.
So since instances were spawned with the old value, it won't find
existing instances using the new value.
And no, I haven't found a way to rename an instance without
redefining/restarting it in libvirt.
Is there any reason why we couldn't default to using something like
'inst-%(uuid)s' for the instance name?
Chris
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
