John D Groenveld wrote:
In message <4b1403ff.6000...@sun.com>, Jordan Vaughan writes:
If I remember correctly, zbe datasets' mountpoints should be set to
"legacy". rpool/var/zones/oracle-1/ROOT/zbe's mountpoint isn't "legacy"
on your snv_127 system. What was rpool/var/zones/oracle-1/ROOT/zbe's
mountpoint property's value on the snv_125 system prior to the zfs send
operation?
Looks like the detach on the snv_125 host changes the mountpoint
property:
This is the expected behavior.
# zoneadm -z foo boot
zone 'foo': zone is already booted
# zfs get mountpoint rpool/var/zones/foo/ROOT/zbe
NAME PROPERTY VALUE SOURCE
rpool/var/zones/foo/ROOT/zbe mountpoint legacy local
# zoneadm -z foo halt
# zoneadm -z foo detach
# zfs get mountpoint rpool/var/zones/foo/ROOT/zbe
NAME PROPERTY VALUE SOURCE
rpool/var/zones/foo/ROOT/zbe mountpoint /var/opt/zones/foo/root local
Is the bug in snv_125's detach or snv_127's attach?
There is no bug, detaching a zone changes the dataset so that
it is accessible on the source system, since the dataset has not
mounted unless the zone is running. The mount behavior has changed
in b127 and the zone's dataset is always mounted now but detaching
a zone will still update the dataset mountpoint.
The work-around is to mount the zbe.
The workaround for what?
Thanks,
Jerry
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
