[systemd-devel] Utility for persistent alternative driver binding

[Charles (Chas) Williams]

 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.