[libvirt-users] Obtaining the PID of a domain's QEMU process from C

[Daniel P. Berrangé]

On Mon, Mar 11, 2019 at 10:49:45AM +0100, Erik Skultety wrote:
> On Mon, Mar 11, 2019 at 09:46:11AM +0000, Daniel P. Berrangé wrote:
> > On Mon, Mar 11, 2019 at 09:33:30AM +0100, Michal Privoznik wrote:
> > > On 3/11/19 9:02 AM, Erik Skultety wrote:
> > > > On Sat, Mar 09, 2019 at 04:32:00PM +0100, Michal Prívozník wrote:
> > > > > On 3/1/19 2:31 AM, Shawn Anastasio wrote:
> > > > > > Hello all,
> > > > > >
> > > > > > I'm currently writing a C program that uses the libvirt API and I need a
> > > > > > way to obtain the pid of a given domain's QEMU process.
> > > > > >
> > > > > > Specifically, I'm writing an ivshmem server that uses SO_PEERCRED to get
> > > > > > the pid of clients that connect to it, and I would like to use that pid
> > > > > > to look up the domain in libvirt to determine the proper domain ID to
> > > > > > return to the client.
> > > > > >
> > > > > > As far as I can tell, libvirt doesn't expose this information in an easy
> > > > > > to access manner. Of course it is possible to call `ps` and grep for the
> > > > > > information I'm looking for, but I was hoping for a cleaner solution.
> > > > > >
> > > > > > If anybody knows how to do this, advice would be greatly appreciated.
> > > > >
> > > > > There isn't an API for that as we don't want users to fiddle with qemu
> > > >
> > > > That's right, and it should stay that way. On the other hand, the same way we
> > > > can't prevent anyone from editing /etc/libvirt/qemu/<domain>.xml or
> > > > /var/run/libvirt/qemu/<domain>.xml or run the 'ps' command or whatever we might
> > > > as well report the PID as part of virConnectListAllDomains data. I don't have
> > > > a problem with reporting PIDs in principle, provided it's used for informatory
> > > > purposes.
> > > > Having said that, there's the question of why libvirt should report something
> > > > that it doesn't need to consume, IOW we report machine ID which we can use to
> > > > control the machine, we also report UUID which we can consume, but we'd do
> > > > absolutely nothing with the PID besides reporting it.
> > > > Another thing is that reporting PIDs of machines running on a remote host is
> > > > quite useless for locally running clients.
> > >
> > > Alternatively, we may do what LXC driver already does -> domain ID is PID of
> > > init running within the container. In QEMU driver, the domain ID can be PID
> > > of qemu then.
> >
> > I would not want todo that - in fact I've wanted to remove that aspect
> > of the LXC driver as it is misleading. People think its the PID of the
> > first proess in the container, but it is in fact the PID of the controller
> > in the host.   Also I like low-numbered domain IDs :-)
> 
> Do you also have an opinion about potentially exposing PID as part of the
> virDomain data I mentioned above (eventhough I'm a bit skeptical about that
> myself)?

I would not like to expose any PID because it puts across the misleading
impression that the VM is represented by a single process. It is increasingly
clear that QEMU is heading in a direction of splitting up to provide a
multitude of processes each with distinct jobs. As such I think it is
important that the notion of how many processes are used remain an internal
impl detail not exposed to applications.

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