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

Reply via email to