Yes, I just tried this in the lab...
- Install base S10U6 on both hosts, create zpool and sparse-root zone.
- On T2000, detach zone, and create ZFS snapshot.
- zfs send/receive that snapshot to a v490, and import zone with '-u'.
- and back to T2000, same way.

This works, as long as you have patch 141715-03 (Which requires kernel patch 139555-08), to avoid bug 6802870. However, even though my migrated-back-to-T2000 zone is operating, not sure how stable it is, or what it might be missing. Think I'm going to recommend to the customer that they zfs send their zone ZFS pool to the M5000.


Steve Lawrence wrote:
You can export/import the zpool on shared storage to move the zone.

To migrate between sun4v and sun4u, you will need to use attach -u to
update the zone to have the necessary platform packages.  My guess
is that once the zone has been attached to both hosts, you won't need to
use the -u after that (assumming niether host is patched).

-Steve L.

On Fri, Sep 04, 2009 at 11:28:07AM -0400, Steffen Weiberle wrote:
On 09/04/09 11:21, Jim Nissen wrote:
A customer is migrating five zones, from a Niagara system to a M5000, to test performance. The zones are in a ZFS pool, on SAN storage. They plan on moving this storage over to the M5000, and doing a straight import of the zones vs. making a copy of them and then importing them. If the M5000 doesn't perform better, they plan on migrating them back to the Niagara system.

I can see that sun4v-to-sun4u zones migrations is supported. However, in the "HOW to MOVE A SOLARIS CONTAINER" How-To guide, they show an example of using 'zfs send' and 'zfs receive' to make a copy of the zpools.

- Is it supported to just detach the zones and deport the zpool, on one host, and reimport on the other host, without making a separate copy of the zonepath zpool?
- How about a straight detach/attach back to the original environment.
- If it is supported, has anybody done it? I'm concerned with what might happen to the zone OS bits, if they do a straight import on the M5000, and then go back to the T5220, again.

zones-discuss mailing list
I don't have an answer directly, however, I would consider creating a snapshot and clone, and attaching the clone on the other system. then detaching and attaching again on the original system. You could then compare the original with the multi-attached, and look for binary differences. Logs and the like will be different.

I do doubt that testing is done in a back and forth manner. Most migrations are one way, or the idea is to have a master and clone from that using the detach/attach methodology.


zones-discuss mailing list
zones-discuss mailing list

Reply via email to