libvirt users - Mar 2019 - Re: Obtaining the PID of a domain's QEMU process from C

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

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

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

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