On Fri, 04 May 2012 10:50:08 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > However, I've ran into a different issue today: migrating while suspended
> > doesn't work. The target VM seems to be locked into S3, it just doesn't
> > resume.
> >
> > Haven't investigated yet, but this is expected to work
On Fri, 04 May 2012 15:54:26 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > There's a quite simple and stupid way to do it. When we migrate an stopped
> > VM, it's automatically resumed on the target. We could do the same for a
> > suspended VM: we could automatically resume it before migrating, as yo
Hi,
> There's a quite simple and stupid way to do it. When we migrate an stopped
> VM, it's automatically resumed on the target. We could do the same for a
> suspended VM: we could automatically resume it before migrating, as you said
> above.
>
> That's not the behavior I'd expect, I mean I wo
Hi,
> However, I've ran into a different issue today: migrating while suspended
> doesn't work. The target VM seems to be locked into S3, it just doesn't
> resume.
>
> Haven't investigated yet, but this is expected to work, right?
Well, that one is still on the todo list. There is the tempor
On Thu, 03 May 2012 09:56:52 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > I think that the question we have to answer is: apart from the keyboard
> > and mouse, is there any device that wants to run while qemu is suspended?
>
> pretty much anything which may wake up the guest. The nics for example
Hi,
> I think that the question we have to answer is: apart from the keyboard
> and mouse, is there any device that wants to run while qemu is suspended?
pretty much anything which may wake up the guest. The nics for example
for wake-on-lan. I'm not sure whenever they care about the runstate
On Wed, 02 May 2012 09:08:55 +0200
Gerd Hoffmann wrote:
> > diff --git a/input.c b/input.c
> > index 6b5c2c3..47e6900 100644
> > --- a/input.c
> > +++ b/input.c
> > @@ -130,7 +130,7 @@ void qemu_remove_led_event_handler(QEMUPutLEDEntry
> > *entry)
> >
> > void kbd_put_keycode(int keycode)
> >
> diff --git a/input.c b/input.c
> index 6b5c2c3..47e6900 100644
> --- a/input.c
> +++ b/input.c
> @@ -130,7 +130,7 @@ void qemu_remove_led_event_handler(QEMUPutLEDEntry *entry)
>
> void kbd_put_keycode(int keycode)
> {
> -if (!runstate_is_running()) {
> +if (!runstate_is_running() && !
QEMU enters in this state when the guest suspends to ram (S3).
This is important so that HMP users and QMP clients can know that
the guest is suspended. QMP clients also have an event for this,
but events are not reliable and are limited (ie. a client can
connect to QEMU after the event has been e
