On Wed, Jun 27, 2018 at 07:02:36AM +0300, Michael S. Tsirkin wrote: > On Tue, Jun 26, 2018 at 10:49:33PM -0500, Venu Busireddy wrote: > > Add the "Vendor-Specific" capability to the Red Hat PCI bridge device > > "pci-bridge", to contain the "Group Identifier" (UUID) that will be > > used to pair a virtio device with the passthrough device attached to > > that bridge. > > > > This capability is added to the bridge iff the "uuid" option is specified > > for the bridge. > > I think the name should be more explicit. How about "failover-group-id"? > > > > > Signed-off-by: Venu Busireddy <venu.busire...@oracle.com> > > I'd like to also tweak the device id in this case, > to make it easier for guests to know it's a grouping bridge.
I tend to think this proposal is rather too narrow. The need to tell the guest OS about the intended usage of devices is a pretty common use case, of which setting up bonding NIC pair is just one example. OpenStack already has this problem & took the approach of providing some structured JSON metadata to the guest that lists all devices (well NICs and disks at least) with identifying metadata (eg PCI address, MAC addr, disk serial and anything else relevant), and also assigns freeform string "tags" against each. eg the host admin could specify tags "lanA" and "lanB" for two NICs, so the guest knows which NIC to use for which purpose. This kind of tagging could easily cover setting up bonded pairs. Or for a disk they could tag it "oracledata" or "apachecache" to indicate what kind of data to use on the disk, etc https://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/virt-device-role-tagging.html I'm not suggesting the impl used in OpenStack is perfect - there's a number of pain points in it, but I think it shows the need for a general solution to the problem of the host admin informing the guest OS about the intended usage of devices being provided. I think freeform string tags do this pretty well. The key problem is how to expose such tags - openstack took approach of an out of band JSON doc exposed from its metadata service and or cloud init config drive, because that was its only viable option. Perhaps there is a way to expose tags at a low level though if we can integrate with QEMU somehow ? Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
