Open Stack

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.

On 09/25/14 16:24, Daniel P. Berrange wrote:
> On Thu, Sep 25, 2014 at 09:19:03AM -0500, Matt Riedemann wrote:
>>
>> On 9/25/2014 8:26 AM, Pasquale Porreca wrote:
>>> The problem to use a different tag than UUID is that it won't be
>>> possible (for what I know) to include this tag in the Bootstrap Protocol
>>> messages exchanged during the pre-boot phase.
>>>
>>> Our original idea was to use the Client-identifier (option 61) or Vendor
>>> class identifier (option 60) of the dhcp request to achieve our target,
>>> but these fields cannot be controlled in libvirt template and so they
>>> cannot be set in OpenStack either. Instead the UUID is set it the
>>> libvirt template by OpenStack and it is included in the messages
>>> exchanged in the pre-boot phase (option 97) by the instance trying to
>>> boot from network.
>>>
>>> Reference:
>>> http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml
> [snip]
>
>> If it's a matter of getting the instance tag information down to the libvirt
>> driver on boot that shouldn't be a problem, there are others asking for
>> similar things, i.e. I want to tag my instances at create time and store
>> that tag metadata in some namespace in the libvirt domain xml so I can have
>> an application outside of openstack consuming those domain xml's and reading
>> that custom namespace information.
> Perhaps I'm misunderstanding something, but isn't the DHCP client that
> needs to send the tag running in the guest OS ? Libvirt is involved wrt
> UUID, because UUID is populated in the guest's virtual BIOS and then
> extracted by the guest OS and from there used by the DHCP client. If
> we're talking about making a different tag/identifier available for
> the DHCP client, then this is probably not going to involve libvirt
> unless it also gets pushed up via the virtual BIOS. IOW, couldn't you
> just pass whatever tag is needed to the guest OS via the configdrive
> or metadata service.
>
> Regards,
> Daniel

-- 
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr