Very lengthy discussion, apologies if I repeat something in one of the
various threads but I read lots of these discussions and I'm somewhat
confused still of what this is all about...
On Wed, Nov 25, 2009 at 04:09:55PM +0200, Michael S. Tsirkin wrote:
> We were discussing features that are (mostl
On Wed, Nov 25, 2009 at 04:10:34PM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" wrote:
> > On Tue, Nov 24, 2009 at 08:33:11AM -0600, Anthony Liguori wrote:
> >> Michael S. Tsirkin wrote:
> >>> It's very easy: if their guest runs fine on the old qemu,
> >>> it should be safe to migrate there.
On Wed, Nov 25, 2009 at 03:53:40PM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" wrote:
> > On Wed, Nov 25, 2009 at 02:59:58PM +0100, Gerd Hoffmann wrote:
> >> On 11/25/09 14:40, Michael S. Tsirkin wrote:
> >>
> We could add a DeviceState->savevm field and make that available as
> p
"Michael S. Tsirkin" wrote:
> On Wed, Nov 25, 2009 at 02:59:58PM +0100, Gerd Hoffmann wrote:
>> On 11/25/09 14:40, Michael S. Tsirkin wrote:
>>
We could add a DeviceState->savevm field and make that available as
property for devices which need to support multiple versions. Then you
On 11/25/09 15:09, Michael S. Tsirkin wrote:
We were discussing features that are (mostly) not user-visible.
It is clear that if you have a user-visible change you have
a different machine, so you can not migrate.
Now if you fix a bug by changing savevm format, without user visible
changes you *
On Wed, Nov 25, 2009 at 03:10:16PM +0100, Gerd Hoffmann wrote:
> Hi,
>
>>> Doesn't work. If you have a qemu 0.11 machine, a virtio nic and your
>>> guest uses MSI-X you simply can't migrate to qemu 0.10. End of story.
>>> If you want to be able to migrate to 0.10 you have to start in 0.10
>>> c
Hi,
Doesn't work. If you have a qemu 0.11 machine, a virtio nic and your
guest uses MSI-X you simply can't migrate to qemu 0.10. End of story.
If you want to be able to migrate to 0.10 you have to start in 0.10
compat mode with MSI-X disabled. So IMHO it does makes sense to tie the
savevm f
On Wed, Nov 25, 2009 at 02:59:58PM +0100, Gerd Hoffmann wrote:
> On 11/25/09 14:40, Michael S. Tsirkin wrote:
>
>>> We could add a DeviceState->savevm field and make that available as
>>> property for devices which need to support multiple versions. Then you
>>> we can use the compat properties to
On 11/25/09 14:40, Michael S. Tsirkin wrote:
We could add a DeviceState->savevm field and make that available as
property for devices which need to support multiple versions. Then you
we can use the compat properties to switch back to the older format with
-M pc-0.10.
I'm confused sorry. Of
On Wed, Nov 25, 2009 at 02:42:25PM +0100, Gerd Hoffmann wrote:
>>> And this is also the trivial part to describe: I want a
>>> machine like the one in qemu-0.11.
>>
>> Yes, but there might be a ton of reasons to want a
>> machine like the one in qemu 0.11.
>> The need to migrate to old qemu is ve
On Wed, Nov 25, 2009 at 02:36:49PM +0100, Gerd Hoffmann wrote:
> On 11/24/09 15:05, Michael S. Tsirkin wrote:
>> On Mon, Nov 23, 2009 at 03:13:59PM +0100, Juan Quintela wrote:
But this would only kick in when using pc-0.11 or something, right?
>>>
>>> Yeap.
>>>
>>> At this point, pc-0.10 is ju
And this is also the trivial part to describe: I want a
machine like the one in qemu-0.11.
Yes, but there might be a ton of reasons to want a
machine like the one in qemu 0.11.
The need to migrate to old qemu is very rare,
it is a completely separate decision
one might take long after starting
"Michael S. Tsirkin" wrote:
> On Wed, Nov 25, 2009 at 10:30:47AM +0100, Juan Quintela wrote:
>> "Michael S. Tsirkin" wrote:
>> > On Tue, Nov 24, 2009 at 03:21:34PM +0100, Juan Quintela wrote:
>>
>> > A device already supports load for a range
>> > of versions between X and Y. We want to support
On 11/24/09 15:05, Michael S. Tsirkin wrote:
On Mon, Nov 23, 2009 at 03:13:59PM +0100, Juan Quintela wrote:
But this would only kick in when using pc-0.11 or something, right?
Yeap.
At this point, pc-0.10 is just:
static QEMUMachine pc_machine_v0_10 = {
.name = "pc-0.10",
.desc = "
On Wed, Nov 25, 2009 at 10:30:47AM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" wrote:
> > On Tue, Nov 24, 2009 at 03:21:34PM +0100, Juan Quintela wrote:
>
> > A device already supports load for a range
> > of versions between X and Y. We want to support
> > saving to a range of versions.
>
"Michael S. Tsirkin" wrote:
> On Tue, Nov 24, 2009 at 03:21:34PM +0100, Juan Quintela wrote:
> A device already supports load for a range
> of versions between X and Y. We want to support
> saving to a range of versions.
>
> Which versions to use is a separate decision
> which should be taken on
On Tue, Nov 24, 2009 at 01:29:09PM -0600, Anthony Liguori wrote:
> Paolo Bonzini wrote:
>> On 11/24/2009 07:51 PM, Anthony Liguori wrote:
to make the primary representation of state an XML document
>>
>> Since my brain is not working well today, I'll just point out that of
>> course I meant
Paolo Bonzini wrote:
On 11/24/2009 07:51 PM, Anthony Liguori wrote:
to make the primary representation of state an XML document
Since my brain is not working well today, I'll just point out that of
course I meant "the primary representation of _schemas_ an XML
document" or anything like that
Blue Swirl wrote:
But the complexity would be a problem only for the transformation
matrix project. For QEMU the gain would be simplified design, maybe at
the expense of some CPP magic.
I don't think it's always a matter of just transforming state. There
will be certain features that need
On 11/24/2009 07:51 PM, Anthony Liguori wrote:
to make the primary representation of state an XML document
Since my brain is not working well today, I'll just point out that of
course I meant "the primary representation of _schemas_ an XML document"
or anything like that.
or anything like
On Tue, Nov 24, 2009 at 8:51 PM, Anthony Liguori wrote:
> Paolo Bonzini wrote:
>>
>> On 11/24/2009 06:08 PM, Michael S. Tsirkin wrote:
> The external version translator tool could support arbitrary
> conversion between the whole NxN matrix of versions (including distro
> hac
Paolo Bonzini wrote:
On 11/24/2009 06:08 PM, Michael S. Tsirkin wrote:
> The external version translator tool could support arbitrary
> conversion between the whole NxN matrix of versions (including
distro
> hacks), or just those that RHEL happens to use. The tool would
not be
> limited to
On 11/24/2009 06:08 PM, Michael S. Tsirkin wrote:
> The external version translator tool could support arbitrary
> conversion between the whole NxN matrix of versions (including distro
> hacks), or just those that RHEL happens to use. The tool would not be
> limited to QEMU development enviro
On 11/24/2009 03:30 PM, Juan Quintela wrote:
No, new -> old is way, way more difficult.
New->old is way more difficult with the current migration file format.
The current migration file format is not at all designed to be read by
an older version.
Or for that matter a tool that only cares
On Tue, Nov 24, 2009 at 07:06:01PM +0200, Blue Swirl wrote:
> On Tue, Nov 24, 2009 at 4:21 PM, Michael S. Tsirkin wrote:
> > On Tue, Nov 24, 2009 at 01:59:49PM +, Paul Brook wrote:
> >> > > Reading in old state files is a whole lot easier (to write
> >> > > maintain, and stay sane) than produc
On Tue, Nov 24, 2009 at 4:21 PM, Michael S. Tsirkin wrote:
> On Tue, Nov 24, 2009 at 01:59:49PM +, Paul Brook wrote:
>> > > Reading in old state files is a whole lot easier (to write
>> > > maintain, and stay sane) than producing state that is bug-compatible with
>> > > previous versions.
>> >
On Tue, Nov 24, 2009 at 08:33:11AM -0600, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>> It's very easy: if their guest runs fine on the old qemu,
>> it should be safe to migrate there.
>>
>
> "Runs fine" is a qualitative statement. There is no way for qemu to
> know whether a guest ru
On Tue, Nov 24, 2009 at 03:21:34PM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" wrote:
> > On Tue, Nov 24, 2009 at 12:39:50PM +0200, Dor Laor wrote:
> >> On 11/23/2009 02:15 PM, Juan Quintela wrote:
> >>> Dor Laor wrote:
> > In the last couple of days we discovered some issues regardi
On Tue, Nov 24, 2009 at 03:21:34PM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" wrote:
> > On Tue, Nov 24, 2009 at 12:39:50PM +0200, Dor Laor wrote:
> >> On 11/23/2009 02:15 PM, Juan Quintela wrote:
> >>> Dor Laor wrote:
> > In the last couple of days we discovered some issues regardi
On Tue, Nov 24, 2009 at 03:20:47PM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" wrote:
>
> >> But to really make it work, we need to take a list of each savevm format
> >> change and put it here. Notice that several changes are needed:
> >> - savevm infrastructure save functions don't know
Michael S. Tsirkin wrote:
It's very easy: if their guest runs fine on the old qemu,
it should be safe to migrate there.
"Runs fine" is a qualitative statement. There is no way for qemu to
know whether a guest runs fine or not. There is no way that we can make
that statement either. It h
On Tue, Nov 24, 2009 at 01:59:49PM +, Paul Brook wrote:
> > > Reading in old state files is a whole lot easier (to write
> > > maintain, and stay sane) than producing state that is bug-compatible with
> > > previous versions.
> >
> > It seems to me that old->new and new->old migrations are
> >
"Michael S. Tsirkin" wrote:
> On Tue, Nov 24, 2009 at 12:39:50PM +0200, Dor Laor wrote:
>> On 11/23/2009 02:15 PM, Juan Quintela wrote:
>>> Dor Laor wrote:
> In the last couple of days we discovered some issues regarding stable
> ABI and the robustness of the live migration protocol.
"Michael S. Tsirkin" wrote:
>> But to really make it work, we need to take a list of each savevm format
>> change and put it here. Notice that several changes are needed:
>> - savevm infrastructure save functions don't know about version id
>> - devices don't know to "behave" as other version
>>
On Mon, Nov 23, 2009 at 03:13:59PM +0100, Juan Quintela wrote:
> Anthony Liguori wrote:
> > Juan Quintela wrote:
> >> Dor Laor wrote:
> >>>
> >>
> >> My idea here is that we need to have further use of machine
> >> descriptions, once that is done, we need something like a new property
> >> f
On Tue, Nov 24, 2009 at 12:39:50PM +0200, Dor Laor wrote:
> On 11/23/2009 02:15 PM, Juan Quintela wrote:
>> Dor Laor wrote:
>>> > In the last couple of days we discovered some issues regarding stable
>>> > ABI and the robustness of the live migration protocol. Let's just jump
>>> > right into i
On Mon, Nov 23, 2009 at 01:15:01PM +0100, Juan Quintela wrote:
> Dor Laor wrote:
> > In the last couple of days we discovered some issues regarding stable
> > ABI and the robustness of the live migration protocol. Let's just jump
> > right into it, ordered by complexity:
> >
> > 1. Control *every*
> > Reading in old state files is a whole lot easier (to write
> > maintain, and stay sane) than producing state that is bug-compatible with
> > previous versions.
>
> It seems to me that old->new and new->old migrations are
> of about the same level of difficulty.
> Supporting one of these but no
On Tue, Nov 24, 2009 at 07:45:13AM -0600, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>> On Sun, Nov 22, 2009 at 09:49:26AM -0600, Anthony Liguori wrote:
>>
We cannot even create a new 'hack section' for new code since the
sections are ordered and expected to be exact matc
Michael S. Tsirkin wrote:
On Sun, Nov 22, 2009 at 09:49:26AM -0600, Anthony Liguori wrote:
We cannot even create a new 'hack section' for new code since the
sections are ordered and expected to be exact match on the
destination.
The result is that new->old migration cannot work.
On Mon, Nov 23, 2009 at 08:49:23AM -0600, Anthony Liguori wrote:
> Juan Quintela wrote:
>> Anthony Liguori wrote:
>>
>>> Juan Quintela wrote:
>>>
>>
>>
>>> I'm not at all convinced that you can downgrade the version of a
>>> device without exposing a functional change to a guest. In fa
On Mon, Nov 23, 2009 at 02:36:40PM +0200, Gleb Natapov wrote:
> > My problem implementing optional features/sections/... is not the
> > savevm/VMState bits. At the end, implementing that is easy. What is
> > more dificult is once that a device have 5 features, what are the valid
> > combinations.
On Sun, Nov 22, 2009 at 09:49:26AM -0600, Anthony Liguori wrote:
>>We cannot even create a new 'hack section' for new code since the
>>sections are ordered and expected to be exact match on the
>>destination.
>>
>>The result is that new->old migration cannot work. This is not cross
On 11/23/2009 08:28 PM, Anthony Liguori wrote:
Eduardo Habkost wrote:
That may be good enough for upstream Qemu, but IMO for RHEL it is not a
realistic policy. If the definition of "guest visible state" is buggy on
the current implementation, we can't drop entirely the possibility of
fixing it o
On 11/23/2009 02:15 PM, Juan Quintela wrote:
Dor Laor wrote:
> In the last couple of days we discovered some issues regarding stable
> ABI and the robustness of the live migration protocol. Let's just jump
> right into it, ordered by complexity:
>
> 1. Control*every* feature exposed to the
On Mon, Nov 23, 2009 at 01:49:09PM -0600, Anthony Liguori wrote:
> Eduardo Habkost wrote:
>> On Mon, Nov 23, 2009 at 12:28:16PM -0600, Anthony Liguori wrote:
>>> After mulling over it a bit, here's what I'd suggest:
>>>
>>> 1) Integrate VMstate with qdev
>>> 2) Introduce a bitmap bla
Excerpts from Anthony Liguori's message of Mon Nov 23 14:44:04 -0200 2009:
>
> I don't want to transparently migrate from 5.4.1 to 5.4.0 and have my
> guest's time start drifting. I specifically want that to fail.
If you migrate from 5.4.0 to 5.4.0 or from 5.4.0 to 5.4.1, the guest
will also st
Eduardo Habkost wrote:
On Mon, Nov 23, 2009 at 12:28:16PM -0600, Anthony Liguori wrote:
Eduardo Habkost wrote:
That may be good enough for upstream Qemu, but IMO for RHEL it is not a
realistic policy. If the definition of "guest visible state" is buggy on
the current implementation, we
On Mon, Nov 23, 2009 at 12:28:16PM -0600, Anthony Liguori wrote:
> Eduardo Habkost wrote:
>> That may be good enough for upstream Qemu, but IMO for RHEL it is not a
>> realistic policy. If the definition of "guest visible state" is buggy on
>> the current implementation, we can't drop entirely the
Juan Quintela wrote:
The problem here isn't migration, it's what you've decided to backport
into your stable branch.
No. the problem is that I made a mistake in the past. And didn't add a
field to the state that I should. It just happens to work without that
field in several use cases.
Eduardo Habkost wrote:
That may be good enough for upstream Qemu, but IMO for RHEL it is not a
realistic policy. If the definition of "guest visible state" is buggy on
the current implementation, we can't drop entirely the possibility of
fixing it on our stable branch.
After mulling over it
Excerpts from Anthony Liguori's message of Mon Nov 23 14:16:39 -0200 2009:
> Eduardo Habkost wrote:
> > Excerpts from Anthony Liguori's message of Mon Nov 23 12:49:23 -0200 2009:
> >>>
> >> In our own stable branch, we do not introduce any savevm changes. I
> >> would recommend the same p
Juan Quintela wrote:
you can weasel the way you want (I can also do it).
Customer had: 5.4 <-> 5.4 migration working (suboptimally)
Now appears 5.4.1 that works best with migration. But he want to do the
migration in two steps:
migrate from qemu 5.4 -> 5.4.1, and be able to migrate back if he
Gleb Natapov wrote:
I am OK with management being responsible to sort things out. Juan
said that destination can't abort migration in the middle, so I pointed
out easy solution that will work in 99.999% cases.
I think there's something elegant about doing migration in a
unidirectional strea
Eduardo Habkost wrote:
Excerpts from Anthony Liguori's message of Mon Nov 23 12:49:23 -0200 2009:
Juan Quintela wrote:
But if you know substitute qemu-0.11 and qemu-0.12 for RHEL5.4 and
RHEL5.4.1, you will see that the code bases are going to be really,
really similar. And if any savev
On Mon, Nov 23, 2009 at 10:09:15AM -0600, Anthony Liguori wrote:
> Gleb Natapov wrote:
> >On Mon, Nov 23, 2009 at 09:32:48AM -0600, Anthony Liguori wrote:
> >>Gleb Natapov wrote:
> >>>On Mon, Nov 23, 2009 at 09:05:58AM -0600, Anthony Liguori wrote:
> Gleb Natapov wrote:
> >Then I don't see
Gleb Natapov wrote:
According to Anthony this is not a bug. Management has all the means to
resolve this situation properly. The bug would be if dst and src both
run or both exit.
Yup. And they do. If you do the same migration with libvirt, it will
fail gracefully with a -1 in the post_lo
Gleb Natapov wrote:
On Mon, Nov 23, 2009 at 09:32:48AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
On Mon, Nov 23, 2009 at 09:05:58AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
Then I don't see why Juan claims what he claims.
Live migration is
On Mon, Nov 23, 2009 at 05:01:58PM +0100, Juan Quintela wrote:
> Anthony Liguori wrote:
> > Gleb Natapov wrote:
> > My problem implementing optional features/sections/... is not the
> > savevm/VMState bits. At the end, implementing that is easy. What is
> > more dificult is once that
On Mon, Nov 23, 2009 at 09:32:48AM -0600, Anthony Liguori wrote:
> Gleb Natapov wrote:
> >On Mon, Nov 23, 2009 at 09:05:58AM -0600, Anthony Liguori wrote:
> >>Gleb Natapov wrote:
> >>>Then I don't see why Juan claims what he claims.
> >>Live migration is unidirectional. As long as qemu can send ou
On Mon, Nov 23, 2009 at 09:00:05AM -0600, Anthony Liguori wrote:
>
> I think the problem is that you shouldn't be changing the guest visible
> state in a stable update of qemu. If you change the guest visible state
> in a stable update, then you won't be able to support live migration
> bet
Gleb Natapov wrote:
On Mon, Nov 23, 2009 at 09:05:58AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
Then I don't see why Juan claims what he claims.
Live migration is unidirectional. As long as qemu can send out all
of the data without the stream closing, it will "succeed"
On 11/23/2009 04:22 PM, Gleb Natapov wrote:
As far as I remember the two general's problem talks about unreliable
channel, not unreliable nodes. Why not having destination send ACK/NACK
to the source when it knows that migration succeeded/failed. If source
gets NACK it continues, if it gets ACK i
Excerpts from Anthony Liguori's message of Mon Nov 23 12:49:23 -0200 2009:
> Juan Quintela wrote:
> > But if you know substitute qemu-0.11 and qemu-0.12 for RHEL5.4 and
> > RHEL5.4.1, you will see that the code bases are going to be really,
> > really similar. And if any savevm format is changed,
On Mon, Nov 23, 2009 at 09:05:58AM -0600, Anthony Liguori wrote:
> Gleb Natapov wrote:
> >Then I don't see why Juan claims what he claims.
>
> Live migration is unidirectional. As long as qemu can send out all
> of the data without the stream closing, it will "succeed" on the
> source. While thi
Eduardo Habkost wrote:
The pvclock MSRs are an example: if the guest is not using pvclock, not
restoring the MSRs won't make any difference. Strictly speaking, not
migrating them is wrong, but the user may argue that they know it won't
impact their guest OS, and that they want to take the risk.
Gleb Natapov wrote:
Then I don't see why Juan claims what he claims.
Live migration is unidirectional. As long as qemu can send out all of
the data without the stream closing, it will "succeed" on the source.
While this may sound like a bug, it's an impossible problem to solve as
it's d
On Mon, Nov 23, 2009 at 03:21:24PM +0100, Paolo Bonzini wrote:
> On 11/23/2009 02:51 PM, Eduardo Habkost wrote:
>> Right, but I wouldn't be surprised if a user complains that "I know that
>> my guest don't use that VM feature, so I want to be able to migrate to
>> an older version anyway".
>
> That
Paolo Bonzini wrote:
On 11/23/2009 02:51 PM, Eduardo Habkost wrote:
Right, but I wouldn't be surprised if a user complains that "I know that
my guest don't use that VM feature, so I want to be able to migrate to
an older version anyway".
That's a bit more tricky. What if the older version doe
On Mon, Nov 23, 2009 at 08:51:17AM -0600, Anthony Liguori wrote:
> Gleb Natapov wrote:
> My problem implementing optional features/sections/... is not the
> savevm/VMState bits. At the end, implementing that is easy. What is
> more dificult is once that a device have 5 features, what
Eduardo Habkost wrote:
Migration needs to be conservative. There should be only two possible
outcomes: 1) a successful live migration or 2) graceful failure with the
source VM still running correctly. Silently ignoring things that could
affect the guests behavior means that it's possible that aft
Gleb Natapov wrote:
My problem implementing optional features/sections/... is not the
savevm/VMState bits. At the end, implementing that is easy. What is
more dificult is once that a device have 5 features, what are the valid
combinations. i.e. if you have pci and msix features, msix requires
Juan Quintela wrote:
Anthony Liguori wrote:
Juan Quintela wrote:
I'm not at all convinced that you can downgrade the version of a
device without exposing a functional change to a guest. In fact, I'm
pretty certain that it's provably impossible. Please give a counter
example of w
On Mon, Nov 23, 2009 at 03:09:35PM +0100, Juan Quintela wrote:
> Gleb Natapov wrote:
> > On Mon, Nov 23, 2009 at 01:25:32PM +0100, Juan Quintela wrote:
> >> Gleb Natapov wrote:
> >> > On Sun, Nov 22, 2009 at 08:17:46PM -0600, Anthony Liguori wrote:
>
> > Yes, I proposed to send device state in m
On 11/23/2009 02:51 PM, Eduardo Habkost wrote:
Right, but I wouldn't be surprised if a user complains that "I know that
my guest don't use that VM feature, so I want to be able to migrate to
an older version anyway".
That's a bit more tricky. What if the older version doesn't support
sound (j
Anthony Liguori wrote:
> Juan Quintela wrote:
>> Dor Laor wrote:
>>>
>>
>> My idea here is that we need to have further use of machine
>> descriptions, once that is done, we need something like a new property
>> for qdev (version?). Once there, each device could do:
>> - if version != last_
Excerpts from Anthony Liguori's message of Mon Nov 23 00:17:46 -0200 2009:
> Paolo Bonzini wrote:
> >
> >> I don't see how this fixes anything. If you used feature bits, how do
> >> you migrate from a version that has a feature bit that an older version
> >> doesn't know about? Do you just ignore i
Paolo Bonzini wrote:
On 11/23/2009 03:17 AM, Anthony Liguori wrote:
You mean, each device would have multiple sections? We already use
chunks for each device state.
If they want to, yes.
We only migrate things that are guest visible. Everything else is left
to the user to configure. We wo
Juan Quintela wrote:
Dor Laor wrote:
I will go further, and think that this kind of issues should be put into
the machine type.
I agree.
If you start qemu with -M pc-0.10, it should save the state in a 0.10
compatible way (that don't happens at the moment, but it should work
that way)
Juan Quintela wrote:
Gleb Natapov wrote:
On Sun, Nov 22, 2009 at 08:17:46PM -0600, Anthony Liguori wrote:
Paolo Bonzini wrote:
I don't see how this fixes anything. If you used feature bits, how do
you migrate from a version that has a feature bit that an older version
doesn't k
On Mon, Nov 23, 2009 at 01:29:11PM +0100, Juan Quintela wrote:
> Gleb Natapov wrote:
> > On Mon, Nov 23, 2009 at 10:29:12AM +0100, Paolo Bonzini wrote:
> >> On 11/23/2009 09:26 AM, Gleb Natapov wrote:
> >> >I'd go with chunk instead of feature bits, specifying them like in
> >> >the PN
On Mon, Nov 23, 2009 at 01:25:32PM +0100, Juan Quintela wrote:
> Gleb Natapov wrote:
> > On Sun, Nov 22, 2009 at 08:17:46PM -0600, Anthony Liguori wrote:
> >> Paolo Bonzini wrote:
> >> >
> >> >>I don't see how this fixes anything. If you used feature bits, how do
> >> >>you migrate from a version
Dor Laor wrote:
> In the last couple of days we discovered some issues regarding stable
> ABI and the robustness of the live migration protocol. Let's just jump
> right into it, ordered by complexity:
>
> 1. Control *every* feature exposed to the guest by qemu cmdline:
>
>While thinking on cro
On Mon, Nov 23, 2009 at 10:29:12AM +0100, Paolo Bonzini wrote:
> On 11/23/2009 09:26 AM, Gleb Natapov wrote:
> >I'd go with chunk instead of feature bits, specifying them like in
> >the PNG specification:
> >>>
> >>> You mean, each device would have multiple sections? We already use
>
On 11/23/2009 09:26 AM, Gleb Natapov wrote:
> >I'd go with chunk instead of feature bits, specifying them like in
> >the PNG specification:
>
> You mean, each device would have multiple sections? We already use
> chunks for each device state.
>
Each device can send device info in multiple
On Sun, Nov 22, 2009 at 08:17:46PM -0600, Anthony Liguori wrote:
> Paolo Bonzini wrote:
> >
> >>I don't see how this fixes anything. If you used feature bits, how do
> >>you migrate from a version that has a feature bit that an older version
> >>doesn't know about? Do you just ignore it?
> >
> >I'd
On 11/23/2009 03:17 AM, Anthony Liguori wrote:
You mean, each device would have multiple sections? We already use
chunks for each device state.
If they want to, yes.
We only migrate things that are guest visible. Everything else is left
to the user to configure. We wouldn't migrate the sta
Paolo Bonzini wrote:
I don't see how this fixes anything. If you used feature bits, how do
you migrate from a version that has a feature bit that an older version
doesn't know about? Do you just ignore it?
I'd go with chunk instead of feature bits, specifying them like in the
PNG specificati
I don't see how this fixes anything. If you used feature bits, how do
you migrate from a version that has a feature bit that an older version
doesn't know about? Do you just ignore it?
I'd go with chunk instead of feature bits, specifying them like in the
PNG specification:
Each chunk
89 matches
Mail list logo
