Integration with APIs

[Alessandro 123]

I have a project where I need to integrate ProxMox (a cluster made with 4 or 5 servers) with an external cloud management platform.

Some questions:
a) is possible, through api, to spawn up and down some new VMs based on a golden image? These VMs must use the golden image as base and "copied" to the node's local disks. Any example or docs about this?

b) as I have some services that are redundant by their nature (like mail MXs, DNS, ....) how can I ensure that these VMs are never executed on the same node? In example: dns1 and dns2 must always executed on different nodes, and never on the same. Only in case just one node is available, both VMs should be run toghether. These VMs must be stored on a GlusterFS by using libgfapi

c) is possible to set some VMs as not "redundant"? In example, all VMs created by software in step "a" must die if the node die. All VMs created in step "b" (i create them manually) must be protected and moved across the whole cluster.

d) We are using Gluster for both golden image hosting (standard fuse mount to read from) and shared image hosting. Gluster seems to be supported in ProxMox, but is possible to use the libgfapi for VMs and not the FUSE mount? Direct access by qemu through libgfapi is faster then fuse.

 

[Alessandro 123]

bump

 

[tom]

bump

Start reading the docs on http://pve.proxmox.com/wiki/Main_Page

And use the search function of the forum.

If there is still something unclear, post your question.

 

[Alessandro 123]

I've posted some questions because it unclear from the docs or from the forum, like questions "b", "c" and "d"

 

[cadbury]

All of what you want to do is possible but it involves you writing the code to handle it. The API exposes all the necessary functions to achieve your result.

 

[Alessandro 123]

So, currently, proxmox (through the web interface) doesn't allow to do nothing of the requested features ?

 

[cadbury]

Part C can be achieved by marking some of the VMs as HA. If the node dies, as long as their storage is shared across all nodes, they'll automatically (I think) be restarted somewhere else. Any non-HA VMs will remain offline.

However, you cannot mark VM A as being unable to run on Host A. For things like DNS, it would probably be better to have each node running its own DNS VM. As long as 1 node is online, there is DNS.

 

[Alessandro 123]

For some services like DNS i can disable HA on the VMs but for other services i can't as one offline vm will cause traffic loss (in example, a service with a round robin DNS, if one of the VM is down, some traffic is loss)

 

[kotakomputer]

a) is possible, through api, to spawn up and down some new VMs based on a golden image? These VMs must use the golden image as base and "copied" to the node's local disks. Any example or docs about this?

Yes possible. Just copy the image to local disks then use API to create, suspend or destroy any VM.

b) as I have some services that are redundant by their nature (like mail MXs, DNS, ....) how can I ensure that these VMs are never executed on the same node? In example: dns1 and dns2 must always executed on different nodes, and never on the same. Only in case just one node is available, both VMs should be run toghether. These VMs must be stored on a GlusterFS by using libgfapi

VM with same ID is not possible in SAME NODE, so never created./executed too.

c) is possible to set some VMs as not "redundant"? In example, all VMs created by software in step "a" must die if the node die. All VMs created in step "b" (i create them manually) must be protected and moved across the whole cluster.

If a node die then all VMs inside death node will die too.

d) We are using Gluster for both golden image hosting (standard fuse mount to read from) and shared image hosting. Gluster seems to be supported in ProxMox, but is possible to use the libgfapi for VMs and not the FUSE mount? Direct access by qemu through libgfapi is faster then fuse.

The fastest and save approach is copy your GOLDEN image to local disk (at each node). Because when disaster happen to your SHARED image hosing and/or network to that hosting you still able to create new VM use local image.

 

[Alessandro 123]

having to copy (manually) the golden image to each node from a shared storage makes the shared storage totally useless