[libvir] How to seek a running QEMU instance
Hi, I have the following question. How can virsh (or, more accurately, libvirt) detect a running QEMU vm, when latter was already started? For example, I have got the following: [aspsk@localhost Server-4.0.1]$ qemu -hda Server-4.0.1.img -m 256 & [1] 12001 [aspsk@localhost Server-4.0.1]$ Could not configure '/dev/rtc' to have a 1024 Hz timer. This is not a fatal error, but for better emulation accuracy either use a 2.6 host Linux kernel or type 'echo 1024 > /proc/sys/dev/rtc/max-user-freq' as root. Could not open '/dev/kqemu' - QEMU acceleration layer not activated: No such file or directory Could not open '/dev/qvm86' - QEMU acceleration layer not activated: No such file or directory [aspsk@localhost Server-4.0.1]$ sudo virsh -c qemu:///system list --all Id Name State ---------------------------------- [aspsk@localhost Server-4.0.1]$ A.
On Tue, Mar 18, 2008 at 05:47:38PM +0300, Anton Protopopov wrote:
Hi, I have the following question. How can virsh (or, more accurately, libvirt) detect a running QEMU vm, when latter was already started? For example, I have got the following:
It doesn't. Libvirt only manages QEMU instances that it started itself. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Tue, Mar 18, 2008 at 05:47:38PM +0300, Anton Protopopov wrote:
I have the following question. How can virsh (or, more accurately, libvirt) detect a running QEMU vm, when latter was already started? For example, I have got the following:
As Dan says, it doesn't, but this is kind of a bug in libvirt. It is in theory possible for libvirt to enumerate running qemu/kvm instances, eg. by looking at the process table. But this is rather nasty. A better way would be to allow qemu processes to drop a monitor socket into a well-known directory; something like: qemu -monitor unix:/var/run/libvirt/monitors/<uuid> (and perhaps wrap this up in a shell script to make it simpler for users to start their own qemu instances and have them transparently managed by libvirt). This would also allow libvirtd to be restarted without killing the qemu guests (I think ...). Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v
On Tue, Mar 18, 2008 at 06:38:44PM +0000, Richard W.M. Jones wrote:
On Tue, Mar 18, 2008 at 05:47:38PM +0300, Anton Protopopov wrote:
I have the following question. How can virsh (or, more accurately, libvirt) detect a running QEMU vm, when latter was already started? For example, I have got the following:
As Dan says, it doesn't, but this is kind of a bug in libvirt.
It is in theory possible for libvirt to enumerate running qemu/kvm instances, eg. by looking at the process table. But this is rather nasty.
A better way would be to allow qemu processes to drop a monitor socket into a well-known directory; something like:
qemu -monitor unix:/var/run/libvirt/monitors/<uuid>
(and perhaps wrap this up in a shell script to make it simpler for users to start their own qemu instances and have them transparently managed by libvirt).
This is one part, but it is not sufficient as we can't determine the full config associated with an existing VM.
This would also allow libvirtd to be restarted without killing the qemu guests (I think ...).
Yes, that would work, since libvirt already has the VM config in that scenario Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Tue, Mar 18, 2008 at 06:46:45PM +0000, Daniel P. Berrange wrote:
This is one part, but it is not sufficient as we can't determine the full config associated with an existing VM.
There's a fair bit we can get but as you say not the full picture. However I'm pretty sure we can get patches into upstream QEMU to get the rest, as with 'info blockstats' which had a relatively smooth passage upstream. XML QEMU command name 'info name' although this command seems to do nothing for me uuid ? - perhaps from socket name memory not available (parse qemu command line?) vcpus 'info cpus' os/type ? - from process name or command line? os/boot not available (parse qemu command line?) devices/emulator process name devices/disk 'info block' devices/interface 'info network' (somewhat indirectly) devices/graphics 'info vnc' (I think) Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top
participants (3)
-
Anton Protopopov -
Daniel P. Berrange -
Richard W.M. Jones