Mail and FTP Users Guide

Using Usermin Webmail

To access the Usermin Webmail system, browse to port 20000 on your domain name, using the HTTPS protocol.

For example:

https://www.domain.tld:20000

Login using your mailbox username and password.

Navigating Usermin

Usermin provides a left-hand menu, and a right-hand content pane.

In the left-hand menu, there is a Mail tab and a Usermin tools tab. The Mail tab includes a list of available mail folders, a search box, and links for folder management, address book, mail preferences, change passwords, system information, and switch user.

The right pane displays either the active folder, mail message, or Usermin tool that has been selected in the left-hand menu.

Virtualmin Resellers Guide

A guide for Virtualmin Reseller account holders. Documents domain creation, editing, maintenance, and script installation.

Introduction

Virtualmin, combined with Webmin and Usermin, provides a complete virtual hosting administration system, allowing for four tiers of operation, "administrator", "reseller", "domain owner", "mail user". This guide is for the second, or reseller, tier of the system. The reseller account type has the ability to create, update and delete domains, manage email addresses within the domains under her control, and optionally install scripts and monitor bandwidth and disk usage. This guide covers only Virtualmin's extensive virtual hosting features that are available to Reseller account holders.

Navigating Virtualmin

Any web browser can be used with Virtualmin, though some themes use advanced browser features that work better in browsers with good CSS support (Firefox, Safari, Opera and Konqueror all fit this description, while Internet Explorer currently does not). It is even possible to use a text-mode browser like lynx or links to use Virtualmin.

To login to Webmin (because Virtualmin is part of Webmin, one logs into Webmin and browses to the Virtualmin module), browse to the address of your server using the HTTPS protocol on port 10000. For example, if your Virtualmin server was running on hostname hosting1.virtualmin.com, you would enter https://hosting1.virtualmin.com:10000 in the URL field of your browser.

Your administrator will provide you a username and password to use for logging in.

Online Help

Within most Webmin modules, there will be a help link in the upper left corner of the page. Clicking it will open a help window with documentation about the specific page you are on. Most options in Webmin can be clicked on to get a popup help window describing that specific option. The Virtualmin module has extensive online help in addition to this manual, so if any option or feature confuses you, you don't have to find the appropriate section in this guide. Clicking on it will popup the help window with help specific to the item you clicked.

Logging Out

At the bottom of the left-hand menu, you'll find a Logout link. Clicking this link will, obviously, log you out of Webmin.

Creating Your First Domain

To create a new virtual server, click the Create Server* menu heading in the left menu bar, and then click the *Create Virtual Server item.

A new page full of options will be displayed in the right content window. We'll assume that most default settings are appropriate for our domain for the sake of simplicity in this example, but later on we'll dive into the depths of custom Server Templates, skeleton directories and customization of the default settings for new domains. After a fresh install, Virtualmin has pretty reasonable defaults for the vast majority of environments, though, so we can create a domain easily and expect it to be useful right away.

image:images/first-domain.png["Screenshot of Virtualmin Create Domain page"]

In the above, I have filled in everything that is needed to create a domain with most features enabled. I only specified a few options: Domain name, Description, Contact email address, and Administration password. The rest I've left at their default values. If you aren't sure what a particular option means, click on the name of the option, and a help window will pop up to describe the option. Every option in Virtualmin has a popup help link, and most pages have a general overview help link in the upper left corner of the page.

Domain Name

