Yes, that is exactly why one thinking about using something with
more liberal license then Solaris11 with payed license, should
first install latest OpenSolaris form snv_134 (Or 2009.06 then
upgrade to /dev Opensolaris 134) and then it can choose upgrade
path to Both openIndiana oi_148(b) and S11Ex on same zpool.
That way, zpool and zfs versions can stay on versions supported
by OI and Nexenta (and Schillix and FreeBSD and ZFS-Fuse on
Linux and Zfs Native on Linux in development) and one can
experiment with more systems supporting ZFS then only being
locked in S11Ex.
If you sadly choose to install from closed S11Ex disc and not
from Osol snv_134 CD
(
www.genunix.org snv_134
.ISO) and upgrade to OpenIndiana OI_xxx dev. release
and/orS11ex, then you might loose ability to use anything but
closed Solaris from Oracle, so be clever and you can use upgrade
path explained.
Of course, you can have as much Boot Environments (BE) on same
zpool as you like, since they basically behave like separate OS
installs to boot from the same zpool, that is the beauty of
ZFS/(Open)Solaris based distributions.
Just do NOT do upgrade to newest closed zpool/zfs version from
S11Ex!
How
about getting a little more crazy... What if this
entire server temporarily hosting this data was a VM
guest running ZFS? I don't foresee this being a
problem either, but with so
The only thing to watch out for is to make sure that the
receiving datasets aren't a higher version that the zfs
version that you'll be using on the replacement server.
Because you can't downgrade a dataset, using snv_151a and
planning to send to Nexenta as a final step will trip you up
unless you explicitly create them with a lower version.
-B
--
Brandon High :
bh...@freaks.com
Hello,
I'm debating an OS change and also thinking about my
options for data migration to my next server, whether it
is on new or the same hardware.
Migrating to a new machine I understand is a simple matter
of ZFS send/receive, but reformatting the existing drives
to host my existing data is an area I'd like to learn a
little more about. In the past I've asked about this and
was told that it is possible to do a send/receive to
accommodate this, and IIRC this doesn't have to be to a
ZFS server with the same number of physical drives?
How about getting a little more crazy... What if this
entire server temporarily hosting this data was a VM guest
running ZFS? I don't foresee this being a problem either,
but with so much at stake I thought I would double check
:) When I say temporary I mean simply using this machine
as a place to store the data long enough to wipe the
original server, install the new OS to the original
server, and restore the data using this VM as the data
source.
Also, more generally, is ZFS send/receive mature enough
that when you do data migrations you don't stress about
this? Piece of cake? The difficulty of this whole
undertaking will influence my decision and the whole
timing of all of this.
I'm also thinking that a ZFS VM
guest might be a nice way to maintain a remote backup of
this data, if I can install the VM image on a
drive/partition large enough to house my data. This seems
like it would be a little less taxing than rsync cronjobs?