WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Migration and CPU type?

To: Noam Taich <noam.taich@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Migration and CPU type?
From: John Byrne <john.l.byrne@xxxxxx>
Date: Thu, 16 Feb 2006 08:56:08 -0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 16 Feb 2006 17:08:36 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <64F9B87B6B770947A9F8391472E0321603494ADF@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <64F9B87B6B770947A9F8391472E0321603494ADF@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5 (X11/20051201)

In a production environment, no one will rely on migration if it can cause mysterious crashes either of the guest or of applications in the guest at some random point in the future. Xen needs to address this is some manner. It may need an override, if someone really wants to do the migration, but by default it should not allow movement between incompatible CPUs.

John


Noam Taich wrote:
John Byrne wrote:

There are various differences between x86 CPU types that I believe
would cause a guest to fail after being migrated. Are there >checks in
the migration code to prevent this from happening? Does it check for an
"incompatible CPU" and fail early, leaving the >guest running on the
source host? If there is a check, what is its nature? (Exact match of
CPU type/rev or something based on >CPU-features?)

Thanks,

John Byrne

No. no checks for CPU type in migration code. And since the RAM image
itself is being copied, there are certainly different

Problems created.
But it's even more complicated than that: the question of whether or not
the migrated guest will fail or not depends on the CURRENT RAM image,
and it may succeed at one point and fail in another one. It all depends
on the current state.

Here is an interesting example I ran into:

I created my guest on my Athlon and tried to migrate it to my laptop
running a Pentium M. The guest failed.

When I tried the opposite, creating it on my laptop and migrating it to
my Athlon, it worked... Not only that,  but now, after being forged in
the flamed of the Pentium M, I could migrate it BACK from the Athlon to
the laptop...then to an Opteron... That was fun. It can actually
function like a roaming guest:-)

One problem is that OSs usually gather information on the system they
are running, on all the features the CPU offers them.

What if one or more of the features is not supported on the target host?
You think it will crash?

NOT necessarily. It won't crash if there's currently no running code on
the guest that uses that feature.

I believe It will also be a problem if some code that USES such a
feature is ON the guest RAM image, but for some reason is not

Currently running, until a user dose something...this could lead to
seemingly unexplained crashes.

I am also interested in future compilations/executions on the migrated
OS...

It can be affected too...

NOW, having said that... completely preventing migration between CPUS
that are not 100% compatible may not be a good idea...
after all...you may KNOW that the current configuration will work on the
other machine (or you may know it was migrated from there

In the first place), and you may need to do a hardware upgrade with no
downtime... no reason to prevent this...

I discovered that as long as you create the guest on the machine with
the LEAST amount of features among the ones it may
Be migrated to (the one that has NO feature the other ones don't have) ,
the migration seems to work fine in every direction.




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>