Distributing VMs with Proxmox

[scotthaskin]

I'm looking to make a virtual machine available to others that are using Proxmox (through the Proxmox GUI if possible). I'm looking to supply whatever is needed to generate a VM on a Proxmox system with minimal input needed from the user. I expect that will include a disk image (likely qcow2) and some set of file(s) describing the VM that Proxmox (GUI?) can use to generate the VM.

Any direction would be welcome.

We've done something similar for ESXi in the form of an OVA, so something like that, but Proxmox based would be nice.

 

[bbgeek17]

There is no direct Proxmox specific packaging equivalent to OVA, where one "archive" exists that contains both VM configuration and disk image.

You can file an enhancement request with your use case in https://bugzilla.proxmox.com.

For a better advice see comment #3 and #4. My apologies, I missed that option.

In the meantime, probably the best you can do is prepare a qcow image and accompany it with either strict specs for the VM (cpu, memory, settings) or a set of "qm" (or pvesh) commands as a script. This way user can just run those, including "disk import", and get a workable VM they can start as a result.

Good luck

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[LnxBil]

I expect that will include a disk image (likely qcow2) and some set of file(s) describing the VM that Proxmox (GUI?) can use to generate the VM.

Look at a backup file vzdump, which is exactly what you want: a tar file of the disk images and the PVE specifiy VM config file.

 

[fabian]

"VMA" (the file format "vzdump" produces when doing a backup up to a dir-style storage like dir,nfs,cifs,cephfs,..) is exactly that - an archive containing the raw disk image contents and the config files of the VM. it is PVE specific (requires our version of qemu to create and our tooling to consume), but it's fairly easy to write your own extractor for as well.

if this is not about distribution as in "public download", but just within your organization, then PBS should also work - a backup snapshot there also contains the contents of the disk images and the relevant config files.

 

[scotthaskin]

"VMA" (the file format "vzdump" produces when doing a backup up to a dir-style storage like dir,nfs,cifs,cephfs,..) is exactly that - an archive containing the raw disk image contents and the config files of the VM. it is PVE specific (requires our version of qemu to create and our tooling to consume), but it's fairly easy to write your own extractor for as well.

if this is not about distribution as in "public download", but just within your organization, then PBS should also work - a backup snapshot there also contains the contents of the disk images and the relevant config files.

Thanks, a VMA seems like a good starting point.

Since this is about a "public download", I'm wondering about changing the network name, and any other similar VM configuration information. It seems like that would need to be done after the restore. Or is there something that can/does prompt for something like network name during the restore of a VM?

 

[LnxBil]

Or is there something that can/does prompt for something like network name during the restore of a VM?

You can use the vma to create a new VM and have all the options available there. Please refer to the qm manpage.

 

[ness1602]

in our company we still only distribute OVA file, and ISO autoinstall file(both are public download). As for the networking,we leave it at dhcp and guide customers to setting up static IP.
OVA is for now let's say all-pervasive so it is easier to distribute just that one file for everyone to use.

 

[LnxBil]

OVA is for now let's say all-pervasive so it is easier to distribute just that one file for everyone to use.

We are in the same boat and provide VMs for various platforms. We dismissed the 'one VM and OVA for all', because you still need to integrate guest tools for every hypervisor out there for best interoperability, which cannot be installed concurrently. We now use the export from every hypervisor to get the best working appliance. Luckily, Hyper-V, VMware, VirtualBox and KVM/Qemu, XEN are directly integrated in most Linux distributions, yet e.g. Nutanix needs special attention. A shame that they are so backwards despite their "new and shiny technology" image.

 

[scotthaskin]

"qm" is a nice tool, but the need to basically write customers a tutorial on how to use it is less than ideal.

To this end I'm working with "makeself" with a script that will do the heavy lifting for the customer. If I can pull it off all the "qm" magic will happen without the customer knowing about it.

An additional benefit for us with the "makeself" approach is that we can just use a qcow2 disk image and don't need to use the VMA (as all the VM parameters can be set with "qm").

Still less than ideal, but likely workable and can be modified for Linux hypervisor platforms that don't have the "qm" utility installed.

The biggest issue with this approach is the need for the customer to scp and ssh to achieve it.