www.fridu.net

QuickStart

Most of us are love to try without any learning curve :) Making the assumption that you have acceptable administation skills and root password of your box, starting Fridu-in-Xen architecture should take you from less than one hour to probably almost one day. When in place, creation of a new VM take excatly one minute, this for a basic but fully YaST compliant OpenSuSE-10.2.

Creating VM automaticlly

Two components will be use for this quickstart Fridu-scripts and a minimal OpenSuSE-102 distribution. Within scrips archive lvm-script is mandatory, it is the one that does automatically every step described in chapter "Installing a VM", second one firewall-script is mandatory only if for Fridu security model. Nevertheless and what ever you will chose to implement later, for a real quickstart I recomment you to use a default configuration in order to maximize "cut and paste". When your first automatically created VM will run, then it will be time for you to taillor this to your own distribution and/or network strategy, starting by trying an Ubuntu in a domu virtual machine. On Dom0 I tested Fridu-Script with OpenSuSE-10.2 Fedora-core5 and Ubuntu-6.1/server and I would expect it to work out of the box on almost any distribution.

Action:

• get OpenSuS-102.tgz somewhere on a disk visible from your Dom0
• untar Fridu-scripts archive and type edit ./install.sh to reflect your configuration and install scripts and samples.
• edit /etc/sysconfig/Fridu-lvm.config to reflect your site preferences.

Assuming that you have a basic XEN configuration in place and a free LVM volume group starting Fridu-lvm.script should you take less than 15mn. Then time to create a new VM with a basic OpenSuSE-102 take on my system 180s, this from typing "return" on script create command to the point where my VM anwser to Dom-O ping.

Start xend with Fridu Network Script

Note: Fridu script for VM creation will work with standard XEN brigde script (/etc/xen/scripts/network-bridge) , nevertheless Fridu security model leveraging zones requirer Fridu-Xen-network.script. The main difference in between both model is that Fridu bridge VMs by zone and later route in between zones, when default Xen script bridge your all your VM to your external NIC interface.

Check you have enough free space on your volume group disk.

You MUST have a working LVM environment to use Fridu VM creation sript, default configuration will create two Logical Volumes per VM with respectively root=5G for swap/tmpfs=1G. Note than while automatic creation of VM only work with LVM, zone security model is independent on disk layering and work perfectly with sparse image file.

Create your site config file

While every single parameter of VM creation configuration can be defined/overloaded at command line, it is usually a good practice to provide some adequate site default values, this especially for almost static element as: kernel location, bridge name, ...

Creating your first VM

If you have a correctly customized config file and stick to its default name. Then in order to create a new virtual machine, you only have to provide "name+ip-address". Obviously you may want to customize more things as: network mac adress, root filesystem, size, ... but for a basic test those two parameters should be more than enough. 

When using verbose=1 as in previous example you get a trace of each step the script is going trough. If needed you can restart the process step by step. Bypassing a step is done by using the option "stepname=no" in command line. By default value is "yes" for every steps except if obvisouly you changed this in your config file. 

• Create VM 's root+tmpfs/swap logical volume group                         (lvmcreate=yes)
• Format root LV with a filesystem (default=ext3)                              (fscreate=yes)
• Untar your root distribution root LV                                                 (installroot=yes)
• Custumize root distribution to run dhcp client, and few other things (tuneroot=yes)
• Update your host /etc/hosts and /etc/ethers automatically               (updateether=yes)
• Build and place vm config file in /etc/xen/vm                                    (createvmconf=yes)

Check you newly generated VM config file

At least at for first VM creation you should check generated config file, and see if is compliant with your site requirements. As everything is done automatically, it should be OK, but shiz.. happen !!! and I did not test on enough different configurations to garanty that it will work everyware and/or under every conditions.

You should at least check what my script does not check:

• Selected bidge exists and is the one you want to use for that given VM
• IP adress you gave for VM is siting within selected bridge network mask
• The name you gave was not already present in /etc/hosts in which case your "vmip" param has been overloaded automatically.
• Kernel+Initrd: script check files existence, but not if it is a valid one.
• Disk should be OK, except if you bypassed lvm/filesytem creation step.

Start your VM

If everything looks OK, you're ready to try your newly built VM, this with:

This is typical Linux boot process, and it should run smoothly at least in console mode, if you have trouble it will probably come from your network config, this especially is you have many zones and mess up your config.

Distribution Dependencies

They're should not be any decencies to your preferred distribution and this script should work with any distribution. Worse case "tuneroot" will fail to understand your VM administration tree and you will have log by "xm console' to activate DHCP on the right virtual network interface.

I noted that Ubuntu is not shipped with domUloader.py as result "xm create" command cannot extract kernel directly from the VM at boot time and you have to store a local copy on VM kernel inside dom0, but generally in case of trouble it is easier to boot with a kernel from dom0. You can pre-extract kernel from virtual machine with Fridu-kernel-extract.script and then rebuilt xen config with Fridu-lvm.script.

How to delete a VM

Nothing more simple, stop your VM and remove attached logical volume

How to Transfert a VM to an other host/environement.

Stop your VM, mount in Dom-0 root logical volume and send your backup.tgz to where ever you have to, at destination rerun Freidu-in-Xen create script on your received root backup.tgz.

Hoop !!! it's not working

They are obvisouly many way to mess up. First I do not pretend that my script is perfect, it is build in bash and is very far from checking everthing it could. Secondly you're not perfect either and you may have done something wrong :)

