pre-sales questions on Cloudmin


We are users of Virtualmin Pro and GPL, over VMWare Server 2.

We are planning to buy Cloudmin Pro 10 to use with KVM and would like to check if our expectancy is right.


  1. Is setting up KVM virtualization in CentOS 64bits a matter of running the Cloudmin installer with no extra complications?

  2. Can we then run Virtual Ubuntu (32 an 64 bits) and Windows (desktop or server editions, 32 and 64 bits) without any complications?

  3. Can we create 2 different network interfaces on the VMs, each one bound to a different host interface?

  4. Can we copy the VMs created on Cloudmin across diferente Cloudmin servers (between GPL and Pro and vice versa?)

  5. Are snapshots supported?

  6. Does the Portuguese keyboard layout work on the console?

  7. Does anything at all stop working if the license is not renewed on time?

  8. Is there anything else we should worry about?

Thank you very much.

Best regards Gustavo Homem

Closed (fixed)


  1. If you have separate KVM host systems, you will need to install the KVM tools on them as documented on

  2. Yes, you can mix 32 and 64-bit VMs.

  3. Yes, that is possible - see the doc at

  4. You can move VMs between host systems. This doesn't require multiple Cloudmin installs .. a single Cloudmin pro master can manage multiple hosts, which only need to run Webmin.

  5. Can you explain further what you mean here?

  6. Yes, this should work. You can select in Cloudmin the keyboard layout to use for a VM console.

  7. No, you will just get a warning when you login.

  8. Hard to say :-)


Quick comments.

  1. It is one instance of Cloudmin for one physical host. Do we need a manual KVM configuration or does the Cloudmin installer do everything?

  2. But are Ubuntu 12.04 and Windows (say 2003 and 2008) known-to-work scenarios?

  3. OK

  4. I mean exporting at a filesystem level to a portable HD (copying the VM directory...) and importing back to another Cloudmin host, not hot moving VMs that are running. Is it possible?

  5. The question is if there is an interface to perform snapshots (saving of a certain VM state to which we can revert later) implemented and if it is known to work with KVM

  6. OK

  7. OK

  1. The Cloudmin installer doesn't setup KVM for you, so you would need to do that manually on the systems that will host VMs. The reason is that the installer can be run on a separate system from the machines that will actually run VMs.

  2. Yes, they will work fine. However, Cloudmin's ability to manage a Windows VM is limited compared to what it can do with Ubuntu or other Linux, as it cannot run commands via SSH or access files inside the filesystem. This means you are restricted to operations like starting up, shutting down, resizing disks, etc.

  3. VM filesystems are just stored in files (by default), so they can be easily copied to other locations when the VM is down.

  4. This can be done in Cloudmin by creating an image of a VM.

Thank you for the comments Jamie. I will order and start testing.


Automatically closed -- issue fixed for 2 weeks with no activity.

Regarding 4) is it enough to copy the .img file?

For each VM i have:

hostname.domain.img hostname.domain.console hostname.domain.monitor hostname.domain-eth0.tap

I would which files I need to copy an existing machine to another host.

To get the filesystem contents, you would only need to copy the .img file. However, this won't include meta-data like memory size, CPU allocated and so on - because KVM unfortunately does not store that in any config file.

A better option is to create an image of the VM (at System Operations -> Create Image), copy the image files from under /var/webmin/server-manager to the new Cloudmin master, and then create a new VM from that image.

I just did that and all that is created is a 335 bytes text file with an img extension. There is no abnormal output on the web interface.

Creating temporary directory for image files .. .. done

Checking filesystem on first disk .. .. no errors found

Mounting KVM instance filesystem .. .. mounted on /mnt/kvm-pdc.domain.intranet

Resetting root password .. .. done

Clearing log and history files .. .. done

Removing authorized SSH keys .. .. done

Un-mounting KVM instance filesystem .. .. done

Compressing filesystem image .................................................................................. ..............................................................

Fetching image files from host .. .. done

Deleting compressed filesystem image .. .. done

Mounting KVM instance filesystem .. .. mounted on /mnt/kvm-pdc.domain.intranet

Undoing license and password changes .. .. done

Un-mounting KVM instance filesystem .. .. done

There should be an ext3.gz file as well, right?

There should be another file in the /var/webmin/server-manager directory with the same prefix as the .img file.

But the file is not there. I created the image twice with two different names, just to be sure.

On my system /var/webmin/server-manager is symlink to /home/server-manager. This is per your advice and is needed since we never have space on the /var partition on our standard partitioning scheme.

Can you advise?

Could you post the contents of the .img file? It should at least tell us where the data files are stored.

Here is the content:

desc=IPBrick template com updates at� ao 10, passwords alteradas e rede

Ok, I think I see the issue now. The problem is that Cloudmin was unable to create a compressed image of the filesystem, but due to an unrelated bug it didn't display any error message about that during the image creation process.

Does the directory /var/webmin/server-manager have enough disk space to store a gzipped copy of the system's first disk?

Yes, there is enough space. It is linked to a big partition (/home).

You might want to wait a day or two for Cloudmin 7.0 to be released, which will at least display an error explaining why the image creation failed.

FYI, the 7.0 release is out now. Please try deleting this image, and then re-creating it.

After updating to 7.0 and deleting existing image trials, I get this while creating a new image:

Compressing filesystem image .. .. failed :

gzip: stdout: No space left on device

But there is lots of space:

[root@terminalserver01 server-manager]# pwd /home/virtual/server-manager [root@terminalserver01 server-manager]# df -h |grep home /dev/sda7 426G 79G 325G 20% /home [root@terminalserver01 server-manager]#

Is it possible that within the last operation Cloudmin might have actually reset the root password of the live machine? I can't seem to "su" anymore.

I think Cloudmin is trying to create the images temporarily at /tmp/.webmin. We don't have enough space on the /tmp partition.

Yes, that's the default directory for temp files. To change this, login to Webmin on the host system at go to Webmin -> Webmin Configuration -> Advanced Options.

Do you know about the root password reset? (see above). I'm stuck with a debian manual install that seems to have lost the root password, and the vnc console doesn't seem to work during boot to go to runlevel 1.

The image creation process will temporarily reset the root password, but should but it back again after the process completes.

If you can't login as root, one solution is to shut down the VM and then use the Change Password link to change the root password. Cloudmin does this by editing the /etc/shadow file inside the VM disk image.

But that only works for VMs that are created from virtualmin images, right? The option is not available for a manually created debian VM. Can you confirm?

Also, how is the clone process handling errors? Perhaps it is stopping and not reverting the original VM to its previous state?

The password change will work for any VM that has the root filesystem on a regular partition (ie. not in an LVM volume group or RAID).

This is all I can see in the "Change password" option for that VM. It can only change the password Cloudmin uses to access it, not the internal password itself.

That is different from what is available on the VMs I created from Cloudmin images.

But I am much more worried about the reset password not being undone on error conditions during the conversion of VMs to images, and about not being able to make images from VMs..

Note: This virtual machine doesn't have RAID and its fstab shows UUIDs. I don't think the fs uses LVM.

Did you shut down the VM before trying to change the password? The function on the Change Password page are different when it is down, as Cloudmin can change the password even if it doesn't know the current password.

No, I tried it with the machine running. I can try it later, as it know is under testing.

I need you to look at the machine creation process. Right now this system is in pre-production and soon will be in production and we shouldn't be unable to make an image from a live VM.

I apologize if we are pressuring your support too much over single purchase.

We intend to purchase another copy during the next weeks, and hopefully several others this year.

UPDATE: I tried to change the password with the machine down and the available options don't change. What is seen in the previous screenshot is what we get...

Summary of issues that are causing most problems so far:

Unability to create image from existing VM + password restore on image creation error conditions (documented on this ticket)

VM Creation GUI needs "in place" validation

Constantly changing MAC address for manually created VM

(tomorrow I'll have this one triple checked to see if there is really no MAC colision on our side)

Create 64bits templates (we want to standardize on x64 and drop i686 - your template system is great)

The remaining issues are more wishlist, than problems at the moment.

Thank you very much Gustavo

Ok, I think I see the issue - you have the "Do not attempt SSH login" option selected.

Try changing that to "Using password" and entering the password you want to use, then click "Save". Then return to the form again, and you should have the option to change the actual root password.

I will test this on the next machine, since the current one is in almost-production state.

I think we have enough information here, including answers to the initial questions. I will close this issue.