This probably has more to do with the potential for different network
devices (if not plumbed via VCS), and the likelihood of patch miss-
syncs. In U1 there's no real error checking, just a copy of the
XML? In U3, with the attach/detach features, it's very common for
the zoneadm attach sequence, or even the zonecfg creat (-a) to fail
without a force option, and therefor no error checking. For me, we
have decided not to support automated zone migration (via clustering
software) due to these issues, and the increase in failover times.
But I expect to not get off so easy when we start to deploy VAD. So
most of this comes down to patch synchronization with local zones.
The likelihood of a patch difference between two identical hardware
platforms is high to begin with, let a lone two different platforms.
Now add to that a support matrix of 4000 systems, and, well, the bar
tab grows ;)
But thanks for posting that info. It is really good to hear that it
will work, if forced(?).
On Mar 2, 2007, at 9:08 AM, Jeff Victor wrote:
Hello Lutz,
First, I'd like to thank you for sharing your experience with the
community. I would guess that few people have the resources and
need (and time) to perform those tests.
Are those zones sparse-root or whole-root zones? As you may know,
a sparse-root zone has (almost) no executable programs. If your
zones are sparse-root, it makes perfect sense that everything
worked correctly.
Lutz Steinbach wrote:
I've did some tests with zones on SF25k (sun4u) and on FSC PP2500
(sun4us).
The zones got created separately on each machine as whole root
zone, no FS
was inherited from the global zone. The zones root FS have been
put on
Hitachi SAN devs, using UFS. Everything was put into a VCS
failover group
to ease zone switching. The OS release used was 01/06, hence we've
got no
OS detach/attach support and had to care ourselves for matching
pkgs/patches etc.
Everything went through just fine. Zones created on sun4u could be
moved to
sun4us and back again as zones created on sun4us could be moved
to sun4u
and back again. The machine class of the system where the non-
global zone
was created seems to be of no relevance for zone migrations.
These tests met my expectations as I assume, that all kernel
structures/functions needed for zones are implemented in kernel
subsystems
that rely on but don't contain any hardware specific code. So I
don't see,
why there is no clear statement, that cross-hardware zone
migrations are
supported.
From a sysadmin point of view this matters, because one of the main
reason we push the use of zones is that we hope to benefit
massively from
it by having in the future snappy migrations. Most likely the
hardware
involved then won't be the same it is now ;-)
Regards Lutz
--
----------------------------------------------------------------------
----
Jeff VICTOR Sun Microsystems jeff.victor @
sun.com
OS Ambassador Sr. Technical Specialist
Solaris 10 Zones FAQ: http://www.opensolaris.org/os/community/
zones/faq
----------------------------------------------------------------------
----
L
_______________________________________________
zones-discuss mailing list
[email protected]
_______________________________________________
zones-discuss mailing list
[email protected]
