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

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.

Erik
> behid its back. Anyway, apart from ps there might be a solution. Libvirt
> of course know the PID and stores it - in the status XML. This is a file
> that libvirt uses to store runtime information for the domain in case
> the daemon restarts. It's located under
> /var/run/libvirt/qemu/$domain.xml. But you'll need root priviledges to
> read it.
>
> Also, it is very wise to follow the comment at the beginning of the file
> and not modify it ;-) And just like with any libvirt internals, we make
> no guarantees they won't change in the long run.
>
> Michal
>
> _______________________________________________
> libvirt-users mailing list
> libvirt-users@redhat.com
> https://www.redhat.com/mailman/listinfo/libvirt-users

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.

Michal

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