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

[Daniel Henrique Barboza]

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.


Thanks,

DHB

> 
>> About mdevs, isn't a mdev device created on demand via hypercalls to the physical
>> device driver, and threw away after use, the only real device being the parent?
>> I'm not sure whether there is a use case/requirement for knowing the parent
>> nodedev device. The parent device can be retrieved via sysfs AFAIC.
> 
> We shouldn't assume mdevs are created on demand. It is reasonable to precreate
> those which are needed at initial machine bootup.
> 
> 
> Regards,
> Daniel
>