Open Stack

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.

-- 
Mathieu