[openstack-dev] [nova] Device tagging: rebuild config drive upon instance reboot to refresh metadata on it
Daniel P. Berrange
berrange at redhat.com
Mon Feb 20 13:38:31 UTC 2017
On Sat, Feb 18, 2017 at 08:11:10AM -0500, Artom Lifshitz wrote:
> In reply to Michael:
> > We have had this discussion several times in the past for other reasons. The
> > reality is that some people will never deploy the metadata API, so I feel
> > like we need a better solution than what we have now.
> Aha, that's definitely a good reason to continue making the config
> drive a first-class citizen.
FYI, there are a variety of other options available in QEMU for exposing
metadata from the host to the guest that may be a better option than either
config drive or network metadata service, that we should consider.
- NVDIMM - this is an arbitrary block of data mapped into the guest OS
memory space. As the name suggests, from a physical hardware POV this
is non-volatile RAM, but in the virt space we have much more flexibilty.
It is possible to back an NVDIMM in the guest with a plain file in the
host, or with volatile ram in the host.
In the guest, the NVDIMM can be mapped as a block device, and from there
mounted as a filesystem. Now this isn't actually more useful that config
drive really, since guest filesystem drivers get upset if the host changes
the filesystem config behind its back. So this wouldn't magically make it
possible to dynamically update role device metdata at hotplug time.
Rather than mounting as a filesystem, you can also use NVDIMM directly
as a raw memory block, in which case it can contain whatever data format
you want - not merely a filesystem. With the right design, you could come
up with a format that let you store the role device metadata in a NVDIMM
and be able to update its contents on the fly for the guest during hotplug.
- virtio-vsock - think of this as UNIX domain sockets between the host and
guest. This is to deal with the valid use case of people wanting to use
a network protocol, but not wanting an real NIC exposed to the guest/host
for security concerns. As such I think it'd be useful to run the metadata
service over virtio-vsock as an option. It'd likely address at lesat some
people's security concerns wrt metadata service. It would also fix the
ability to use the metadat service in IPv6-only environments, as we would
not be using IP at all :-)
Both of these are pretty new features only recently added to qemu/libvirt
so its not going to immediately obsolete the config drive / IPv4 metadata
service, but they're things to consider IMHO. It would be valid to say
the config drive role device tagging metadata will always be readonly,
and if you want dynamic data you must use the metdata service over IPv4
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
More information about the OpenStack-dev