From: Yonit Halperin <yhalperi@redhat.com>
To: Gerd Hoffmann <kraxel@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: Mon, 12 Mar 2012 20:45:46 +0200 [thread overview]
Message-ID: <4F5E445A.7000201@redhat.com> (raw)
In-Reply-To: <4F5DFF3B.3040007@redhat.com>
Hi,
On 03/12/2012 03:50 PM, Gerd Hoffmann wrote:
> Hi,
>
>> Can you explain/exemplify, why sending data as a blob (either by (a) or
>> (b)), that is verified only by the two ends that actually use it, is a
>> problem?
>
> It tends to be not very robust. Especially when the creating/parsing is
> done ad-hoc and the format changes now and then due to more info needing
> to be stored later on. The qemu migration format which has almost no
> structure breaks now and then because of that. Thus I'd prefer to not
> go down this route when creating something new.
>
> cheers,
> Gerd
Exposing spice server internals to the client/qemu seems to me more
vulnerable then sending it as a blob. Nonetheless, it introduces more
complexity to backward compatibility support and it will need to involve
not only the capabilities/versions of the server but also those of the
qemu/client. Which reminds me, that we also need capabilities
negotiation for the migration protocol between the src and the destination.
Regards,
Yonit.
next prev parent reply other threads:[~2012-03-12 18:47 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 [this message]
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=4F5E445A.7000201@redhat.com \
--to=yhalperi@redhat.com \
--cc=alevy@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=hdegoede@redhat.com \
--cc=kraxel@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=spice-devel@freedesktop.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.