[PVE-User] migrate *just* config of VM between unclustered PVE servers?

[Thomas Lamprecht]

On 3/8/18 7:23 PM, Alexis Huxley wrote:
> I'm currently using KVM and libvirt with two *unclustered* servers and
> shared storage [*], but am considering migrating to Proxmox because
> I want to switch to lighter weight containers.
> 
> At the moment, with libvirt, on the first server I create a VM and
> run 'virsh dumpxml <vmname>', copy the resulting XML over to the
> second server (or write it to the shared storage) and run 'virsh
> define <xmlfile>' and then the VM is available on both servers.
> I then manually start the VM on one server only.
> 
> What is the equivalent procedure for Proxmox? (Ideally a procedure
> that works for both KVM-based VMs and containers.)
> 

With Proxmox VE already have all config files in plaintext under /etc/pve
node local VMs: /etc/pve/qemu-server
node local CTs: /etc/pve/lxc

For specific nodes the same directories can be found under:
/etc/pve/nodes/NODENAME/
(the two above are actually just magic symlinks to the local latter)

You can copy just those if you wish, if the storage names are the
same on both names you should be able to just start it then.

> I was hoping that vzdump might have a '--config-only' option and
> that there would be a 'vzload' command, but I don't find either
> of these things. Googling turns up plenty of results for migrating
> the entire VM, but I really want *only* the config, not the image /
> container tree.
> 

FYI, our CLI tools can output also the configuration via:

qm config VMID
pct config VMID

> If it's as simple as rsyncing over some directories, then is it then
> necessary to 'nudge' the GUI, to get it to notice the changes?
> 

No, once a VMID.conf gets added to the qemu-server or lxc directory,
respectively, the are known to PVE and can be directly used.
It may take a few seconds until it pops up in the webUI.

See: https://pve.proxmox.com/pve-docs/chapter-pmxcfs.html
for a bit more info about our configuration file system.

cheers,
Thomas

> Thanks!
> 
> Alexis
> 
> [*] The shared storage is DRBD running in primary/primary mode with
>     OCFS2 filesystem on top. It's obviously not immune to split brain,
>     but recovery is straightforward and very rare. It's been quite
>     suitable for home, but IO is relatively slow.