[RFC] exposing 'nodedev assigned to domain' info to users

[Daniel P. Berrangé]

On Wed, Jan 06, 2021 at 02:40:15PM -0300, Daniel Henrique Barboza wrote:
> 
> 
> On 1/6/21 2:30 PM, Daniel P. Berrangé wrote:
> > On Wed, Jan 06, 2021 at 02:24:35PM -0300, Daniel Henrique Barboza wrote:
> > > 
> > > 
> > > On 1/6/21 8:13 AM, Erik Skultety wrote:
> > > > On Wed, Jan 06, 2021 at 08:00:52AM -0300, Daniel Henrique Barboza wrote:
> > > > > 
> > > > > 
> > > > > On 1/6/21 7:09 AM, Daniel P. Berrangé wrote:
> > > > > > On Tue, Jan 05, 2021 at 05:18:13PM -0300, Daniel Henrique Barboza wrote:
> 
> [...]
> 
> 
> > > > > > 
> > > > > > 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.
> > > > > 
> > > > > One possible alternative would be a new API that operates on hostdevs instead
> > > > > of nodedevs. "hostdev-list" would list the devices assigned to any domain, as
> > > > > opposed to "nodedev-list" that lists all nodedevs of the host. I'm not sure if this
> > > > > differentiation between hostdev and nodedev (i.e. hostdev is a nodedev that is
> > > > > assigned to a domain) would be clear enough to users though. We would need to
> > > > > document it clearer in the docs.
> > > > 
> > > > Wasn't this about the connection to the nodedev though? E.g. with mdevs we only
> > > > have a UUID in the domain XML which doesn't tell you anything about the device
> > > > nor its parent and you also can't take the uuid and try finding the
> > > > corresponding nodedev entry for it (well, you can hack it so that you construct
> > > > the resulting nodedev name). Maybe I'm just misunderstanding the use case
> > > > though.
> > > 
> > > This particular case I'm asking for comments is related to PCI hostdevs (namely,
> > > SR-IOV virtual functions) that might get removed from the host, while being
> > > assigned to a running domain. We don't support that (albeit I posted patches
> > > that tries to alleviate the issue in Libvirt), and at the same time we don't
> > > provide easy tools for the user to check whether a specific hostdev is
> > > assigned to a domain. The user must query the running domains to find out.
> > 
> > This isn't all that much different to other host resources that are given
> > to guests. eg if pinning vCPUs 1:1 to pCPUs, the admin/mgmt app has to
> > keep track of which pCPUs are used. If assuming host block devices to a
> > guest, the admin/mgmt app has to keep track of block devices in use.
> > If assigning NICs for dedicated guest use the admin/mgmt app has to keep
> > track. etc, etc.
> > 
> > Apps like oVirt, OpenStack, KubeVirt will all do this tracking themselves
> > generally. This is especially important when they need to have this usage
> > information kept on a separate host so that the schedular can use it
> > when deciding which host to place a new guest on.
> > 
> > So, I'm not entirely convinced libvirt needs has a critical need to do
> > anything for PCI devices in this respect.
> 
> I agree that whether we implement this or not, this is a feature 'good to have'
> at best, that just the average admin that has access to a SR-IOV card and
> doesn't have OVirt like apps to manage the VMs will end up using. Not sure how
> many ppl out there that fits this profile TBH.
> 
> Definitely nothing that warrants breaking thing to implement.

For the adhoc use case we don't especially need to know which VM is using
a PCI devices. We just need to know that the device is in use or not.

We know if a PCI device is in use because it will be bound to a specific
kernel driver whenever assigned. Could we use this perhaps as a way to
filter the list of node devs to only show those which are not assigned


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 :|