On 2/20/06, Jerry Jelinek Gerald.Jelinek at sun.com wrote:
Mike,
Mike Gerdts wrote:
There is already an RFE open for this:
6383119 RFE: add support for using zfs clones when cloning a zone
Sigh... I so wish that RFE's (with relevant status information) were
accessible outside of Sun.
I thought the bugs and RFEs were all accessible on opensolaris?
I was able to pull up 6383119 on the opensolaris bug screen but
I am not sure how easy it is to search for bugs/rfes. When I
put in zones zfs under Solaris/Utilities, I got almost
1300 hits so that isn't very helpful although 6383119 was the first
one on the list.
Ahh... my search was zoneadm AND clone AND zfs that yielded no
results. Had it been zone instead of zoneadm I would have found
it. (It looks like it is important to use AND rather than to narrow
results.)
I think we'll have a note posted about those discussions so everyone can see
what kind of ideas we have internally and maybe get ideas for new projects
that they want to start working themselves, if they are interested. I haven't
actually sent out the formal announcement about the zfs cloning to the alias
yet because we are still having some discussions about what the final design
should be (what options to offer, how it will actually behave, etc.). I
should be able to send that out later in the week though. I do have most
of the first cut at the code changes done, modulo some of these minor tweaks
like options and things, so it is really far along. We have been talking
about
talking about integrating zfs clones since we started the initial cloning
changes last November which is why it is almost done.
I look forward to this.
FWIW, with S10 GA and update 1 I have been doing an (unsupported) version of
cloning where I create an SVM soft partition for each zone, then use dd to
copy the data. This has brought zone creation down from about 5 minutes
with really fast disks to less than one with most any disk.
Yes, that is a good technique too. The only worry is the manual editing of
the zones index file that you have to do. That is guaranteed to break in the
near future. We are working on a supported technique for that using the
attach/detach -F option. I emailed that proposal out to zones-discuss
a while back. The code is in final review and should be integrating any
day now.
Yeah, I kinda expected that it would break at some point in time. The
hope was that the ability to clone using zfs or some other improvement
would help out when that breakage happened.
We are really interested in you (and others) getting involved with new ideas
and features for zones and solaris in general. I sure hope this hasn't put
you
off in any way. We would be really interested to hear what things you are
doing and what other ideas you have for new features for zones. If would be
great to see those posted on zones-discuss so we can all see what needs to be
done and who wants to work on it.
Before I get into what is good for my business, I feel I need a bit of
a disclaimer. Code that I contribute to OpenSolaris is based upon
personal interest and is a separate pursuit from the work that I
perform for my employer. My employer does not endorse or support my
development activity with OpenSolaris. All equipment used to develop
OpenSolaris is my own.
Now, here is what makes sense for my business. I would be happy to
provide you with an LSDC contract number to tip the scales in favor of
developing these features.
1. Currently the creation of the first zone on a machine (inheriting
/usr and /opt) takes longer than a jumpstart that installs a flar of
SUNWCXall. This, of course, is only counting the actual install time,
not the POST and OS boot. It would be helpful to be able to have
flars of standard zones that can be deployed as template or standard
zones. These would likely contain the /etc/zones/zone/template
name.xml file. Of course, there needs to be patch and package
compatibility between the OS that is running and the zone flar that is
applied. This could be tricky, but I am confident it is not
insurmountable. zonecfg and/or zoneadm should be enhanced to support
this.
2. If copying a zone happens using a cpio mechanism, it should use the
same options as flash archives. This would allow me to exclude
particular directories or files. This is especially important to be
able to exclude any sparse files (e.g. /var/adm/lastlog), tmp files,
etc. Bug 4480319
3. If cpio is used to clone zones, cpio should be enhanced to preserve
sparse files. In my business, there are UIDs clustered at 0 - 64k,
100 million, 212 million, 500 million, and 900 million. This causes
lastlog to increase in disk usage from negligible to gigabytes.
Similar things would likely happen with ufs quotas files. This
problem currently affects live upgrade, flash archives, and the nevada
b33 implementation of zoneadm clone. At one point I filed an RFE to
use GNU cpio