First class of errors will break script at creation time. Potential errors are almost unlimtted and range from "not enough space" to "already used IP address", "distribution not found", ... In this case you typically restart creation script changing one parameter and bypassing previsouly succeded step. Here after few sample of typical errors.

Second class of errors: create command fly, but "xm create $vmname" fails. In almost every cases this is coming from your newly generated VM config file. You need to check "/etc/xen/vm/$vmame" and try to understand what went wrong. You may have an invalide config for example in your disk definition, this is especially classical when you generate a config on an existing distribution bypassing previous installation steps.

Third class or error: Your VM start, you can connect onto it with "xm console" but it does not do what you want. In most cases problems are coming from network, but you nevertheless can connect from "xm console", in rarer situations kernel will fail to boot.

• Cannot find mandatory device. After a relatively long wait, you arrive on a "mini shell". What's happen is that your kernel failed to mount your root and you're sitting in the initrd ramdisk. This is probably coming from in invalid "root" value in one of your boot attributes, but it may also come come from a wrong initrd. A this level you have almost no commands but you still can leverage "/sys" pseudo filesystem to browse around. For example "ls /sys/block" will allow you to check which disk are visible, then make sure that "root=/dev/xxx" inside vmconfig is pointing to the good one.
• Kernel Panic, a little more complex to handle has you do not have any running system.  In most of the case this is coming from a wrong Initrd, a typical example is trying to mount a reiserfs formated logical group with an inirtd that only contains ext3. The best option is to look messages, and eventually to mount from Dom-O your VM LV and look from inside what could be wrong.
• Your VM start, you can connect from the console, but your network is not working. This is for sure the most typical case. The first thing is to check basic network infrastructure environment: is your DNS running ? does it listen on Dom-0 bridge port? is your VM IP within bridge IP range ?, ... If you do not find any obvious error then the best is to use "tcpdump" in conjuction with "dhcpcd-test" and ping. You connect on the console to force a request and you check from Dom-O packets coming from your VM. When this is done you need then to run tcpdump inside the VM to see if packet are passing from Dom-0 to your VM.

Creating of your Firewall and Security zones

Distribution is shipped with tree samples, what ever is your target, I advice you to do is to draw your target network, and to build rule from your graphic.

Let's start with a simple case. We only have one zone, with one external IP and two Xen virtual machines.  Access to virtual machines is done by remapping ssh port from external to internal, and each VM should have a full access to Internet.

• ssh -p 22 root@MyInternetIP (connect dom0)
• ssh -p 23 root@MyInternetIP (connect Xen-One )
• ssh -p 24 root@MyInternetIP (connect Xen-Two)

 We only one one zone, each zone is defined with

• Name (what ever you want until is it unique)
• Network Interface, this is use to allow incomming traffic
• External IP address, that is used to allow incomming traffic and to NAT outgoing one.
• Bridge, which define the entry point for the given zone
• Zone IP address and the network mark that will contain all VM IPs

We have three applications, each of them is defined with

• Name (what ever you want until is it unique)
• Zone name the application site in,as defined previsoully . Note that "none" is a special zone pointing on "Dom0"
• External port/proto Internet user will see. Note that external interface and IP is inherited from zone definition.
• Internal VM target IP and port in case we remap the application.

An avanced sample, this is more or less the one we have for Fridu in production.

• One Network Interface
• Two Internet IP
• One VPN for admin and Internal services.
• Two zones (one per admin), First one support two VMs while second one only hold one.
• VM-Common services(LDAP, backup, IMAP, ...)
• VM-Fulup  (WebMail, Photos, Video Streaming, ...)
  • VM-Domi (Joomla)
  • VMs can see each other within and outside their containing zone.
  • VMs can talk route to any VPN endpoint and vice versa

In this example we have two zones and, while they are both mapped on the same physical network interface (eth0) they are using different external IP adresses.

zFulup is mapped onto  91.121.65.140

• Accept external traffic from port 25 and map it locally onto vm(Common) port 2525
• Accept external traffic from 80 and map it onto vm(Web-Fulup) port 8080
• Accept unlimitted internal traffic

zDomi is mapped onto 87.98.130.56

• Accept external traffic from 80 and map it onto vm(Web-Fulup) port 8080
• Accept external traffic from22 and map it onto 22(ssh)

Dom0 (none zone) accept port 22(ssh) and openvpn(44096+563)

• no special restriction on zone
• VPN(tun0) can talk to any VMs and vice versa.
• VMs can talk inside and outside their own zone. 

Guru sample, even if you do not need it today it is important to make sure that you architecture can scale to support your furtur requirements. Next case has been tested in my lab and while today I have no requirement and no money for such a configuration, and wanted to make sure it was possible.

• Tree zones two mapped on internet with a dedicated NIC, one isolated from Internet.
• Dom0 support SSH and OpenVPN.
• First zone as tree VM and second two.
• First zone handle mail, web and SIP
• Second zone only web.
• A tuning rule prevent second zone from sending mail.
• Custom rules allow unlitted VPN traffic and inter zone communication.

Firewall rules for this sample are defined here after. You may note that the Internet isolated zone does not have any applications defined. This is logical as applications only define autorization for external traffic, we could nevertheless have a special custom rule to prevent outgoing traffic to the external word as well. Check tune rule for zDominig zone that prevent every VM from this zone to send mail, this both externally and internally.