3:47 p.m.
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.
3:52 p.m.
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 :|
7:38 p.m.
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
7:46 p.m.
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 :|
10:50 a.m.
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
6028
days inactive
6029
days old
4 comments
3 participants
participants (3)
-
Anton Protopopov -
Daniel P. Berrange -
Richard W.M. Jones