These are docs about (yet another completely undocumented part of DTC) creating your own custom xen VM images. Also interesting if you try to modify your OS installs.
Note that I'm just trying to reverse-engineer this to the point where I can keep the stacklet images updated and / or install CentOS via Cobbler.
I also need to run cfengine in the VMs no matter how they were installed.
So we'll be looking at each point where a postinst is possible.
export scripts_to_document="dtc_change_bsd_kernel dtc-xen_domUconf_network_debian
dtc_install_centos dtc-xen_domUconf_network_redhat
dtc_kill_vps_disk dtc-xen_domUconf_standard
dtc_reinstall_os dtc-xen_domU_gen_xen_conf
dtc_reinstall_os.params dtc-xen_finish_install
dtc_setup_vps_disk dtc-xen_migrate
dtc-soap-server dtc-xen-ping-all-ips
dtc_write_xenhvm_conf dtc-xen-volgroup"
First of all, DTC will setup your VM disks which is done in
dtc_setup_vps_disk.
Note: This script is a little buggy.
If parameters in the hosting product setup of DTC are wrong, then you will see the VM parameters shifting, which means you will get a 512MB root volume for your VM called "30000". Can happen i.e. if the hostname for the VM isn't set up correctly, I think. At some later point things will bail out and you might eventually notice.
It would be really cool if the parameters were checked before trying to running OS installs as root on a server.
If you (the reader) can help working on this, please do so and commit patches.
up now: let's make something installable!
Option 1
Stacklet Bundler Images go to
/usr/share/dtc-xen-os/<distro-arch-version>
In there you need to have the following files:
- custom_os
- install_os
- setup_network
- osname.arch-version-stacklettimestamp.tar.gz
custom_os:
this script is used to do local customizations.
by default, it will only copy a custom MOTD to the VM (for rebranding)
To use that option, edit /etc/dtc-xen/motd to your liking.
The MOTD is supported between all domU types that are installed via DTC mechanisms, as opposed to using an ISO image.
setup_network:
well, this script sets up the domU networking:
either it will be sourcing a standard script for the main distros or have something for the OS you're installing.
The following scripts are available for it in a default install:
- dtc-xen_domUconf_network_debian - (Debian, Ubuntu)
- dtc-xen_domUconf_network_redhat = (Centos, RHEL, OEL, Cloudlinux)
At least on debian they resided in /usr/sbin and I think it's the same on RPM-based systems.
install_os:
this has a hardcoded reference to the image file name and the directory where to all the scripts relevant for this OS. These will be used to create a tar command line that can extract the tarball to it's destination.
In practice it just looks like this:
tar --numeric-owner -xzpf ${OSDIR}/${DISTRO_FNAME} -C ${VPS_PATH}
Note numeric-owner ensures everything keep's its UID and -C ensures tar chroots to the VMs temporary mountpoint (which is handled by all scripts courtesy of dtc-xen-parse-param and defined in /etc/dtc-xen/dtc-xen.conf.
a tarball created from the root filesystem inside the stacklet image
(that means, after downloading the image, mount it using
mount -o loop,ro /path/to/stacklet_image /mnt
then compress the contents of /mnt stripping away the path until you have it relative to /mnt.
Verify the tar image using
tar -tvf yourdistroimage.tgz
The files should look like this
-rw-r--r-- root/root 353 2009-03-31 11:01 etc/rc0.d/README
source by all config or installer scripts is:
/usr/share/dtc-xen/dtc-xen-parse-param
this takes all the arguments that had been passed to the SOAP daemon from dtc.
Yes it's undocumented, we'll come to that.
So far I don't yet know what is calling the 3 scripts custom_os/install_os/setup_network
I'll check into stacklet images some more and provide examples for packaging current stuff from stacklet. Obviously you'd have to automate that.
note: it might be worthwhile to write down all steps to import OVM templates, and make the domU install similar to it, too.
update:
I did a test-run with a maverick image from stacklet.
Items I had to modify
- use pygrub
- edit the grub config in the vm to point to "xvda" instead of "sda1". (never use sda1 as in the stacklet images. It can / will cause great pains if you hot-add disks as linux will assign the letter sda to them. fail.)
next:
Option 2 using rpmstrapped or debootstrapped install
- call rpm / deb installer via
- dtc_reinstall_os for Debian (and Ubuntu??) VM
- dtc_install_centos for a centos VM
(somewhere a little naming convention is silently weeping)
- call one more script for post-setup:
dtc-xen_domUconf_standard
also you could:
Option 3 wrap up premade ISOS
This is interesting, because here you can also boot i.e. a premade cobbler iso for HVM guests.
The normal procedure is that either the admin or the VPS owner uploads the iso to the Xen host.
The user will have ssh access to the Xen host using the same account as used for accessing the domU console, and using that account he'll be able to scp an iso to vps host:/home/vpsnum.
It would be vital to apply a ulimit for the users to avoid filling up /home (or /, if it's not a separate FS).
You might want to take away write permissions and upload premade isos instead?
As soon as a ISO is found in the VPS home directory the OS selection dropdown will be expanded to show the ISO image. If the user selects that ISO, DTC will present him with new input fields for setting the DTC console pass.
Not sure yet:
- How to integrate koan for cobbler based installs on PV domUs, which is most interesting because it i.e. allows to use a proper LVM based setup.
- How to integrate with opennebula, that'd mean most of the install is done via oned. Using open nebula will for one sort out the lack of clustering support, the only tweak for this will be to "float" the console access IP adresses.
- How to enable pygrub or the much more mature PVgrub
- How to extend the webif to allow singleuser boot and a rescue image.
- Where to create hooks for error handling!
