I use "dir" type
if you want short downtime, use shared storage (then the downtime is essentially the time it takes for your container to reboot)
Then it won't be quick, as you don't have a shared storage format.
But that was described is not online, it's an offline migration. If you really need online, just go with KVM/QEMU
I would use local and shared storage combined in your case.
Critical VM's run on shared storage and non critical on local dir.
What I wanted to say is : I don't want to see all my VM encountering difficulties (critical and not critical VM) if the shared storage has problems (bad sectors, raid rebuild, etc). That's why I prefer a not shared storage.
I'm just surprise that I cannot use "live" migration with short downtime (shutdown, reboot).
If I use gui interface to do migration, the "restart mode" is checked and it shutdown the CT before to start copying. So long downtime if big disk.
If I uncheck 'restart mode', I've got erreor message : "can't migrate running container without --online or --restart (500)"
So migration is impossible for big CT if no shared storage ?
Sure that shared network storage like ceph, glusterfs, etc. can have problems, but local storage can have them too!What I wanted to say is : I don't want to see all my VM encountering difficulties (critical and not critical VM) if the shared storage has problems (bad sectors, raid rebuild, etc). That's why I prefer a not shared storage.
I'm just surprise that I cannot use "live" migration with short downtime (shutdown, reboot).
If I use gui interface to do migration, the "restart mode" is checked and it shutdown the CT before to start copying. So long downtime if big disk.
If I uncheck 'restart mode', I've got erreor message : "can't migrate running container without --online or --restart (500)"
So migration is impossible for big CT if no shared storage ?
Fabian - two-phase short-downtime migration for containers is planed ir Proxmox 5.0?
If the cluster hosts 100 CT in 10 nodes of 10CT with local storage, I have 10 CT down if problem happens with 1 storage. Instead of 100 CT. That's my choice.Sure that shared network storage like ceph, glusterfs, etc. can have problems, but local storage can have them too!
I upgraded from 3.4 to 4.4 with hope this would be operational yet. I'm a bit disappointed by proxmox 4.4. I recently discovered too that it's impossible to reduce disk size of CT. That was possible with Proxmox 3...You should understand, that it takes time to copy data from one cluster members local storage to other.
Fabian - two-phase short-downtime migration for containers is planed ir Proxmox 5.0?
If the cluster hosts 100 CT in 10 nodes of 10CT with local storage, I have 10 CT down if problem happens with 1 storage. Instead of 100 CT. That's my choice.
Online migration for containers is not possible, you need to use the "restart" mode. As long as you have your data on shared storage, this works in a few seconds.