Open Stack

On 09/30/2014 06:53 AM, Pasquale Porreca wrote:
> Going back to my original question, I would like to know:
>
> 1) Is it acceptable to have the UUID passed from client side?

In my opinion, no.  This opens a door to issues we currently don't need 
to deal with, and use cases I don't think Nova should support. Another 
possibility, which I don't like either, would be to pass in some data 
which could influence the generation of the UUID to satisfy requirements.

But there was a suggestion to look into addressing your use case on the 
QEMU mailing list, which I think would be a better approach.

>
> 2) What is the correct way to do it? I started to implement this 
> feature, simply passing it as metadata with key uuid, but I feel that 
> this feature should have a reserved option rather then use metadata.
>
>
> On 09/25/14 17:26, Daniel P. Berrange wrote:
>> On Thu, Sep 25, 2014 at 05:23:22PM +0200, Pasquale Porreca wrote:
>>> This is correct Daniel, except that that it is done by the virtual
>>> firmware/BIOS of the virtual machine and not by the OS (not yet 
>>> installed at
>>> that time).
>>>
>>> This is the reason we thought about UUID: it is yet used by the iPXE 
>>> client
>>> to be included in Bootstrap Protocol messages, it is taken from the 
>>> <uuid>
>>> field in libvirt template and the <uuid> in libvirt is set by 
>>> OpenStack; the
>>> only missing passage is the chance to set the UUID in OpenStack 
>>> instead to
>>> have it randomly generated.
>>>
>>> Having another user defined tag in libvirt won't help for our issue, 
>>> since
>>> it won't be included in Bootstrap Protocol messages, not without 
>>> changes in
>>> the virtual BIOS/firmware (as you stated too) and honestly my team 
>>> doesn't
>>> have interest in this (neither the competence).
>>>
>>> I don't think the configdrive or metadata service would help either: 
>>> the OS
>>> on the instance is not yet installed at that time (the target if the 
>>> network
>>> boot is exactly to install the OS on the instance!), so it won't be 
>>> able to
>>> mount it.
>> Ok, yes, if we're considering the DHCP client inside the iPXE BIOS
>> blob, then I don't see any currently viable options besides UUID.
>> There's no mechanism for passing any other data into iPXE that I
>> am aware of, though if there is a desire todo that it could be
>> raised on the QEMU mailing list for discussion.
>>
>>
>> Regards,
>> Daniel
>