I have just recently discovered the XEN VMM and am trying to familiarize myself with it. I''m a newbe at it, so bear with me. I''d like to install an O/S onto a guest virtual machine. Domain 0 is RHEL4 on Xen 2.0.7. My question is how I would go about installing from a set of distribution CD''s (say RHEL4 or SUSE9) into a file-backed VMM. Can anyone help me out with this? Thanks, Nick Couchman Systems Integrator SEAKR Engineering, Inc. 6221 South Racine Circle Centennial, CO 80111 Main: (303) 790-8499 Fax: (303) 790-8720 Web: http://www.seakr.com _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> I have just recently discovered the XEN VMM and am trying to familiarize > myself with it. I''m a newbe at it, so bear with me.No probs, here goes...> I''d like to install an O/S onto a guest virtual machine. Domain 0 is RHEL4 > on Xen 2.0.7. My question is how I would go about installing from a set of > distribution CD''s (say RHEL4 or SUSE9) into a file-backed VMM. Can anyone > help me out with this?Installing into a file-backed VBD from a distro CD is tricky. If you really want to use the distro CD then the easiest thing is to install into a spare partition and use that as your virtual machine disk. (it''ll also perform better than a file-backed VBD) Otherwise, debootstrap (Debian) and rpmstrap (works with Redhat, maybe Suse) may be worth looking at: just mount the loop file and use one of these programs to install into the directory. Cheers, Mark> Thanks, > > Nick Couchman > Systems Integrator > SEAKR Engineering, Inc. > 6221 South Racine Circle > Centennial, CO 80111 > Main: (303) 790-8499 > Fax: (303) 790-8720 > Web: http://www.seakr.com_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
There are probably better ways... But I would probably "cheat" and do a normal (or minimal) install of the guest OS into a partition somewhere and then copy that partition into a file-backed VMM. Then I''d make a copy of that file and use that to stamp out new copies as required. No doubt there are better ways, but that''s probably what I would do. :) I happened to have a tar backup of a minimal SuSE SLES 9 install lying around (that I had made months ago under Vmware and then scp''d out of the virtual machine) and I just used that to make the guest. Seemed to work just fine. SUSE SLES 9 has the option to "install into a directory". So if that was your Dom 0 you could use that to stamp out mew guests. I''m not sure if RHEL4 has a similar functionality. Perhaps it has a function to install a UML guest into a directory and you could use that to populate your file system (once you''ve mounted that file-backed filesystem somewhere)? Though this wont help you to make a SUSE9 image under Red Hat or vice-versa. Which is why I like my original idea! Cheers Mike> -----Original Message----- > From: xen-users-bounces@lists.xensource.com > [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of > Nick Couchman > Sent: Thursday, 25 August 2005 8:43 a.m. > To: XEN Users Mailing List > Subject: [Xen-users] Guest O/S Questions > > I have just recently discovered the XEN VMM and am trying to > familiarize myself with it. I''m a newbe at it, so bear with me. > > I''d like to install an O/S onto a guest virtual machine. > Domain 0 is RHEL4 on Xen 2.0.7. My question is how I would go > about installing from a set of distribution CD''s (say RHEL4 > or SUSE9) into a file-backed VMM. Can anyone help me out with this? > > Thanks, > > Nick Couchman > Systems Integrator > SEAKR Engineering, Inc. > 6221 South Racine Circle > Centennial, CO 80111 > Main: (303) 790-8499 > Fax: (303) 790-8720 > Web: http://www.seakr.com > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Mark Williamson wrote:>>I have just recently discovered the XEN VMM and am trying to familiarize >>myself with it. I''m a newbe at it, so bear with me. >> >> > >No probs, here goes... > > > >>I''d like to install an O/S onto a guest virtual machine. Domain 0 is RHEL4 >>on Xen 2.0.7. My question is how I would go about installing from a set of >>distribution CD''s (say RHEL4 or SUSE9) into a file-backed VMM. Can anyone >>help me out with this? >> >> > >Installing into a file-backed VBD from a distro CD is tricky. >Actually, if you use QEMU to install the distro into a raw disk, and you only create one partition on the disk, you should be able to just use a command like this: dd skip=63 bs=512 if=qemu.img of=xen.img Keep in mind, I''ve not tried this myself :-) Exporting the qemu image as /dev/hda in domU and just setting your parameters right seems to work well and is much simplier. Regards, Anthony Liguori> If you really >want to use the distro CD then the easiest thing is to install into a spare >partition and use that as your virtual machine disk. (it''ll also perform >better than a file-backed VBD) > >Otherwise, debootstrap (Debian) and rpmstrap (works with Redhat, maybe Suse) >may be worth looking at: just mount the loop file and use one of these >programs to install into the directory. > >Cheers, >Mark > > > >>Thanks, >> >>Nick Couchman >>Systems Integrator >>SEAKR Engineering, Inc. >>6221 South Racine Circle >>Centennial, CO 80111 >>Main: (303) 790-8499 >>Fax: (303) 790-8720 >>Web: http://www.seakr.com >> >> > >_______________________________________________ >Xen-users mailing list >Xen-users@lists.xensource.com >http://lists.xensource.com/xen-users > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Here''s my instructions that I wrote up for another list member this is for RHEL3, modify for your needs. You may not need to use the mke2fs binary as RHEL4 is more modern. YMMV 1) Take the iso''s and copy the RPMS to a folder /root/rhel3 2) Get a list of RPM''s that you need, here''s a list from one of my previous installs. I''m going to work on paring this down... Also, this is important! grab a copy of mke2fs binary from a previous install. hwdata-0.101.14-1.noarch. libgcc-3.2.3-47.i386. redhat-logos-1.1.14.3-1.noarch. setup-2.5.27-1.noarch. filesystem-2.2.1-3.i386. basesystem-8.0-2.noarch. termcap-11.0.1-17.1.noarch. tzdata-2004e-1.EL.noarch. glibc-common-2.3.2-95.30.i386. glibc-2.3.2-95.30.i686. beecrypt-3.0.1-0.20030630.i386. bzip2-libs-1.0.2-11.i386. chkconfig-1.3.11-0.3.i386. cracklib-2.7-22.i386. db4-4.1.25-8.i386. e2fsprogs-1.32-15.1.i386. elfutils-libelf-0.91-3.i386. ethtool-1.8-3.3.i386. expat-1.95.5-6.i386. gdbm-1.8.0-20.i386. glib-1.2.10-11.1.i386. glib2-2.2.3-2.0.i386. gmp-4.1.2-5.i386. hdparm-5.4-1.i386. iputils-20020927-11.30.1.i386. laus-libs-0.1-66RHEL3.i386. libattr-2.2.0-1.i386. libacl-2.2.3-1.i386. libtermcap-2.0.8-35.i386. losetup-2.11y-31.2.i386. lvm-1.0.8-9.i386. mingetty-1.06-1.i386. mktemp-1.5-18.i386. bash-2.05b-29.0.3.i386. iproute-2.4.7-11.30E.1.i386. MAKEDEV-3.3.12.3-1.i386. mount-2.11y-31.2.i386. net-tools-1.60-20E.1.i386. pcre-3.9-10.1.i386. popt-1.8.2-13.i386. raidtools-1.00.3-7.i386. rootfiles-7.2-6.noarch. setserial-2.17-12.i386. shadow-utils-4.0.3-22.02.i386. slang-1.4.5-18.i386. newt-0.51.5-1.i386. usbutils-0.11-1.i386. hotplug-2002_04_01-20.2.i386. vim-minimal-6.3.029-1.30E.3.i386. words-2-21.noarch. cracklib-dicts-2.7-22.i386. zlib-1.1.4-8.1.i386. file-3.39-9.i386. info-4.5-3.i386. cpio-2.5-3.i386. ed-0.2-33.i386. findutils-4.1.7-9.i386. gawk-3.1.1-9.i386. grep-2.5.1-24.1.i386. coreutils-4.5.3-26.i386. ash-0.3.8-16.i386. grub-0.93-4.3.i386. krb5-libs-1.2.7-31.i386. modutils-2.4.25-14.EL.i386. ncurses-5.3-9.3.i386. gpm-1.19.3-27.2.i386. less-378-11.i386. gzip-1.3.3-9.i386. openssl-0.9.7a-33.12.i686. procps-2.0.17-13.i386. psmisc-21.3-1.RHEL.0.i386. readline-4.3-5.2.i386. python-2.2.3-6.i386. pyxf86config-0.3.5-1.i386. rhpl-0.110.6-1.i386. sed-4.0.7-3.i386. dev-3.3.12.3-1.i386. pam-0.75-62.i386. authconfig-4.3.7-1.i386. kudzu-1.1.22.9-1.i386. sysklogd-1.4.1-12.3.i386. SysVinit-2.85-4.2.i386. tar-1.13.25-13.i386. mkinitrd-3.5.13-1.i386. util-linux-2.11y-31.2.i386. which-2.14-7.i386. initscripts-7.31.18.EL-1.i386. cyrus-sasl-2.1.15-10.i386. cyrus-sasl-md5-2.1.15-10.i386. kernel-2.4.21-27.EL.i686. kernel-smp-2.4.21-27.EL.i686. openldap-2.0.27-17.i386. libuser-0.51.7-1.EL3.3.i386. passwd-0.68-3.1.i386. usermode-1.68-5E.2.i386. kbd-1.08-10.2.i386. redhat-config-mouse-1.0.13-1.noarch. rpm-4.2.3-13.i386. rpm-libs-4.2.3-13.i386. eal3-certification-doc-1.1-2.noarch. mailcap-2.1.14-1.noarch. man-pages-1.60-4.2.noarch. redhat-menus-0.39-1.noarch. rmt-0.4b28-7.i386. dump-0.4b28-7.i386. specspo-3EL-1.noarch. dos2unix-3.1-15.i386. dosfstools-2.8-10.i386. eject-2.0.13-2.i386. finger-0.17-18.i386. hesiod-3.0.2-28.1.i386. jfsutils-1.1.2-2.i386. krbafs-1.1.1-11.i386. lha-1.14i-10.4.i386. attr-2.2.0-1.i386. acl-2.2.3-1.i386. libjpeg-6b-30.i386. libstdc++-3.2.3-47.i386. libtool-libs-1.4.3-6.i386. lslk-1.29-8.i386. lsof-4.63-4.i386. mailx-8.1.1-31.i386. bzip2-1.0.2-11.i386. crontabs-1.10-5.noarch. htmlview-2.0.0-10.noarch. mt-st-0.7-11.i386. nc-1.10-18.i386. ncompress-4.2.4-38.i386. pam_passwdqc-0.7.5-1.i386. pam_smb-1.1.7-1.i386. parted-1.6.3-29.3.i386. patch-2.5.4-16.i386. pax-3.0-6.i386. perl-5.8.0-88.9.i386. fbset-2.1-13.i386. perl-Filter-1.29-3.i386. logrotate-3.6.9-1.i386. procmail-3.22-9.i386. pspell-0.12.2-16.1.i386. rdate-1.3-2.i386. rdist-6.1.5-35.30.1.i386. rpmdb-redhat-3-0.20041216.i386. rsh-0.17-17.i386. rsync-2.5.7-5.3E.i386. schedutils-1.3.0-5.i386. setarch-1.3-1.i386. lockdev-1.0.1-1.2.i386. netconfig-0.8.19-1.1.i386. ntsysv-1.3.11-0.3.i386. setuptool-1.13-1.i386. slocate-2.7-3.i386. star-1.5a08-4.i386. symlinks-1.2-18.i386. tcp_wrappers-7.6-34.1.i386. traceroute-1.4a12-20.i386. unix2dos-2.2-19.i386. unzip-5.50-34.i386. wireless-tools-26-2.i386. XFree86-libs-data-4.3.0-78.EL.i386. zip-2.3-16.i386. freetype-2.1.4-4.0.i386. fontconfig-2.2.1-13.i386. libpng-1.2.2-25.i386. libtiff-3.5.7-20.1.i386. libxml2-2.5.10-7.i386. binutils-2.14.90.0.4-35.i386. diffutils-2.8.1-8.i386. elfutils-0.91-3.i386. at-3.1.8-60_EL3.i386. eal3-certification-1.1-2.noarch. groff-1.18.1-27.i386. jwhois-3.2.2-1.i386. krb5-workstation-1.2.7-31.i386. krbafs-utils-1.1.1-11.i386. laus-0.1-66RHEL3.i386. libgcj-3.2.3-47.i386. logwatch-4.3.2-2.noarch. m4-1.4.1-13.i386. make-3.79.1-17.i386. mgetty-1.1.30-3.i386. irda-utils-0.9.15-1.i386. mtools-3.9.8-8.i386. aspell-0.33.7.1-25.1.i386. man-1.5k-10.i386. minicom-2.00.0-17.1.i386. mtr-0.52-2.i386. nano-1.2.1-4.i386. nscd-2.3.2-95.30.i386. nss_db-2.2-20.4.i386. authd-1.4.1-1.rhel3.i386. bind-libs-9.2.4-1_EL3.i386. bind-utils-9.2.4-1_EL3.i386. cups-libs-1.1.17-13.3.16.i386. libwvstreams-3.70-10.i386. pam_krb5-1.73-1.i386. pdksh-5.2.14-21.i386. pinfo-0.6.6-4.i386. psacct-6.3.2-28.rhel3.i386. pyOpenSSL-0.5.1-8.i386. bc-1.06-15.i386. ftp-0.17-17.i386. lftp-2.6.3-5.i386. gettext-0.11.4-7.i386. libxml2-python-2.5.10-7.i386. python-optik-1.4.1-2.noarch. rhnlib-1.8-6.p22.noarch. jpackage-utils-1.5.38-1jpp_4rh.noarch. ppp-2.4.1-14.1.i386. sharutils-4.2.1-16.i386. stunnel-4.04-4.i386. sudo-1.6.7p5-1.i386. syslinux-2.06-0.3E.i386. sysreport-1.3.7.2-2.noarch. talk-0.17-20.i386. mkbootdisk-1.5.1-1.i386. tcsh-6.12-11.EL3.i386. telnet-0.17-26.i386. tftp-0.39-0.EL3.1.i386. time-1.7-23.i386. tmpwatch-2.8.4-5.i386. utempter-0.5.5-1.3EL.0.i386. vim-common-6.3.029-1.30E.3.i386. wget-1.8.2-15.i386. apmd-3.0.2-18.i386. cyrus-sasl-gssapi-2.1.15-10.i386. cyrus-sasl-plain-2.1.15-10.i386. devlabel-0.48.03-6.i386. dhclient-3.0.1-10_EL3.i386. diskdumputils-0.4.0-1.i386. ipsec-tools-0.2.5-0.6.i386. isdn4k-utils-3.1-76.i386. iptables-1.2.8-12.3.i386. iptables-ipv6-1.2.8-12.3.i386. iscsi-initiator-utils-3.6.2-4.i386. kernel-pcmcia-cs-3.1.31-13.i386. kernel-utils-2.4-8.37.7.i386. autofs-4.1.3-47.i386. gnupg-1.2.1-10.i386. nss_ldap-207-11.i386. openssh-3.6.1p2-33.30.3.i386. openssh-clients-3.6.1p2-33.30.3.i386. netdump-0.6.11-3.i386. openssh-server-3.6.1p2-33.30.3.i386. pciutils-2.1.10-7.i386. portmap-4.0-56.i386. nfs-utils-1.0.6-33EL.i386. prelink-0.3.2-2.EL.i386. quota-3.10-4.i386. redhat-config-securitylevel-tui-1.2.9.2-1.i386. rp-pppoe-3.5-4.1.i386. sendmail-8.12.11-4.RHEL3.1.i386. mdadm-1.5.0-9.i386. tcpdump-3.7.2-7.E3.2.i386. vconfig-1.6-2.i386. vixie-cron-3.0.1-75.1.i386. wvdial-1.53-11.i386. XFree86-libs-4.3.0-78.EL.i386. XFree86-Mesa-libGL-4.3.0-78.EL.i386. xinetd-2.3.12-6.3E.i386. cups-1.1.17-13.3.16.i386. redhat-lsb-1.3-3.1.EL3.i386. ypbind-1.12-5.21.1.i386. yp-tools-2.8-6.i386. rpm-python-4.2.3-13.i386. redhat-config-network-tui-1.2.63-1.noarch. up2date-4.2.57-2.i386. up2date-update-4.2.57-2.i386. net-snmp-libs-5.0.9-2.30E.12.i386. perl-DateManip-5.42a-0.rhel3.noarch. net-snmp-5.0.9-2.30E.12.i386. libcap-1.10-15.1.i386. tcl-8.3.5-92.2.i386. ntp-4.1.2-4.EL3.1.i386. cipe-1.4.5-16.i386. net-snmp-utils-5.0.9-2.30E.12.i386. openldap-clients-2.0.27-17.i386. sysstat-5.0.5-5.rhel3.i386. compat-libstdc++-7.3-2.96.128.i386. openssl096b-0.9.6b-16.i386. compat-db-4.0.14-5.1.i386. curl-7.10.6-4.2.i386. compat-glibc-7.x-2.2.4.32.6.i386. redhat-release-3ES-7.4.i386. comps-3ES-0.20041216.i386. 3) Use the Fedora Xen Quickstart Howto as a base instruction set. http://fedoraproject.org/wiki/FedoraXenQuickstart 4) Use the mke2fs binary that you copied to format the image file, otherwise Fedora C4 mke2fs has features that RHEL3 does not support, and you will have issues. 5) At the mkdir /proc stage also create the following directories. mkdir /mnt/sys mkdir /mnt/dev/pts There''s one more in /mnt/dev, but I forgot to write it down. When the domU boots, it will give an error. and you can create it. 6) Use MAKEDEV to create console, tty, random, and urandom. MAKEDEV console -d /mnt/dev MAKEDEV tty -d /mnt/dev MAKEDEV random -d /mnt/dev MAKEDEV urandom -d /mnt/dev 7) At the yum step, use rpm to install the packages listed above, or use your list. rpm -ivh --root /mnt package.rpm --force --nodeps I actually did something like this for A in `cat install.list` do rpm -ivh --root /mnt /root/rpms/${A}rpm --force --nodeps done 8) Make sure that /etc/fstab matches the howto, the rpms add misc stuff to it. Note that you will be using the 2.6 domU kernel that FC4 provides, it works nicely. That''s it. Enjoy! Brian Kosick On Wed, 2005-08-24 at 14:43 -0600, Nick Couchman wrote:> I have just recently discovered the XEN VMM and am trying to > familiarize myself with it. I''m a newbe at it, so bear with me. > > I''d like to install an O/S onto a guest virtual machine. Domain 0 is > RHEL4 on Xen 2.0.7. My question is how I would go about installing > from a set of distribution CD''s (say RHEL4 or SUSE9) into a > file-backed VMM. Can anyone help me out with this? > > Thanks, > > Nick Couchman > Systems Integrator > SEAKR Engineering, Inc. > 6221 South Racine Circle > Centennial, CO 80111 > Main: (303) 790-8499 > Fax: (303) 790-8720 > Web: http://www.seakr.com > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Another thought: http://free.oszoo.org These are qemu images but (in principle) exporting them as a "whole disk" to a Xen virtual machine ought to work too. Cheers, Mark On Wednesday 24 August 2005 22:58, Anthony Liguori wrote:> Mark Williamson wrote: > >>I have just recently discovered the XEN VMM and am trying to familiarize > >>myself with it. I''m a newbe at it, so bear with me. > > > >No probs, here goes... > > > >>I''d like to install an O/S onto a guest virtual machine. Domain 0 is > >> RHEL4 on Xen 2.0.7. My question is how I would go about installing from > >> a set of distribution CD''s (say RHEL4 or SUSE9) into a file-backed VMM. > >> Can anyone help me out with this? > > > >Installing into a file-backed VBD from a distro CD is tricky. > > Actually, if you use QEMU to install the distro into a raw disk, and you > only create one partition on the disk, you should be able to just use a > command like this: > > dd skip=63 bs=512 if=qemu.img of=xen.img > > Keep in mind, I''ve not tried this myself :-) > > Exporting the qemu image as /dev/hda in domU and just setting your > parameters right seems to work well and is much simplier. > > Regards, > > Anthony Liguori > > > If you really > >want to use the distro CD then the easiest thing is to install into a > > spare partition and use that as your virtual machine disk. (it''ll also > > perform better than a file-backed VBD) > > > >Otherwise, debootstrap (Debian) and rpmstrap (works with Redhat, maybe > > Suse) may be worth looking at: just mount the loop file and use one of > > these programs to install into the directory. > > > >Cheers, > >Mark > > > >>Thanks, > >> > >>Nick Couchman > >>Systems Integrator > >>SEAKR Engineering, Inc. > >>6221 South Racine Circle > >>Centennial, CO 80111 > >>Main: (303) 790-8499 > >>Fax: (303) 790-8720 > >>Web: http://www.seakr.com > > > >_______________________________________________ > >Xen-users mailing list > >Xen-users@lists.xensource.com > >http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Anthony Liguori wrote:> Mark Williamson wrote: > >>> I have just recently discovered the XEN VMM and am trying to >>> familiarize >>> myself with it. I''m a newbe at it, so bear with me. >>> >> >> >> No probs, here goes... >> >> >> >>> I''d like to install an O/S onto a guest virtual machine. Domain 0 >>> is RHEL4 >>> on Xen 2.0.7. My question is how I would go about installing from a >>> set of >>> distribution CD''s (say RHEL4 or SUSE9) into a file-backed VMM. Can >>> anyone >>> help me out with this? >>> >> >> >> Installing into a file-backed VBD from a distro CD is tricky. >> > Actually, if you use QEMU to install the distro into a raw disk, and > you only create one partition on the disk, you should be able to just > use a command like this:That''s actually getting to be a preferred method here, at least for some folks. qemu file-backed installs allow you to use an existing RHEL installer, without much fuss or mess, the tricky bit is finding the filesystem afterward, as what qemu produces is a _partitioned_ file with filesystems within it.> > dd skip=63 bs=512 if=qemu.img of=xen.img > > Keep in mind, I''ve not tried this myself :-) > > Exporting the qemu image as /dev/hda in domU and just setting your > parameters right seems to work well and is much simplier.Are you doing this with the qemu partitioned file itself? The procedure I''ve worked up is: 1. Create a target install file. Creating this as a sparse file saves blocks on disk until you actually need them: dd if=/dev/zero of=rhel4_qemu bs=1024k seek=$(( 6 * 1024 )) count=0 The $(( 6 * 1024 )) gives you 6 GB to work with, the seek means it''s sparse, and the count=0 means there''s only one block used on disk 2. Install RHEL flavor of your choosing. You can boot either from an install CD, _or_ an ISO image corresponding to same: qemu -cdrom <cd drive or ISO image> -boot c rhel4_qemu Walk through the installation. Your image file (rhel4_qemu) will automatically be partitioned. 3. Shut down qemu after the install is completed. 4. Find out the image file''s partitioning. fdisk''s ''-u'' option gives output in sectors. This helps in the next step. Sample partition table: $ /sbin/fdisk -lu rhel4 You must set cylinders. You can do this from the extra functions menu. Disk rhel4: 0 MB, 0 bytes 255 heads, 63 sectors/track, 0 cylinders, total 0 sectors Units = sectors of 1 * 512 = 512 bytes Device Boot Start End Blocks Id System rhel4p1 * 63 208844 104391 83 Linux rhel4p2 208845 401624 96390 82 Linux swap / Solaris rhel4p3 401625 4192964 1895670 83 Linux Ignore the cylinder messages (they matter if you''re going to modify the partition table). The start sector times the blocksize (512 bytes) gives you the partition offset in bytes. This is used if you want to loopback mount the filesystems to copy them someplace else, which you do. The first partition is /boot, the second is /. I didn''t use logical volumes, though it''s possible to do so, complicating matters somewhat more. 5. Loopback mount the qemu images, creating a couple of mountpoints. Using the file I''m referencing above (rhel4): mkdir mp1 mp2 su -c ''mount -o loop,offset=$(( 63 * 512 )) -t ext3 rhel4 mp1'' su -c ''mount -o loop,offset=$(( 4192964 * 512 )) -t ext3 rhel4 mp2'' As a final step, you could copy the contents of these two mountpoints into a partition or a single filesystem image (a file with just a filesystem in it, no partitions) which can be used for a Xen file-backed DomU, etc. You will have to modify the DomU''s /etc/fstab and likely comment the MAC address registered in /etc/sysconfig/network-scripts/ifcfg-eth0 for things to work properly. Once you have a suitable image, you can simply use it as a DomU image for new deployments. There are some good related docs on Fedora and Debian installs as well: https://www.redhat.com/archives/fedora-devel-list/2005-January/msg01320.html http://www.fedoraproject.org/wiki/FedoraXenQuickstart Debian: http://hands.com/d-i/HOWTO-xen.txt -- Karsten M. Self <karsten@xensource.com> XenSource, Inc. 2300 Geng Road #250 +1 650.798.5900 x259 Palo Alto, CA 94303 +1 650.493.1579 fax _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> 5. Loopback mount the qemu images, creating a couple of mountpoints. > Using the file I''m referencing above (rhel4): > > mkdir mp1 mp2 > su -c ''mount -o loop,offset=$(( 63 * 512 )) -t ext3 rhel4 mp1'' > su -c ''mount -o loop,offset=$(( 4192964 * 512 )) -t > ext3 rhel4 mp2''Just use ''lomount'' which is installed with the -unstable version of Xen. Ian _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Karsten M. Self wrote:> 4. Find out the image file''s partitioning. fdisk''s ''-u'' option gives > output in sectors. This helps in the next step. Sample partition > table: > $ /sbin/fdisk -lu rhel4 > You must set cylinders. > You can do this from the extra functions menu. > > Disk rhel4: 0 MB, 0 bytes > 255 heads, 63 sectors/track, 0 cylinders, total 0 sectors > Units = sectors of 1 * 512 = 512 bytes > > Device Boot Start End Blocks Id System > rhel4p1 * 63 208844 104391 83 Linux > rhel4p2 208845 401624 96390 82 Linux > swap / Solaris > rhel4p3 401625 4192964 1895670 83 Linux > > Ignore the cylinder messages (they matter if you''re going to modify > the partition table). > > The start sector times the blocksize (512 bytes) gives you the > partition offset in bytes. This is used if you want to loopback > mount the filesystems to copy them someplace else, which you do. > > The first partition is /boot, the second is /. I didn''t use logical > volumes, though it''s possible to do so, complicating matters > somewhat more. >...or as Ian pointed out off-list, you can use lomount (there''s a related losetup command), included in Xen 3. I mentioned the hand-rolled method as lomount isn''t generally available in most off-the-shelf distros. It also helps in understanding the concept of partitioned files. Cheers. -- Karsten M. Self <karsten@xensource.com> XenSource, Inc. 2300 Geng Road #250 +1 650.798.5900 x259 Palo Alto, CA 94303 +1 650.493.1579 fax _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Karsten M. Self wrote:> That''s actually getting to be a preferred method here, at least for > some folks. > > qemu file-backed installs allow you to use an existing RHEL installer, > without much fuss or mess, the tricky bit is finding the filesystem > afterward, as what qemu produces is a _partitioned_ file with > filesystems within it.Or you can just expose as a device with a partition table. IMHO, this is the best approach. I''ve even had success resizing the disk image, and then (using a boot disk), appropriately resizing the filesystem.>> >> dd skip=63 bs=512 if=qemu.img of=xen.img >> >> Keep in mind, I''ve not tried this myself :-) >> >> Exporting the qemu image as /dev/hda in domU and just setting your >> parameters right seems to work well and is much simplier. > > > Are you doing this with the qemu partitioned file itself?Yup. My xend config line looks like this: disk = [ ''file:/root/FC4.img,hda,w'' ] root = "/dev/hda1" That just works. There shouldn''t be any disadvantage to using this method (other than it makes resizing individual partitions a bit more difficult).> The first partition is /boot, the second is /. I didn''t use logical > volumes, though it''s possible to do so, complicating matters > somewhat more.If you want to extract the filesystems, I''d recommend using lomount as Ian suggests (and then just tar up the partitions).> 5. Loopback mount the qemu images, creating a couple of mountpoints. > Using the file I''m referencing above (rhel4): > > mkdir mp1 mp2 > su -c ''mount -o loop,offset=$(( 63 * 512 )) -t ext3 rhel4 mp1'' > su -c ''mount -o loop,offset=$(( 4192964 * 512 )) -t ext3 rhel4 > mp2'' > > As a final step, you could copy the contents of these two mountpoints > into a partition or a single filesystem image (a file with just a > filesystem in it, no partitions) which can be used for a Xen file-backed > DomU, etc.There''s a few things you''ll want to do once you do the QEMU install. Namely, you''ll want to make sure to install the appropriate modules (and run depmod). Otherwise, it just works. The next logical step is to run QEMU within a domU and automate the whole process. QEMU is a pretty amazing little piece of software :-) Regards, Anthony Liguori> You will have to modify the DomU''s /etc/fstab and likely comment the MAC > address registered in /etc/sysconfig/network-scripts/ifcfg-eth0 for > things to work properly. > > Once you have a suitable image, you can simply use it as a DomU image > for new deployments. > > > There are some good related docs on Fedora and Debian installs as well: > > https://www.redhat.com/archives/fedora-devel-list/2005-January/msg01320.html > > http://www.fedoraproject.org/wiki/FedoraXenQuickstart > > Debian: http://hands.com/d-i/HOWTO-xen.txt > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Anthony Liguori wrote:> Karsten M. Self wrote: > >> That''s actually getting to be a preferred method here, at least for >> some folks. >> >> qemu file-backed installs allow you to use an existing RHEL >> installer, without much fuss or mess, the tricky bit is finding the >> filesystem afterward, as what qemu produces is a _partitioned_ file >> with filesystems within it. > > > Or you can just expose as a device with a partition table. IMHO, this > is the best approach. > > I''ve even had success resizing the disk image, and then (using a boot > disk), appropriately resizing the filesystem. > >>> >>> dd skip=63 bs=512 if=qemu.img of=xen.img >>> >>> Keep in mind, I''ve not tried this myself :-) >>Doh! I missed your skip. That should work for a partitioned file with a single partition. If you''ve got multiple partitions, you''d want to add the size in blocks as ''count'', otherwise you''re going to have multiple partitions in what you''re assuming is a single filesystem image. Somewhere down the road, something''s probably going to get confused, unhappy, or both, about that. Or you''re just going to carry around a lot of slack space.>> Are you doing this with the qemu partitioned file itself? > > > Yup. > > My xend config line looks like this: > > disk = [ ''file:/root/FC4.img,hda,w'' ] > root = "/dev/hda1"> > That just works. There shouldn''t be any disadvantage to using this > method (other than it makes resizing individual partitions a bit more > difficult).... that''s on a filesystem image, not a partitioned file, though, right?>> volumes, though it''s possible to do so, complicating matters >> somewhat more. > > The first partition is /boot, the second is /. I didn''t use logical > If you want to extract the filesystems, I''d recommend using lomount as > Ian suggests (and then just tar up the partitions).Sure. Diff''rent strokes for diff''rent folks...[1]> >> 5. Loopback mount the qemu images, creating a couple of mountpoints. >> Using the file I''m referencing above (rhel4): >> >> mkdir mp1 mp2 >> su -c ''mount -o loop,offset=$(( 63 * 512 )) -t ext3 rhel4 mp1'' >> su -c ''mount -o loop,offset=$(( 4192964 * 512 )) -t ext3 rhel4 >> mp2'' >> >> As a final step, you could copy the contents of these two mountpoints >> into a partition or a single filesystem image (a file with just a >> filesystem in it, no partitions) which can be used for a Xen file-backed >> DomU, etc. > > > There''s a few things you''ll want to do once you do the QEMU install. > Namely, you''ll want to make sure to install the appropriate modules > (and run depmod).Which modules? I''m running RHEL4 and after /etc/fstab, relocating boot and modifying /etc/fstab, commenting out the MAC address, it seems happy.> > Otherwise, it just works. > > The next logical step is to run QEMU within a domU and automate the > whole process.Actually, a decent RH bootstrap would be useful. Dittos the ability to install into an arbitrary target, *without* requiring a valid bootable partition. See RH Bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=150206 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=150946> > QEMU is a pretty amazing little piece of software :-)Innit just? Spread the word, brother ;-) Cheers. -------------------- Notes: 1. ObGaryColeman, showing my age. Wait! I tuned in, but I didn''t watch... -- Karsten M. Self <karsten@xensource.com> XenSource, Inc. 2300 Geng Road #250 +1 650.798.5900 x259 Palo Alto, CA 94303 +1 650.493.1579 fax _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Karsten M. Self wrote:>>>> >>>> dd skip=63 bs=512 if=qemu.img of=xen.img >>>> >>>> Keep in mind, I''ve not tried this myself :-) >>> >>> > Doh! I missed your skip. That should work for a partitioned file > with a single partition. If you''ve got multiple partitions, you''d > want to add the size in blocks as ''count'', otherwise you''re going to > have multiple partitions in what you''re assuming is a single > filesystem image. Somewhere down the road, something''s probably going > to get confused, unhappy, or both, about that. Or you''re just going > to carry around a lot of slack space.It''s pretty straight forward to write a program to split a partitioned file into multiple single partition images. I''m not sure it''s the right use case though.>> Yup. >> >> My xend config line looks like this: >> >> disk = [ ''file:/root/FC4.img,hda,w'' ] >> root = "/dev/hda1" > > >> >> That just works. There shouldn''t be any disadvantage to using this >> method (other than it makes resizing individual partitions a bit more >> difficult). > > > ... that''s on a filesystem image, not a partitioned file, though, right?No. This is a partitioned file. Xen will expose any file as a straight block device under any device number. If you use the device number for a whole disk (in this case, hda--although hdb, sda, etc. would also work), linux will read the partition table during bootup (that is, the first 63 sectors of the disk) and create the appropriate partitions. To reiterate, FC4.img is an unmodified QEMU raw device. Furthermore, with qemu-img convert, you could convert a VMWare image to a QEMU raw image, and boot that directly in Xen using this method.>> There''s a few things you''ll want to do once you do the QEMU install. >> Namely, you''ll want to make sure to install the appropriate modules >> (and run depmod). > > > Which modules?Depends on your domU config I guess. FC4 won''t boot for me unless it finds a modules.dep for the appropriate kernel.>> Otherwise, it just works. >> >> The next logical step is to run QEMU within a domU and automate the >> whole process. > > > Actually, a decent RH bootstrap would be useful. Dittos the ability > to install into an arbitrary target, *without* requiring a valid > bootable partition.With QEMU + VNC under a domU, you can actually install directly into a domU I posted a link to a script to build a ramdisk that contains QEMU/VNC specifically for this purpose.>> >> QEMU is a pretty amazing little piece of software :-) > > > Innit just? Spread the word, brother ;-)We could definitely improve our collaboration with QEMU. There''s a lot of cool things you can do when you combine QEMU and Xen. Regards, Anthony Liguori> > Cheers. > > -------------------- > Notes: > > 1. ObGaryColeman, showing my age. Wait! I tuned in, but I didn''t > watch... >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi all, This looks quite interesting, however I''m confused about the partition table issue. AFAIK the bootloader takes the first 446 bytes of the first sector on the partition, and the partition table is the last 64 bytes of this same sector (a sector being 512 bytes). Your dd command skips the first 63 sectors of the image. How does this produce a workable disk image? Marcus. Anthony Liguori wrote:> Karsten M. Self wrote: > >>>>> >>>>> dd skip=63 bs=512 if=qemu.img of=xen.img >>>>> >>>>> Keep in mind, I''ve not tried this myself :-) >>>> >>>> >>>> >> Doh! I missed your skip. That should work for a partitioned file >> with a single partition. If you''ve got multiple partitions, you''d >> want to add the size in blocks as ''count'', otherwise you''re going to >> have multiple partitions in what you''re assuming is a single >> filesystem image. Somewhere down the road, something''s probably going >> to get confused, unhappy, or both, about that. Or you''re just going >> to carry around a lot of slack space. > > > It''s pretty straight forward to write a program to split a partitioned > file into multiple single partition images. I''m not sure it''s the right > use case though. > >>> Yup. >>> >>> My xend config line looks like this: >>> >>> disk = [ ''file:/root/FC4.img,hda,w'' ] >>> root = "/dev/hda1" >> >> >> >>> >>> That just works. There shouldn''t be any disadvantage to using this >>> method (other than it makes resizing individual partitions a bit more >>> difficult). >> >> >> >> ... that''s on a filesystem image, not a partitioned file, though, right? > > > No. This is a partitioned file. Xen will expose any file as a straight > block device under any device number. If you use the device number for > a whole disk (in this case, hda--although hdb, sda, etc. would also > work), linux will read the partition table during bootup (that is, the > first 63 sectors of the disk) and create the appropriate partitions. > > To reiterate, FC4.img is an unmodified QEMU raw device. Furthermore, > with qemu-img convert, you could convert a VMWare image to a QEMU raw > image, and boot that directly in Xen using this method. > >>> There''s a few things you''ll want to do once you do the QEMU install. >>> Namely, you''ll want to make sure to install the appropriate modules >>> (and run depmod). >> >> >> >> Which modules? > > > Depends on your domU config I guess. FC4 won''t boot for me unless it > finds a modules.dep for the appropriate kernel. > >>> Otherwise, it just works. >>> >>> The next logical step is to run QEMU within a domU and automate the >>> whole process. >> >> >> >> Actually, a decent RH bootstrap would be useful. Dittos the ability >> to install into an arbitrary target, *without* requiring a valid >> bootable partition. > > > With QEMU + VNC under a domU, you can actually install directly into a > domU I posted a link to a script to build a ramdisk that contains > QEMU/VNC specifically for this purpose. > >>> >>> QEMU is a pretty amazing little piece of software :-) >> >> >> >> Innit just? Spread the word, brother ;-) > > > We could definitely improve our collaboration with QEMU. There''s a lot > of cool things you can do when you combine QEMU and Xen. > > Regards, > > Anthony Liguori > >> >> Cheers. >> >> -------------------- >> Notes: >> >> 1. ObGaryColeman, showing my age. Wait! I tuned in, but I didn''t >> watch... >> > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Marcus Brown wrote:>Hi all, > >This looks quite interesting, however I''m confused about the partition >table issue. AFAIK the bootloader takes the first 446 bytes of the first >sector on the partition, and the partition table is the last 64 bytes of >this same sector (a sector being 512 bytes). > >Your dd command skips the first 63 sectors of the image. >How does this produce a workable disk image? > >You''re right. fdisk (and AFAIK, modern partitioning tools) prefer to start partitions on the first cylinder boundary. The assumption here is that each cylinder contains 63 sectors. Regards, Anthony Liguori _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Anthony, Anthony Liguori wrote:> Marcus Brown wrote: > >> Hi all, >> >> This looks quite interesting, however I''m confused about the partition >> table issue. AFAIK the bootloader takes the first 446 bytes of the first >> sector on the partition, and the partition table is the last 64 bytes of >> this same sector (a sector being 512 bytes). >> >> Your dd command skips the first 63 sectors of the image. >> How does this produce a workable disk image? >> >> > You''re right. fdisk (and AFAIK, modern partitioning tools) prefer to > start partitions on the first cylinder boundary. The assumption here is > that each cylinder contains 63 sectors.OK, but why skip this cylinder? If you are creating an image with multiple partitions won''t you need to keep the partition table intact? Marcus. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Marcus Brown wrote:>>You''re right. fdisk (and AFAIK, modern partitioning tools) prefer to >>start partitions on the first cylinder boundary. The assumption here is >>that each cylinder contains 63 sectors. >> >> > >OK, but why skip this cylinder? >If you are creating an image with multiple partitions won''t you need to >keep the partition table intact? > >Ok, let''s back track a little. The dd command I suggested is only useful for extracting the first partition from a partitioned disk image assuming that the first partition occupies all of the remaining disk space and starts on the 63rd sector. It just so happens that if you partition a disk with only a single partition, with most partitioning tools, they''ll always put the first partition on the 63rd sector. I think the reason it chooses that sector is that it is the first sector on the second cylinder and it reserves the rest of the first cylinder for other uses (such as extra space for a boot loader). If you''re just exporting the whole disk, you don''t need to do this command. You would only use this command if you were trying to export a file system image as a partition (as hda1, hda3, etc.). Regards, Anthony Liguori>Marcus. > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Anthony Liguori wrote:> Marcus Brown wrote: > >>> You''re right. fdisk (and AFAIK, modern partitioning tools) prefer to >>> start partitions on the first cylinder boundary. The assumption >>> here is >>> that each cylinder contains 63 sectors. >>> >> >> >> OK, but why skip this cylinder? >> If you are creating an image with multiple partitions won''t you need to >> keep the partition table intact? >> >> > Ok, let''s back track a little. The dd command I suggested is only > useful for extracting the first partition from a partitioned disk > image assuming that the first partition occupies all of the remaining > disk space and starts on the 63rd sector.... *and* the goal is to end up with a filesystem image, *not* a partitioned file image. Eg: what''s extracted is similar to what you''d get with: dd if=/dev/zero bs=1M seek=100 count=0 of=fs_image mke2fs -F fs_image mkdir mp mount -o loop -t ext2 fs_image mp More traditional use of filesystem image files has been for files _without_ partition tables. ...or, to answer your question: if you''re extracting individual filesystems to their own file, you _don''t_ need to keep the partition table intact. -- Karsten M. Self <karsten@xensource.com> XenSource, Inc. 2300 Geng Road #250 +1 650.798.5900 x259 Palo Alto, CA 94303 +1 650.493.1579 fax _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users