<div dir="ltr">Doesn't the virtio solution assume/require a libvirt or more exactly a QEMU/KVM based hypervisor?<div><br></div><div>What about the N-1 other hypervisors?</div><div><br></div><div>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.)</div><div><br></div><div>On the plus side, we do actually run the md service.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 20, 2017 at 1:22 PM, Artom Lifshitz <span dir="ltr"><<a href="mailto:alifshit@redhat.com" target="_blank">alifshit@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We've been having a discussion [1] in openstack-dev about how to best<br>
expose dynamic metadata that changes over a server's lifetime to the<br>
server. The specific use case is device role tagging with hotplugged<br>
devices, where a network interface or volume is attached with a role<br>
tag, and the guest would like to know what that role tag is right<br>
away.<br>
<br>
The metadata API currently fulfills this function, but my<br>
understanding is that it's not hugely popular amongst operators and is<br>
therefore not universally deployed.<br>
<br>
Dan Berrange came up with an idea [2] to add virtio-vsock support to<br>
Nova. To quote his explanation, " think of this as UNIX domain sockets<br>
between the host and guest. [...] It'd likely address at least some<br>
people's security concerns wrt metadata service. It would also fix the<br>
ability to use the metadata service in IPv6-only environments, as we<br>
would not be using IP at all."<br>
<br>
So to those operators who are not deploying the metadata service -<br>
what are your reasons for doing so, and would those concerns be<br>
addressed by Dan's idea?<br>
<br>
Cheers!<br>
<br>
[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2017-February/112490.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2017-<wbr>February/112490.html</a><br>
[2] <a href="http://lists.openstack.org/pipermail/openstack-dev/2017-February/112602.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2017-<wbr>February/112602.html</a><br>
<br>
--<br>
Artom Lifshitz<br>
<br>
______________________________<wbr>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.<wbr>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a><br>
</blockquote></div><br></div>