[systemd-devel] Utility for persistent alternative driver binding

[Daniel P. Berrange]

On Tue, Dec 08, 2015 at 09:46:13AM -0500, Charles (Chas) Williams wrote:
>  On Tue, 2015-12-08 at 14:21 +0000, Daniel P. Berrange wrote:
> > On Tue, Dec 08, 2015 at 09:14:17AM -0500, Charles (Chas) Williams wrote:
> > > On Tue, 2015-12-08 at 11:34 +0200, Panu Matilainen wrote:
> > > > Hmm, got a pointer? I dont think PCI slots change between reboots 
> > > > without physically swapping hardware, the "ethX-problem" comes from the 
> > > > order of device discovery being unstable across boots, which is a 
> > > > different issue and not relevant for this case.
> > > 
> > > With virtual machines the ordering of PCI devices isn't always the same.
> > > This is especially true with OpenStack which regenerates the
> > > configurations on the fly.  The only thing that seems to be consistent
> > > is the MAC address.
> > 
> > The MAC address is not guaranteed to be unique of course - you can have
> > multiple NICs with the same MAC provided they're connected to different
> > subnets.
> 
> Typically not done but yes it can happen.  I was referring specifically
> to the OpenStack case though where it causes the most trouble for me.
> 
> > For OpenStack we're working on a feature that allows the user booting
> > an OpenStack instance to associate an arbitrary tag with each device
> > they have on their VM. The info about the tags and the currently assigned
> > device addresses is then exposed to the guest OS via the metadata service
> > and/or config drive and/or firmware. There will be a utility that can read
> > this metadata and then register tags against the corresponding devices in
> > the udev database.
> > 
> > The idea is that people building OpenStack compatible cloud images can
> > configure their image to look for the device in udev with the desired
> > user "tag" string. That way they don't need to care about specific
> > device addresses directly. More info on OpenStack plans is here:
> > 
> >   http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/virt-device-role-tagging.html
> 
> That would be a huge step forward but I need this to work when someone
> hotplugs an interface to a running image.  The config drive doesn't work
> here since it wouldn't have the tag information.  The metadata service
> might work (although I think cloud-init blackholes the metadata service
> after boot).  Exposing this via the PCI device with some ACPI mechanism
> would be nice.

Yep, config drive is obviously useless for hotplug, but metadata service
is usable in the short term. There is QEMU work to let us expose data
via the firmware, but not sure help hotplug really. The would really
be a virtio based filesystem like virtio-9p except without the suckiness
of 9p - a future virtio-nfs might be best.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|