[RFC] exposing 'nodedev assigned to domain' info to users
Daniel P. Berrangé
berrange at redhat.com
Wed Jan 6 10:09:17 UTC 2021
On Tue, Jan 05, 2021 at 05:18:13PM -0300, Daniel Henrique Barboza wrote:
> This is something I've been giving a thought after working in Gitlab issue
> #72 and decided to run through the ML before hitting the code.
> We don't have an easy way to retrieve the domain that is using an specific
> hostdev. Let's say that I want to know which domain is using the PCI card
> pci_0000_01_00_2. 'nodedev-dumpxml' will return the hardware/driver capabilities
> of the device, such as IOMMU group, driver and so on, but will not inform
> which domain is using the hostdev, if any. 'nodedev-list' will simply list
> all nodedev names known to Libvirt, without outputting any other information.
> IIUC, the only existing way I can reliably tell whether a hostdev is being
> used by domain, aside from having to register the information by myself
> during domain definition of course, is via 'virsh dumpxml <domain>' each
> existing running domain and matching the nodedev name with the source.address
> element of the XML.
> When we consider SR-IOV devices that can have 28+ VFs each (and have lots of
> fun caveats, like Github #72 showed us), the capability of hot plug/unplug
> hostdevs freely, and lots of running domains, it is clear that we're putting a
> considerable pressure in the upper layers (OVirt, or a poor human admin) to
> keep track of the nodedevs each running domain is using. An info that we
> already have internally and can just expose it.
> I have a few ideas to make this happen:
> 1 - upgrade 'nodedev-list' to add an extra 'assigned to' column
> This is the more straightforward way of exposing the info. A simple 'nodedev-list'
> call can retrieve which domain is using which nodedev. To preserve the existing
> usage we can add an "--show-assigned-domains" option to control whether we
> will display this info.
That would mean nodedev-list has to fetch XML for every running guest
and parse and extract it. That's not a scalable solution.
> 2 - add an '<assigned_to>' element in nodedev XML definition
> I'm not a fan of exposing this in this particular XML because we would mix
> host/hw related attributes with domain info. But it would be easier to pull
> this off comparing to (1), so I'm mentioning it for the record.
This is similar to what we do for the nwfilter-binding and net-port XML
where we have an <owner> element present.
The complication here is that right now we don't ever touch the nodedev
driver when doing host device assignment, and so don't especially want
to introduce a dependancy.
|: 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 :|
More information about the libvir-list