* Paolo Bonzini (pbonz...@redhat.com) wrote:
> Il 02/06/2014 19:44, Dr. David Alan Gilbert ha scritto:
> >>> If the version-based interface turns out to be not enough, we've done the
> >>> work for nothing. In fact, we already know that it is not enough to solve
> >>> 2.0->1.6 migration with -M pc
Il 02/06/2014 19:44, Dr. David Alan Gilbert ha scritto:
> If the version-based interface turns out to be not enough, we've done the
> work for nothing. In fact, we already know that it is not enough to solve
> 2.0->1.6 migration with -M pc-1.5.
Remind me, why doesn't it solve that?
(It would be
* Paolo Bonzini (pbonz...@redhat.com) wrote:
> Il 02/06/2014 18:40, Dr. David Alan Gilbert ha scritto:
> >
> >So putting this in now, and getting it into libvirt means everyone has
> >the info.
> >>>
> >>> It also means we have a higher risk of getting it wrong, and having to do
> >
Il 02/06/2014 18:40, Dr. David Alan Gilbert ha scritto:
> >
> >So putting this in now, and getting it into libvirt means everyone has the
info.
>
> It also means we have a higher risk of getting it wrong, and having to do
> the work twice.
That's why all this is does is provide the interface;
* Paolo Bonzini (pbonz...@redhat.com) wrote:
> Il 02/06/2014 15:50, Dr. David Alan Gilbert ha scritto:
> >However, it gets trickier since the destination libvirt has to know to send
> >the version information to the source; so we can only use this trick between
> >versions where the libvirt on both
Il 02/06/2014 15:50, Dr. David Alan Gilbert ha scritto:
However, it gets trickier since the destination libvirt has to know to send
the version information to the source; so we can only use this trick between
versions where the libvirt on both ends knows about it; so if we suddenly hit
a compatib
* Markus Armbruster (arm...@redhat.com) wrote:
> "Dr. David Alan Gilbert" writes:
>
> > * Paolo Bonzini (pbonz...@redhat.com) wrote:
> [...]
> >> Version numbers open a huge compatibility can of worms (what is a version
> >> number?)
> >
> > No, a version number here is very well defined; it's th
"Dr. David Alan Gilbert" writes:
> * Paolo Bonzini (pbonz...@redhat.com) wrote:
[...]
>> Version numbers open a huge compatibility can of worms (what is a version
>> number?)
>
> No, a version number here is very well defined; it's the output of
> query-version'
> (or 'info version' for the HMP w
* Paolo Bonzini (pbonz...@redhat.com) wrote:
> Il 28/05/2014 14:04, Dr. David Alan Gilbert ha scritto:
> >* Paolo Bonzini (pbonz...@redhat.com) wrote:
> >>Il 28/05/2014 13:20, Dr. David Alan Gilbert (git) ha scritto:
> >>>There aren't any uses of the migration version in this patch set, however
> >
Il 28/05/2014 14:04, Dr. David Alan Gilbert ha scritto:
* Paolo Bonzini (pbonz...@redhat.com) wrote:
Il 28/05/2014 13:20, Dr. David Alan Gilbert (git) ha scritto:
There aren't any uses of the migration version in this patch set, however
uses I can think of include:
a) Generating an old forma
* Paolo Bonzini (pbonz...@redhat.com) wrote:
> Il 28/05/2014 13:20, Dr. David Alan Gilbert (git) ha scritto:
> >From: "Dr. David Alan Gilbert"
> >
> >This patch set provides an optional parameter to 'migrate' giving
> >the destination QEMU version, it's intended for those having to maintain
> >com
Il 28/05/2014 13:20, Dr. David Alan Gilbert (git) ha scritto:
From: "Dr. David Alan Gilbert"
This patch set provides an optional parameter to 'migrate' giving
the destination QEMU version, it's intended for those having to maintain
compatibility between minor versions (including downstream vers
From: "Dr. David Alan Gilbert"
This patch set provides an optional parameter to 'migrate' giving
the destination QEMU version, it's intended for those having to maintain
compatibility between minor versions (including downstream versions) and
also for those who need to think about backwards migra
13 matches
Mail list logo
