qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Yonit Halperin <yhalperi@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	"spice-devel@freedesktop.org" <spice-devel@freedesktop.org>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] seamless migration with spice
Date: Sun, 11 Mar 2012 10:36:50 -0500	[thread overview]
Message-ID: <4F5CC692.7050002@codemonkey.ws> (raw)
In-Reply-To: <20120311152528.GD7273@garlic.redhat.com>

On 03/11/2012 10:25 AM, Alon Levy wrote:
> On Sun, Mar 11, 2012 at 09:18:17AM -0500, Anthony Liguori wrote:
>> On 03/11/2012 08:16 AM, Yonit Halperin wrote:
>>> Hi,
>>>
>>> We would like to implement seamless migration for Spice, i.e., keeping the
>>> currently opened spice client session valid after migration.
>>> Today, the spice client establishes the connection to the destination before
>>> migration starts, and when migration completes, the client's session is moved to
>>> the destination, but all the session data is being reset.
>>>
>>> We face 2 main challenges when coming to implement seamless migration:
>>>
>>> (1) Spice client must establish the connection to the destination before the
>>> spice password expires. However, during migration, qemu main loop is not
>>> processed, and when migration completes, the password might have already expired.
>>>
>>> Today we solve this by the async command client_migrate_info, which is expected
>>> to be called before migration starts. The command is completed
>>> once spice client has connected to the destination (or a timeout).
>>>
>>> Since async monitor commands are no longer supported, we are looking for a new
>>> solution.
>>
>> We need to fix async monitor commands.  Luiz sent a note our to
>> qemu-devel recently on this topic.
>>
>> I'm not sure we'll get there for 1.1 but if we do a 3 month release
>> cycle for 1.2, then that's a pretty reasonable target IMHO.
>
> What about the second part? it's independant of the async issue.

Isn't this a client problem?  The client has this state, no?

If the state is stored in the server, wouldn't it be marshaled as part of the 
server's migration state?

I read that as the client needs to marshal it's own local state in the session 
and restore it in the new session.

Regards,

Anthony Liguori

>
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>> The straightforward solution would be to process the main loop on the
>>> destination side during migration.
>>>
>>> (2) In order to restore the source-client spice session in the destination, we
>>> need to pass data from the source to the destination.
>>> Example for such data: in flight copy paste data, in flight usb data
>>> We want to pass the data from the source spice server to the destination, via
>>> Spice client. This introduces a possible race: after migration completes, the
>>> source qemu can be killed before the spice-server completes transferring the
>>> migration data to the client.
>>>
>>> Possible solutions:
>>> - Have an async migration state notifiers. The migration state will change after
>>> all the notifiers complete callbacks are called.
>>> - libvirt will wait for qmp event corresponding to spice completing its
>>> migration, and only then will kill the source qemu process.
>>>
>>> Any thoughts?
>>>
>>> Thanks,
>>> Yonit.
>>>
>>
>>

  reply	other threads:[~2012-03-11 15:37 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-11 13:16 [Qemu-devel] seamless migration with spice Yonit Halperin
2012-03-11 14:18 ` Anthony Liguori
2012-03-11 15:25   ` Alon Levy
2012-03-11 15:36     ` Anthony Liguori [this message]
2012-03-11 19:11       ` Yonit Halperin
2012-03-12  7:57       ` Gerd Hoffmann
2012-03-12  8:51         ` [Qemu-devel] [Spice-devel] " Hans de Goede
2012-03-12  9:46           ` Gerd Hoffmann
2012-03-12 10:03             ` Alon Levy
2012-03-12 10:26               ` Gerd Hoffmann
2012-03-12 11:29                 ` Alon Levy
2012-03-12 11:34                   ` Gerd Hoffmann
2012-03-12 11:45                     ` Alon Levy
2012-03-12 12:44                       ` Gerd Hoffmann
2012-03-12 14:24                         ` Alon Levy
2012-03-12 14:35                           ` Alon Levy
2012-03-12 11:23             ` Hans de Goede
2012-03-12 12:21               ` Gerd Hoffmann
2012-03-12 12:47             ` Yonit Halperin
2012-03-12 13:50               ` Gerd Hoffmann
2012-03-12 18:45                 ` Yonit Halperin
2012-03-13  6:40                   ` Gerd Hoffmann
2012-03-13  6:52                     ` Yonit Halperin
2012-03-13  7:40                       ` Gerd Hoffmann
2012-03-12 11:39           ` David Jaša
2012-03-12  8:42 ` Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F5CC692.7050002@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=spice-devel@freedesktop.org \
    --cc=yhalperi@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).