Problem with cloning templates when using proxmox to sell virtual servers

[JohnDoes]

We are testing a couple of proxmox servers in a 2-server test cluster environment. Ultimately, we would like to be able to use proxmox as the back-end system to sell virtual servers through a billing system such as hostbill, which currently has a pretty advanced proxmox module.

The servers are named prox1 and prox2 and are in a cluster with the exact same RAM/storage configuration.

corosync.conf -> pastebin.com/DWL8k0Mk
.members -> pastebin.com/URHFqa5r
storage.conf -> pastebin.com/pnHGRp6p

We created a template which is stored on NFS mounted as prox-templates storage on both prox1 and prox2. The local LVM VG is "vservers" and is identical on both prox1 and prox2. We can clone the template (full clone) with no issues to the vservers storage on prox1. However, if we try to clone it to target node (prox2) and target storage (vservers) the resulting clone is shown as created on prox2 but when we inspect the storage the disk image is created on prox1 so the new VM cannot be started. If we make "vservers" not shared, then it doesn't even show up as target storage when we try the clone so that is not an option.

As a workaround, once a customer purchases a virtual server, we could just have the new VM created on prox1 and then simply migrate it to prox2, which we actually tried and it works as expected. The problem with this workaround, however, is when the customer decides to rebuild the VM with a fresh copy of the OS, he will not be able to accomplish this because the template and his VM are not on the same server.

Is proxmox not suitable for hosting companies, at least not with the process I described above? I don't understand why a template on prox1 cannot be cloned to another server (prox2). Is there something we are missing here?

Having a template on every server (both prox1 and prox2) is not an option because the billing system module only communicates with the master server (prox1) and lists the templates present on that server.

Please help.

Thanks.

JD

 

[JohnDoes]

Can anyone please help with this? Is this the right place to ask about this issue?
Thanks.
JD

 

[JohnDoes]

I just tried with the API/pvesh like this:

pve:/> create /nodes/prox1/qemu/203/clone --newid 225 --description test225 --full true --name test225name --storage vservers --target prox2

and the VM is created on prox2 but the LV disk is created on prox1, so obviously the VM cannot be started. Is this really an unsupported situation?

Thanks.

 

[wolfgang]

Hi,

if you mark the lvm storage ' vservers' as shared then PVE assume that it is the same storage as an iSCSI.
Set it as non shared.
If this does not work you must get an error.

 

[JohnDoes]

I changed 'vservers' to non-shared and tried again. I get this error now:

pve:/> create /nodes/prox1/qemu/203/clone --newid 226 --description test226 --full true --name test226name --storage vservers --target prox2
can't clone to non-shared storage 'vservers'

It looks like a catch 22, can't clone to non-shared storage, but if the storage is shared it can only write to the local 'vservers' on prox1, not on prox2. How can I clone (full clone) a template to another server (prox2) when using local storage?

Thanks.

 

[wolfgang]

The problem is your api call.
you have to call it on node 'prox2' not on 'prox1'

pve:/> create /nodes/prox2/qemu/203/clone --newid 226 --description test226 --full true --name test226name --storage vservers

 

[JohnDoes]

Thanks for your reply, however the template (203) is on prox1. Here's the output with the command you mentioned:

pve:/> create /nodes/prox2/qemu/203/clone --newid 226 --description test226 --full true --name test226name --storage vservers
unable to find configuration file for VM 203 - no such machine
proxy handler failed

 

[wolfgang]

Now I see.
the only way is to clone and then migrate or you can also create a second template on the other node what you use.

 

[JohnDoes]

Thanks for your reply. Unfortunately, this just confirms my fears that proxmox is not a suitable solution for webhosting automation for selling virtual servers. As I explained in my original post:

"The problem with this workaround, however, is when the customer decides to rebuild the VM with a fresh copy of the OS, he will not be able to accomplish this because the template and his VM are not on the same server."

If we clone then migrate, the customer will not be able to rebuild his VM with a fresh copy of the template. If we create a second template we will have two identical templates (for example Centos7) which will then have to show up as choices in the user interface when the customer decides which OS to install on his new VM, which I am sure will be confusing as there will be multiple Centos7 choices in the drop down combo box.

Is a solution to this issue possibly coming at a later date as a new feature or is this something your team is not even thinking about? It looks like for this scenario, proxmox would only work ok if the setup is using shared storage only, such as ceph, iscsi or nfs.

Thanks.

 

[Craig St George]

I solved this problem but only for VM in clone for VM API call there is a target
Lets say the template is on node1 and you want to create on node to the first API call must be to node one with the target set to node2

BUT it only works if your template is on shared storage and same with the created VM ( I assume I have not tested local on node2)
BUT when the template was not on shared storage it failed

I see LXC also has target in the API call
You can test if you can do it via the interface you can get it working on the API

 

[JohnDoes]

Thanks for your reply. Yes I am aware that it works with shared storage, however the goal here is to create the full clone on the other server on a local storage disk, and that does not work. The same thing does not work both through the web interface and through the API.