zfs discuss - May 2007 - Boot disk clone with zpool present

I''m hoping that this is simpler than I think it is. :-)

We routinely clone our boot disks using a fairly simple script that:
1) Copies the source disk''s partition layout to the target disk using
[i]prtvtoc[/i], [i]fmthard[/i] and [i]installboot.[/i]
2) Using a list, runs [i]newfs[/i] against the target slice and [i]ufsdump[/i]
of the source slice piped to a [i]ufsrestore[/i] of the target slice.

The result is a bootable clone of the source disk.  Granted, there are
vulnerabilities with using ufsdump on a mounted file system but it works for us.

We''re now looking at using ZFS file systems for /usr, /var, /opt,
/export/home, etc., leaving the root file system ("/") as UFS and swap
as a bare slice as it is now.

I''ve successfully created an Alternate Root Pool and have replicated
the ZFS file systems from another source [i]zpool[/i] into the Alternate Root
Pool using "zfs send" and "zfs receive".  Right now,
I''m doing this without the benefit of a bootable system to play with. 
I''m experimenting with just ordinary file systems, [b][i]not[/i][/b]
"/ufs", "/opt", etc.  Now comes the "chicken and the
egg" part.

I think I would have to fix-up the mount points of the newly copied ZFS file
systems on the Alternate Root Pool so that they remain set to "/ufs",
"/opt", etc.  By the way, would these file systems have to be
"legacy" mount points?  It seems like they would have to be.

Here''s the part that makes my head hurt: If I''ve created this
Alternate Root Pool on this separate disk slice and populated it and exported it
and I''ve replicated a UFS root ("/") file system on that same
disk but in slice 0, how does that zpool get connected when I try to boot that
cloned disk?

Fundamentally, the question is, how does one replicate a boot/system disk that
contains zpool(s) for file systems other than the root file system?

This is fairly straightforward with UFS file system technology.  The addition of
zpool identity seems to complicate the issue considerably.

Thank you very much for any advice or clarification.
 
 
This message posted from opensolaris.org

Mark V. Dalton wrote:
> I''m hoping that this is simpler than I think it is. :-)
> 
> We routinely clone our boot disks using a fairly simple script that:
> 1) Copies the source disk''s partition layout to the target disk
using [i]prtvtoc[/i], [i]fmthard[/i] and [i]installboot.[/i]
Danger Will Robinson!  Disks can and do have different sizes, even disks with
the
same (Sun) part number.  This causes difficulties or inefficiencies when you
blindly
copy the partition table like this.  You will be better off using a script which
creates the new partition map based upon the actual geometry and your desired
configuration.  This really isn''t hard, but it does become site
specific.  Hint use bc.
> 2) Using a list, runs [i]newfs[/i] against the target slice and
[i]ufsdump[/i] of the source slice piped to a [i]ufsrestore[/i] of the target
slice.
Yep, been doing that for decades.  Actually, cpio is generally easier.
> The result is a bootable clone of the source disk.  Granted, there are
vulnerabilities with using ufsdump on a mounted file system but it works for us.
Actually, cpio is generally easier.
> We''re now looking at using ZFS file systems for /usr, /var, /opt,
/export/home, etc., leaving the root file system ("/") as UFS and swap
as a bare slice as it is now.
Actually, cpio is generally easier.
> I''ve successfully created an Alternate Root Pool and have
replicated the ZFS file systems from another source [i]zpool[/i] into the
Alternate Root Pool using "zfs send" and "zfs receive". 
Right now, I''m doing this without the benefit of a bootable system to
play with.  I''m experimenting with just ordinary file systems,
[b][i]not[/i][/b] "/ufs", "/opt", etc.  Now comes the
"chicken and the egg" part.
> 
> I think I would have to fix-up the mount points of the newly copied ZFS
file systems on the Alternate Root Pool so that they remain set to
"/ufs", "/opt", etc.  By the way, would these file systems
have to be "legacy" mount points?  It seems like they would have to
be.
> 
> Here''s the part that makes my head hurt: If I''ve created
this Alternate Root Pool on this separate disk slice and populated it and
exported it and I''ve replicated a UFS root ("/") file system
on that same disk but in slice 0, how does that zpool get connected when I try
to boot that cloned disk?
> 
> Fundamentally, the question is, how does one replicate a boot/system disk
that contains zpool(s) for file systems other than the root file system?
> 
> This is fairly straightforward with UFS file system technology.  The
addition of zpool identity seems to complicate the issue considerably.
IMHO, it is more straightforward with ZFS, but I''m biased :-).  For
information
see the ZFS boot pages, http://www.opensolaris.org/os/community/zfs/boot/

How far you can go with this today depends on whether you''re using
SPARC or x86.
  -- richard

The ZFS boot disk support we need has to be SPARC-based and our standards would
require that the support be present in the commercial Solaris 10 code-base,
unfortunately.

Your comments and observations are welcome input.  I thank you very much for
your time and effort in replying. :-)

Best Regards,

Mark V. Dalton
 
 
This message posted from opensolaris.org