xen discuss - Oct 2007 - HOWTO Installing a zvol-based gentoo domU from an existing linux partition

# I booted the gentoo partition

emerge xen-sources
cd /usr/src/linux-2.6.20-xen-r6
mount /boot
make && make install && make modules install
tar Ccp / linux-2.6.20-xen-r6-x64.tar.gz /boot/*2.6.20-xen-r6*
/lib/modules/*2.6.20-xen-r6*

# I transfered my xen domU kernel to a safe place.

# Now we can reboot in Solaris dom0

# Let''s create a 10 gig zvol 

zfs create -V 10G tank/gentoo-disk

# The gentoo partition was on partition 4 of the c2t0d0p0 (your mileage may
vary.)
# We create a xen config file that will drop us in a bash shell 

cat >gentoo.py <<EOF
name = "gentoo"
vcpus = 1
memory = 512
kernel = "/tank/xen/gentoo/boot/vmlinux-syms-2.6.20-xen-r6-domU"
extra = "init=/bin/bash"
disk = [ ''phy:/dev/dsk/c2t0d0p0,hdb,w'',
''phy:/dev/zvol/dsk/tank/gentoo-disk,xvda1,w'' ]
root="/dev/hdb4 ro"

vif = ['''']

on_shutdown = "destroy"
on_reboot = "restart"
on_crash = "destroy"

EOF

# let''s start the domU

xm create gentoo.py  -c

# now we need to remount the root partition rw and create xvda device and create
an ext3 filesystem (they can resize nicely and are better supported then
reiserfs [author is jail] and xfs [SGI bankrupt])

mount -o rw,remount /
mknod /dev/xvda1 b 202 1 
mke2fs -j /dev/xvda1

mount /dev/xvda1 /mnt  

# Now let''s copy the content of our original filesystem to the zvol
ext3

tar Ccp   / --one-file-system . | tar Cxp /mnt

# We need to fix fstab

cat >/mnt/etc/fstab <<EOF
/dev/xvda1              /            ext3     noatime  1 1
#/dev/sda3              /boot        ext2    noauto,noatime  1 2
proc                   /proc        proc    defaults        0 0
shm                    /dev/shm     tmpfs   nodev,nosuid,noexec 0 0
/dev/cdroms/cdrom0     /mnt/cdrom   iso9660 noauto,ro   0 0
EOF

# We need to disable hardware checksuming for eth0

cat >>/mnt/etc/conf.d/net <<EOF
postup() {
    if [[ "${IFACE}" == "eth0" ]] ; then
    /usr/sbin/ethtool -K ${IFACE}  tx off 

}
EOF

vi /mnt/etc/inittab # comment all all the c2:c5 getty entries and keep the first
one (c1)

umount /mnt
mount -o ro,remount /
halt

# Now this is our final gentoo.py

cat >gentoo.py <<EOF
name = "gentoo"
vcpus = 1
memory = 512
kernel = "/tank/xen/gentoo/boot/vmlinux-syms-2.6.20-xen-r6-domU"
extra = ""
disk = [ ''phy:/dev/zvol/dsk/tank/gentoo-disk,xvda1,w'' ]
root="/dev/xvda1 ro"

vif = ['''']

on_shutdown = "destroy"
on_reboot = "restart"
on_crash = "destroy"
on_xen_start = "start"
EOF

xm new gentoo.py
xm start gentoo.py

voila :D
 
 
This message posted from opensolaris.org

my post was truncated by the jive interface... I reposted it by e-mail... it
should appear shortly.
 
 
This message posted from opensolaris.org

Oh well, even if I post via e-mail it gets truncated by opensolaris.org jive
forum interface. It probably doesn''t escape meta-character correctly.

You can find my post here http://www.kugutsumen.com/showthread.php?t=1701
 
 
This message posted from opensolaris.org

Kugutsumen wrote:
> 
> xm new gentoo.py
> xm start gentoo.py
> 
> voila :D
When you domU is shutdown, snapshot the zvol.  Makes
a great backup in case you blow way something..



MRJ


-- 
Mark Johnson <mark.johnson@sun.com>
Sun Microsystems, Inc.
(781) 442-0869

Yes, I did that :)

Btw what''s the best way to dump and archive a snapshot?
 
 
This message posted from opensolaris.org

ZFS Snapshots sent by zfs send/recv are data streams, so you can dump to a file:

zfs snapshot pool/dataset@snapshot
zfs send pool/dataset@snapshot > /backups/dataset-snapshot-100107.zfssnap

Then restore later:

cat /backups/dataset-snapshot-100107.zfssnap | zfs recv -d pool

For compression, etc, just send the snapshot datastream to gzip or something
rather than directly to file.

benr.
 
 
This message posted from opensolaris.org

> ZFS Snapshots sent by zfs send/recv are data streams,
> so you can dump to a file:
> 
> zfs snapshot pool/dataset@snapshot
> zfs send pool/dataset@snapshot >
> /backups/dataset-snapshot-100107.zfssnap
> 
> Then restore later:
> 
> cat /backups/dataset-snapshot-100107.zfssnap | zfs
> recv -d pool
> 
> For compression, etc, just send the snapshot
> datastream to gzip or something rather than directly
> to file.
> 
> benr.
It''s a bummer, but from what I''ve heard, this isn''t a
great idea.  Among other reasons, ZFS Send data format is subject to change, so
it''s very possible that you won''t be able to restore anything
you''ve archived after an update.  Also, that data format is apparently
not particularly good for detecting when bits have been flipped and the archive
is corrupt.
-- 
This message posted from opensolaris.org