From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: Migration and CPU type? Date: Thu, 16 Feb 2006 12:25:07 -0600 Message-ID: <43F4C383.5040303@us.ibm.com> References: <43F3BE60.1040901@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <43F3BE60.1040901@hp.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: John Byrne Cc: xen-devel List-Id: xen-devel@lists.xenproject.org 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?) This, unfortunately, is always going to be a heuristic. There's no way to guarantee CPU compatibility (except, of course, with VT/SVM). The major problem is the CPUID instruction. If an application obtains CPUID info (which I think can even contain a serial number for the processor), and relies on this info (even for something simple like CPU frequency), it will break when moved to another CPU that doesn't have the same exact information reported for CPUID. This is a bit contrived but important as a base case to assert that there's no completely safe heuristic for migration. There are going to, of course, be common cases of incompatibility mostly related to things like the presence of SIMD instructions. One can argue that for a lot server work loads, this isn't going to be an issue. I don't think it's horrible that Xend doesn't do any checking right now because of this. It certainly wouldn't be harmful to do some checking and issue a warning to the user before migration. Personally, I think it's far easier for high level tools to take care of this since they will have a better idea of the cluster's hardware layout and can make appropriate decisions based on risk compared to availability. Regards, Anthony Liguori > Thanks, > > John Byrne > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >