SO what is the REAL compatibility of Cloudmin GPL with the various Distros?

19 posts / 0 new
Last post
#1 Sat, 08/11/2012 - 04:07

SO what is the REAL compatibility of Cloudmin GPL with the various Distros?

I am very confused here.

The Cloudmin documentation page ( ) mentions that Cloudmin GPL for KVM is compatible with CentOS, Fedora, Debian and Ubuntu.

Text from website:

"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"

HOWEVER, the installer for Cloudmin GPL for KVM when you run it, it says:

"Operating systems supported by this installer are:

Fedora Core 3-12 on i386 and x86_64 CentOS and RHEL 3-5 on i386 and x86_64

If your OS is not listed above, this script will fail (and attempting to run it on an unsupported OS is not recommended"

So what's the truth? To be more specific:

A) Will Cloudmin GPL for KVM run on Centos 5.8 ? B) Will Cloudmin GPL for KVM run on Centos 6.x ? C) Will Cloudmin GPL for KVM run on Ubuntu 12.04 ?

Please advise!

Sat, 08/11/2012 - 09:55


Yeah, the specific VPS support can get a little confusing due to what's supported by the individual Linux distros -- that's definitely an area the documentation can be improved in. I've put that on my todo list.

Here's the rundown --

CentOS 5 supports Xen.

CentOS 5.4 and later support KVM, but only when using 64 bit.

CentOS 6 only supports KVM.

Ubuntu 12.04 supports KVM (and Xen, I think).

I hope that helps!


Sat, 08/11/2012 - 18:10

Well not really... it didn't help because it didn't answer the question which was about Cloudmin and Distros. Not virtualization platforms and distros.

For example, (from my experience & from what others say) Cloudmin GPL IS NOT ready for the 12.04 version of Ubuntu Link:

Also I can't remember if it is compatible with the combination Centos 6 + cloudmin Gpl KVM as I did so many installs within one day and I have forgotten the details. I think this combination resulted in the server been not responsive after the installation of the script and the initial reboot.

Centos 5.8 though 'seems' to support XEN and I say seems because I still haven't managed to get the networking side working:


Sun, 08/12/2012 - 14:49


What I described above are combinations of Linux platforms and virtualization technologies that Cloudmin runs on.

Essentially, Cloudmin GPL supports KVM and Xen -- and should run on CentOS, Ubuntu, and Debian -- when those distros support KVM and/or Xen.

There are indeed some reports of folks who had trouble installing Cloudmin on Ubuntu 12.04 -- I've been requesting someone file a bug report about that, but no one has yet :-)

For example, I responded to your post about that here:

If you file a bug report we can work on getting that fixed :-)

I don't know the cause of the CentOS issues you're describing, though I haven't heard any other reports of them.


Sun, 08/12/2012 - 21:55

Just a heads up -- I asked Jamie if he could comment on your question regarding Cloudmin setup on CentOS 5 -- I gave him the link to your post on that... we should hear from him soon regarding that.


Tue, 08/14/2012 - 00:54
Joe's picture

Sounds like there's some old copypasta from the Virtualmin installer that shouldn't be in the Cloudmin installer. The supported OS list doesn't represent current reality at all. I'll have to look into that.

But, CentOS 6 is the recommended CentOS version for KVM with Cloudmin GPL. Ignore that supported OS's just wrong, and we'll get it fixed soon.

If you were using Xen, you'd probably want to stick with CentOS 5. But, for KVM, the obvious choice is 6.


Check out the forum guidelines!

Wed, 01/23/2013 - 17:42

Here are some of the Ubuntu 12 changes required for the install script.

libdigest-sha1-perl has been deprecated as per

Old line: apt-get install -y libdigest-sha1-perl

New line: apt-get install -y libdigest-sha-perl || apt-get install -y libdigest-sha1-perl

Seems it could also need some code changes to change Digest::SHA1 calls to Digest::SHA. Read the bug-report above.

Hypervisor version (this is technically not as required since the "xen-hypervisor" fallback installs the appropriate package).

Old: apt-get -y install xen-hypervisor-3.2-1-$arch || apt-get -y install xen-hypervisor-3.2 || apt-get -y install xen-hypervisor-4.0-$arch || apt-get -y install xen-hypervisor

Fixed: apt-get -y install xen-hypervisor-4.1-$arch || xen-hypervisor-3.2-1-$arch || apt-get -y install xen-hypervisor-3.2 || apt-get -y install xen-hypervisor-4.0-$arch || apt-get -y install xen-hypervisor

As seen here:

These are just two things I have found now. I am about to install Cloudmin+Xen on Ubuntu 12.

Here's another thing: Ubuntu has built-in kernel support for Xen since Ubuntu 11 (see No need to install an alternative kernel package.

I think this is the line that attempts to install an alternative Xen kernel: apt-get -y install apt-cache search 'ubuntu-xen-server|xen-linux-system' | awk '{ print $1 }' | tail -1

Luckily(?) both of those packages are missing in the Quantal repos so it doesn't overwrite the pristine, Xen-ready 3.5.x kernel on the system you're running the install script on. There is no more linux-xen (kernel) package in Ubuntu 12 (see - it's missing).

However, those two now-missing packages installed a lot of dependencies, and you must be sure that your script manually installs anything that you relied on them for.

Wed, 01/23/2013 - 17:40

Also, there are lots of updated packages. Your installation script does things like: apt-get -y install xen-utils-3.2 || apt-get -y install xen-utils-4.0 || apt-get -y install xen-utils

The latest version is

Luckily the xen-utils fallback covers that. But there are lots of cases like that in your install script.

When updating your script, look at to check for existence of each package you are trying to install. Alternatively go to and modify the search-term to find the appropriate package names.

Wed, 01/23/2013 - 19:08

Found another issue, which is that "/usr/share/webmin/server-manager/" outputs "GRUB v1 not found on this system!" on Grub2 systems.

If your system runs Grub v2, do this:

cat /boot/grub/grub.cfg | grep -i "^menuentry.*Xen"

This should output a line such as these:

  • menuentry 'Ubuntu GNU/Linux, with Xen hypervisor'

  • menuentry 'LinuxMint GNU/Linux, with Xen hypervisor' (the popular Ubuntu derivative)

When you have the name, edit the Grub defaults as appropriate (using Ubuntu example below) to automatically boot into it:

sudo sed -i 's/GRUB_DEFAULT=.*+/GRUB_DEFAULT="Ubuntu GNU\/Linux, with Xen hypervisor"/' /etc/default/grub

sudo update-grub

Note the "GNU\/Linux" above to avoid the slash being interpreted as the end of the sed command. This is important!

Would be very good if the installation scripts could support Grub2 natively.

Wed, 01/23/2013 - 19:44

Finally, remember that Xend/XM are on their way to being deprecated as of Xen 4.2 and replaced with

Cloudmin will have to be capable of using XL instead.

XM will continue to work for the foreseeable future, but the default toolset as of Xen 4.2 is XL.

To switch toolsets, edit /etc/default/xen.

Wed, 01/23/2013 - 20:02

Alright, network bridging is also incomplete out of the box. Cloudmin will complain that "This system cannot be a Xen host : No network bridges were found on the system. Perhaps the Xen global configuration is missing the (network-script network-bridge) line. Virtual systems cannot be created or added until this is fixed."

There are several different methods of solving this:

Method 1 (single bridge)

  • By default, /etc/xen/xend-config.sxp contains the line "(vif-script vif-bridge)" which means that it automatically searches for the first available bridge device.
  • So define a bridge device by editing /etc/network/interfaces as follows:
auto lo
iface lo inet loopback

auto xenbr0
iface xenbr0 inet dhcp
    bridge_ports eth0

auto eth0
iface eth0 inet manual

Method 2 (multiple bridges)

  • If you have created more than one bridge in your /etc/network/interfaces and want to use a specific one, you must edit /etc/xen/xend-config.sxp as follows:
  • Comment out the "(vif-script gif-bridge)" line to disable it.
  • Add a line saying the following (replace the NAMEHERE with the name of your bridge such as xenbr1):

(network-script 'network-bridge bridge=NAMEHERE')

Method 3 (automatic bridge creation, not recommended)

  • For this to work, edit /etc/xen/xend-config.sxp as follows:
  • Comment out the "(vif-script gif-bridge)" line to disable it.
  • Add a line saying the following (replace eth0 with the name of the network device you want to hook into):

(network-script 'network-bridge netdev=eth0')

Would be nice if Cloudmin added support for doing one of theese automatically during either installation or from the web UI. Or at least explained it, because it's not mentioned anywhere in the documentation.

Thu, 01/24/2013 - 16:35 (Reply to #11)

Normally xend will create the xenbr0 bridge on startup, or setup eth0 as a bridge. Is that not happening on Ubuntu in a default Xen install?

If this is Xen 4, it should be using eth0 as a bridge, which Cloudmin is supposed to detect. You can check this with brctl show to list active bridges..


Fri, 01/25/2013 - 13:17 (Reply to #12)

Apologies for the delay in my reply.

Xen 4.1 on Ubuntu 12 does not create a bridge in /etc/network/interfaces. That must be done manually and is mentioned on their installation pages as well:

The /etc/xen/xend-config.sxp file contains the line "(vif-script vif-bridge)" which means that it automatically searches for the first-found bridge device.

The xen-hypervisor-4.1 package is what contains xend, and the entire build log as well as custom Ubuntu patches can be seen here:

For a full list of what patches Ubuntu has made to the Xend core, see the patches folder inside this file:

They do not seem to have applied any patches that would modify whether or not a bridge is automatically created.

The next thing to check would be their build logs, which shows the exact method by which they configured and built xend, available at:

Reading their logs, I don't see any suggestion that they've disabled bridge-creation.

In short: Xen 4.x doesn't create any bridge BY DEFAULT. It's not Ubuntu-behavior. It's Xen-behavior. If Xen used to do it in the past, it sure doesn't do it anymore. The new default is to search for the first-available bridge, the creation of which is left up to the user.

This is corroborated if you go to and in particular:

So yes, you need to update the Cloudmin documentation, telling people to create a bridge device BEFORE running the cloudmin install script (alternatively, write a script that looks for bridges, and if none are found, performs one of the 3 bridge creation methods I wrote about in the above post). Also, be ready to switch to using XL instead of XM, since it's now the default toolset as of Xen 4.2. My 4.1 installation still uses XM, so dual support will be needed since not everyone will be on 4.2. Making cloudmin automatically select the appropriate tool based on what's active on the system should be on the agenda.

Oh, and I named my manually created bridge xenbr0, which Cloudmin detects and uses just fine, so it's good to see that you're obviously not using hardcoded/expected bridge names. xenbr0 is a common name, as is br0. eth0 is just a common legacy name for autocreated bridges, and is an insane misnomer. ;-)

Thu, 01/24/2013 - 00:26

There's one final thing that has to be done.

Xen 4 expects the keymaps for qemu to be located in /usr/share/qemu/keymaps, but on the latest Ubuntu/Mint, they are under /usr/share/qemu-linaro/qemu.

If this isn't fixed, the VM will not be bootable, and will show an "error: domain 'vm-name-here' does not exist" and /var/log/xen/qemu-dm-vmnamehere.log will say "Could not read keymap file: '/usr/share/qemu/keymaps/en-us'"

Citrix (Xen) has already patched this in the latest dev branch, but it's going to be a long time until that's in a final release (

The fix is to create a symlink. This should be done by your install-script, if detects the /usr/share/qemu-linaro/qemu path and no /usr/share/qemu path.

ln -s /usr/share/qemu-linaro/qemu /usr/share/qemu

That's it. If the devs follow all of my posts in this topic, they will have Ubuntu 12 and Linux Mint 14 compatibility for the installer script.


Thu, 01/24/2013 - 02:17

There's also a bug in Cloudmin with regards to creating a VM with a static IP that just took me 4 hours to find.

When you create a new system, you have these options:

  • "IP address for Xen instance" which can be either "Assign automatically" (DHCP) or "Address" (statically defined)
  • "Default gateway" which can be either "From host system" (DHCP)" or "IP address" (statically defined)

The problem is that they are independent radio buttons, so my setup was as follows:

  • "IP address for Xen instance: Address:"
  • "Default gateway: From host system"

I assumed that since they were independent settings, it would give me the static IP AND take the default gateway (from my "Xen Host Settings" IP range's "default gateway" setting, or maybe even from the running host system with a trick like route -n | grep 'UG[ \t]' | awk '{print $2}')

Well, "route -n" in the guest constantly confirmed that I was not getting the gateway routing.

The only thing that worked was setting BOTH a static IP and static gateway when creating the VM.

This needs to be extremely clearly explained in the documentation/context sensitive help. Or better yet: Tie the static IP/static gateway options together so that they are one option as follows:

  • DHCP: Enabled (automatically assign an IP address and Gateway from the "Xen Host Settings")
  • DHCP: Disabled (enables text-entry boxes for IP address and Gateway for precise control, and make sure that the Gateway box and IP address boxes pre-fill using suggested values from "Xen Host Settings" so that people don't have to go look up the correct gateway)

I just lost 4 hours of my life figuring this out. Argh...

Thu, 01/24/2013 - 09:20

Thanks for all your comments... I've asked Jamie if he could take a look. I suspect you'll hear from him shortly :-)


Fri, 01/25/2013 - 13:18 (Reply to #16)

I saw that nobody else had stepped up to aid you with platform-specific issues, and am just glad to help bring Ubuntu 12/Linux Mint 14 support to Cloudmin.

The trickiest bit is supporting the GRUB2-bootloader and choosing the correct default menu option, which uses different names for the Xen boot option on Ubuntu and Mint, but I've listed both above as well as the method of writing the new default choice to the system.

At worst, selecting the correct kernel in the bootloader might have to be left up to the end-user as a manual step mentioned in the docs, if it can't be reliably automated. ;-)

Mon, 07/15/2013 - 03:28

CentOS 6.x doesn't have a /etc/networks/interfaces file, or even a /etc/networks folder.

Which file do I need to edit in order to get the bridge working on CentOS 6.x?

Mon, 07/15/2013 - 06:10 (Reply to #18)

The relevant files are in the /etc/sysconfig/network-scripts directory, such as ifcfg-eth0 and ifcfg-br0 . For more details on bridge setup, see


Topic locked