Re: [Xen-users] live migration between heterogeneous cpu

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Fri, 2015-09-18 at 18:30 +0200, matteo nunziati wrote:
> Am I wrong thinking that the oldest cpu in the pool should define the
> maximum exposed features?

In general yes since older cpus tend to have fewer features than newer
ones.

I suppose it's not out of the question that a newer processor might lack a
feature which the previous generation had, but that would be pretty
unusual.

Ian.

> Il 18/set/2015 18:15, "Ian Campbell" <ian.campbell@xxxxxxxxxx> ha
> scritto:
> > On Fri, 2015-09-18 at 17:28 +0200, matteo nunziati wrote:
> > > hello,
> > >
> > > quick Q&A redirects me here [1].
> > >
> > > I'm going to build a micro-cluster for internal services in our
> > company.
> > > services run on both windows and linux. it is a fact that the cluster
> > > will grow up slowly and cpu diversity will be very probable.
> > >
> > > While I do not know if an intel-amd mix will be present, for sure we
> > > already have started using different xeon E* families from either v2
> > or
> > > v3 generations (namely an E3-1220v2 will be "pooled" with either a E3
> > > -1220v3 or a E5-2609v3).
> > >
> > > the question is: can I live migrate guests in this kind of scenario?
> > 
> > Within processors from a single manufacturer the thing to watch out for
> > is
> > processors with features which others in the pool do not have and which
> > a
> > guest might therefore be exposed to on boot and be upset about losing
> > after
> > a migration.
> > 
> > The way to make this work is to "level" the CPUs, by hiding features on
> > the
> > newer processors from guests.
> > 
> > You can do this on a per guest bases from the xl cfg file using the
> > cpuid
> > directive or for the whole host from the hypervisor command line using
> > the
> > various cpuid_mask identifiers.
> > 
> > Unfortunately actually figuring the masks to use is tricky. I suppose
> > you
> > could start by comparing the flags shown in /proc/cpuinfo in dom0
> > across
> > the different machines and then eradicating the differences by taking
> > each
> > one in turn, figuring out which cpuid bit it corresponds to, and
> > setting
> > the host mask to get rid of it. Pretty tedious though.
> > 
> > >
> > > To be honest, live migration is not mandatory, but considering that
> > some
> > > dependable services run on windows server, move the machine in
> > offline
> > > migration from 1 cpu to another is not something I really like to do
> > as
> > > windows OS itself will start complain about the move. Therefore I
> > _guess_
> > > that avoiding windows complains goes in parallel to live migration
> > > capabilities as this means that VM is not aware of the underling HW
> > > (maybe I'm wrong).
> > >
> > > regards,
> > > MN
> > >
> > > [1] 
> > http://www.xenproject.org/help/questions-and-answers/live-migrate-bet
> > > ween-different-cpu.html
> > > _______________________________________________
> > > Xen-users mailing list
> > > Xen-users@xxxxxxxxxxxxx
> > > http://lists.xen.org/xen-users
> > 

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users