On Mon, 01 Aug 2011 08:53:28 -0500
Anthony Liguori anth...@codemonkey.ws 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
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 before
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
On 31 July 2011 11:48, Dor Laor dl...@redhat.com 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
On 07/31/2011 02:37 PM, Peter Maydell wrote:
On 31 July 2011 11:48, Dor Laordl...@redhat.com 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
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 mean to
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
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
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: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 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
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
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 in
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
On 07/25/2011 04:10 PM, Paolo Bonzini wrote:
On Thu, Jun 30, 2011 at 17:46, Paolo Bonzinipbonz...@redhat.com 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
Am 26.07.2011 14:37, schrieb Anthony Liguori:
On 07/26/2011 07:07 AM, Juan Quintela wrote:
Anthony Liguorianth...@codemonkey.ws 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
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
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
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.
Given two compatible
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.
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 that
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 Bonzinipbonz...@redhat.com wrote:
With the current migration format, VMS_STRUCTs with subsections
are ambiguous. The protocol cannot tell whether
Anthony Liguori anth...@codemonkey.ws 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
On 07/26/2011 07:07 AM, Juan Quintela wrote:
Anthony Liguorianth...@codemonkey.ws 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)
On Tue, Jul 26, 2011 at 10:48 AM, Stefan Hajnoczi
stefa...@linux.vnet.ibm.com 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 Bonzinipbonz...@redhat.com wrote:
With the current migration
Anthony Liguori anth...@codemonkey.ws 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
On 07/26/2011 03:13 PM, Juan Quintela wrote:
Anthony Liguorianth...@codemonkey.ws 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
On 26 July 2011 22:46, Anthony Liguori anth...@codemonkey.ws 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
On Thu, Jun 30, 2011 at 17:46, Paolo Bonzini pbonz...@redhat.com 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
On 07/25/2011 04:10 PM, Paolo Bonzini wrote:
On Thu, Jun 30, 2011 at 17:46, Paolo Bonzinipbonz...@redhat.com 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
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
31 matches
Mail list logo
