You may want to consider sharing a single /export/home from an NFS server (or 
from the dom0?), and NFS mounting it from each vm. I think this has a lot of 
advantages, especially if they are all "your" home directories .. now if this 
is a shared customer environment, it may not be as nice. I can also see obvious 
advantages of keeping them separated, even if they are all yours, but most of 
them are based on using a GUI desktop on more than one at a time.

COMMENTS ON THE PROCEDURE WITHIN....


On Jan 25, 2010, at 9:54 AM, Kent Watsen wrote:

> 
> I have ZFS-based SAN and an xVM-based virtualization server.  I have a 
> para-virtualized 2009.6 DomU that gets it's root disk from a zvol on the SAN. 
>  I want to replace this DomU's /export/home with another virtual drive 
> mounted from the SAN (so that I can easily fresh install the DomU's OS).
> 
> Following some online guides, I have achieved my goal, but I wonder if I'm 
> unnecessarily having two layers of ZFS - leading to inefficiencies.  What 
> I've done so far is:
> 
> In Dom0:
>  - zfs create -V 1T tank/lunar-export-home

1TB PER virtual machine, dang! :)

>  - xm block-attach lunar-1 phy:/dev/zvol/dsk/tank/lunar-export-home 1 w

I think "virsh" is the "sponsored" interface to do this, but this should work.

> 
> In DomU:
>  - touch /reconfigure
>  - shutdown -i5 -g0 -y

You should NOT need to do the above two steps. The disk shows up instantly, if 
it doesn't, try "devfsadm -c disk"


You will probably also have to "enable" the root account as a user, or create 
another user account with "privileges" that does not have its home directory on 
/export/home.


>  - echo | pfexec format  (it shows up as "c7d1")
>  - zpool create data c7d1
>  - zfs snapshot -r rpool/export/h...@transfer
>  - zfs send rpool/export/h...@transfer | zfs receive data/home
>  - zfs send rpool/export/home/k...@transfer | zfs receive data/home/kent

you might look into "zfs send -R" instead of sending each one separately.

>  - zfs umount -f rpool/export/home/kent
>  - zfs umount -f rpool/export/home

I would suggest something like:

zfs set mountpoint=/oldhome rpool/export/home

No need to umount. I would not suggest just umounting, I prefer to "change" the 
mountpoint, in case the system reboots or something unexpectedly. Also, 
remember that the "kent" dataset inherits its mountpoint from the parent, so it 
will automatically move underneath.


>  - zfs set mountpoint=/export/home data/home
>  - zfs set mountpoint=/export/home/kent data/home/kent

The second set mountpoint will not be necessary, "kent" will automatically stay 
under data/home unless you have previously set it statically, in which case you 
can do something like

zfs inherit mountpoint data/home/kent



>  - zfs destroy -r rpool/export/home

right, only after verifying everything is ok :)

> 
> 
> Is there a better strategy?  Could one mount /export/home directly (i.e. 
> `mount /dev/dsk/c7d1s2 /export/home`) and, if so, would it be more efficient? 
>  - what ZFS-goodness would be lost?

think snapshots, although you can take them from the dom0, its not as nice. 
stick with zfs goodness ;)

Tommy

> 
> Thanks,
> Kent
> 
> 
> _______________________________________________
> xen-discuss mailing list
> [email protected]

_______________________________________________
xen-discuss mailing list
[email protected]

Reply via email to