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:32:09 -0600 Message-ID: <43F4C529.90201@us.ibm.com> References: <64F9B87B6B770947A9F8391472E0321603494ADF@ehost011-8.exch011.intermedia.net> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <64F9B87B6B770947A9F8391472E0321603494ADF@ehost011-8.exch011.intermedia.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Noam Taich Cc: xen-devel@lists.xensource.com, john.l.byrne@hp.com List-Id: xen-devel@lists.xenproject.org Noam Taich wrote: > > I created my guest on my Athlon and tried to migrate it to my laptop=20 > running a Pentium M. The guest failed. > As a general principle, migrating between AMD and Pentium chipsets is a=20 bad idea. If you google a bit, VMware has VMotion compatibility tables that match=20 which processor families they consider "safe" to migrate to and from. Regards, Anthony Liguori > > When I tried the opposite, creating it on my laptop and migrating it=20 > to my Athlon, it worked=85 Not only that, but now, after being forged i= n=20 > the flamed of the Pentium M, I could migrate it BACK from the Athlon=20 > to the laptop=85then to an Opteron=85 That was fun. It can actually=20 > function like a roaming guestJ > > One problem is that OSs usually gather information on the system they=20 > are running, on all the features the CPU offers them. > > What if one or more of the features is not supported on the target=20 > host? You think it will crash? > > NOT necessarily. It won't crash if there's currently no running code=20 > on the guest that uses that feature. > > I believe It will also be a problem if some code that USES such a=20 > feature is ON the guest RAM image, but for some reason is not > > Currently running, until a user dose something=85this could lead to=20 > seemingly unexplained crashes. > > I am also interested in future compilations/executions on the migrated = OS=85 > > It can be affected too=85 > > NOW, having said that=85 completely preventing migration between CPUS=20 > that are not 100% compatible may not be a good idea=85 > after all=85you may KNOW that the current configuration will work on th= e=20 > 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=20 > downtime=85 no reason to prevent this=85 > > I discovered that as long as you create the guest on the machine with=20 > 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)=20 > , the migration seems to work fine in every direction. > > -----------------------------------------------------------------------= - > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > =20