qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] migration: add a MAINTAINERS entry for migratio


From: Juan Quintela
Subject: Re: [Qemu-devel] [PATCH] migration: add a MAINTAINERS entry for migration
Date: Mon, 14 Nov 2011 18:40:20 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

Anthony Liguori <address@hidden> wrote:
> I think this is an accurate reflection of the state of migration today.  This
> is the second release in a row where we're scrambling to fix a critical issue
> in migration.

We need to make our mind about it.

A patch to do the reopen was posted long, long ago.  Code existed on
RHEL5 from 3 years ago.  Answer was that:
- we need to do it other way
- we need to change it inside qcow2

No suggestions for former, and internals of qcow2 are quite difficult
to grasp (at least for me).

Then my fault for not pushing more for the patches.

But then it happens again with migration with Huge Memory machines.
Series were rejected because it "only" fixed completely the stalls on
the iothread, and it don't fixed completely the problem on the vcpus.
And here we still are, we need to finish the migration thread to get
things included.

And then, we have problems with the format (that is not
comprehensible).  Took almost 2 years to convince you that we need a
"size", checksum, start/end markers.  And we got:
- on one hand, we need to have perfect solutions to get them integrated
  (huge memory patches)
- on the other hand, we can think about including patches that only fix
  one of the more minor points that we have (visitors).

So, the question is:

What we expect for migration?
- Backward compatibility: A must for corporate users -> a burden for
  everybody else
- Testing: What is that?
- Format: it is a mess, but as Avi likes to point, we would have to
  "maintain" current one temporarily  (a.k.a. forever).

To make things more interesting, lots of changes on migration touch lot
of code (i.e. not only migration*/savevm.c), and getting that patches
accepted take forever.

> The first step in fixing this problem is being up front about what the current
> state of the subsystem is.  If we're going to treat migration as a release
> blocking feature in the future, than we need to promote the migration 
> subsystem
> above 'Odd Fixes' status.

Later, Juan.

PD.  And yes, I agree that migration is in a very sad state today.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]