On Mon, 01 Aug 2011 08:53:28 -0500
Anthony Liguori wrote:
> On 08/01/2011 02:54 AM, Christoph Hellwig wrote:
> > On Sun, Jul 31, 2011 at 07:15:21PM -0500, Anthony Liguori wrote:
> >> I think we've set the bar too low historically for introducing new
> >> interfaces. I think Avi's new memory API
On 08/01/2011 02:54 AM, Christoph Hellwig wrote:
On Sun, Jul 31, 2011 at 07:15:21PM -0500, Anthony Liguori wrote:
I think we've set the bar too low historically for introducing new
interfaces. I think Avi's new memory API is a good example of how we
should approach these things--do the vast maj
On Sun, Jul 31, 2011 at 07:15:21PM -0500, Anthony Liguori wrote:
> I think we've set the bar too low historically for introducing new
> interfaces. I think Avi's new memory API is a good example of how we
> should approach these things--do the vast majority of the thankless work up
> front befo
On 07/31/2011 06:10 PM, Christoph Hellwig wrote:
On Sun, Jul 31, 2011 at 11:43:08PM +0300, Dor Laor wrote:
/me caught off guard. I wonder why it wasn't converted to VMSTATE before?
virtio is one of the key devices, it's not just random forgotten one that
might not care about migration.
It just
On Sun, Jul 31, 2011 at 11:43:08PM +0300, Dor Laor wrote:
> /me caught off guard. I wonder why it wasn't converted to VMSTATE before?
> virtio is one of the key devices, it's not just random forgotten one that
> might not care about migration.
It just shows the extent of incomplete transitions
On 07/31/2011 04:25 PM, Dor Laor wrote:
On 08/01/2011 12:03 AM, Anthony Liguori wrote:
On 07/31/2011 03:57 PM, Dor Laor wrote:
On 07/31/2011 11:43 PM, Anthony Liguori wrote:
ps: how hard is to finish the vmstate conversion? Can't we just assume
not converted code is not functional and just rem
On 08/01/2011 12:03 AM, Anthony Liguori wrote:
On 07/31/2011 03:57 PM, Dor Laor wrote:
On 07/31/2011 11:43 PM, Anthony Liguori wrote:
ps: how hard is to finish the vmstate conversion? Can't we just assume
not converted code is not functional and just remove all of it?
No. VMState is a solutio
On 07/31/2011 03:57 PM, Dor Laor wrote:
On 07/31/2011 11:43 PM, Anthony Liguori wrote:
ps: how hard is to finish the vmstate conversion? Can't we just assume
not converted code is not functional and just remove all of it?
No. VMState is a solution looking for a problem. Many important device
On 07/31/2011 11:43 PM, Anthony Liguori wrote:
On 07/31/2011 05:48 AM, Dor Laor wrote:
On 07/30/2011 01:28 AM, Anthony Liguori wrote:
No, not at all. Just that converting everything to VMState isn't a
prerequisite for building a more robust migration protocol.
The main thing is to priorities
On 07/31/2011 03:43 PM, Dor Laor wrote:
On 07/31/2011 09:46 PM, Christoph Hellwig wrote:
On Sun, Jul 31, 2011 at 02:45:07PM +0300, Dor Laor wrote:
No, definitely not. I think most people using non-x86 architectures
don't use the vmsave/vmload/migration features at all, but would
be annoyed if t
On 07/31/2011 05:48 AM, Dor Laor wrote:
On 07/30/2011 01:28 AM, Anthony Liguori wrote:
No, not at all. Just that converting everything to VMState isn't a
prerequisite for building a more robust migration protocol.
The main thing is to priorities the problems we're facing with.
- Live migration
On 07/31/2011 09:46 PM, Christoph Hellwig wrote:
On Sun, Jul 31, 2011 at 02:45:07PM +0300, Dor Laor wrote:
No, definitely not. I think most people using non-x86 architectures
don't use the vmsave/vmload/migration features at all, but would
be annoyed if the perfectly functional device models the
On Sun, Jul 31, 2011 at 02:45:07PM +0300, Dor Laor wrote:
>> No, definitely not. I think most people using non-x86 architectures
>> don't use the vmsave/vmload/migration features at all, but would
>> be annoyed if the perfectly functional device models they were
>> using got deleted...
>
> I didn't
On 07/31/2011 02:37 PM, Peter Maydell wrote:
On 31 July 2011 11:48, Dor Laor wrote:
ps: how hard is to finish the vmstate conversion? Can't we just assume
not converted code is not functional and just remove all of it?
No, definitely not. I think most people using non-x86 architectures
don't
On 31 July 2011 11:48, Dor Laor wrote:
> ps: how hard is to finish the vmstate conversion? Can't we just assume
> not converted code is not functional and just remove all of it?
No, definitely not. I think most people using non-x86 architectures
don't use the vmsave/vmload/migration features at a
On 07/30/2011 01:28 AM, Anthony Liguori wrote:
No, not at all. Just that converting everything to VMState isn't a
prerequisite for building a more robust migration protocol.
The main thing is to priorities the problems we're facing with.
- Live migration protocol:
- VMState conversion is n
On 07/29/2011 10:18 AM, Kevin Wolf wrote:
Am 29.07.2011 16:28, schrieb Anthony Liguori:
The one change for backends is that if we migrate a device in way so
that it can say "I need the block backend with the ID 'foo'", then we
can at least make sure that the backend actually exists and is usable
Am 29.07.2011 16:28, schrieb Anthony Liguori:
> On 07/29/2011 09:03 AM, Kevin Wolf wrote:
>> Am 26.07.2011 14:37, schrieb Anthony Liguori:
>>> Hrm, I'm not sure I agree with these conclusions.
>>>
>>> Management tools should do their best job to create two compatible
>>> device models.
>>>
>>> Give
On 07/29/2011 03:14 PM, Anthony Liguori wrote:
I really hate the idea of changing the migration format moments before
the release.
So do I, but that's life.
Since subsections are optional, can't we take the offending subsections,
remove them, bump the section version numbers and make the fiel
On 07/29/2011 09:03 AM, Kevin Wolf wrote:
Am 26.07.2011 14:37, schrieb Anthony Liguori:
Hrm, I'm not sure I agree with these conclusions.
Management tools should do their best job to create two compatible
device models.
Given two compatible device models, there *may* be differences in the
stru
Am 26.07.2011 14:37, schrieb Anthony Liguori:
> On 07/26/2011 07:07 AM, Juan Quintela wrote:
>> Anthony Liguori wrote:
>>> == What we need ==
>>>
>>> We need to decompose migration into three different problems: 1)
>>> serializing device state 2) transforming the device model in order to
>>> satis
On 07/25/2011 04:10 PM, Paolo Bonzini wrote:
On Thu, Jun 30, 2011 at 17:46, Paolo Bonzini wrote:
I have now tested this series (exactly as sent) both by examining
manually the differences between the two formats on the same guest
state, and by a mix of saves/restores (new on new, 0.14 on new
pc-
On 07/26/2011 05:22 PM, Peter Maydell wrote:
On 26 July 2011 22:46, Anthony Liguori wrote:
[This is a bit random-sniping at minor points because I'm still thinking
about the big-picture bits]
So we never actually walk the VMState tables to do anything. The
unconverted purely imperative routi
On 26 July 2011 22:46, Anthony Liguori wrote:
[This is a bit random-sniping at minor points because I'm still thinking
about the big-picture bits]
> So we never actually walk the VMState tables to do anything. The
> unconverted purely imperative routines we just convert to use marshal to a
> Vi
On 07/26/2011 03:13 PM, Juan Quintela wrote:
Anthony Liguori wrote:
On 07/26/2011 07:07 AM, Juan Quintela wrote:
- Be able to describe that different features/versions. This is not the
difficult part, it can be subsections, optional fields, whatever.
What is the difficult part is _k
Anthony Liguori wrote:
> On 07/26/2011 07:07 AM, Juan Quintela wrote:
>> I will change this to:
>> - We need to be able to "enable/disable" features of a device.
>>A.K.A. make -M pc-0.14 work with devices with the same features
>>than 0.14. Notice that this is _independent_ of migration.
On 07/26/2011 07:51 AM, Stefan Hajnoczi wrote:
On Tue, Jul 26, 2011 at 10:48 AM, Stefan Hajnoczi
wrote:
On Mon, Jul 25, 2011 at 06:23:17PM -0500, Anthony Liguori wrote:
However, doing so imposes extra work on management tools - they need to
understand and drive negotiation. If QEMU adds a new
On Tue, Jul 26, 2011 at 10:48 AM, Stefan Hajnoczi
wrote:
> On Mon, Jul 25, 2011 at 06:23:17PM -0500, Anthony Liguori wrote:
>> On 07/25/2011 04:10 PM, Paolo Bonzini wrote:
>> >On Thu, Jun 30, 2011 at 17:46, Paolo Bonzini wrote:
>> >>With the current migration format, VMS_STRUCTs with subsections
On 07/26/2011 07:07 AM, Juan Quintela wrote:
Anthony Liguori wrote:
== What we need ==
We need to decompose migration into three different problems: 1)
serializing device state 2) transforming the device model in order to
satisfy forwards and backwards compatibility 3) encoding the
serialized
Anthony Liguori wrote:
> On 07/25/2011 04:10 PM, Paolo Bonzini wrote:
> == Today ==
>
> Today we only support generating the latest serialization of
> devices. To increase the probability of the latest version working on
> older versions of QEMU, we strategically omit fields that we know can
> sa
On Mon, Jul 25, 2011 at 06:23:17PM -0500, Anthony Liguori wrote:
> On 07/25/2011 04:10 PM, Paolo Bonzini wrote:
> >On Thu, Jun 30, 2011 at 17:46, Paolo Bonzini wrote:
> >>With the current migration format, VMS_STRUCTs with subsections
> >>are ambiguous. The protocol cannot tell whether a 0x5 byte
On Mon, Jul 25, 2011 at 06:23:17PM -0500, Anthony Liguori wrote:
> We also need a way to future proof ourselves.
>
> == What we can do ==
>
> 1) Add migration capabilities to future proof ourselves. I think
> the simplest way this would work is to have a
> 'query-migration-capabilities' command
On 07/25/2011 04:10 PM, Paolo Bonzini wrote:
On Thu, Jun 30, 2011 at 17:46, Paolo Bonzini wrote:
With the current migration format, VMS_STRUCTs with subsections
are ambiguous. The protocol cannot tell whether a 0x5 byte after
the VMS_STRUCT is a subsection or part of the parent data stream.
In
On Thu, Jun 30, 2011 at 17:46, Paolo Bonzini wrote:
> With the current migration format, VMS_STRUCTs with subsections
> are ambiguous. The protocol cannot tell whether a 0x5 byte after
> the VMS_STRUCT is a subsection or part of the parent data stream.
> In the past QEMU assumed it was always a p
With the current migration format, VMS_STRUCTs with subsections
are ambiguous. The protocol cannot tell whether a 0x5 byte after
the VMS_STRUCT is a subsection or part of the parent data stream.
In the past QEMU assumed it was always a part of a subsection; after
commit eb60260 (savevm: fix corrup
35 matches
Mail list logo
