[Openstack-operators] [nova] Metadata service over virtio-vsock

David Medberry openstack at medberry.net
Tue Feb 21 15:08:54 UTC 2017


Doesn't the virtio solution assume/require a libvirt or more exactly a
QEMU/KVM based hypervisor?

What about the N-1 other hypervisors?

I think the idea of a "hot remove, hot add" of the configdrive has some
merit (but remember it is not always ISO-9660 but could be VFAT as well to
aid in some migrations.)

On the plus side, we do actually run the md service.

On Mon, Feb 20, 2017 at 1:22 PM, Artom Lifshitz <alifshit at redhat.com> wrote:

> We've been having a discussion [1] in openstack-dev about how to best
> expose dynamic metadata that changes over a server's lifetime to the
> server. The specific use case is device role tagging with hotplugged
> devices, where a network interface or volume is attached with a role
> tag, and the guest would like to know what that role tag is right
> away.
>
> The metadata API currently fulfills this function, but my
> understanding is that it's not hugely popular amongst operators and is
> therefore not universally deployed.
>
> Dan Berrange came up with an idea [2] to add virtio-vsock support to
> Nova. To quote his explanation, " think of this as UNIX domain sockets
> between the host and guest. [...] It'd likely address at least some
> people's security concerns wrt metadata service. It would also fix the
> ability to use the metadata service in IPv6-only environments, as we
> would not be using IP at all."
>
> So to those operators who are not deploying the metadata service -
> what are your reasons for doing so, and would those concerns be
> addressed by Dan's idea?
>
> Cheers!
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2017-
> February/112490.html
> [2] http://lists.openstack.org/pipermail/openstack-dev/2017-
> February/112602.html
>
> --
> Artom Lifshitz
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170221/10895699/attachment.html>


More information about the OpenStack-operators mailing list