I have a qemu-kvm guest (apparently a Ubuntu 11.04 x86-64 install) which has
stopped and refuses to continue:
(qemu) info status
VM status: paused
(qemu) cont
(qemu) info status
VM status: paused
The host is running linux 2.6.39.2 with qemu-kvm 0.14.1 on 24-core Opteron
6176 box, and
Am 24.10.2011 12:00, schrieb Chris Webb:
I have a qemu-kvm guest (apparently a Ubuntu 11.04 x86-64 install) which has
stopped and refuses to continue:
(qemu) info status
VM status: paused
(qemu) cont
(qemu) info status
VM status: paused
The host is running linux 2.6.39.2 with
Kevin Wolf kw...@redhat.com writes:
Am 24.10.2011 12:00, schrieb Chris Webb:
I have qemu monitor access and can even strace the relevant qemu process if
necessary: is it possible to use this to diagnose what's caused this guest
to stop, e.g. the unsupported instruction if it's an emulation
Am 24.10.2011 12:58, schrieb Chris Webb:
Kevin Wolf kw...@redhat.com writes:
Am 24.10.2011 12:00, schrieb Chris Webb:
I have qemu monitor access and can even strace the relevant qemu process if
necessary: is it possible to use this to diagnose what's caused this guest
to stop, e.g. the
Kevin Wolf kw...@redhat.com writes:
In qemu 1.0 we'll have an extended 'info status' that includes the stop
reason, but 0.14 doesn't have this yet (was committed to git master only
recently).
Right, okay. I might take a look at cherry-picking and back-porting that to
our version of qemu-kvm
Am 24.10.2011 13:29, schrieb Chris Webb:
Kevin Wolf kw...@redhat.com writes:
In qemu 1.0 we'll have an extended 'info status' that includes the stop
reason, but 0.14 doesn't have this yet (was committed to git master only
recently).
Right, okay. I might take a look at cherry-picking and
Kevin Wolf kw...@redhat.com writes:
Good point... The only other thing that I can think of would be
attaching gdb and setting a breakpoint in vm_stop() or something.
Perfect, that seems to identified what's going on very nicely:
(gdb) break vm_stop
Breakpoint 1 at 0x407d10: file
