RFC: New APIs for delegation of privileged operations

[Daniel P. Berrangé]

On Tue, Nov 29, 2022 at 09:05:33AM -0800, Andrea Bolognani wrote:
> Proposal
> --------
> 
> In order to address the issues outlined above, I propose that we
> introduce a new set of APIs in libvirt.
> 
> These APIs would expose some of the inner workings of libvirt, and
> as such would come with *massively reduced* stability guarantees
> compared to the rest of our public API.
> 
> The idea is that applications such as KubeVirt, which track libvirt
> fairly closely and stay pinned to specific versions, would be able to
> adapt to changes in these APIs relatively painlessly. More
> traditional management applications such as virt-manager would simply
> not opt into using the new APIs and maintain the status quo.
> 
> Using memlock as an example, the new API could look like
> 
>     typedef int (*virInternalSetMaxMemLockHandler)(pid_t pid,
>                                                    unsigned long long bytes);
> 
>     int virInternalSetProcessSetMaxMemLockHandler(virConnectPtr conn,
> virInternalSetMaxMemLockHandler handler);

I don't think this is a workable approach. A client connection to
libvirt is a transient thing. We expect disconects+reconnects, and
the VM needs to continue functioning throughout. We also expect
there to be multiple clients sometimes. Even if most callbacks are
only needed at VM startup, for KubeVirt, if we're going to design
a privilege offload mechanism, we need to consider the broader
picture.  We need a mechanism that works for all VMs at all phases
of their lifecycle, regardless of client connections that may or
may not be present.

IOW this is not something that can be wired into a public facing
client API, it needs to be in-process for virtqemud.

So what we're looking at here is better thought off as a platform
backend "plugin". IOW, something would provide a plugin .so file
for virtqemud, which can expose callbacks that can handle various
low level operations. The plugin to be loaded would be configured
at host deploy time.



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