26
edits
Changes
→Other issues
Because of this matters, this issue I had put in his moment off until new order has got back to the scene.
Openvz has its own mechanisms to perform actions when starting a container. Migration knows about container state before migrating so after migrating data it can returns return the container to the the same previous state.
When considering migration that take into account insulated filesystems, it involve situations not considered by standard migration. By example, migrating a stopped container with its own filesystem, probably it will not have available its files because openvz supposedly will have scripts to unmount filesystem when container is stopped.
To get Openvz mount the filesystem before starting the container, '''vps.premount''' can have:
<pre>
#!/bin/bash
source ${VE_CONFFILE}
[ -d ${VE_PRIVATE} ] || mkdir ${VE_PRIVATE}
[[Image:Vzmigrate_b.jpeg|400px]]
<pre>
vzmigrate --dst-device /dervdev/sdg1 HN_target 123
</pre>
Remove VE_DEVICE parameter from 123.conf and operate the same as shared-shared
== Undo actions ==
The issue has got me required a lot hard work when for modifying vzmigrate is to track undo actions when a error arised arises in the code. May I permit felt free to restructure reorganise undo actions in a the function that follows described on the next following diagram.
mount /dev/sda1 /vz/private/123
mv /var/tmp/123/* /vz/private/123
# reflect this change in VE_PRIVATE parameter these changes in /etc/vz/conf/123.conf...VE_PRIVATE="/vz/private/$VEID"VE_DEVICE="/dev/sda1"...
</pre>