145 lines
4.7 KiB
Markdown
145 lines
4.7 KiB
Markdown
+++
|
|
title = "moving a zone between zpools"
|
|
date = "2013-01-05T09:11:53+00:00"
|
|
author = "Gibheer"
|
|
draft = false
|
|
+++
|
|
|
|
I got an interesting question regarding zones on Solaris in #omnios.
|
|
|
|
> scarcry: Does anyone know how to move a zone from one zpool to another?
|
|
|
|
There are some guides out there on how to move a zone from one machine to
|
|
another, but most of them install the zone in the same place as before.
|
|
|
|
But instead of moving it from one machine to another, this small guide will just
|
|
show what to do, when only the location is chaning.
|
|
|
|
preparations
|
|
------------
|
|
|
|
First, we need to setup the partitions and zones for our little experiment. For
|
|
this example, I will use the pool `rpool` and the following partitions
|
|
|
|
* `rpool/zones/old` mounted to `/zones/old/`
|
|
* `rpool/zones/new` mounted to `/zones/new/`
|
|
|
|
We also need the zone config, so here is it.
|
|
|
|
create -b
|
|
set zonepath=/zones/old/zone1
|
|
set ip-type=exclusive
|
|
set autoboot=false
|
|
add net
|
|
set physical=zone1
|
|
end
|
|
commit
|
|
|
|
Just install the zone with the normal commands
|
|
|
|
$ zonecfg -z zone1 < zone.config
|
|
$ zoneadm -z zone1 install
|
|
$ zoneadm -z zone1 boot
|
|
|
|
Check if the zone is running and write a file, just to make sure, we have the
|
|
same zone at the end.
|
|
|
|
moving the zone
|
|
---------------
|
|
|
|
For this guide, we will assume, that the zone is in production use and can't be
|
|
offline too long. For that to work, we will do a first snapshot, when the zone
|
|
is still running.
|
|
|
|
$ zfs snapshot -r rpool/zones/old/zone1@move1
|
|
|
|
After that, we can replay that snapshot into the new location.
|
|
|
|
$ zfs send -R rpool/zones/old/zone1@move1 | zfs recv rpool/zones/new/zone1
|
|
|
|
This step will take some time, depending on the size of your zone. Now we stop
|
|
the the zone and detach it.
|
|
|
|
$ zoneadm -z zone1 halt
|
|
$ zoneadm -z zone1 detach
|
|
|
|
This frees the zfs partition from the zone and makes it accessible. We need that
|
|
a bit later.
|
|
Now we need an incremental snapshot and move that data to the new location.
|
|
|
|
$ zfs snapshot -r rpool/zones/old/zone1@move2
|
|
$ zfs send -R -i move1 rpool/zones/old/zone1@move2 | zfs recv rpool/zones/new/zone1
|
|
|
|
When we now list all zfs partitions, we see, that a partition zbe is mounted two
|
|
times into the same location.
|
|
|
|
rpool/zones/old/zone1/ROOT/zbe 724M 1.59T 723M /zones/old/zone1/root
|
|
rpool/zones/new/zone1/ROOT/zbe 724M 1.59T 723M /zones/old/zone1/root
|
|
|
|
To fix that, issue the following command.
|
|
|
|
zfs set mountpoint=/zones/new/zone1/root rpool/zones/new/zone1/ROOT/zbe
|
|
|
|
Now the partition has to be mounted, so that zoneadm can find it for the attach.
|
|
You can do that with the following command
|
|
|
|
zfs mount rpool/zones/new/zone1/ROOT/zbe
|
|
|
|
Now with the partition in the correct place, we have to tell the zone, where to
|
|
look for its new partition.
|
|
|
|
$ zonecfg -z zone1
|
|
zonecfg:zone1> set zonepath=/zones/new/zone1
|
|
zonecfg:zone1> verify
|
|
zonecfg:zone1> commit
|
|
zonecfg:zone1> exit
|
|
|
|
With the zone reconfigured, attach the zone.
|
|
|
|
$ zoneadm -z zone1 attach
|
|
|
|
This may take a bit of time, as the content of the zone gets checked for
|
|
compatibility. When it is back, check the zone is installed.
|
|
|
|
$ zoneadm list -cv
|
|
ID NAME STATUS PATH BRAND IP
|
|
- zone1 installed /zones/new/zone1 ipkg excl
|
|
|
|
Now boot the zone and we are done.
|
|
|
|
$ zoneadm -z zone1 boot
|
|
|
|
Now check if everything is where you expect it to be and start your services and
|
|
everything is good.
|
|
|
|
ideas
|
|
-----
|
|
|
|
Here are some ideas, what can be done differently in the process.
|
|
|
|
### **iterative snapshots**
|
|
|
|
If you zone has a lot of traffic, where many changes aggregate between the first
|
|
snapshot and the second, do some more iterative snapshots before taking down the
|
|
zone.
|
|
This has the advantage, that you can close the gap of changes to a minimum size
|
|
and therefore make the move at the end a bit faster. But check the available
|
|
disk space in the process to avoid a full disk.
|
|
|
|
### **create a new zone**
|
|
|
|
Instead of chaning the old zone and therefore making a rollback more complicated,
|
|
create a new zone, which looks exactly like the old one.
|
|
Instead of chaning the old one, do instead
|
|
|
|
$ zonecfg -z zone2
|
|
zonecfg:zone2> create -a /zones/new/zone1
|
|
|
|
This will set everything from the old zone with the new zonepath. Keep in mind,
|
|
that this will also use the old interface. If you don't want that, create a new
|
|
interface before and change it in the config step.
|
|
|
|
You can also restore that zfs partition in a partition which has the correct.
|
|
|
|
I hope it helps and you have some fun playing with it.
|