PUBLIC MARKS from camel with tag xen

A virtual machine snapshot is a great feature, freezing the current state of a virtual machine. Unfortunately, open source Xen doesn't offer support for snapshots -- but Linux does. Since open source Xen always uses Linux as its privileged domain, you can use Linux commands to create snapshots.

Some more or less commonly used shell commands for managing Xen Virtual Machines (VM, also called Domains). Tested on Xen 3.0, should work also in other versions.

Xen is a GPLed virtualization solution available in Debian 4.0 Etch repositories. This article help you to create a coherent Xen installation, with backups and minimum security enhancements. This guide fits my vision of a Xen setup. If it does not fit yours, you are free to adapt it to your needs, or to not use it. For information In this guide, i use the term "virtual host". Be aware that Xen use its own terminology. In a Xen setup, instanciated (aka. started) virtual hosts are called "Domains". Once your computer configured for Xen, all the operating systems run in "domains". The original operating system, where the Xen's control tools are installed, is called "dom0" (for domain No zero). All the guest operating systems are said to be installed in a "domU" (for User domain). As i'm a little lazy (well, yeah... very lazy), i don't want to endure this mind twisting, and i will mainly use the "virtual host" term in this guide. So, if you read this guide, don't by angry at me because of the terms i use.

# Performing remote backups of VMs created with xen-create-image tool (xen-tools). # Use rdiff-backup as backend.

In order to be able to do a live migration of a Xen guest from one cluster member to another, some sort of shared storage is required. As the Xen guest won’t run on more than one cluster member at a time, a cluster filesystem is not required. That is, as long as you configure Xen to access the Xen guest by a physical device, not a file.

If you're using LVM based storage for your domains this script will create a snapshot and backup each server to a local drive or a remote system using rdiff-backup.

This guide shows the types of networks Xen can be used on, or to set-up. It uses default configurations of xen, in their most simplest form. Firewalls and security is not discussed here. Feel free to email the author comments at: sburke[at]burkesys.com Xen is used from Debian, and the following setup should be the same for Ubuntu and all other setups of Xen 3.

This has been tested on Xen 2.0.7-1 with Shorewall 3.0.3-1. This Howto presupposes you already have a base Xen install. If not, and you are unfamiliar with Xen, then you probably want to start with the Xen_Debian_Quick_Start. If you do have such a system and you used the default, networking should be running relatively seemlessly. These configurations are only if you want to switch to routed networking (and have a bit more control). There is nothing particularly funky about them, but I haven't had a chance to change it, and that was the first thing that came off of my fingers when I created this page

One of the reasons we use Xen based virtualization is to create a scalable and flexible development and test platform for the Hannibal system stack. Check the Hannibal section of this wiki for more information.

Zentific is a browser-based management interface for clusters of virtual machines running on the open-source Xen® hypervisor. In the spirit of the open-source projects which have made Zentific possible, the application will be released to the community. To ensure that Zentific maintains a high level of reliability, security, and ease of use, we will also be offering a supported version for commercial use.

Out of the box, Zimbra is tuned for a fairly beefy machine. Zimbra will easily consume 1.5GB of ram with default settings. Some of these changes mean turning off a few Zimbra features and there are quite a few ways to do this, so you will need to evaluate memory usage given your own situation. If you simply can't live without *all* the Zimbra features or intend to support a larger (> 15) number of users, my only suggestion is to get more ram ;). But if you are willing to make some compromises, please read on. The changes below are ones that I found to be a reasonable compromise. With a few easy changes, you can bring the memory consumption way down, so that it will hum along just fine on a server with ~512MB of ram. Of course this reduces the amount of users that your server can support, but I've found that for a small installation of around 15 users, these settings will work just fine and give you the same performance as the out-of-the-box config with gobs of RAM. The server I have been testing with has 560MB of ram, and after tuning consumes all the ram and only about 80MB of swap on average. You will find that if you don't make changes similar to the ones suggested below with ~512MB of ram, your Zimbra install will slowly creep up its consumption of swap and your Zimbra install will start to crawl. Also, > 512MB seems to be about the minimum amount of ram to get a useful/zippy server

After my last post on limiting bandwidth usage on a Xen node I thought I would follow up with how to monitor the bandwidth usage of a Xen node. I chose to use netacct-mysql to monitor bandwidth and store the results into a mysql database. This isn't the only way of monitoring the bandwidth but it was easy to set up and stores the information directly into mysql without needing any extra scripts. On the Xen setup I'm using for an example there are 3 nodes and a bucket for each node will be created in the mysql database by netacct. Setting up netacct can be tricky so you will want to check to make sure traffic for each node is going into the correct bucket.