From: Gerd Hoffmann <kraxel@redhat.com>
To: Yonit Halperin <yhalperi@redhat.com>
Cc: Anthony Liguori <anthony@codemonkey.ws>,
Hans de Goede <hdegoede@redhat.com>, Alon Levy <alevy@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>,
"spice-devel@freedesktop.org" <spice-devel@freedesktop.org>
Subject: Re: [Qemu-devel] [Spice-devel] seamless migration with spice
Date: Tue, 13 Mar 2012 08:40:17 +0100 [thread overview]
Message-ID: <4F5EF9E1.2000701@redhat.com> (raw)
In-Reply-To: <4F5EEEC5.4040400@redhat.com>
Hi,
> It is not easy when you have 2 components, and it is much less easy when
> you have 3 or 4 components. So why make it more complicated if you can
> avoid it. Especially since there is no functional reason for making the
> qemu/client capabilities/versions dependent on the server internal data.
qemu has ways to handle compatibility in the vmstate format. We can use
those capabilities. That of course requires exposing the structs to be
saved to qemu and adds some complexity to the qemu <-> spice interface.
What session state is needed by the target?
What of this can be negotiated between client and target host without
bothering the source?
What needs be transfered from source to target, either directly or via
client?
>> If this is a hard requirement then using the vmstate channel isn't going
>> to work. The vmstate is a one-way channel, no way to negotiate anything
>> between source and target.
>>
> We can do this via the client.
Then you can send the actual state via client too.
Out-of-band negotiation for the blob send via vmstate scares me.
Can we please start with a look at which state we actually have to send
over?
cheers,
Gerd
next prev parent reply other threads:[~2012-03-13 7:40 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
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 [this message]
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=4F5EF9E1.2000701@redhat.com \
--to=kraxel@redhat.com \
--cc=alevy@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=hdegoede@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).