Hi,
I collected some quick questions regarding storing containers on some kind of shared storage.
Oddly enough information about this topic is usually very much outdated (as in: for 1.x).
1.) Most importantly: Does proxmox offer any kind of live migration for openvz containers that does NOT need to rsync the disk content via network (meaning: uses some sort of shared storage)? The way I understand it proxmox/openvz would still use rsync even if some sort of shared storage was used for openvz?
2.) I can see that the openvz live migration process deletes the container's files on the node1 when migrating node1->node2. Would it be possible/reasonable to have an optional switch somewhere that would result in those files STAYING on the node? If you did that, the migration BACK (node2->node1) would be faster because rsync only needs to transfer files with a different "last modified" timestamp.
I understand that this would be a trade-off: you'd save migration time at the cost of more required storage space.
HOWEVER: Considering that you need to be able to migrate the container back anyway, the storage on node1 needs to have enough space anyway. Yes, theres a difference between needing to keeping X amount of space free and constantly occupying X amount of space with old data, but wouldnt this be a good idea?
I collected some quick questions regarding storing containers on some kind of shared storage.
Oddly enough information about this topic is usually very much outdated (as in: for 1.x).
1.) Most importantly: Does proxmox offer any kind of live migration for openvz containers that does NOT need to rsync the disk content via network (meaning: uses some sort of shared storage)? The way I understand it proxmox/openvz would still use rsync even if some sort of shared storage was used for openvz?
2.) I can see that the openvz live migration process deletes the container's files on the node1 when migrating node1->node2. Would it be possible/reasonable to have an optional switch somewhere that would result in those files STAYING on the node? If you did that, the migration BACK (node2->node1) would be faster because rsync only needs to transfer files with a different "last modified" timestamp.
I understand that this would be a trade-off: you'd save migration time at the cost of more required storage space.
HOWEVER: Considering that you need to be able to migrate the container back anyway, the storage on node1 needs to have enough space anyway. Yes, theres a difference between needing to keeping X amount of space free and constantly occupying X amount of space with old data, but wouldnt this be a good idea?