3.x to 4.2 without booting vms

[tapsa]

So official answer is that you cannot migrate from 3.x to 4.2 without booting vms. But how about unofficial? In our case it just does not have option to shut down each virtual. That reason at earlier upgrades we have made scripts what migrate computers from cluster to another cluster and from 2 to 3 series. Have someone already make script what allows make one direction migration from 3.x to 4.2 cluster?
Actually it is quite odd that same time when proxmox advertise them as HA system when they make updates what does not allow any kind live migration path. I understand that in some point you must drop compatibility to old version. But seriously, it is very poor design when there is no even one way upgrade migration tool what allows transfer vm from old cluster to new cluster without booting it. It does not give very enterprise feel of proxmox when you need hack your own tools to make upgrade without booting each vm.

 

[fireon]

Ok, good question. This time i think it is not possible. But what can you do for minimal downtime. If you have a cluster (with external storage) move the VM processes all to another clusternode. Then upgrade the first node. Copy only the VMconfigfiles to the upgradet node, check that your storage with the vm-images is online and connected. Shutdown the VMs on the old host, and start it immediately on the updated host. So have an minimum of downtime. Maybe some minutes.

 

[tapsa]

I dont believe to "not possible" it is always matter how much you need to code But what are things what make this incompatible? Is this underlying kvm incompatible to do memory migration or is it just scripts what are incompatible to request migration channel?

 

[spirit]

see my howto:

https://forum.proxmox.com/threads/howto-proxmox-3-4-4-2-upgrade-with-qemu-live-migration.27348/


(I have done it on multiple cluster)

 

[tapsa]

Spirit, Nice work, thank you. That was my point that is usual is just issue of will and effort. And again shame on you proxmox product coordinator that you put users to even think this kind things. It is not HA if you need reboot you virtuals at upgrade. This kind things define value of product. Product it self is great and I see that there had been huge effort to develop it. But it will waste that effort if customers need bunch of propel heads to consider how to migrate to it. Looks that again this had been resolved with relatively small script what allows migrate vm from cluster to another. I understand that is not fail proof but at least it works most of time.