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 :| _______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