You must always provide a domain name for a virtual server account (there are ways to create websites for users without domains using Virtualmin, but that is a much simpler problem and isn't the focus of Virtualmin).

Description

The description is simply a short description of the domain. It is free text, and does not impact any aspect of the virtual server, so it can be just about anything. It will appear as the "Real Name" of the domain user in the Users and Groups module.

Contact email address

Here, you select what email address should receive notifications about this domain, including the creation email that lists the available services, provides login instructions, etc. If you choose to generate the password later on, this may be the only way for the user to find out the password, so it may be appropriate to choose Other address.. and enter the users preferred address in the field provided.

Administration password

You can choose to have a password generated randomly, which is a good idea from a security standpoint. Virtualmin will generate a reasonably long (8+ characters) random password, which will be sent to the user via email. They can, of course, immediately change the password when they login.

Other options

All of the other options can generally be left alone. We'll discuss many of them in more detail later on, but for now, let's just assume that the defaults are perfect.

When you click the Create Server button, Virtualmin will spin into action...it will create the new user and group, add Apache virtual host configuration, add a zone and domain to BIND, add virtual domain configuration to Postfix, create new databases and users in MySQL and PostgreSQL, configure SpamAssassin and ClamAV for the domain, configure log rotation and Webalizer log reports, (woo! I'm getting tired just talking about it...that Virtualmin works hard so you don't have to) and configures any optional Virtualmin Plugin features, like Mailman mailing lists or SubVersion revision control repositories.

Now you can return to the Virtualmin main page and you'll see your new domain in the list of available domains. Clicking on the domain allows you to edit all of the options we just configured, so you can always return to the domain to alter the settings (be careful with that feature, however, as turning off a feature may delete user data...Virtualmin will warn you before destructive changes).

The domain owner can also login using the new domain account and the password you assigned (or that was randomly generated).

Bandwidth Monitoring

Bandwidth monitoring is a standard feature of Virtualmin, allowing the administrator to limit bandwidth usage or simply notify users and administrators when a domain is approaching and has surpassed their allotted network bandwidth.

To find out bandwidth usage of your domains, click the Bandwidth Usage link in the left-hand menu (if unavailable, bandwidth monitoring has not been enabled for your account).

Install Scripts

Virtualmin Professional provides the ability for domain owners, resellers, and administrators to easily install dozens of PHP and Perl scripts within a Virtualmin domain. It also allows for one or more scripts to be installed automatically on server creation, based on the selec ted Server Template for the new domain. New Script Installer scripts can also easily be writ ten using the Install Scripts to add support for internally developed applications.

To install a new script select the domain you'd like to install for in the dropdown menu at the top of the left-hand menu, and then click Install Scripts. Then, click the radio button next to the script you'd like to install, and optionally select a version (often both a stab le and development version are provided). Finally, scroll to the bottom of the page and clic k the Show Install Options button.

On this page, you'll be able to select the database to use from existing databases, optionally create a new database, and choose the name of the subdirectory to install the script under. Clicking Install Now will then install the script and setup the database with the appropr iate items. Some scripts don't need a database, and so the database-related option will be unavailable.

Virtualmin Virtual Server Owners Guide

Introduction

Virtualmin allows you, the domain virtual server account holder, to manage your website files, mailboxes, databases, DNS entries, and install scripts.

Getting Started

Logging in to Virtualmin

Virtualmin is the administrative interface, or control panel, you will use for most of the administrative functions you'd like to accomplish. You can open your account using any browser (modern browsers like Firefox, Safari, and Opera are recommended), by browsing to port 10000 on the server address using the HTTPS protocol.

For example, if your domain were virtualmin.com, you could access it at the URL: https://virtualmin.com:10000

Enter your username and password, as provided by your system administrator.

Navigating Virtualmin

When you login to Virtualmin, you'll see a left-hand menu bar and a right-hand content page, as shown in the diagram below:

image:/images/first-look.png

The left menu contains all of the options available for your domain. Some shown here might not be available in your menu, it depends on the options available for your domain.

The right content page opens with a summary of your virtual server data, such as number of domains, disk usage, mailboxes etc.

Uploading Files

There are several ways to upload content to your Virtualmin account. You can use any of them or all of them, based on your needs and skills.

SSH, SCP and FTP over SSH

The preferred method for sending many files, directories of files, or very large files, is the SSH protocol. SSH is a fast and secure protocol, that allows you to safely login, upload and download files, and manage existing files. SCP is the name for file transfer commands that work using the SSH protocol. Likewise, FTP over SSH (sometimes also called FISH, or SFTP) is a mechanism for providing FTP-like service over a secure link.

There are many graphical and textmode clients for the SSH protocol available for free and commercially.

We'll cover where to find SSH-capable clients for your Operating System, and we'll provide a few examples of using them to manage the files in your Virtualmin account.

Windows SCP Clients

pscp

The best free command line SCP client is called pscp.exe and it can be found at:

http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

It is related to PuTTY, which is a very nice free SSH client.

After you've placed the pscp.exe file into your system path, using it is quite simple. In a DOS shell, simply enter a command like the following:

C:\> pscp.exe myfile.htm user@domain.tld:/home/user/public_html

Then, enter your password at the prompt, and hit enter. This will copy the file "myfile.htm", located in the current directory, to the /home/user/public_html folder on the Virtualmin server.

Windows graphical FTP clients

Filezilla

A free graphical FTP client that supports FTP over SSH is Filezilla. http://filezilla.sourceforge.net/|Filezilla Home Page.

To Configure Filezilla:

1. Download and Install Filezilla
2. Run Filezilla
3. File -> Site Manager ->
4. Click "New Site" -> Give it a name such as "example"
5. In the top right "Host" box fill in "example.com"
6. In the "Servertype" box choose "SFTP using SSH2"
7. "Logontype" choose "Normal"
8. Fill in the "User" and "Password" boxes with the virtual server owner username and password respectively.
9. In Virtualmin -> Webmin -> Servers -> SSH Server
10. Access Control -> Only allow users -> add the above virtual server username
11. Click "Save" -> Click "Apply Changes"

Your admin user will be able to use a graphical FTP style program or Dreamweaver to upload their pages now.

WinSCP

Another good free graphical FTP over SSH option is WinSCP:

http://winscp.net/eng/index.php|WinSCP Home Page

After installation, simply start it up. It will ask for your login information. Enter the details as provided by your system administrator for hostname, username, and password. Then click Login.

Now you'll see a window displaying the files in your Virtualmin account home directory. You can copy files into your public_html directory to make them accessible via the webserver, or into the cgi-bin directory, if the files are executable CGI scripts.

Mac OS X SCP Clients

scp

Mac OS X includes the free OpenSSH SCP client, called simply scp. Usage is just like Linux and UNIX scp clients. Open a Terminal and execute a command like the following:

$ scp myfile.htm user@domain.tld:/home/usr/public_html

After this hit enter, and then enter your password.

Cyberduck

Cyberduck is a popular Mac-native Open Source graphical FTP client that supports SCP, SFTP, FTP over SSL, WebDAV/SSL, and Amazon S3 secure connections.

It also integrates very cleanly with most favorite external OSX text editors, like SubEthaEdit, BBEdit, TextWrangler, Text-Edit Plus, TextMate, mi, Smultron, JeditX, CSSEdit, CotEditor and Tag, skEdit, and PageSpinner.

Download it for free from here:

[http://cyberduck.ch_ Cyberduck Home Page]

Linux SCP Clients

scp

Like Mac OS X, all Linux distributions include a complete SSH implementation, including the scp command. Run the following to copy a file named "myfile.htm" to the domain.tld server using the username "user":

$ scp myfile.htm user@domain.tld:/home/usr/public_html

After this hit enter, and then enter your password.

gftp

gftp is a popular Gnome-based graphical FTP client that also supports scp and FTP over SSH protocol connections.

Download it for free from here:

[http://gftp.seul.org/ gftp Home Page]

Or, preferably, simply install the package provided by your OS vendor. gftp is very popular and is available from the majority of Linux distributions, so you don't need to build it yourself.

WebDAV

FTP

Your FTP client should be configured to connect to yourdomain.tld, or, if DNS has not yet propagated, you could use the IP address or temporary hostname given to you by your administrator (which will be of the form youdomain.hostdomain.tld). You will use the domain account name and password given to you by your system administrator. Note that, by default, only the domain account has FTP access to the website data for your account, and additional users are only email users.

Webmin File Manager Applet

Cloudmin Paid AMI

• Cloudmin Paid AMI on EC2
  • Introduction to Paid AMIs
  • Pricing
  • Using the paid AMI
  • Using Cloudmin on EC2

Cloudmin Paid AMI on EC2

Introduction to Paid AMIs

Pricing

Using the paid AMI

Using Cloudmin on EC2

Virtualmin GPL AMI

• Virtualmin GPL AMI on EC2
• Virtualmin EC2 Image in Europe
• Virtualmin GPL Debian Etch Image

AMI Summary

Virtualmin GPL AMI on EC2

Virtualmin EC2 Image in Europe

export EC2_URL=https://eu-west-1.ec2.amazonaws.com

Virtualmin GPL Debian Squeeze Image

ec2-run-instances ami-6735f30e -k vgpl-keypair

Amazon Linux Image

ec2-run-instances ami-c5cd70ac -k vgpl-keypair

Virtualmin Professional Paid AMI

• Virtualmin Pro Paid AMI on EC2
  • Introduction to Paid AMIs
  • Pricing
  • Using the paid AMI
  • Using Virtualmin Pro on EC2

Virtualmin Pro Paid AMI on EC2

Introduction to Paid AMIs

Pricing

Using the paid AMI

Account Plans

Introduction to Plans

In Cloudmin, an account plan is a set of restrictions that can be applied to a system owner. Plans can limit the following :

• Number of systems the owner can create
• Total RAM assigned to virtual systems
• Total disk space assigned
• Total CPU assigned
• Number of IP addresses assigned to virtual systems
• Disk space used for backups created by the system owner
• Combined bandwidth for virtual systems
• Allowed actions, such as shutting down, creating systems and managing virtual disks
• Allowed host systems
• System images the owner can use

All limits apply to the total usage of all systems owned by the user the plan is applied to.

Creating and Managing Plans

Cloudmin comes with one default plan that is created when installed. To add your own plans, do the following :

1. Open the Cloudmin Settings category on the left menu, and click on Account Plans.
2. Click on Add a new account plan , and fill in the Plan name field.
3. Enter any other limits you want, such as on disk space or RAM.
4. If needed, take away some actions in the Plan restrictions section. Those selected by default are generally safe and reasonable.
5. In the Host system restrictions section, choose hosts that owners on this plan should be able to use for new systems. You can also select the method via which a host is chosen.
6. To prevent use of some images (such as those containing commerical software), limit the selection in the System images section.
7. Click the Create button.

To edit a plan after it is created, go to the Account Plans page and click on its name. Any changes in limits or restrictions will be immediately applied to system owners on the plan.

To delete a plan, check the box next to its name in the Account Plans list, then hit the Delete Selected Plans button.

Applying Plans to Owners

Once a plan has been created, you can apply it to an owner as follows :

1. Go to Cloudmin Settings -> System Owners, and click on an owner.
2. Under Limits and restrictions, select your new plan.
3. Make sure that other settings are set to From plan, so that the owner's individual limits will not be used.
4. Click the Save button.

Adding an EC2 Account

EC2 is different from other virtualization systems supported by Cloudmin, as it is a hosted service run by Amazon on their machines. They charge by the hour of machine time, and also for storage of any machine images that you create and host on their S3 service.

Cloudmin can manage virtual systems running under EC2 in almost exactly the same way as it does for other virtualized systems. The biggest difference is that they cannot be shut down without losing the contents of the system, which makes them a little risky for web hosting, as Amazon gives no guarantees of the stability of EC2 instances. Fortunately, Virtualmin makes it easy to backup hosted domains to Amazon's S3 service, which is fast and cheap when accessed from EC2 instances.

Auto-Scaling Groups

Introduction

Auto-scaling groups are Cloudmin's way of scaling up the number of systems that provide some service in response to load. They are typically used when you have multiple virtual systems with identical configurations providing the same service, such as a website, mail server or database replicas. When CPU load or some other metric exceeds a configurable threshold on some or all systems, additional systems are created to handle the load. Conversely, a group can be reduced in size when a second set of thresholds is reached.

Creating an Auto-Scaling Group

Before creating a scaling group, you should create a virtual system that will be used as a template for the additional system that the group will create. For example, if the objective is to host a high-traffic website with variable load, this template system should have the appropriate front-end webserver and content installed and configured, so that when Cloudmin clones it the new system can accept traffic for the website immediately. This template system should be shut down, so that it can be more quickly cloned as needed.

To create a group, the steps to follow are :

1. Create a template system as described above, with the appropriate RAM, CPU and disk limits.
2. Go to System Monitoring -> Auto-scaling Groups on the Cloudmin left menu.
3. In the menu at the bottom of the page, select the virtualization type for the systems in the group, and click the Add Auto-scaling Group For button.
4. On the creation form, enter a name for your new group in the Scaling group description field.
5. Fill in the maximum and minimum allowed systems in the group - the max should be set to prevent all your host system resources from being consumed.
6. To limit the rate at which systems are added or removed from the group, adjust the Interval between system changes field. This only applies to background evaluations.
7. If you want Cloudmin to start evaluating and possibly increasing the group right away, set the Auto-scaling enabled? field to Yes.
8. Fill in the Hostname template field with a template that will be used for new system's names. The code ${num} in the template will be replaced with a unique system number, starting from zero.
9. Select your template system from the Source system to clone menu.
10. If desired, select allowed host systems for new virtual systems in the group in the Host systems to create on section.
11. In the Conditions for scaling up section, enter one or more rules that will trigger the automatic addition of a virtual system to the group. For example, you might select CPU load over 0.9 for 10 minutes. More than one rule can be entered, and you can choose if any or all rules need to apply.
12. Optionally also add rules to the Conditions for scaling down section. Make sure that these are the inverse of the up-scaling rules or lower - otherwise Cloudmin may enter a loop in which it rapidly creates and then destroys systems. For example, you could select CPU load under 0.2 for 30 minutes.
13. In the Email notification settings section, enter the addresses you want notified when the group changes, and the conditions for sending email.
14. Click the Create button.
15. On the list of scaling groups, select your new group and click the Scale Up Groups button to add a first system and test that creation is working. All groups should have at least one member system for their rules to operate on.

Managing Groups

Once a group has been created, you can edit its settings by clicking on the hostname template on the Auto-Scaling Groups page. You can also select one or more groups and force immediate evaluation of their rules with the Update Systems In Groups button, or add or remove a system with the Scale Up and Scale Down buttons respectively.

To see the status of systems within a group, click on it and open the Current status section. This will show for each member system whether it is exceeding the scale up or down conditions. If the conditions are being met currently but have not been active for long enough to trigger a scaling rule, the period for which they have been active will be displayed.

Groups can also be increased or decreased via the Cloudmin API with the increase-scalegroup and decrease-scalegroup API commands. Both take a host parameter which must contain the group's hostname template. Scaling via the API can be used instead of automatic scaling based on rules, driven by code in your own application that detects when additional systems are needed.

Scaling Groups on EC2

EC2 is an excellent service for use with auto-scaling groups, as it has enormous capacity and only charges for use by the hour. Cloudmin supports the use of auto-scaling on EC2 as well, but with some minor differences :

• Systems added to the group are created from an AMI, rather than by cloning a source system. An AMI can be created from an existing EC2 instance using the System Operations -> Create EC2 Image page in Cloudmin.
• When creating a group, you must select an EC2 account, AMI and SSH key for new systems, just as you would when creating a new EC2 instance.
• The hostname generated from the template in the scaling group will be set as the Unix hostname for new EC2 instances.

Scaling Groups and DNS Roundrobins

Auto-scaling groups are most useful when combined with DNS roundrobins, which automatically update a DNS record to point to multiple systems based on their status. For instructions on creating one, see the Roundrobin DNS Records page. During creation, you can use the Systems in scaling groups option to choose one or more groups' systems' IP addresses to include in the DNS record.

Each time a system is added to or deleted from an auto-scaling group, any associated DNS records will be immediately updated.

Automatic Failovers

Automatic Host Failovers in Cloudmin

Cloudmin's automatic failover feature provides protection against host system failures, by moving virtual systems off a down host to a new host with shared storage. The running state (memory contents and network connections) of virtual systems will be lost in this case, but they will be re-started on the new host with minimal interruption.

For failovers to work, your host systems must share the storage location for virtual system disk images or filesystems. This can be done via NFS, Cluster LVM, iSCSI, or other network filesystem technologies. Cloudmin's failover feature does not yet include automatic replication of disk images between host systems, and cannot setup shared storage for you.

Currently automatic failovers are supported only for Xen, OpenVZ and KVM virtual systems.

Failover Groups

A failover group is a collection of host systems that support some virtualization type, and share storage used for virtual systems. Some or all systems running on those hosts will be failed over to another host in the group if one goes down, assuming that there is enough free RAM available. Groups can contain an explicit list of hosts, members of some location group, or hosts in a Cloudmin system group.

The steps to create a new failover group are :

1. Login to Cloudmin as root, and go to Host Systems -> Host Failover Groups
2. Click the Add a new failover group link
3. Select a virtualization type from the Virtual system type menu.
4. Enter a name for the group in the Group description field.
5. If you want Cloudmin to automatically perform failovers, set the Failover group enabled? to automatic mode. Otherwise you can select manual mode to trigger failovers manually when you detect a host system has gone down.
6. In the Host systems in failover group section, select the hosts that will be part of this group.
7. To limit automatic failovers to only certain virtual systems, select them in the Virtual systems to failover section. You might want to do this for only important systems, or those on shared storage.
8. Click the Create button.

Once a group has been created, it can be edited or deleted at any time by clicking on its description on the *Host Failover Groups * page.

Failover Notification

When automatic failovers are enabled, they will be triggered by Cloudmin's regular status collection process. When it detects that a virtual system's host is down, it will wait for the Host downtime timeout set on the failover group page, and then attempt to move the virtual system to a new host.

Upon success or failure, email will be sent to the master administrator and possibly the owner(s) of a virtual system. If the virtual system was running before its old host failure, it will be re-started on the new host after the failover completes.

The move can fail for several reasons :

• No hosts in the failover group share the storage for this virtual system.
• No hosts have enough free RAM
• All other hosts in the group are down
• Any error occurred copying configuration files to the new host

Triggering a Manual Failover

If you have set a failover group to manual mode, Cloudmin will not automatically move virtual systems off down hosts in the group. However, you can force a failover at System Operations -> Force Failover. On this page you can optionally select a specific new host system, and decide if the virtual system should be started up on the new host or not.

A manual failover can also be done using the failover-system API command.

Backup and Restore

Introduction to Cloudmin Backups

Cloudmin allows the master administrator and system owners to create backups of virtual systems running under Xen, OpenVZ, Vservers or Solaris Zones. This provides protection against accidental deletion of files within the filesystem, for example by an accidental rm * command.

Backups can be either run manually or on a regular schedule, such as once per day. When a backup is taken the virtual system can be either shut down to ensure a consistent filesystem state, or left running to avoid downtime.

What is and is not Backed Up

As of Cloudmin 6.2, backups include all details of selected systems - this allows deleted systems to be re-created as part of the restore process. In older versions backups only include the contents of the virtual system's filesystem or disk images. For Xen systems the backup contains a compressed copy of all virtual disks, while for other virtualization types it is just a TAR file of the filesystem.

When backing up a running Xen system using LVM logical volumes to store disk images, LVM snapshots are used to take an instantaneous copy of the filesystem while it is copied. Each will consume 10% of the space in the volume group as the underlying disk images, so make sure you leave some LVM space free.

A multi-disk Xen or KVM system will have each disk stored in a separate file. Disks used for virtual memory or swap space will not be backed up, as the restore process always effectively reboots the system, meaning that memory contents do not need to be saved.

Backup Destinations

Cloudmin can backup virtual systems to a variety of different destinations - via SCP, FTP or to any system it manages. In a typical Cloudmin setup a single system with plenty of disk space is chosen as backup destination, perhaps the master system itself. Backups are taken on the host systems and then transferred to this backup machine. Alternately, you can choose to store backups on the hosts themselves, to avoid the need to transfer large backup files over the network.

Each host system defines a default backup destination for its virtual systems. You can set this as follows :

• Login to Cloudmin, open the Host Systems category and click on the link for your virtualization type, such as Xen Host Systems.
• Click on the first of your hosts, and open the Default backup destination section.
• Select a destination type and fill in the fields next to it - for example, in you have a dedicated backup system you could select Directory on system, choose it from the menu, and enter a path like /backup.
• Click the Save button, then repeat the same steps for other host systems.

When a backup is made it will be saved to the specified directory in a file whose name is that of the virtual system with .tar.gz appended. Each subsequent backup of the same system to the same destination will overwrite that file.

Creating a Scheduled Backup

Once a default destination has been set, you can schedule a backup like so :

• Open the Backup and Restore category on the left menu and click on System Backups.
• Click the Add a new system backup link.
• From the Systems to backup list select the virtual systems you want to include.
• To have them shut down during the backup process, change Shut down systems? to Yes.
• In the Backup destination, you can typically leave Default destination for host system selected unless you want the backup to be sent to an FTP or SSH server outside of Cloudmin's control.
• Change Scheduled backup enabled? to Yes, and select a schedule in the When to backup field.
• To be notified on backup failures, enter your address in the Email results to field.
• Click the Create button.

It is possible to leave Scheduled backup enabled? set to No if you just want to define a backup that will always be run manually.

After a backup has been defined, you can edit or remove it by clicking on its entry in the System Backups list.

Running a Backup Manually

To kick off a backup, just click on it in the System Backups list and then hit the Backup Now button. Progress messages will be displayed as it runs, and a final summary of systems completed and backup sizes when it finishes. Depending on the sizes of the systems being backed up, it may take minutes or hours.

Testing a scheduled backup after creating it is strongly recommended. Also, you should create, backup and restore a test system that uses the same configuration and destination as your production systems to ensure that all steps in the process are working properly.

Backup Logs and Restoring Backups

Cloudmin logs all backups it performs, including their final status, systems included, disk used and possibly the complete progress report. To view logs, go to Backup and Restore -> Backup Logs, and enter a hostname or destination path into the Find backup logs box, then click Search.

The simplest way to restore a backup is to click on its destination in the search results, which will open a restore form. You can also restore some or all systems from a scheduled backup as follows :

• Go to Backup and Restore -> System Backups, and click on a backup.
• Click the Restore button.
• Select the systems to restore - typically you only want one, instead of everything that was included.
• Click Restore Now.

If the system no longer exists, the restore process will re-create it from details stored alongside the backup file. It will be re-created on the original host system with the same disk sizes, resource limits and ownership, if possible.

Bridged Networking Setup

Introduction To Bridged Networking

Normally Xen and KVM virtual systems are configured so that they appear to be directly connected to the same LAN as the host system, and so can talk to the network without having their packets routed through the host. A bridge is typically created (xenbr0 for Xen or br0 for KVM), but this operates at the Ethernet level by connecting the host's real interface eth0 with peth or tap interfaces used by virtual machines.

However, some colocation providers don't allow additional virtual systems to be directly connected to the same LAN as their hosts - Hetzner for example is one commonly used by Cloudmin customers that have this restrictions. Also, a direct connection limits the firewalling you can do to restrict or protect virtual systems. And it requires that each virtual system have an IP address that is valid on the same LAN as the host system, which is typically a real Internet IP address.

Address Ranges for Bridged Networking

The first step to setup a network bridge is to work out the IP range that will be used by your virtual systems. Typically this is assigned by your hosting company, and includes a starting IP, ending IP and netmask. However, it is also possible to use an RFC 1918 address range like 192.168.1.1 to 192.168.1.255. In this case, you will also need to setup NAT so that your virtual systems can access the Internet.

Setting Up Bridged Networking

This page uses the term "bridged networking" to describe a setup in which virtual systems are connected to an additional bridge on the host, normally named br1. It is most commonly used with KVM, but the same principals apply to open-source Xen as well.

Bridge setup is best done before any virtual systems are created. It must be repeated on each host system, after Webmin, Cloudmin or Virtualmin is installed.

If your system runs the latest Webmin, the steps to setup a bridge are :

1. Login to Webmin on the host system, and go to Networking -> Network Configuration -> Network Interfaces.
2. Click on the Add a new bridge link. The number for a new bridge should be filled in auto
3. Select Static configuration, and fill in the IPv4 address and Netmask fields. The address should be the first IP in the range you plan to use for this bridge.
4. Select None in the Connect bridge to interface field.
5. Click the Create and Apply button.

Otherwise you can setup a bridge on Debian or Ubuntu Linux as follows :

1. Edit the /etc/network/interfaces and add a section like :

   iface br1 inet static
           address 192.168.1.1
           netmask 255.255.255.0
           broadcast 192.168.1.255
           network 192.168.1.0
           pre-up brctl addbr br1

2. Run the command ifup br1

Or on Redhat, Fedora or CentOS Linux :

1. Create the file /etc/sysconfig/network-scripts/ifcfg-br1 containing :

   BOOTPROTO=none
   MACADDR=""
   IPV6INIT=yes
   TYPE=Bridge
   DEVICE=br1
   NETMASK=255.255.255.0
   MTU=""
   BROADCAST=192.168.1.255
   IPADDR=192.168.1.1
   NETWORK=192.168.1.0
   ONBOOT=yes

2. Run the command ifup br1

Enabling Routing

Once the bridge has been created, you will need to make sure that your system is configured to route traffic between it and the LAN. This can be done in Webmin on the host as follows :

1. Go to Networking -> Network Configuration -> Routing and Gateways.
2. Change the Act as router? option to Yes, and click Save.
3. Click the Apply Configuration button.

If your Cloudmin master system is different from the host on which the bridge has been created, you may also need to add a static route for the bridge network with the host system as the gateway.

Enabling NAT

If your IP range is for internal use only, you should enable NAT so that virtual systems can access the Internet. Note that this will allow only outgoing connections, unless you also setup one to one destination NAT.

The steps to setup network address translation are :

1. Login to Webmin on the host system, and go to Networking -> Network Configuration.
2. If your firewall has not been setup, you will be promoted for an initial configuration. Choose NAT, with eth0 being the external interface.
3. Otherwise, select the Network address translation table and add a rule in the POSTROUTING chain with the action set to Masquerade and the Outgoing interface set to eth0.
4. Click the Apply Configuration button.

Using Bridged Networking in Cloudmin

Once a network bridge has been created, you can configure Cloudmin to use it on the host as follows :

1. Login to the Cloudmin master and go to Host Systems -> KVM Host Systems and click on the host machine. If the host has not been registered yet, follow the documentation on the Setting Up KVM Virtualization page.
2. In the IP address allocation ranges section, enter or select the IP range for your bridged network. In the Bridge column, select br1.
3. Enter the IP address of the host system that was assigned to br1 as the default gateway.
4. In the Bridges on host system for KVM interfaces field, select br1
5. Click the Save button.

Cloning Systems

Introduction to Cloning

A clone is a copy of a virtual system that has the same disk contents, accounts, root password and number of network interfaces as the original. However, it is assigned a new hostname, IP address(es) and description.

Creating a clone is easier than imaging a system and then creating a new system from it, as it is done in a single operation. Cloning is also available to system owners, subject to limits on disk, RAM and CPU use, and assuming that the owner is allowed to create new systems at all.

Virtual systems using Xen, KVM, OpenVZ, Vservers, LXC and Citrix Xen can be cloned in Cloudmin versions 4.5 and later. The process is the same regardless of the virtual system type. On Cloudmin 5.5 and later, a clone can be created on a different host system to the original system's host.

Cloning a System

The steps to follow to clone an existing system are :

1. Select it from the left menu, then go to System Operations -> Clone System
2. Enter a new system name into the New hostname prefix field. This typically only has to be a prefix, as the domain will be automatically appended.
3. Enter a description for the new system.
4. By default, Cloudmin will allocate new IP addresses for the clone in the same way that it does allocation for any new system. However, you can alternatively select Entered below in the IP addresses for clone and enter an address for each interface on the new system.
5. If you have multiple host systems for the virtualization type of the chosen system, you can select another host from the New host system for clone menu for the clone to be created on.
6. Click the Create Clone button, and wait for the process to complete.

Cloning is generally faster than creating a new system, as there are fewer steps involved. However, if the system being cloned has large disks, it will take proportionally longer.

Cloning will be disallowed if the host system does not have enough free RAM or disk space, or if your usage is too close to the limits set in your plan.

Cloudmin Cloud Computing Control Panel

Cloud Computing Everywhere

Cloudmin is a new cloud computing platform from the developers of Webmin, Virtualmin, and Usermin. Cloudmin enables hosting providers to offer new kinds of services, and enterprise data centers to evolve into private clouds, all from existing infrastructure.

The four best ways to manage your cloud

Cloudmin offers four methods for managing your cloud infrastructure: Web, mobile device, command line, and remote API. Cloudmin is always available, no matter where you are or how you want to work. Integrate with Virtualmin, Webmin, and Usermin for management of your whole data center, from servers to users and applications.

Enterprise

Build a private cloud, integrate with the public cloud, and manage your heterogeneous network. Cloudmin helps you build your cloud and maximize your existing infrastructure while taking advantage of Amazon Web Services when needed, Virtualmin enables web application hosting and user management, Webmin brings it all together.

Hosting Provider

Offer compelling cloud services to your customers with Cloudmin, provide an integrated control panel with Virtualmin, and maximize your infrastructure ROI. Become a reseller to provide privately branded Virtualmin products and be the single point of contact for your customers, while increasing your per-customer revenue.

Hybrid Clouds

Cloudmin enables heterogeneous hybrid clouds, using both private and public infrastructure. Cloudmin supports private virtualized system management via Linux Xen, Solaris Zones, OpenVZ, and vservers, as well as management of public cloud resources via Amazon EC2 instances, all from the same UI.

Cloudmin Introductory Offer!

Cloudmin is our new cloud computing control panel. Cloudmin provides a unified UI for building cloud services based on Linux Xen, Solaris Zones, Linux vservers, OpenVZ, and Amazon AWS. Cloudmin also supports physical servers, allowing you to gradually migrate your websites into the cloud. Cloudmin, like Webmin and Virtualmin, is designed with flexibility in mind.

Build your own cloud, integrate with existing clouds, and migrate existing servers into the cloud on your schedule, and do it with industry standard technology like Xen and Zones. With a comprehensive web-based UI and scriptable API, you can build the cloud services you want to use, while leveraging existing cloud services, like those provided Amazon Web Services, when needed.

We're extremely excited, and we want everyone to try it, so we're offering all of our Cloudmin products for 50% off. As with Virtualmin, we also offer a 45 day money back guarantee on Cloudmin, so there's no risk and you'll get the lowest price that we will ever offer.

Cloudmin GPL

Introduction to Cloudmin GPL

The GPL version of Cloudmin is a designed to manage Xen or KVM instances on only a single host system, rather than supporting multiple hosts and virtualization types as in the full (Pro) version. It lets users try out Cloudmin and virtualization concepts without having to purchase the full package.

Installing Cloudmin GPL for Xen

Cloudmin's installer can be used on CentOS, Redhat Enterprise, Debian and Ubuntu systems. It will both install Cloudmin and setup the system as a Xen host, by installing a Xen-capable kernel and associated tools.

You can download the install script for CentOS and Redhat from : http://cloudmin.virtualmin.com/gpl/scripts/cloudmin-gpl-redhat-install.sh

The install script for Debian and Ubuntu can be downloaded from : http://cloudmin.virtualmin.com/gpl/scripts/cloudmin-gpl-debian-install.sh

In either case, it needs to be copied to the system you plan to run Cloudmin on and then executed with a command like :

sh cloudmin-gpl-redhat-install.sh

Cloudmin can co-exist with Webmin or Virtualmin GPL on the same system. The installer uses YUM or APT to add the required packages, some from our repository and some from the repository provided by your distribution vendor.

Once installation is complete, you will need to reboot your system. Then go to https://yoursystem:10000 in your browser , download some system images, and type creating a Xen instance.

Installing Cloudmin GPL for KVM

Cloudmin's installer can be used on CentOS, Fedora, Debian and Ubuntu systems. It will both install Cloudmin and setup the system as a KVM host, by installing KVM and related packages.

You can download the install script for CentOS and Fedora from : http://cloudmin.virtualmin.com/gpl/scripts/cloudmin-kvm-redhat-install.sh

The install script for Debian and Ubuntu can be downloaded from : http://cloudmin.virtualmin.com/gpl/scripts/cloudmin-kvm-debian-install.sh

In either case, it needs to be copied to the system you plan to run Cloudmin on and then executed with a command like :

sh cloudmin-kvm-redhat-install.sh

Cloudmin can co-exist with Webmin or Virtualmin GPL on the same system. The installer uses YUM or APT to add the required packages, some from our repository and some from the repository provided by your distribution vendor.

Once installation is complete, you will need to reboot your system. Then go to https://yoursystem:10000 in your browser , download some system images, and begin creating a KVM instance.

Differences between Cloudmin GPL and Pro

Features missing from the GPL version of Cloudmin include :

1. Support for multiple virtualization types -- Cloudmin Pro supports Xen, KVM, OpenVZ, LXC, VServers, Solaris Zones virtual systems.
2. Can create and manage EC2 accounts, instances, images, addresses and storage volumes.
3. The ability to manage multiple host systems (each of which can run multiple virtual systems) from a single interface.
4. Support for managing multiple non-virtual systems, such as dedicated machines running Virtualmin.
5. Live replication of settings from a Cloudmin master to one or more backup systems.
6. Multiple locations for storing system images, to avoid repeated copies to distant datacenters.

Upgrading from Cloudmin GPL to Pro

Cloudmin can be upgraded to the Pro version without effecting any existing settings as follows :

1. Go to the Virtualmin shop at http://www.virtualmin.com/catalog/43 and purchase a Cloudmin licence.
2. Go to http://www.virtualmin.com/serial and note down your serial number and licence key. There is no need to download the new install script.
3. Login to your Cloudmin GPL install, and go to Cloudmin Settings -> Upgrade Cloudmin.
4. Enter your new serial number and licence key, then click the Upgrade button.

The full version packages will then be downloaded and installed, and your APT or YUM configuration will be updated to use the correct repositories.

Cloudmin Glossary

Cloudmin and its documentation uses the following terms to refer to different types of systems and other objects :

• System A machine with its own IP addresses, filesystems and accounts. This can either be an actual physical computer, or a virtual machine running under some virtualization technology such as Xen, OpenVZ, EC2, Vservers or Solaris Zones. Systems are the primary object managed by Cloudmin.

• Virtual System A system that runs under some virtualization type, such as Xen or OpenVZ.

• Real System or Physical System An actual computer with its own hardware.

• Host System A real machine that can host virtual systems of some type(s).

• Cloudmin Master The system on which the Cloudmin software is installed and runs. This may also be a host system, or in some rare cases a virtual system that it also controls. System images are also primarily stored here.

• Server A process that provides some service, such as Apache or BIND.

• Virtual Server A combination of services provided by several servers, typically associated with a domain name. Virtual servers are the object primarily managed by Virtualmin.

• System Image A template from which virtual systems can be created, containing the contents of its filesystem.

• System Owner An additional login to Cloudmin will access to a subset of systems and functions.

• Account Plan A set of limits on disk, CPU, RAM and network use that can be applied to a system owner.

Cloudmin Services

Introduction

The Cloudmin Services is an add-on to Cloudmin that allows many systems running Virtualmin to create DNS zones, MySQL databases and other virtual hosting services on a set of centralized systems. It is designed to allow resource-intensive services to be offloaded from web host systems onto one or more shared systems that are dedicated to hosting those services. This reduces the RAM, CPU and disk requirements of those web hosts, which is particularly useful in an environment with many virtual systems.

Concepts

When Cloudmin Services is being used there are three types of systems involved :

• The Master System This system runs Cloudmin and has the services plugin installed. It keeps track of which client systems have requested which services, and which host systems they are setup on. The plugin extends the regular Cloudmin UI with additional pages and sections for provisioning systems and limits.

• Client System A client is a system running Virtualmin that has been configured to offload some services to a provisioning host. It need not be managed by the master Cloudmin system. Each client is setup to connect to the services API with the login and password of a Cloudmin system owner.

• Host System A host is a system managed by Cloudmin that actually hosts the DNS zones, MySQL databases and other centralized services, up to limits set on the provisioning server. It must run Webmin and be configured to run the service(s) you select to provision on it. If multiple hosts exist for a service, Cloudmin will select one randomly for each client request, based on current usage and limits.

Accounts

For a client system to be able to request services from the Cloudmin master system, it must authenticate using the login and password of a Cloudmin system owner. Normally owners are people who are granted permissions to manage or create virtual systems, but when the services plugin is installed an owner can be created that can also (or only) call the Cloudmin API to request features.

Each owner must have a limit set on the number of each type of service he is allowed to create. If no limit is set (which is the default), creation of those services will be disallowed. Limits can also be defined in Cloudmin plans, which are then applied to all owners on the plan.

In a typical deployment, a customer who owns multiple real or virtual systems would have a single owner account that is used by Virtualmin on all those systems.

Installation

Because the Cloudmin Services plugin is just a single Webmin module with no dependencies, the basic installation process is simple :

1. Make sure Cloudmin is installed and running.
2. Download the appropriate install script for your OS from http://www.virtualmin.com/serial to the Cloudmin system.
3. Run the script as root.
4. After it completes, login to Cloudmin and go to Cloudmin Settings -> Cloudmin Plugins. Make sure the box next to Cloudmin Services is checked, and click Save.

Once it is done, you should be able to see the Cloudmin Services page under Virtualmin Settings on the left menu.

Cloudmin Services API

Using the Services API

When a Virtualmin system requests the creation of a DNS zone or MySQL database, it makes an HTTP call to the Cloudmin master, using the request format documented on the Cloudmin remote API page. Even though this API was initially designed for internal use between Virtualmin products, it can also be called by other programs that want to create DNS zones or databases.

This allows the managed of a Cloudmin installation to offer services similar to Amazon's hosted DNS and MySQL products, and frees customers from having to run their own BIND or MySQL server.

Cloudmin Services API Access

The Cloudmin API requires a system owner login and password to access, which can be created as documented on the Cloudmin Services and system owners page. API caller must use the system owner login and password for HTTP authentication when making requests.

The system owner must also be granted permissions to make Cloudmin API calls, just as they would if services creation was going to be done from client systems by Virtualmin.

Calling the API

The Cloudmin Services client adds several new commands to the core API, which are documented on the services section of the API documentation.

For example, to create a new MySQL login and database from the Unix shell on another system, you could use the commands :

curl "http://owner:password@cloudminmaster:10000/server-manager/remote.cgi?program=provision-mysql-login&user=dblogin&pass=smeg&domain-owner="
curl "http://owner:password@cloudminmaster:10000/server-manager/remote.cgi?program=provision-mysql-database&database=junk&user=dblogin"

In these examples, owner is the system owner login, password is his password, cloudminmaster is the Cloudmin system, dblogin is the MySQL user, and junk is the MySQL database name.

When the first command is run, assuming it is successful it will return a line like :

OK: host=provisioningmachine

This tells the caller which MySQL host system the login and database have been created on. Any subsequent API calls to mange or remove the login or database must include a host URL parameter whose value is this hostname. For example, to delete the database you could use :

curl "http://owner:password@cloudminmaster:10000/server-manager/remote.cgi?program=unprovision-mysql-database&database=junk&host=provisioningmachine"

API Output

Cloudmin Services API commands that perform some action output a line that starts with OK on success, like :

OK: host=something

Or on failure, they will produce a line like :

ERROR: User dblogin is not a domain owner

If called with incorrect parameters, a summary of valid parameters is returned instead.

Some API commands return information, such as records in a DNS zone or users with access to a MySQL database. For example, the following command :

curl "http://owner:password@cloudminmaster:10000/server-manager/remote.cgi?program=list-provision-mysql-users&database=junk&host=provisioningmachine&multiline=&json="

This requests a list of users who can access the junk database. The multiline= parameter indicates that the command should provide machine-parseable output, and json= indicates that you want it in JSON format. Other formats can be selected with perl= or xml= . The output of this example would be :

{
   "status" : "success",
   "data" : [
      {
         "name" : "dblogin",
         "values" : {
            "hosts" : [
               "193.9.101.104"
            ],
            "password" : [
               "*E474E7F197FAC1D7280FF181D07F1FA09566F5FC"
            ],
            "databases" : [
               "junk"
            ]
         }
      }
   ],
   "command" : "list-provision-mysql-users"
}

Cloudmin Services and System Owners

Creating System Owners

Before creating any system owner accounts for Cloudmin Services clients, you should read the general documentation on system owners , which explains how they can be added and managed.

For service creation purposes, it is not necessary for an owner to actually be able to manage or create any systems. However, if your Cloudmin server is managing virtual systems that belong to an owner, it makes sense for the same account to be used for service creation as well.

When creating or editing an owner, make sure that in the Limits and restrictions section, the Allowed operations field has at least the Call remote API box checked. Without this it will be impossible for Virtualmin on a client system to connect to the Cloudmin master to request the provisioning of features. This operation can also be granted at the plan level, which makes it available to owners on that plan.

System owners must also be granted permissions to provision features up to some limits, which are set in the Additional limits and capabilities section of the Edit System Owner page. This section also lists all features that have been created for that owner, and shows which host systems they have been created on. Once a limit is hit, requests from clients to create additional features of the limited type will fail.

Plans and Service Limits

Limits on features to create can also be set at the plan level, at Cloudmin Settings -> Account Plans. When creating or editing a plan, these are set in the Additional owner limits and capabilities section. However, these will only apply to system owners who have the Use services limits from plan? option set - otherwise, their individual limits will apply.

Setting Services Limits Via the API

Cloudmin has commands that can be run as root from the shell on the master system to create and modify system owners, documented on the owners API page.

When the Cloudmin Services plugin is installed, the modify-owner and create-owner commands gain additional flags to set services limits. For example, you could set the number of allowed DNS zones with a command like :

cloudmin modify-owner --name bob --max-provision-dns 77

To control if an owner inherits services limits from a plan, use the --provision-from-plan flag followed by either true or false.

To see the full list of available flags, run :

cloudmin modify-owner --help

To remove access to a Cloudmin Services feature, just set the limit to 0.

This same flags can be used when the API is called remotely via HTTP, but as URL parameters.

Shell and remote API commands to create and modify plans also accept the same flags, and will apply the specified limits to system owners on the plan being changed.

Command Line API

Explains how to use the command-line scripts included with Cloudmin to manage users, aliases, servers, databases and resellers.

Introduction

Command Categories

Create FreeBSD Virtual Systems

Introduction

Cloudmin versions 7.0 and above have the ability to fully manage virtual systems running FreeBSD under KVM. Almost all the same features that are available for Linux systems are supported, except for resizing filesystems. Older Cloudmin releases allowed you to create a FreeBSD system, but did not have the ability to set its root password or IP address, or manage network interfaces and virtual disks.

Host Requirements

Before a host machine can host a FreeBSD system it must satisfy the following requirements :

1. The kernel must be compiled with read/write support for the UFS filesystem. The kernel config file option for this is CONFIG_UFS_FS_WRITE=y . To check if this is enabled in your host's running kernel, run grep CONFIG_UFS_FS_WRITE /boot/config-$(uname -r)

2. The host must have the UFS tools for Linux package installed. On Debian / Ubuntu systems, this can be done with the command apt-get install ufsutils . Unfortunately, no similar standard package appears to exist for CentOS or Redhat systems. However, we have created a TAR file of the required commands that can be installed with :

   cd /usr/local/bin
   wget -O - http://cloudmin.virtualmin.com/gpl/ufsutils.tar.gz | tar xzf -

Limitations

In version 7.0 of Cloudmin there are some functions that are not available for FreeBSD virtual systems :

1. When creating a system, the first disk cannot be re-sized to be larger or smaller than the default size from the image. This is due to lack of support on Linux systems for manipulating FreeBSD partition tables.

2. After creation a virtual disk cannot be resized from its initial size. This is due to bugs in the growfs.ufs command included with Debian Linux ( see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632832 )

Creating IP Pools

If you plan to have more that one host machine for virtual systems (like Xen instances or OpenVZ containers), we recommend defining the IP allocation range for those systems in a single place. This way the range only has to be created once, and can be changed in a single place.

The steps to create a common IP range are :

1. Open the Host Systems category on the left menu, and click on IP Addresses.
2. Go to the Common IPv4 pools tab.
3. In the first empty row, enter starting and ending IP addresses for your allocation range, such as 192.168.1.1 and 192.168.1.200.
4. Enter a netmask for the range, like 255.255.255.0.
5. Optionally enter a gateway IP address.
6. If you have one, enter a description for this IP range.
7. Click the Save button.
8. To add another range, repeat the steps above.

Once the range has been created, it will be available when creating or editing host systems.

The starting, ending and gateway fields allow you to enter multiple addresses on separate lines, to define more than one range for this common IP pool.

IPv6 Allocation Pools

If you are running Cloudmin 5.6 or later and plan to use IPv6, you can also define IPv6 allocation ranges on this page. This assumes that an IPv6 network has been allocated for your use. The steps to do so are :

1. Open the Host Systems category on the left menu, and click on IP Addresses.
2. Go to the Common IPv6 pools tab.
3. In the first empty row, enter starting and ending IPv6 addresses for your allocation range, such as 2001:db8:0:f101::0 and 2001:db8:0:f101::fff. The starting and ending addresses should be the same except for the last word.
4. Enter a netmask for the range, typically 64.
5. Optionally enter a gateway IPv6 address.
6. If you have one, enter a description for this IPv6 range.
7. Click the Save button.
8. To add another range, repeat the steps above.

Once the range has been created, it will be available when creating or editing host systems.

IP Addresses and Host Systems

When you edit a KVM, Xen, OpenVZ or other host system under the Host Systems menu category, you can select one or more IP allocation pools that will be used for virtual systems created on that host. In a small Cloudmin deployment all your host systems will be on the same network, as thus can share the same pool - but if you have host systems in different datacenters, you may need multiple pools.

Pools are selected using the IP address allocation ranges table. For host systems that have multiple network bridges (each typically connected to a different LAN), you can choose which bridge each pool is used for.

If any IPv6 pools have been defined, you can similarly select them in the IPv6 address allocation ranges table.

IP Address Allocation

When a virtual system is created, the default behavior of Cloudmin is to assign one or more IP address from the pools specified for the chosen host system. Alternately you can manually enter an IP address, netmask and gateway in the Host and networking options section of the creation form.

When creating a new network interface for a virtual system an IPv4 address can also be allocated from the range assigned to the system it is hosted on.

If any IPv6 allocation ranges have been defined you can also select at creation time to allocate a IPv6 addresses for the new virtual system, or enter one manually. By default IPv6 allocation is disabled, but can be turned on by default at Cloudmin Settings -> Cloudmin Configuration -> Virtual system settings -> Allocate an IPv6 address for new systems?.

Creating a Citrix Xen Virtual Machine

Creation From a Cloudmin System Image

Once you have at least one system setup to host Citrix Xen instances and registered with Cloudmin, and have downloaded at least one Citrix Xen system image, you can create your first virtual system. The steps to do this are :

1. On the left menu, open the Create System link and click on Create Citrix Xen VM. This will open the Create New System page.
2. In the System hostname field, enter a short hostname for the new instance. This does not need to include a domain name - it will be appended automatically based on the Xen host selected.
3. In the System description field enter a short description, like Foo Corp's webserver.
4. From the Initial system image menu, select the OS image to install. We provide images for CentOS and Debian.
5. In the Root login mode section, select Using password and enter the root password to set for the new system into the adjacent field.
6. In the Webmin installation mode section you do not have to select anything if you have chosen to use an image with Virtualmin, as Webmin will be installed automatically.
7. Because the selected image may include old packages, you should set the Update Virtualmin packages? field to Yes, so that Cloudmin will install all available updates after instance creation.
8. From the Citrix Xen hosting system menu, select the host on which this Xen system should be created. It is generally a good idea to spread your instances across hosts to avoid putting too much load on a single system.
9. If the new Xen system with run Virtualmin, you should increase the Memory allocated to instance field to 512 MB, or even more if the host system has enough RAM.
10. By default, Citrix Xen VMs created from images with Virtualmin Pro have 2 GB filesystems, while those without it get 1 GB. In both cases, there is only about 500 MB free. To increase the size of the instance's filesystem, use the Disk space allocated to instance field.
11. If the image contains Virtualmin Pro, you will need to select a license for it using the License for Virtualmin from image field. See the Virtualmin Licenses page for more details on aquiring and registering licenses, so that they can be easily allocated at system creation time.
12. Finally, click the Create System button to start the creation process.

Because Xen instance creation involves the copying and uncompression of large filesystem images, the creation process may take up to 5 minutes. However, Cloudmin will display each step in the process as it is run, including copying the image file, un-compressing it, modifying the Xen filesystem to set the root password and IP address, and finally starting up the instance.

Assuming that everything works, the new virtual system will be added to the left menu. You will be able to use Cloudmin to rebooting, shut it down, start it up, or create Virtualmin domains on it, just as you could for any real system. If you no longer need this Xen VM2, it can be completely removed with the Delete System link on the left menu.

Creation From a Xen Template

Citrix Xen also allows a virtual system to be created empty, and setup to boot the installer for some Linux distribution or other operating system. This allows you to create a new VM into which you install Debian, CentOS or even Windows. The steps to do this are :

1. On the left menu, open the Create System link and click on Create Citrix Xen VM. This will open the Create New System page.
2. In the System hostname field, enter a short hostname for the new instance. This does not need to include a domain name - it will be appended automatically based on the Xen host selected.
3. In the System description field enter a short description, like New CentOS install.
4. From the Initial system image menu, select From Citrix Xen template.
5. In the Root login mode section, select Using password and enter the root password to set for the new system into the adjacent field.
6. From the Citrix Xen hosting system menu, select the host on which this Xen system should be created. It is generally a good idea to spread your instances across hosts to avoid putting too much load on a single system.
7. If the OS being installed needs more than the default of 128 MB of rAM, increase the Memory allocated to instance field.
8. From the Citrix Xen template menu select a template for the OS you plan to install, such as Debian Lenny 5.0.
9. In the Repository URL for template field enter the base URL appropriate for the selected Linux distribution. For Debian 5.0 this would be http://ftp.debian.org/ , while for CentOS 5 it would be like http://mirror.centos.org/centos-5/5.4/os/i386/ .
10. Click the Create System button to start the creation process.
11. Creation will be relatively quick, as only the installer for the new VM gets set up. Cloudmin will report the status as Ping failed, which is expected as networking has not been enabled yet.
12. Open the System State menu category and then click on Graphical Console. This will allow you to complete the install process as though you were accessing a physical system at the console. Be sure to enter the same root password, hostname and IP address that you chose above, or else Cloudmin will be unable to manage the new system. When it comes to disk partitioning, we recommend creating a single partition that does not use LVM or RAID - otherwise Cloudmin will be unable to access files in the VM when it is shut down. If you must use swap, put the swap partition at the start of the disk so that the partition with the filesystem on it can be expanded later.
13. Once installation is complete and the virtual system has been rebooted, click Refresh Status on the left menu - if all went well the status should show up as SSH.

Creating a KVM Virtual Machine

Once you have at least one system setup to host KVM instances and registered with Cloudmin, and have downloaded at least one KVM system image, you can create your first virtual system. The steps to do this are :

1. On the left menu, open the Create System link and click on Create KVM instance. This will open the Create New System page.
2. In the System hostname field, enter a short hostname for the new instance. This does not need to include a domain name - it will be appended automatically based on the KVM host selected.
3. In the System description field enter a short description, like Foo Corp's webserver.
4. From the Initial system image menu, select the OS image to install.
5. In the Root login mode section, select Using password and enter the root password to set for the new system into the adjacent field.
6. In the Webmin installation mode section you do not have to select anything if you have chosen to use an image with Virtualmin, as Webmin will be installed automatically.
7. Because the selected image may include old packages, you should set the Update Virtualmin packages? field to Yes, so that Cloudmin will install all available updates after instance creation.
8. From the KVM hosting system menu, select the host on which this KVM system should be created. It is generally a good idea to spread your instances across hosts to avoid putting too much load on a single system.
9. If the new KVM system with run Virtualmin, you should increase the Memory allocated to instance field to 512 MB, or even more if the host system has enough RAM.
10. By default, KVM instances created from images with Virtualmin Pro have 2 GB filesystems, while those without it get 1 GB. In both cases, there is only about 500 MB free. To increase the size of the instance's filesystem, use the Disk space allocated to instance field.
11. If the image contains Virtualmin Pro, you will need to select a license for it using the License for Virtualmin from image field. See the Virtualmin Licenses page for more details on aquiring and registering licenses, so that they can be easily allocated at system creation time.
12. Finally, click the Create System button to start the creation process.

Because KVM instance creation involves the copying and uncompression of large filesystem images, the creation process may take 5 to 10 minutes. However, Cloudmin will display each step in the process as it is run, including copying the image file, un-compressing it, modifying the KVM filesystem to set the root password and IP address, and finally starting up the instance.

Assuming that everything works, the new virtual system will be added to the left menu. You will be able to use Cloudmin to rebooting, shut it down, start it up, or create Virtualmin domains on it, just as you could for any real system. If you no longer need this KVM instance, it can be completely removed with the Delete System link on the left menu.

Creating a Solaris Zones Virtual Machine

Once you have at least one system setup to host Solaris Zones and registered with Cloudmin, you can create your first virtual system. The steps to do this are :

1. On the left menu, open the Create System link and click on Create Solaris Zone. This will open the Create New System page.
2. In the System hostname field, enter a short hostname for the new instance. This does not need to include a domain name - it will be appended automatically based on the Zones host selected.
3. In the System description field enter a short description, like Foo Corp's webserver.
4. From the Initial system image menu, select the OS image to install. Or you can select None - base OS only, which tells Cloudmin that the zone should be created by copying packages from the host system. If you do use an image, make sure you select one of the same architecture (X86 or Sparc) as the host system.
5. In the Root login mode section, select Using password and enter the root password to set for the new system into the adjacent field.
6. In the Webmin installation mode section you do not have to select anything if you have chosen to use an image with Virtualmin, as Webmin will be installed automatically.
7. Because the selected image may include old packages, you should set the Update Virtualmin packages? field to Yes, so that Cloudmin will install all available updates after instance creation.
8. From the Zones hosting system menu, select the host on which this zone should be created. It is generally a good idea to spread your instances across hosts to avoid putting too much load on a single system.
9. Finally, click the Create System button to start the creation process.

If you chose to create the zone from an image, the process will take 5 to 10 minutes, as the image needs to be transferred from the Cloudmin master and un-compressed on the host system. If you selected the base OS option it will take longer, as all packages that need to be copied from the host system. Either way, Cloudmin will display each step in the process as it is run, including copying the image file, un-compressing it, modifying the zones's filesystem to set the root password and IP address, and finally starting up the instance.

Assuming that everything works, the new virtual system will be added to the left menu. You will be able to use Cloudmin to rebooting, shut it down, start it up, or create Virtualmin domains on it, just as you could for any real system. If you no longer need this zone, it can be completely removed with the Delete System link on the left menu.

Creating a VServers Virtual Machine

Once you have at least one system setup to host Linux VServer instances and registered with Cloudmin, you can create your first virtual system. The steps to do this are :

1. On the left menu, open the Create System link and click on Create VServer. This will open the Create New System page.
2. In the System hostname field, enter a short hostname for the new instance. This does not need to include a domain name - it will be appended automatically based on the VServer host selected.
3. In the System description field enter a short description, like Foo Corp's webserver.
4. From the Initial system image menu, select the OS image to install. Or you can select None - base OS only, which tells Cloudmin that the VServer should be created by downloading and installing packages for the host system's Linux distribution.
5. In the Root login mode section, select Using password and enter the root password to set for the new system into the adjacent field.
6. In the Webmin installation mode section you do not have to select anything if you have chosen to use an image with Virtualmin, as Webmin will be installed automatically.
7. Because the selected image may include old packages, you should set the Update Virtualmin packages? field to Yes, so that Cloudmin will install all available updates after instance creation.
8. From the VServer hosting system menu, select the host on which this VServer should be created. It is generally a good idea to spread your instances across hosts to avoid putting too much load on a single system.
9. Finally, click the Create System button to start the creation process.

If you chose to create the VServer from an image, the process will take 5 to 10 minutes, as the image needs to be transferred from the Cloudmin master and un-compressed on the host system. If you selected the base OS option it will take longer, as all packages that need to be installed will be downloaded from the appropriate Linux distribution repository. Either way, Cloudmin will display each step in the process as it is run, including copying the image file, un-compressing it, modifying the VServer's filesystem to set the root password and IP address, and finally starting up the instance.

Assuming that everything works, the new virtual system will be added to the left menu. You will be able to use Cloudmin to rebooting, shut it down, start it up, or create Virtualmin domains on it, just as you could for any real system. If you no longer need this VServer instance, it can be completely removed with the Delete System link on the left menu.

Creating a Xen Virtual Machine

Once you have at least one system setup to host Xen instances and registered with Cloudmin, and have downloaded at least one Xen system image, you can create your first virtual system. The steps to do this are :

1. On the left menu, open the Create System link and click on Create Xen instance. This will open the Create New System page.
2. In the System hostname field, enter a short hostname for the new instance. This does not need to include a domain name - it will be appended automatically based on the Xen host selected.
3. In the System description field enter a short description, like Foo Corp's webserver.
4. From the Initial system image menu, select the OS image to install. We recommend CentOS 5 with Virtualmin Pro.
5. In the Root login mode section, select Using password and enter the root password to set for the new system into the adjacent field.
6. In the Webmin installation mode section you do not have to select anything if you have chosen to use an image with Virtualmin, as Webmin will be installed automatically.
7. Because the selected image may include old packages, you should set the Update Virtualmin packages? field to Yes, so that Cloudmin will install all available updates after instance creation.
8. From the Xen hosting system menu, select the host on which this Xen system should be created. It is generally a good idea to spread your instances across hosts to avoid putting too much load on a single system.
9. If the new Xen system with run Virtualmin, you should increase the Memory allocated to instance field to 512 MB, or even more if the host system has enough RAM.
10. By default, Xen instances created from images with Virtualmin Pro have 2 GB filesystems, while those without it get 1 GB. In both cases, there is only about 500 MB free. To increase the size of the instance's filesystem, use the Disk space allocated to instance field.
11. If the image contains Virtualmin Pro, you will need to select a license for it using the License for Virtualmin from image field. See the Virtualmin Licenses page for more details on aquiring and registering licenses, so that they can be easily allocated at system creation time.
12. Finally, click the Create System button to start the creation process.

Because Xen instance creation involves the copying and uncompression of large filesystem images, the creation process may take 5 to 10 minutes. However, Cloudmin will display each step in the process as it is run, including copying the image file, un-compressing it, modifying the Xen filesystem to set the root password and IP address, and finally starting up the instance.

Assuming that everything works, the new virtual system will be added to the left menu. You will be able to use Cloudmin to rebooting, shut it down, start it up, or create Virtualmin domains on it, just as you could for any real system. If you no longer need this Xen instance, it can be completely removed with the Delete System link on the left menu.

Creating an EC2 Image

Introduction to EC2 Images

Unlike other virtual system types, EC2 images (called AMIs or Amazon Machine Images) are not stored on your Cloudmin master system. Instead they are stored as files inside Amazon's S3 storage service, and can be selected when creating a virtual system on EC2.

Each image has a unique ID, like ami-7c1df915, and a manifest path in S3 like centos-virtualmin-gpl-3.63/image.manifest.xml . An image can be either made available to everyone, or limited to certain EC2 accounts. Images can also be associated with production codes, indicating that customers must pay to use them.

Creating an EC2 Image

An image is created from a virtual system running on Amazon's EC2 service. The steps to make an image are :

1. Select your EC2 system from Cloudmin's left menu, then go to System Operations -> Create EC2 Image.
2. Enter a unique directory name for the image in S3 in the S3 bucket for image field. This should typically contain the operating system, version and purpose, such as //centos-5.3-webserver// .
3. If you have multiple EC2 accounts, select the one who will own this image from the Save under S3 account menu.
4. The size of an image determines the filesystem size of virtual systems create from it. The default is 5GB, but you can enter a larger size in the Size of image filesystem field. Make sure this is at least as big as the root filesystem on the system being imaged.
5. If you want anyone to be able to use this image, change Make image publicly available? to Yes.
6. If the bucket already contains an image and you want to replace it, change Overwrite AMI in same bucket? to Yes.
7. Click the Create Image button.

Once started, Cloudmin will display the progress of the image creation process. This can take up to an hour depending on the size and speed of the system.

Once creation is complete, Cloudmin will display the new image's ID. You can select this on the Create New System page to generate a new EC2 instance that will be a duplicate of the one you imaged. In additional, if you made the AMI publicly available the ID can be shared with any other EC2 users to use.

Managing EC2 Images

You can see all EC2 images Cloudmin knows about at Amazon EC2 -> EC2 Images. By default this includes those you created, images provided by Amazon, and public images from selected other accounts. The accounts to show are set at Cloudmin Settings -> Module Config -> EC2 accounts to display AMIs from.

To change the permissions on an image you created, just click on its ID in the list. On the page that appears you will be able to select if it is public (with the Grant access to everyone checkbox), or only available to a list of EC2 account numbers that you enter.

To remove an image, check the box next to it in the image list and hit the Delete Selected Images button at the bottom of the page. On the confirmation page that appears you will have the option of removing the associated files from S3 too, which is generally a good idea as you are charged for S3 usage by disk space and time.

Creating an EC2 Virtual Machine

Once you have at least one EC2 account registered with Cloudmin and one EC2-generated SSH key, you can create your first EC2 system. The steps to do this are :

1. On the left menu, open the Create System link and click on Create EC2 instance. This will open the Create New System page.
2. In the System description field enter a short description, like Foo Corp's webserver.
3. From the SSH key for root menu, select one of your keys. Typically you will only have one.
4. If you have multiple EC2 accounts registered, select one from the EC2 account menu. At the time of writing, Amazon only allowed 20 active instances per account.
5. From the EC2 image to start menu, select the image that defines the initial operating system and software stack for the instance. For webhosting you can use the virtualmin-pro image, or you can go with one of the base operating systems supplied by Amazon. Or if you have created your own EC2 images, you can select one of those.
6. Because the selected image may include old packages, you should set the Update Virtualmin packages? field to Yes, so that Cloudmin will install all available updates after instance creation.
7. Finally, click the Create System button to start the creation process.

Amazon is generally pretty fast to create new instances, and no data needs to be copied from the Cloudmin master to the new system. Typically this takes about 5 minutes, and Cloudmin will display each step taken in the system creation process.

Assuming that everything works, the new virtual system will be added to the left menu. You will be able to use Cloudmin to reboot it, update it, or create Virtualmin domains on it, just as you could for any real system. If you no longer need this zone, it can be completely removed with the Delete System link on the left menu.

Disk Image Directories

Introduction

By default, Cloudmin will create KVM or Xen virtual disk images in the directory or LVM volume group selected on the Host System page for the virtual system's host. All additional virtual disks will be created in the same location. Virtualization types that use a directory on the host's filesystem will always be placed in a sub-directory under the path specified for the host system.

Cloudmin versions 6.0 and later give you more flexibility in placing disk images and virtual filesystems, using the new Disk Image Directories page. This lets the master administrator define additional paths on host systems that can be selected when a virtual system is created, moved or cloned, instead of using the host system default. For example, this could be used to control if a system is created on storage local to the host, or a directory mounted from a common file server, or faster local disks.

Creating A Shared Disk Image Directory

Before adding a directory to Cloudmin, it should first be created on all the host systems that you intend to use it on. If it will only exist locally, it can either be simply created with the mkdir command, or mounted from an additional local disk, RAID device or LVM logical volume.

If you want to use NFS to share a directory between hosts, it must first be exported from a file server. This could be a dedicated device such as one sold by NetApp, or a Linux system with a suitably large and fast local disk or RAID array. In the latter case, you can use Webmin to export a directory as follows :

1. SSH into the system as root, and create the directory with a command like mkdir /shared
2. Login to Webmin (or Cloudmin or Virtualmin) on the system, and go Networking -> NFS Exports.
3. Click the Add a new export button, and enter /shared into the Directory to export field.
4. In the **Export to..* field, enter the IPs of the host systems that will share this directory.
5. Click the Create button, then click Apply Changes.

One a directory is shared, it can be mounted on each of your host systems as follows :

1. Select the host system from the left menu in Cloudmin, and click on Link to Webmin or Open Webmin
2. In Webmin on the host, go to System -> Disk and Network Filesystems
3. Select Network Filesystem from the menu, and click the Add mount button.
4. In the Mounted As field, enter the directory you are sharing, like /shared
5. In the NFS hostname field, enter the hostname or IP address of the NFS server setup above.
6. In the NFS directory field, enter the path exported by the NFS server - this will typically be the same as in step 4.
7. Click the Create button.

Adding A Disk Image Directory

Once the directory exists on all the hosts you want to use it on, it can be added to Cloudmin as follows :

1. Login as the master administrator, and go to Host Systems -> Disk Image Directories.
2. Click the Add a new disk image directory link.
3. In the Directory path on host field, select Directory on host and enter the path (like /shared) into the adjacent text box.
4. Fill in the Description field with a short description of the directory.
5. To limit the hosts on which the directory can be used, select them in the For use on host systems field.
6. By default virtual systems of any type will be able to use the directory, but you can restrict it to a subset of types by selecting them in the For use by virtualization types field.
7. If you have created any system owner plans, access to the directory can be limit to owners on those plans using the For use by system owners field. Alternately, you can restrict access to only the root (master administrator) user.
8. Finally, click the Create button. The directory will now be selectable when creating new virtual systems.

Selecting A Directory At Creation Time

Once you have created a disk directory, you can select it when creating a virtual system of a supported type using the Disk image directory field in the Resource limit options section of the creation form. For Xen and KVM systems, all disk image and config files will be created in that directory instead of the host's default directory or volume group. For OpenVZ and LXC systems, the directory that contains the filesystem will be created below the selected path. However, other configuration files will remain in their regular directories.

If creating a system using the Cloudmin command-line API, you can use the --disk-directory flag follow by a path to specify the path. When creating via the remote API, use the disk-directory parameter followed by the path. In all cases, if creating a system while logged in as a system owner you can only select directories that have been made available to the owner's plan.

Changing The Directory For New Disks

If you add an additional disk to a KVM or Xen system after creation, it will by default be created in the directory selected at creation time. However, this can be changed as follows :

1. Select the virtual system from the left menu.
2. Open the Resources category and click on Manage Disks.
3. In the Default disk image directory section, select an alternate path from the New directory menu, and click Save.

The default can also be changed using the modify-system API command, with the --disk-directory flag.

Moving And Cloning Virtual Systems

By default when a virtual system with a non-standard disk directory is moved, Cloudmin will attempt to keep the same directory on the destination system as was used on the source. If the directory is not available on the destination, the move or clone operation will fail.

Both the forms for moving and cloning a system have a field for selecting a new disk image directory to use, similar to the field on the system creation form. Also, the clone-system and move-system API commands accept the --disk-directory flag followed by a directory to use. The --no-disk-directory flag can be used instead to revert to the default directory on the destination host.

Directory Permissions

As mentioned above, the master administrator (root) can limit access to disk directories by system owners based on their plan. For example, a directory that is mounted from faster and more expensive storage (like RAID or SSD) might be reserved for only a subset of users.

You can also control if system owners are allowed to use the default disk directory or logical volume on host systems, by editing the special Host system default path on the Disk Image Directories page. This entry cannot be renamed or deleted, but its permissions can be changed to restrict access to some system owners, or none at all.

Disk Snapshots

Introduction

In Cloudmin, a snapshot is a copy of the contents of all disks attached to a virtual system, taken at a point in time. After creating a snapshot you can make changes to the contents of the system's disks (such as installing or re-configuring software), and if that goes wrong you can roll back to the state when the snapshot was taken.

Snapshots do not include the contents of the virtual system's RAM - only disks. This means that a rollback will require that the system be rebooted.

System owners can be granted permission to create snapshots, either individually or at the plan level. Any disk space they consume will be counted towards the owner's disk limit.

Snapshots use "copy on write" to store differences between the virtual system disks at the time the snapshot was made and the current time. This means that the snapshot can be much smaller than the system it was made from - typically only 10 or 20%. However, once the space allocated to the snapshot has been consumed it will become unusable.

Requirements

In order to create and manage snapshots, a virtual system must satisfy the following requirements :

• The primary disk and all additional disks to be included in the snapshot must be stored in LVM logical volumes. Because snapshotting makes use of LVM's snapshot feature, it cannot be performed on regular files.
• The host system's kernel must support LVM snapshot merging. We have confirmed that CentOS 6, RHEL 6 and Debian 7 include this support.
• Snapshotting is only supported on open-source Xen and KVM systems.
• Only Cloudmin versions 7.1 and later support the snapshot feature

Creating a Snapshot

Once you have a virtual system that meets the requirements above, you can create a snapshot as follows in the UI :

• Open the Resources category, and click on Disk Snapshots.
• In the form at the bottom of the page, enter a unique ID for the snapshot (which can consist of only letters and numbers).
• Enter the percentage of the system's disk space that will be consumed by the snapshot. This is a tradeoff between the amount of disk space consumed and the number of changes the snapshot can store.
• Click the Create button.

To create a snapshot using the command line API, use the create-snapshot command. For example :

cloudmin create-snapshot --host yourvm.cloudmin.com --id snapid --percent 20

Reverting to a Snapshot

To revert a system to the state it was in when the snapshot was taken, the steps are :

• Open the Resources category, and click on Disk Snapshots.
• Click on the ID of the snapshot you want to revert to.
• Click the Revert button.

Reversion should be relatively fast, as only disk blocks changed since the snapshot was created need to be copied.

From the command line you can revert a snapshot with the merge-snapshot command, like so :

cloudmin merge-snapshot --host yourvm.cloudmin.com --id snapid

Deleting Snapshots

If a snapshot is no longer needed, it can be removed by checking the box next to it on the Disk Snapshots page and clicking the Delete button.

From the shell, you can use the delete-snapshot command. For example :

cloudmin delete-snapshot --host yourvm.cloudmin.com --id snapid

Limitations

There are some limitations to take into account when using snapshots :

• When a virtual system is moved to a new host, snapshots will not be transferred. Instead, they will be deleted from the original host.
• When snapshots exist for a virtual system its disks cannot be resized.

These are limitations of the underlying LVM snapshot system that Cloudmin uses.

Downloading System Images

A system image is effectively a file containing the entire filesystem of a virtual system, either in tar.gz or EXT3 format. When a virtual system is created by Cloudmin, it can use an image as the basis of the system's filesystem, rather than needing to download and install packages, or copy files from the host system.

Cloudmin customers have access to system images for a variety of operating systems and virtualization types, but by default none are included when it is installed. To download images that you can use to create systems, do the following :

1. On the left menu under Cloudmin Settings click on New System Images.
2. A page listing all available images will be displayed. Choose the ones you want based on the virtualization technology you prefer (such as Xen or Zones), and the Linux distribution that will run in the image.
3. Check the boxes next to the ones you want to use, and click the Download Selected Images button.
4. Depending on the speed of your network connection and the total size of those you choose, images may take minutes or hours to download. The progress of each download will be displayed.

You can now create virtual systems using the selected images, assuming that one or more host systems of the corresponding virtualization type have been registered.

If you are using Solaris Zones, only images for the architecture that matches the physical Solaris host systems will work. For Xen or VServers, I recommend selecting images of the same type as your host systems, just to keep management easier.

Some images include the full Virtualmin stack, such as Webmin, Apache, Postfix, BIND, MySQL, ProFTPd and so on. If you plan to create virtual systems for web hosting, we recommend using these images rather than manually installing Virtualmin on created systems - even though Cloudmin is capable of doing this for you.

Cloudmin does not limit you to provided images - once you have some virtual systems running, you can create your own, as documented on the Making Your Own Images page.

EC2 Security Groups

Introduction to Security Groups

An EC2 security group is basically a set of firewall rules that can be applied to EC2 instances. Each rule specifies a protocol (TCP or UDP), starting and ending port numbers, and an optional network. When a group is applied to a system, only traffic matching one of the rules will be allowed through. All other traffic will be dropped.

In addition, a security group can list other groups to allow traffic from, regardless of port or address. This will then match other EC2 systems using one of the selected groups. This feature is useful for allowing arbitrary connections between your own machines, while applying stricter restrictions on other systems.

By default every EC2 account has a security group named default that allows connections on a limited number of ports. Cloudmin will create a group named virtualmin when you create a system that allows all the ports typically used for web hosting, such as 110, 80, 443 and 25.

Editing a Security Group

If you want to change the rules for an existing group, the steps to take are :

1. Go to Amazon EC2 -> EC2 Security Groups, and click on the group you want to edit.
2. On the page that appears all current rules will be listed. You can change the port range, protocol or allowed addresses for some rule, or use the empty row at the bottom to add a new rule.
3. To allow network traffic from systems on some other group (or this group), select an EC2 account in the Allowed security groups section and enter the group name in the adjacent field.
4. Click the Save button to activate your changes.

To create a new group, go to the EC2 Security Groups page and click the Create group for link for the EC2 account you want to add it under. Then fill in rules form with protocols and ports to accept. Make sure you allow at least port 22 (for SSH) and port 10000 (for Webmin), or Cloudmin's access to systems using this security group may be blocked.

To delete a security group that is not in use, check the box next to it on the EC2 Security Groups page and hit the Delete Selected Security Groups button.

Applying a Security Group

A security group can be selected when creating a new EC2 system, using the EC2 security groups field under Advanced options. Actually, you can choose several groups, and traffic matching rules from any of them will be allowed. If you have multiple EC2 accounts in Cloudmin, only groups for the account selected to own the new system can be used though.

If no security group is chosen, just the default group will be used. If a group is changed after system creation (such as to add a new port), it will be immediately applied to all virtual systems using that group. There is no way to select different groups for a system after it is created though.

EC2 Static IP Addresses

IP Addresses on EC2

Every EC2 instance has two IP addresses - the real one on its eth0 interface (typically in the 10.0.0.0/8 network), and an external Internet-accessible address. The Amazon using NAT to foward all traffic to the external address to the internal one, and back again for outgoing connections.

Both addresses are dynamically assigned when a system is created. Because an EC2 instance may need to be destroyed and re-created, there is no guarantee that a replacement instance will get the same IP address that a previous system did, even one under the same account.

However, Amazon does allow EC2 accounts to request static IP addresses, which they call Elastic IPs. Each static IP can be associated with a single EC2 instance at a time, and can be moved between instances. This allows you to keep your external addresses consistent in the face of virtual system creation and deletion.

Creating and Managing Static Addresses

To request a new static EC2 address, follow these steps :

1. Login to Cloudmin, and go to Amazon EC2 -> EC2 Static IP Addresses.
2. Select an EC2 account from the menu at the bottom of the page (if you have more than one), and click the Allocate New Address button.
3. If all goes well, the new IP will show up in the list on the same page.

Amazon bills for each static IP address associated with your access, so don't request too many of them!

To give back an address, check the box next to it and click the Return Selected IP Addresses button. Be careful doing this, as you will not be able to request the same address again. Only addresses not assigned to any system can be returned.

Assigning a Static Address

Once an address has been requested, you can assign it to an EC2 system as follows :

1. Select the system from the left menu, and go to System Operations -> Assign EC2 Address.
2. Select the address from the IP address to assign menu, and click Update IP Address.
3. Wait for Cloudmin to detect that the new address has been applied. This may take several minutes.

You can also dis-associate an address from a system on the same page, by selecting <None> from the IP address to assign menu.

EC2 Volumes

Introduction to EC2 Volumes

EC2 Volumes (called Elastic Block Storage by Amazon) are essentially disk images that can be mounted on any system running on EC2, and continue to exist even if the system they were attached to is deleted. They are a more permanent place to store data than the filesystem of an EC2 instance, and more easily accessible than S3.

Each volume is typically formatted with a filesystem like EXT3, and is mapped to a device like /dev/sdb1 on the system it is connected to. It can then be mounted with the standard Linux mount command. The size of a volume is typically several GB, and is chosen at creation time. Amazon charges for volumes based on their size and the amount of time they exist.

EC2 Volume Snapshots

An EC2 volume snapshot is a copy of a volume taken at some point in time, and stored in S3. Once a snapshot has been created, additional volumes can be created from the data in that snapshot. They can be used for backup purposes, or to duplicate or fork the contents of a volume.

Snapshots are differential backups, meaning that only the blocks on the device that have changed since your last snapshot will be incrementally saved. This means that if you have a device with 100 GBs of data, but only 5 GBs of data has changed since your last snapshot, only the 5 additional GBs of snapshot data will be stored back to Amazon S3.

Creating and Managing EC2 Volumes

To create an EC2 volume in Cloudmin, do the following :

1. Login to the UI as root and go to Amazon EC2 -> EC2 Volumes.
2. In the New volume details form, choose your account from the EC2 account menu.
3. Enter a size in the EC2 account field, or select a snapshot to copy this volume from.
4. From the Availability zone menu, select the zone that your EC2 systems have been created in. A volume can only be attached to systems in the same zone.
5. Click the Create button.

Once a volume has been created, it will appear in the list on the EC2 Volumes page. To remove it, check the box next to it's ID and click the Delete Selected Volumes button. Be careful, as the data on the volume will be lost forever (unless you made a snapshot first).

Creating and Managing EC2 Snapshots

Once you have at least one EC2 volume, Cloudmin will allow you to create a snapshot of it as follows :

1. Go to Amazon EC2 -> EC2 Volumes, and click on the EBS Snapshots tab.
2. In the New volume snapshot details section, select the volume to copy from the Copy from volume menu.
3. Click the Create button.

Once a snapshot has been created, it can be used to create new volumes as explained above. Snapshots can be deleted on the EBS Snapshots* tab by checking the boxes next to their names and clicking the Delete Selected Snapshots button.

Assigning Volumes to Systems

Once a volume has been created, it can be attached to an EC2 instance as a block device, and typically mounted a filesystem. This can be done within Cloudmin like so :

1. Select your system from the left menu, and go to Resources -> Attached EC2 Volumes.
2. In the Volume attachment options form, select the volume from the Volume to attach menu.
3. If this is a new volume that has not been mounted anywhere yet, change the Format with filesystem to EXT3. Otherwise, leave it set to Dont format to preserve existing data.
4. To have Cloudmin attempt to mount the volume, enter a path in the Mount on directory field like /mnt/disk2 or /home.
5. Click the Attach EC2 Volume button.

Once a volume has been attached and mounted, you can use it on your EC2 system however you wish. To detach a volume, go to the ttached EC2 Volumes page, check the box next to its ID and click the Detach Selected Volumes.

Empty Systems

Introduction to Empty Systems

Cloudmin uses the term "empty system" to refer to one that is created without any operating system initially installed on its virtual disk. Empty systems are always connected to a CD image or physical CD-ROM drive, from which any operating system can be installed. Once the install is complete, the formerly empty system can be managed like any other Cloudmin virtual machine.

The open-source Xen, KVM and Citrix Xen virtualization types all support the creation of systems that are initially empty. In the case of Xen, full hardware virtualization (HVM) is used, which has a performance overhead as compared to para-virtualization. However, HVM allows any operating system to be run inside the virtual system, such as OpenBSD, Windows or other Linux distributions.

Cloudmin will not be able to fully manage non-Linux virtual systems though, as it cannot access files inside their filesystems. This prevents Cloudmin from editing network interfaces unless the system is up and running Webmin, and from fully managing virtual disks.

Creating CD Images

Before creating an empty system, you should add the CD image that you plan to install it from to Cloudmin's system images list. This can be done as follows :

1. Login as root and go to Cloudmin Settings -> New System Images.
2. Click Create image for Xen (or whatever virtualization type you are using).
3. In the Image file format field, select CD or DVD ISO.
4. In the Image source field, enter the path or URL to the .iso file for the CD image.
5. Enter a short name for the image in the Unique ID for image field, like xen-debian5-cd.
6. Enter a longer description in the Description for image field.
7. Change Compress image file to No.
8. Click the Create button.

Depending on where the image file has to be fetched from and whether it is initially compressed or not, the creation process may take from seconds to minutes. Once it is complete, you should see it appear on the New System Images page.

Setting up DHCP

When Cloudmin creates an empty virtual system, the IP address that it selects for that system cannot actually be inserted into the appropriate configuration files until after the OS install is complete. Because the OS install is done manually, it is possible that the virtual system might be assigned a different IP address to what Cloudmin expects it to have, which will cause the status to be falsely shown as "Ping failed". This prevents the system from being fully managed by Cloudmin.

The best solution to this issue is to setup a DHCP server on your Cloudmin master system, which will then be automatically configured for each new virtual system so that systems can obtain the correct IP address. The steps to do this are :

1. Login to Cloudmin at root , and go to Webmin -> Servers -> DHCP Server
2. If the DHCP server is not installed yet, you may be prompted to have Webmin install it on that page. If this prompt doesn't appear, you will need to install it manually using whatever package or method is appropriate for your operating system.
3. If the Start Server button appears at the bottom of the page, click it to start DHCPd.
4. On the left menu, go to System -> Bootup and Shutdown, check the box next to the dhcpd or dhcp-server action, and click the Start on Boot button.
5. Go to Cloudmin -> Cloudmin Settings -> Cloudmin Configuration -> DHCP settings and change Add DHCPd host for virtual systems? to Yes.

Once this is done, Cloudmin will add a DHCP host entry for each new virtual system it creates. However, this will only be actually used if your master system and Xen or HVM hosts are on the same subnet. If not, you will need to setup the appropriate firewall rules or router configurations to forward DHCP packets from other networks to your Cloudmin master.

Creating Empty Systems

The process of creating a new empty virtual system is mostly similar to that for creating a full system. The steps to follow are :

1. Open the Create System category on the left menu, and click on Create Xen instance (or whatever virtualization type you want to use).
2. Select the Create empty system tab.
3. Enter a short name in the Internet hostname field, like gentoobox.
4. Enter a longer description in the System description field, like Gentoo Linux install.
5. In the Installation CD image field, either select a CD image that you added to Cloudmin as documented above, or enter the path to an ISO format CD or DVD file on the host system.
6. If you entered a CD image page, make sure the correct host is selected in the Xen hosting system field.
7. In the Resource limit options section, enter the size of the system's empty virtual disk in the Disk space allocated to instance field.
8. If the virtual system is not Linux and you are using KVM virtualization, change Use VirtIO disk driver? to No in the advanced options section.
9. Click the Create System button.

Creation should take less time than in would for a Cloudmin system created from an image. At the end of the process, you will have a virtual system whose status is Ping failed, which indicates that Cloudmin could not contact it on the assigned IP address. This is expected, as the system will be waiting for you to complete the OS install process as follows :

1. Open the System State menu category, and click on Graphical Console.
2. You should now see the initial installation screen of the operation system whose CD image you selected. Begin the install process, just as you would on a real system.
3. When you reach the disk partitioning step, make sure that the virtual drive is given only a single partition which contains the root filesystem. Having multiple partitions may make it impossible for Cloudmin to expand the disk later.
4. When prompted for the system's IP address and hostname, if they do not get correctly assigned by DHCP, make sure you enter the same IP and hostname that Cloudmin selected when the empty system was created.
5. Complete the rest of the install process as normal. Keep a note of the root password that you select.
6. Go to System State -> Change Boot Method , and set the boot device to Hard disk only.
7. Click on Edit System, and in the Authentication options section change the SSH login mode to Using password and enter the password you chose during the install process.
8. Shut down the virtual system, then start it up again.
9. Make sure that Cloudmin now shows the system's status as SSH.

If the new system is not contactable by Cloudmin after rebooting, use the Graphical Console page to ensure that it has fully booted from the hard disk, and has the correct IP address.

Managing Empty Systems

Once an empty system has been fully installed, it can be managed by Cloudmin like any other virtual machine. However, Xen instances created this way will always use HVM virtualization, as will any clones created from them. If you create an image of an initially empty Xen instance and then create a new virtual system from that image, it will also use HVM.

Open source Xen systems that were initially created empty will use virtual disks that are in whole-disk format, rather than single-partition format. This generally has no impact on the user, but if the disk has more than one partition it may be impossible to expand its size if both partitions are mounted.

Getting Started With Cloudmin

Recommended Systems

Techically you can run Cloudmin on just a single system, which will be both the master that runs the UI and the host for your virtual systems. However, a more common setup has multiple host systems, one of which is typically also the Cloudmin master on which the install script is run.

If you have a choice of operating systems and are planning to host Xen or OpenVZ instances, we recommend running the latest version of CentOS if possible. The CentOS YUM repository includes a kernel with Xen support and all the needed Xen tools. For more details on how to setup each host system, see the Xen documentation.

If you plan to host OpenVZ containers, a kernel for CentOS that supports them is available from the OpenVZ website. The same website has a kernel that can run both Xen and OpenVZ on the same host, which is fully supported by Cloudmin.

Regardless of the virtualization type you choose, your host systems should have plenty of RAM - a typical Xen instance will consume at least 512MB of RAM, while OpenVZ containers are usually assigned 256MB or more. For Xen hosts, we recommend 4-8 GB RAM and plenty of CPU cores. Running a 64-bit distribution is not generally needed for systems with less than 4GB of RAM, and can actually be counter-productive due to the increased RAM use.

SSH Key Configuration

Once Cloudmin is installed, the first thing you should do is add an SSH key that can be used to login to your host systems as root. The steps to do this are :

1. Go to Cloudmin Settings -> SSH Keys, and click on Add a new SSH key.
2. Fill in the Key description field, and enter the path to the private key file into the In existing file box, such as /root/.ssh/id_rsa
3. Change the Add to root's authorized keys field to Yes.
4. Click the Create button.

Alternately, you can have Cloudmin generate a new key or use one that you paste in on that same form.

DNS Configuration

Cloudmin adds all newly created virtual systems to a DNS zone hosted on the master system. If your company's domain is example.com, you might name this xen.example.com, and add an NS record to the example.com zone for this sub-domain.

To create this DNS zone on your Cloudmin master, do the following :

1. Go to Webmin -> Servers -> BIND DNS Server, and click on Create master zone.
2. Enter the name you chose into the Domain name field, such as xen.example.com.
3. In the Master server field, enter the externally resolvable name for your Cloudmin master system, such as cloudmin.example.com.
4. Enter your email addresss in the Email address field.
5. Click the Create button, then the Apply Configuration link in the top-right corner of the page.

Adding Host Systems

Before you can use a real system to host virtual systems (like Xen or OpenVZ containers), it must be added to Cloudmin. For a host other than the Cloudmin master, the steps to follow are :

1. Go to Add System -> Add physical system .
2. Fill in the Internet hostname field with the resolvable hostname or IP address of the machine.
3. Fill in the SSH login mode section, possibly selecting the key you added above.
4. If the system already has Webmin installed, fill in the Webmin login mode section.
5. Click the Add System button.
6. Assuming the details you entered were correct, the new system should appear on Cloudmin's left menu.
7. If the system doesn't have Webmin installed yet, select it from the left menu, then go to System Operations -> Install Webmin.

To enable this system for hosting virtual machines, you should first ensure that it has the kernel and tools installed for the virtualization type you are using. Then follow these steps :

1. Open the Host Systems category on the left menu, and click on the link for the VPS type that you want to host, such as Xen Host Systems.
2. Click the Register a system for Xen hosting link, and select it from the System hosting Xens menu.
3. In the IP address allocation range section, select an IP range that you defined earlier. Alternately, you can enter a starting and ending IP address to assign to Xen instances. This should be on the same subnet as the host system's primary network interface. This is typically supplied by your ISP or hosting company.
4. Select the DNS domain you created earlier from the Add Xen systems to DNS domain field.
5. If your host system has plenty of disk space, open the System image cache section and fill in the Maximum image cache size field. A cache of 5 to 10 GB is generally enough.
6. If your host system has LVM setup, we recommend using it for storing Xen disk image due to the performance benefits. Enter the volume group name in the LVM volume group field.
7. Finally, click the Register button.

If Cloudmin does not detect any problems with the host system, it can now be used to host new virtual instances.

Downloading Images

Cloudmin comes with pre-created images for creating virtual systems of all the supported types. However, they must be first downloaded to your master system before they can be used, as follows :

1. Go to Cloudmin Settings -> New System Images, and check the boxes next to the images you want.
2. Click the Download Selected Images button at the bottom of the page, and wait for the downloads to complete.

For each virtualization type (such as Xen and OpenVZ), images are available with CentOS and either Debian or Ubuntu Linux, plus possibly other distributions. For each Linux variant, an image containing just the base operating system is available, plus images containing Virtualmin GPL and Pro.

Creating Your First System

Once all the steps above are complete, you can create a new virtual system as follows :

1. Open the Create System menu category, and click on the link for the VPS type that you want to create.
2. Enter a short hostname for the new system in the System hostname field, such as myvps.
3. Select the image for the new system from the Initial system image menu.
4. Enter a root password in the SSH login mode field.
5. Optionally enter memory and disk limits in the Resource limit options section.
6. Click the Create System button.

How to use the Cloudmin documentation

Organization

Documentation is divided into a few categories, such as "Virtualization", "Installation", and "Administrative and User Accounts", which covers the common types of service you'll be managing with your Cloudmin installation. Within each category you'll find a few types of document, such as "FAQ", "Troubleshooting", and specific task guides.

Pages labeled "FAQ" or "Frequently Asked Questions" are intended primarily for common questions new users, or potential users, ask about Cloudmin and the machines it manages. For example, the FAQ for Xen includes a brief, non-technical, description of the Xen virtualization layer and how Cloudmin interacts with it. The FAQs are generally non-technical in nature, and do not generally provide solutions to problems. They are conceptual and broad, merely to describe the way Cloudmin does things.

Pages labeled "Troubleshooting" are intended to help you solve specific problems. If you are receiving an error message from a service or Cloudmin, the troubleshooting section for that particular area may have solutions. Troubleshooting pages are specific and technical, and are intended to help you solve problems.

Search

You can also search just the documentation by opening the search form and using the Advanced Search form to search within content "Only of the type(s)" and choosing "Book page".

The search page, by default, searches all of the content on Virtualmin.com, including forums, issues, and documentation. This may, or may not, be what you want, depending on the questions you have.

Installing Cloudmin

Cloudmin can be installed in a number of ways, including an automated install script which uses the standard package management features of your OS, and software repositories containing our software in native package formats. We strongly recommend that you use the automated install script to install Virtualmin, if at all possible.

Automated Cloudmin Installation - Installation of the full Cloudmin stack using our automated install script. This is the recommended way to install Cloudmin.

Manual Cloudmin Installation - Installation of Cloudmin and related packages manually. This is the method recommends for systems that are not currently supported by the automated install script.

Installation Troubleshooting - Troubleshooting common problems encountered during installation.

Uninstalling Cloudmin - Uninstallation of Cloudmin and selective removal of packages.

rpm -e webmin wbm-server-manager wbt-virtual-server-theme wbt-virtual-server-mobile wbm-security-updates
rm /etc/yum.repos.d/cloudmin

dpkg --remove webmin-server-manager webmin-virtual-server-theme webmin-virtual-server-mobile webmin-security-updates
grep -v cloudmin.virtualmin.com /etc/apt/sources.list >/etc/apt/sources.list.tmp && mv /etc/apt/sources.list.tmp /etc/apt/sources.list

Introduction to Virtualization Concepts

What is Virtualization?

In Cloudmin, virtualization refers to running a virtual system that appears from the inside to be a real computer, but is actually being emulated on a real machine. The terms "virtual machine" and "VPS" are also used to refer to these, as are type-specific terms like "Xen guest", "OpenVZ container" and "EC2 instance". There are several different technologies that can be used to implement virtualization, which varying support for different operating systems, resource isolation and resource overheads.

Why Use Virtualization?

The most common case is to provide customers or users with what appears to be their own system on which they have full root access and control of all services, but without the overhead of maintaining an actual physical machine. For example, a hosting company might sell virtual systems to customers which in turn use them for web hosting, database hosting or email.

A single physical machine can host multiple virtual systems, each of which is granted a slice of its memory, disk space and CPU time. Each virtual system is protected from others on the same host system. Because many applications or customers do not require the full CPU, RAM or disk capacity of a real systems, virtualization can be used to safely host several on a single physical system, thus saving resources.

Another advantage of Virtualization is the ability to easily move virtual systems between hosts without interruption or the need to re-install applications. If a hardware problem is detected on a host system, all virtual machines on it can be moved to a new host without changing their IP addresses or other settings, and possibly without even interrupting running processes.

Virtualization Types

Not all virtualization technologies are created equal - some (like Xen) provide more isolation between systems but at the cost of additional CPU and RAM overhead, while others (like OpenVZ) can be used to host more virtual systems per physical system, but with more chance of cross-system disruption.

Virtualization types can be generally separated into two categories :

• Separate Kernels Examples : Xen, KVM, Amazon EC2 These types run a separate kernel for each virtual system, and typically store system files within a disk image or logical volume instead of on the host system's filesystem. RAM used is higher due to the need to run a copy of the kernel for each system, and free disk space and RAM cannot be used by other systems. However they provide more protection and isolation between systems, allow different kernels to be used, and provide more flexibility in filesystem and disk usage within the virtual systems.

• Shared Kernel Examples : OpenVZ, LXC, Vservers, Solaris Zones These types run under the host system's kernel, which provides filesystem and process isolation between systems. Typically each system's files are stored under some directory on the host, possibly with common files like binaries being shared. They offer less isolation and force use of the same kernel, but the per-virtual-system RAM, CPU and disk overhead is lower. Also, RAM and disk space can potentially be over-committed to make better use of host system resources.

Which Virtualization Type to Use?

If you are running Solaris systems, you really only have one choice - Solaris Zones.

On Linux, your choice depends on the level of isolation you want and how much RAM and CPU overhead you are willing to tolerate. Given the ample CPU and RAM on most modern systems, we recommend using Xen as the overhead is usually tolerable unless you plan to run a large number of small virtual systems. In that case, OpenVZ is the best solution. KVM is similar to Xen in its resource use, but tends to have more overhead as it does not support paravirtualization.

Cloudmin also supports Linux Vservers, but this appears to be poorly maintained and offers no advantages over OpenVZ. As of Cloudmin 5.4, LXC is also supported on Linux. It has the advantage of being a standard part of recent Linux kernels, but lacks many features of OpenVZ such a live migration and disk space limits.

Amazon EC2 is different from other virtualization types in that the virtual systems don't actually run on your own machines - instead, they are hosted by Amazon for an hourly cost. It is worth using if your needs are highly variable, for example if you plan to run a hundred systems for a few hours a day then shut them down.

Location Groups

Introduction to Location Groups

A location group contains a set of host systems, typically in the same physical location. When a virtual system is created you can select a location group instead of a specific host, and Cloudmin will choose a host from that group based on some selection method. The selection may be random, or based on free memory or disk space.

Location groups are most useful when you have a large number of host systems in different locations, and want to avoid selecting an appropriate one manually for each new virtual system. It is quite possible to have just a single location group if all your host systems are in the same datacenter and treated equally for allocation purposes.

Creating a Location Group

To add a new location group, do the following :

1. Login to Cloudmin and go to Host Systems -> Location Groups.
2. In the first empty row check the box in the Active column.
3. Enter a name for the group in the Description column.
4. Select an allocation method from the Host selection method column. We recommend Most free RAM, as that is the resource likely to run out first.
5. Click the Save button.

Once a group has been created, you can assign a host system to it as follows :

1. Open the Host Systems category on the list menu and click on the link for your host system type, such as Xen.
2. Click on the host you want to assign.
3. Select the group from the Location group menu, then click Save.

Once at least one running host system is in a group, you will be able to select it on the Create System page.

Making Your Own Images

Images for Xen, VServers or Zones

Image Storage Locations

Images for EC2

# cloudmin modify-limits --host kvmioclass.home --ioclass 7
Setting IO class on KVM system kvmioclass.home to 7 ..
.. done

Creating Domains

IP Address Allocation

Finding Domains

Deleting and Disabling Domains

Moving Domains

Configuring Default Features

cd /tmp
wget --no-check-certificate "https://downloads.sourceforge.net/project/clamd-stream-cl/clamd-stream-client/1.3/clamd-stream-client-1.3.tar.gz"
tar xvzf clamd-stream-client-1.3.tar.gz
cd clamd-stream-client-1.3
make
./configure
make install

Setting up DNS

Registering a Xen Host