Niclas Sodergard wrote:
Hi everyone,
Sorry for crossposting but it seems I have stumbled upon a problem
that affects both. I have a V490 running Solaris 10u3 with a 16x750GB
raid array connected to it. I've created an 8TB zfs filesystem called
data1 and created a zfs filesystem called data1/zon
Ivan Buetler wrote:
Jerry, Thank you for your response. See my zonecfg of the named NGZ here:
[EMAIL PROTECTED] ~ # zonecfg -z named export
create -b
set zonepath=/zpool/zones/named
set autoboot=true
add inherit-pkg-dir
set dir=/lib
end
add inherit-pkg-dir
set dir=/platform
end
add inherit-pkg-d
Ivan Buetler wrote:
Is this true for OpenSolaris? My experience:
I was trying to upgrade from "SunOS 5.11 snv_28" to "SunOS 5.11 snv_54" where
my NGZ zone roots were set to a zfs mount point like below:
NAME USED AVAIL REFER MOUNTPOINT
zpool 93.8G 40.1G26
Rich Teer wrote:
Excellent; disk space won't be an issue for me, nor will the
non-live-upgradability, so I'll be putting my zone roots on
ZFS.
Rich,
Just to be clear, both live-upgrade and the mini-root upgrade
do not yet know about zfs so if you place your zones on zfs,
you won't be able to d
John Clingan wrote:
This is incorrect. All S10 updates have supported upgrading systems
with zones. I believe what you are thinking of is that live-upgrade
does not support upgrading systems with zones. This is being
fixed in the next S10 update. It is already fixed in nevada.
Which Nevada
Rich,
Rich Teer wrote:
Hi all,
Last time I checked, having one's zone roots (zonepaths) on
ZFS file systems was not a recommended practice, despite the
fact that this works. IIRC, the problem was that the upgrade
code didn't grok zfs and would therefore get terribly confused
should the zone ro
Eric Schrock wrote:
Upon closer inspection, we found that this scenario should work with
the current upgrade solution. What will definitely not work is to
delegate a ZFS dataset to a local zone, and then place system software
(i.e. Solaris package contents) within such a filesystem. This should
