[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Spice-devel] seamless migration with spice
From: |
Gerd Hoffmann |
Subject: |
Re: [Qemu-devel] [Spice-devel] seamless migration with spice |
Date: |
Mon, 12 Mar 2012 10:46:44 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 |
Hi,
> The problem with (b) is, that iirc the way b was implemented in the past
> was still the big blob approach, but then pass the blob through the client,
> which means an evil client could modify it, causing all sorts of
> "interesting"
> behavior inside spice-server. Since we're re-implementing this to me the
> send a blob through the client approach is simply not acceptable from a
> security pov, also see my previous mail in this thread.
Agree. It should be a normal spice message which goes through the spice
marshaller for parsing & sanity checking.
> I disagree. Note that there is more info to send over then just which
> surfaces / images are cached by the client. There also is things like
> partial complete agent channel messages, including how much bytes must
> be read
> to complete the command, etc.
Is there a complete list of the session state we need to save?
> IMHO (b) would only be acceptable if the data send through the client stops
> becoming a blob.
Using (a) to send a blob isn't better.
> Instead the client could simply send a list of all
> surface ids,
> etc. which it has cached after it connects to / starts using the new
> host. Note
> that the old hosts needs to send nothing for this, this is info the
> client already
> has, also removing the need for synchronization.
Yes, some session state is known to the client anyway so we don't need a
source <-> target channel for them.
> As for certain other
> data, such
> as (but not limited to) partially parsed agent messages, these should be
> send through the regular vmstate methods IMHO.
That isn't easy to handle via vmstate, at least as soon as this goes
beyond a fixed number of fields aka 'migrate over this struct for me'.
Think multiple spice clients connected at the same time.
> 1) Do (a), sending everything that way
> 2) Do (a) sending non client state that way; and
> let the client send state like which surfaces it has cached
> when the new session starts.
I think we have to look at each piece of state information needed by the
target and look how to handle this best.
cheers,
Gerd
- [Qemu-devel] seamless migration with spice, Yonit Halperin, 2012/03/11
- Re: [Qemu-devel] seamless migration with spice, Anthony Liguori, 2012/03/11
- Re: [Qemu-devel] seamless migration with spice, Alon Levy, 2012/03/11
- Re: [Qemu-devel] seamless migration with spice, Anthony Liguori, 2012/03/11
- Re: [Qemu-devel] seamless migration with spice, Yonit Halperin, 2012/03/11
- Re: [Qemu-devel] seamless migration with spice, Gerd Hoffmann, 2012/03/12
- Re: [Qemu-devel] [Spice-devel] seamless migration with spice, Hans de Goede, 2012/03/12
- Re: [Qemu-devel] [Spice-devel] seamless migration with spice,
Gerd Hoffmann <=
- Re: [Qemu-devel] [Spice-devel] seamless migration with spice, Alon Levy, 2012/03/12
- Re: [Qemu-devel] [Spice-devel] seamless migration with spice, Gerd Hoffmann, 2012/03/12
- Re: [Qemu-devel] [Spice-devel] seamless migration with spice, Alon Levy, 2012/03/12
- Re: [Qemu-devel] [Spice-devel] seamless migration with spice, Gerd Hoffmann, 2012/03/12
- Re: [Qemu-devel] [Spice-devel] seamless migration with spice, Alon Levy, 2012/03/12
- Re: [Qemu-devel] [Spice-devel] seamless migration with spice, Gerd Hoffmann, 2012/03/12
- Re: [Qemu-devel] [Spice-devel] seamless migration with spice, Alon Levy, 2012/03/12
- Re: [Qemu-devel] [Spice-devel] seamless migration with spice, Alon Levy, 2012/03/12
- Re: [Qemu-devel] [Spice-devel] seamless migration with spice, Hans de Goede, 2012/03/12
- Re: [Qemu-devel] [Spice-devel] seamless migration with spice, Gerd Hoffmann, 2012/03/12