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)?
Erik