26
edits
Changes
→Other issues
Reading thoroughly quick installation documentation, it says "It is recommended to use a separate partition for container's private directories (by default /vz/private/<veid>)". As much as I searched the net, I have not found anything about it.
This is a subject a something I thought about long ago, but I considered difficult to do in my actual current implementation. Now things had have changed. I have received directives in my job to have each container in separated filesystems insulated from the rest of containers.
Actually vzmigrate does not have take into account this issue. vzmigrate assume data are available when migration occurs and it does not know about filesystems neither mounted filesystems at all.
Because of this matters, this issue I had put off 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}
</pre>
Similarly to get the filesystem unmounted after the container is stopped, we can have in '''vps.postumount''':
<pre>
#!/bin/bash
this optional device can be set with configuration parameter '''VE_DUMP_DEVICE'''. This parameter has only meaning if we share between HN the device over which container is set up.
== Migrations depending on the contexto context ==[[ArchivoImage:Vzmigrate_a.jpeg|400px]]
Migration in this case, as you would expect, es is the same as always.
[[Image:Vzmigrate_b.jpeg|400px]]
<pre>
vzmigrate --dst-device /dervdev/sdg1 HN_target 123
</pre>
[[ArchivoImage:Vzmigrate_c.jpeg|400px]]
Remove VE_DEVICE parameter from 123.conf and operate the same as shared-shared
[[ArchivoImage:Vzmigrate_d1.jpeg|400px]]
<pre>
vzmigrate --dst-device /dev/sdm1 HN_target 123
[[ArchivoImage:Vzmigrate_d2.jpeg|400px]]
<pre>
vzmigrate HN_target 123
== 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.
[[ArchivoImage:Vzmigrate_undo.jpeg|250px|center]]
== Other issues ==
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>
== Links to modified vzmigrate ==
ftp://ftp.uma.es/pub/Linux/openvz/
[[Category:HOWTO]]