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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
