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 or virtio-vsock. Regards, Daniel -- |: 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/ :| __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
