I don't want to argue against your decision, but you're able to build
your domU kernel with "generic x86" support.
Anyway, we made a few assumptions:
- heterogene clusters are harder to manage by default
(even without xen)
- new x86 hardware supports virtually all features of
current one.
- hardware upgrades (10Gbit NICs, Infiniband, ...) are
likely to be necessary earlier than x86 changes
- regular updates and kernel patches are always necessary,
optimization for newer hardware can be done if support
for older hardware has become obsolete.
- electricity tends to get expensive
Taking this assumptions, and having in mind that a cluster does not
necessarily need to cover every and all machine, our decision is clear ;)
But to your question. I don't know what kind of automation you're using
for migration, but it's not too hard to get /proc/cpuinfo of a remote
host to check the capabilities before calling xm migrate.
For complex scenarios, some work has always been done outside xen.
Cheers,
Stephan
b52@xxxxxxxxx schrieb:
I already thought that, but hoped there is a way to tell the domU which
cpu flags to use. Well this will be the reason my company will not use xen
for domain management. You will never know what kind of CPUs you will buy
in future and sure you don't want to buy a complete new cluster because
you need one box more..
Btw. should the relocation daemon not at least check the CPU flags of the
remote server before migration?
And there is really no way to pin the domU to a set of CPU flags?
-- Holger
This has been brought up a few times on the list. The problem is the cpu
features that the guest is using. When you transfer a domain from the p4
to
the a64, it supports all the flags (being a generation or two newer) that
the p4 does, however in reverse it is not the case.
There was some ongoing work to create a filter for domain creation that
would allow the 'lowest common denominator'. However, it seems it's never
made into the codetree. It has been listed on the xen roadmap for a long
time now.
In short, this doesn't work now, and unless somebody completes the feature
filter, it may not work for some time.
You should be careful to ensure that all the hosts that you transfer to do
in fact support all the cpu flags that the creating host does, otherwise
you
will run into seemingly random crashes, corruption, or hangs.
For the moment, it is only recommendable to do domain transfer between
identical (or same generation same lineup) cpus.
-----Original Message-----
From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of b52@xxxxxxxxx
Sent: February 23, 2008 4:13 AM
To: Xen-users@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-users] migrating between different hardware (xen-3.1.3)
Hi,
I setup a testbed todo some migration tests for work and got a problem..
I used two P4 2.4GHz an AMD64 4200+ (SVM) and an Intel C2D 6320 1.86GHz. I
had xen 3.1.3 with 2.6.18 and exactly the same versions on all systems
(mirrored AoE) and one 32Bit domU
Now if I created this domU on one of the P4s, I was able to migrate it
between every host.
If I created this domU on the AMD or Intel C2D, it was only possible to
migrate between these both. The domU always crashed if I tried to migrate
it to the P4s.
You can find the xm info of all 4 PCs and one xm log of source(AMD) and
one xm log of destination(P4) in close.
Any help is appreciated and please CC me
Cheers,
Holger
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
--
Stephan Seitz
Senior System Administrator
*netz-haut* e.K.
multimediale kommunikation
zweierweg 22
97074 würzburg
fon: +49 931 2876247
fax: +49 931 2876248
web: www.netz-haut.de <http://www.netz-haut.de/>
registriergericht: amtsgericht würzburg, hra 5054
s_seitz.vcf
Description: Vcard
signature.asc
Description: OpenPGP digital signature
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home