OpenVZ Virtuozzo Containers Wiki - User contributions [en]

Vzmigrate filesystem aware

2012-06-08T11:24:52Z

Jcrey: /* Other issues */

== Motivation ==
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 something I thought about long ago, but I considered difficult to do in current
implementation. Now things 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 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 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 return the container to the 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.

I have modified migration script to adapt to these circumstances. I have named as '''shared''' those containers that share filesystem with others containers (legacy) and those with their own filesystem as '''insulated'''. With this in mind, there are four migration scenario.

* shared -> shared
* shared -> insulated
* insulated -> shared
* insulated -> insulated

To get Openvz to know a container is mounted on its own filesystem, optional parameter '''VE_DEVICE''' is defined in configuration file.

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}
[ -n "$VE_DEVICE" ] && mount ${VE_DEVICE} ${VE_PRIVATE} || echo -n " "
</pre>

Similarly to get the filesystem unmounted after the container is stopped, we can have in '''vps.postumount''':
<pre>
#!/bin/bash
source ${VE_CONFFILE}
if [ -n "$VE_DEVICE" ]; then
umount ${VE_PRIVATE} 2> /dev/null || echo -n ""
fi
</pre>

This configuration along the use of a SAN, gives interesting advantages when migrating containers that last so long at sincronization phase. If the same device is presented in both HN, we can skip sincronization phase. Migration only have to unmount filesystem in source HN and mount the filesystem in target HN avoiding this way the copy of data.

If we want to improve and minimize migration time, we could consider sharing another device for dump/undump container and share this way the file between HN. Using
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 context ==
[[Image:Vzmigrate_a.jpeg|400px]]

Migration in this case, as you would expect, is the same as always.

[[Image:Vzmigrate_b.jpeg|400px]]
<pre>
vzmigrate --dst-device /dev/sdg1 HN_target 123
</pre>

[[Image:Vzmigrate_c.jpeg|400px]]

Remove VE_DEVICE parameter from 123.conf and operate the same as shared-shared

[[Image:Vzmigrate_d1.jpeg|400px]]
<pre>
vzmigrate --dst-device /dev/sdm1 HN_target 123
</pre>

[[Image:Vzmigrate_d2.jpeg|400px]]
<pre>
vzmigrate HN_target 123
</pre>

If you use a shared dump filesystem between HN.
<pre>
vzmigrate --dump-device /dev/VG/dump --online HN_target 123
</pre>

== Undo actions ==
The issue has required a lot hard work for modifying vzmigrate to track undo actions when a error arises in the code. I felt free to reorganise undo actions in the function described on the following diagram.

[[Image:Vzmigrate_undo.jpeg|250px|center]]

== Other issues ==
Creating a container over a insulated filesystem is not possible straightly because of vzctl complains if the the device is previously mounted under VE_PRIVATE. To overcome this:
<pre>
vzctl create 123 --private /var/tmp/123
mkdir /vz/private/123;
mount /dev/sda1 /vz/private/123
mv /var/tmp/123/* /vz/private/123
# reflect 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]]

Vzmigrate filesystem aware

2012-06-08T11:24:32Z

Jcrey: /* Other issues */

== Motivation ==
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 something I thought about long ago, but I considered difficult to do in current
implementation. Now things 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 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 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 return the container to the 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.

I have modified migration script to adapt to these circumstances. I have named as '''shared''' those containers that share filesystem with others containers (legacy) and those with their own filesystem as '''insulated'''. With this in mind, there are four migration scenario.

* shared -> shared
* shared -> insulated
* insulated -> shared
* insulated -> insulated

To get Openvz to know a container is mounted on its own filesystem, optional parameter '''VE_DEVICE''' is defined in configuration file.

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}
[ -n "$VE_DEVICE" ] && mount ${VE_DEVICE} ${VE_PRIVATE} || echo -n " "
</pre>

Similarly to get the filesystem unmounted after the container is stopped, we can have in '''vps.postumount''':
<pre>
#!/bin/bash
source ${VE_CONFFILE}
if [ -n "$VE_DEVICE" ]; then
umount ${VE_PRIVATE} 2> /dev/null || echo -n ""
fi
</pre>

This configuration along the use of a SAN, gives interesting advantages when migrating containers that last so long at sincronization phase. If the same device is presented in both HN, we can skip sincronization phase. Migration only have to unmount filesystem in source HN and mount the filesystem in target HN avoiding this way the copy of data.

If we want to improve and minimize migration time, we could consider sharing another device for dump/undump container and share this way the file between HN. Using
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 context ==
[[Image:Vzmigrate_a.jpeg|400px]]

Migration in this case, as you would expect, is the same as always.

[[Image:Vzmigrate_b.jpeg|400px]]
<pre>
vzmigrate --dst-device /dev/sdg1 HN_target 123
</pre>

[[Image:Vzmigrate_c.jpeg|400px]]

Remove VE_DEVICE parameter from 123.conf and operate the same as shared-shared

[[Image:Vzmigrate_d1.jpeg|400px]]
<pre>
vzmigrate --dst-device /dev/sdm1 HN_target 123
</pre>

[[Image:Vzmigrate_d2.jpeg|400px]]
<pre>
vzmigrate HN_target 123
</pre>

If you use a shared dump filesystem between HN.
<pre>
vzmigrate --dump-device /dev/VG/dump --online HN_target 123
</pre>

== Undo actions ==
The issue has required a lot hard work for modifying vzmigrate to track undo actions when a error arises in the code. I felt free to reorganise undo actions in the function described on the following diagram.

[[Image:Vzmigrate_undo.jpeg|250px|center]]

== Other issues ==
Creating a container over a insulated filesystem is not possible straightly because of vzctl complains if the the device is previously mounted under VE_PRIVATE. To overcome this:
<pre>
vzctl create 123 --private /var/tmp/123
mkdir /vz/private/123;
mount /dev/sda1 /vz/private/123
mv /var/tmp/123/* /vz/private/123
# reflect these changes in VE_PRIVATE parameter 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]]

Vzmigrate filesystem aware

2012-06-08T11:22:50Z

Jcrey: /* Other issues */

== Motivation ==
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 something I thought about long ago, but I considered difficult to do in current
implementation. Now things 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 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 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 return the container to the 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.

I have modified migration script to adapt to these circumstances. I have named as '''shared''' those containers that share filesystem with others containers (legacy) and those with their own filesystem as '''insulated'''. With this in mind, there are four migration scenario.

* shared -> shared
* shared -> insulated
* insulated -> shared
* insulated -> insulated

To get Openvz to know a container is mounted on its own filesystem, optional parameter '''VE_DEVICE''' is defined in configuration file.

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}
[ -n "$VE_DEVICE" ] && mount ${VE_DEVICE} ${VE_PRIVATE} || echo -n " "
</pre>

Similarly to get the filesystem unmounted after the container is stopped, we can have in '''vps.postumount''':
<pre>
#!/bin/bash
source ${VE_CONFFILE}
if [ -n "$VE_DEVICE" ]; then
umount ${VE_PRIVATE} 2> /dev/null || echo -n ""
fi
</pre>

This configuration along the use of a SAN, gives interesting advantages when migrating containers that last so long at sincronization phase. If the same device is presented in both HN, we can skip sincronization phase. Migration only have to unmount filesystem in source HN and mount the filesystem in target HN avoiding this way the copy of data.

If we want to improve and minimize migration time, we could consider sharing another device for dump/undump container and share this way the file between HN. Using
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 context ==
[[Image:Vzmigrate_a.jpeg|400px]]

Migration in this case, as you would expect, is the same as always.

[[Image:Vzmigrate_b.jpeg|400px]]
<pre>
vzmigrate --dst-device /dev/sdg1 HN_target 123
</pre>

[[Image:Vzmigrate_c.jpeg|400px]]

Remove VE_DEVICE parameter from 123.conf and operate the same as shared-shared

[[Image:Vzmigrate_d1.jpeg|400px]]
<pre>
vzmigrate --dst-device /dev/sdm1 HN_target 123
</pre>

[[Image:Vzmigrate_d2.jpeg|400px]]
<pre>
vzmigrate HN_target 123
</pre>

If you use a shared dump filesystem between HN.
<pre>
vzmigrate --dump-device /dev/VG/dump --online HN_target 123
</pre>

== Undo actions ==
The issue has required a lot hard work for modifying vzmigrate to track undo actions when a error arises in the code. I felt free to reorganise undo actions in the function described on the following diagram.

[[Image:Vzmigrate_undo.jpeg|250px|center]]

== Other issues ==
Creating a container over a insulated filesystem is not possible straightly because of vzctl complains if the the device is previously mounted under VE_PRIVATE. To overcome this:
<pre>
vzctl create 123 --private /var/tmp/123
mkdir /vz/private/123;
mount /dev/sda1 /vz/private/123
mv /var/tmp/123/* /vz/private/123
# reflect this change in VE_PRIVATE parameter in /etc/vz/conf/123.conf
...
VE_DEVICE=/dev/sda1
...
</pre>

== Links to modified vzmigrate ==
ftp://ftp.uma.es/pub/Linux/openvz/

[[Category:HOWTO]]

Vzmigrate filesystem aware

2012-06-08T11:22:27Z

Jcrey: /* Other issues */

== Motivation ==
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 something I thought about long ago, but I considered difficult to do in current
implementation. Now things 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 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 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 return the container to the 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.

I have modified migration script to adapt to these circumstances. I have named as '''shared''' those containers that share filesystem with others containers (legacy) and those with their own filesystem as '''insulated'''. With this in mind, there are four migration scenario.

* shared -> shared
* shared -> insulated
* insulated -> shared
* insulated -> insulated

To get Openvz to know a container is mounted on its own filesystem, optional parameter '''VE_DEVICE''' is defined in configuration file.

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}
[ -n "$VE_DEVICE" ] && mount ${VE_DEVICE} ${VE_PRIVATE} || echo -n " "
</pre>

Similarly to get the filesystem unmounted after the container is stopped, we can have in '''vps.postumount''':
<pre>
#!/bin/bash
source ${VE_CONFFILE}
if [ -n "$VE_DEVICE" ]; then
umount ${VE_PRIVATE} 2> /dev/null || echo -n ""
fi
</pre>

This configuration along the use of a SAN, gives interesting advantages when migrating containers that last so long at sincronization phase. If the same device is presented in both HN, we can skip sincronization phase. Migration only have to unmount filesystem in source HN and mount the filesystem in target HN avoiding this way the copy of data.

If we want to improve and minimize migration time, we could consider sharing another device for dump/undump container and share this way the file between HN. Using
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 context ==
[[Image:Vzmigrate_a.jpeg|400px]]

Migration in this case, as you would expect, is the same as always.

[[Image:Vzmigrate_b.jpeg|400px]]
<pre>
vzmigrate --dst-device /dev/sdg1 HN_target 123
</pre>

[[Image:Vzmigrate_c.jpeg|400px]]

Remove VE_DEVICE parameter from 123.conf and operate the same as shared-shared

[[Image:Vzmigrate_d1.jpeg|400px]]
<pre>
vzmigrate --dst-device /dev/sdm1 HN_target 123
</pre>

[[Image:Vzmigrate_d2.jpeg|400px]]
<pre>
vzmigrate HN_target 123
</pre>

If you use a shared dump filesystem between HN.
<pre>
vzmigrate --dump-device /dev/VG/dump --online HN_target 123
</pre>

== Undo actions ==
The issue has required a lot hard work for modifying vzmigrate to track undo actions when a error arises in the code. I felt free to reorganise undo actions in the function described on the following diagram.

[[Image:Vzmigrate_undo.jpeg|250px|center]]

== Other issues ==
Creating a container over a insulated filesystem is not possible straightly because of vzctl complains if the the device is previously mounted under VE_PRIVATE. To overcome this:
<pre>
vzctl create 123 --private /var/tmp/123
mkdir /vz/private/123;
mount /dev/sda1 /vz/private/123
mv /var/tmp/123/* /vz/private/123
# reflect this change in VE_PRIVATE parameter in /etc/vz/conf/123.conf
# /etc/vz/conf/123.conf:
...
VE_DEVICE=/dev/sda1
...
</pre>

== Links to modified vzmigrate ==
ftp://ftp.uma.es/pub/Linux/openvz/

[[Category:HOWTO]]

Vzmigrate filesystem aware

2012-06-08T11:19:16Z

Jcrey: /* Migrations depending on context */

== Motivation ==
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 something I thought about long ago, but I considered difficult to do in current
implementation. Now things 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 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 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 return the container to the 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.

I have modified migration script to adapt to these circumstances. I have named as '''shared''' those containers that share filesystem with others containers (legacy) and those with their own filesystem as '''insulated'''. With this in mind, there are four migration scenario.

* shared -> shared
* shared -> insulated
* insulated -> shared
* insulated -> insulated

To get Openvz to know a container is mounted on its own filesystem, optional parameter '''VE_DEVICE''' is defined in configuration file.

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}
[ -n "$VE_DEVICE" ] && mount ${VE_DEVICE} ${VE_PRIVATE} || echo -n " "
</pre>

Similarly to get the filesystem unmounted after the container is stopped, we can have in '''vps.postumount''':
<pre>
#!/bin/bash
source ${VE_CONFFILE}
if [ -n "$VE_DEVICE" ]; then
umount ${VE_PRIVATE} 2> /dev/null || echo -n ""
fi
</pre>

This configuration along the use of a SAN, gives interesting advantages when migrating containers that last so long at sincronization phase. If the same device is presented in both HN, we can skip sincronization phase. Migration only have to unmount filesystem in source HN and mount the filesystem in target HN avoiding this way the copy of data.

If we want to improve and minimize migration time, we could consider sharing another device for dump/undump container and share this way the file between HN. Using
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 context ==
[[Image:Vzmigrate_a.jpeg|400px]]

Migration in this case, as you would expect, is the same as always.

[[Image:Vzmigrate_b.jpeg|400px]]
<pre>
vzmigrate --dst-device /dev/sdg1 HN_target 123
</pre>

[[Image:Vzmigrate_c.jpeg|400px]]

Remove VE_DEVICE parameter from 123.conf and operate the same as shared-shared

[[Image:Vzmigrate_d1.jpeg|400px]]
<pre>
vzmigrate --dst-device /dev/sdm1 HN_target 123
</pre>

[[Image:Vzmigrate_d2.jpeg|400px]]
<pre>
vzmigrate HN_target 123
</pre>

If you use a shared dump filesystem between HN.
<pre>
vzmigrate --dump-device /dev/VG/dump --online HN_target 123
</pre>

== Undo actions ==
The issue has required a lot hard work for modifying vzmigrate to track undo actions when a error arises in the code. I felt free to reorganise undo actions in the function described on the following diagram.

[[Image:Vzmigrate_undo.jpeg|250px|center]]

== Other issues ==
Creating a container over a insulated filesystem is not possible straightly because of vzctl complains if the the device is previously mounted under VE_PRIVATE. To overcome this:
<pre>
vzctl create 123 --private /var/tmp/123
mkdir /vz/private/123;
mount /dev/sda1 /vz/private/123
mv /var/tmp/123/* /vz/private/123
# reflect this change in VE_PRIVATE parameter in /etc/vz/conf/123.conf
</pre>

== Links to modified vzmigrate ==
ftp://ftp.uma.es/pub/Linux/openvz/

[[Category:HOWTO]]

Vzmigrate filesystem aware

2012-06-08T11:17:56Z

Jcrey: /* Migrations depending on context */

== Motivation ==
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 something I thought about long ago, but I considered difficult to do in current
implementation. Now things 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 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 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 return the container to the 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.

I have modified migration script to adapt to these circumstances. I have named as '''shared''' those containers that share filesystem with others containers (legacy) and those with their own filesystem as '''insulated'''. With this in mind, there are four migration scenario.

* shared -> shared
* shared -> insulated
* insulated -> shared
* insulated -> insulated

To get Openvz to know a container is mounted on its own filesystem, optional parameter '''VE_DEVICE''' is defined in configuration file.

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}
[ -n "$VE_DEVICE" ] && mount ${VE_DEVICE} ${VE_PRIVATE} || echo -n " "
</pre>

Similarly to get the filesystem unmounted after the container is stopped, we can have in '''vps.postumount''':
<pre>
#!/bin/bash
source ${VE_CONFFILE}
if [ -n "$VE_DEVICE" ]; then
umount ${VE_PRIVATE} 2> /dev/null || echo -n ""
fi
</pre>

This configuration along the use of a SAN, gives interesting advantages when migrating containers that last so long at sincronization phase. If the same device is presented in both HN, we can skip sincronization phase. Migration only have to unmount filesystem in source HN and mount the filesystem in target HN avoiding this way the copy of data.

If we want to improve and minimize migration time, we could consider sharing another device for dump/undump container and share this way the file between HN. Using
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 context ==
[[Image:Vzmigrate_a.jpeg|400px]]

Migration in this case, as you would expect, is the same as always.

[[Image:Vzmigrate_b.jpeg|400px]]
<pre>
vzmigrate --dst-device /dev/sdg1 HN_target 123
</pre>

[[Image:Vzmigrate_c.jpeg|400px]]

Remove VE_DEVICE parameter from 123.conf and operate the same as shared-shared

Mount/unmount container's filesystem if appropriated.

[[Image:Vzmigrate_d1.jpeg|400px]]
<pre>
vzmigrate --dst-device /dev/sdm1 HN_target 123
</pre>

[[Image:Vzmigrate_d2.jpeg|400px]]
<pre>
vzmigrate HN_target 123
</pre>

If you use a shared dump filesystem between HN.
<pre>
vzmigrate --dump-device /dev/VG/dump --online HN_target 123
</pre>

== Undo actions ==
The issue has required a lot hard work for modifying vzmigrate to track undo actions when a error arises in the code. I felt free to reorganise undo actions in the function described on the following diagram.

[[Image:Vzmigrate_undo.jpeg|250px|center]]

== Other issues ==
Creating a container over a insulated filesystem is not possible straightly because of vzctl complains if the the device is previously mounted under VE_PRIVATE. To overcome this:
<pre>
vzctl create 123 --private /var/tmp/123
mkdir /vz/private/123;
mount /dev/sda1 /vz/private/123
mv /var/tmp/123/* /vz/private/123
# reflect this change in VE_PRIVATE parameter in /etc/vz/conf/123.conf
</pre>

== Links to modified vzmigrate ==
ftp://ftp.uma.es/pub/Linux/openvz/

[[Category:HOWTO]]

Vzmigrate filesystem aware

2012-06-08T11:15:51Z

Jcrey: /* Motivation */

== Motivation ==
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 something I thought about long ago, but I considered difficult to do in current
implementation. Now things 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 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 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 return the container to the 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.

I have modified migration script to adapt to these circumstances. I have named as '''shared''' those containers that share filesystem with others containers (legacy) and those with their own filesystem as '''insulated'''. With this in mind, there are four migration scenario.

* shared -> shared
* shared -> insulated
* insulated -> shared
* insulated -> insulated

To get Openvz to know a container is mounted on its own filesystem, optional parameter '''VE_DEVICE''' is defined in configuration file.

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}
[ -n "$VE_DEVICE" ] && mount ${VE_DEVICE} ${VE_PRIVATE} || echo -n " "
</pre>

Similarly to get the filesystem unmounted after the container is stopped, we can have in '''vps.postumount''':
<pre>
#!/bin/bash
source ${VE_CONFFILE}
if [ -n "$VE_DEVICE" ]; then
umount ${VE_PRIVATE} 2> /dev/null || echo -n ""
fi
</pre>

This configuration along the use of a SAN, gives interesting advantages when migrating containers that last so long at sincronization phase. If the same device is presented in both HN, we can skip sincronization phase. Migration only have to unmount filesystem in source HN and mount the filesystem in target HN avoiding this way the copy of data.

If we want to improve and minimize migration time, we could consider sharing another device for dump/undump container and share this way the file between HN. Using
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 context ==
[[Image:Vzmigrate_a.jpeg|400px]]

Migration in this case, as you would expect, is the same as always.

[[Image:Vzmigrate_b.jpeg|400px]]
<pre>
vzmigrate --dst-device /derv/sdg1 HN_target 123
</pre>

[[Image:Vzmigrate_c.jpeg|400px]]

Remove VE_DEVICE parameter from 123.conf and operate the same as shared-shared

Mount/unmount container's filesystem if appropriated.

[[Image:Vzmigrate_d1.jpeg|400px]]
<pre>
vzmigrate --dst-device /dev/sdm1 HN_target 123
</pre>

[[Image:Vzmigrate_d2.jpeg|400px]]
<pre>
vzmigrate HN_target 123
</pre>

If you use a shared dump filesystem between HN.
<pre>
vzmigrate --dump-device /dev/VG/dump --online HN_target 123
</pre>

== Undo actions ==
The issue has required a lot hard work for modifying vzmigrate to track undo actions when a error arises in the code. I felt free to reorganise undo actions in the function described on the following diagram.

[[Image:Vzmigrate_undo.jpeg|250px|center]]

== Other issues ==
Creating a container over a insulated filesystem is not possible straightly because of vzctl complains if the the device is previously mounted under VE_PRIVATE. To overcome this:
<pre>
vzctl create 123 --private /var/tmp/123
mkdir /vz/private/123;
mount /dev/sda1 /vz/private/123
mv /var/tmp/123/* /vz/private/123
# reflect this change in VE_PRIVATE parameter in /etc/vz/conf/123.conf
</pre>

== Links to modified vzmigrate ==
ftp://ftp.uma.es/pub/Linux/openvz/

[[Category:HOWTO]]

Vzmigrate filesystem aware

2012-06-08T11:01:14Z

Jcrey: /* Undo actions */

== Motivation ==
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 something I thought about long ago, but I considered difficult to do in current
implementation. Now things 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 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 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 return the container to the 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.

I have modified migration script to adapt to these circumstances. I have named as '''shared''' those containers that share filesystem with others containers (legacy) and those with their own filesystem as '''insulated'''. With this in mind, there are four migration scenario.

* shared -> shared
* shared -> insulated
* insulated -> shared
* insulated -> insulated

To get Openvz to know a container is mounted on its own filesystem, optional parameter '''VE_DEVICE''' is defined in configuration file.

To get Openvz mount the filesystem before starting the container, '''vps.premount''' can have:
<pre>
source ${VE_CONFFILE}
[ -d ${VE_PRIVATE} ] || mkdir ${VE_PRIVATE}
[ -n "$VE_DEVICE" ] && mount ${VE_DEVICE} ${VE_PRIVATE} || echo -n " "
</pre>

Similarly to get the filesystem unmounted after the container is stopped, we can have in '''vps.postumount''':
<pre>
#!/bin/bash
source ${VE_CONFFILE}
if [ -n "$VE_DEVICE" ]; then
umount ${VE_PRIVATE} 2> /dev/null || echo -n ""
fi
</pre>

This configuration along the use of a SAN, gives interesting advantages when migrating containers that last so long at sincronization phase. If the same device is presented in both HN, we can skip sincronization phase. Migration only have to unmount filesystem in source HN and mount the filesystem in target HN avoiding this way the copy of data.

If we want to improve and minimize migration time, we could consider sharing another device for dump/undump container and share this way the file between HN. Using
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 context ==
[[Image:Vzmigrate_a.jpeg|400px]]

Migration in this case, as you would expect, is the same as always.

[[Image:Vzmigrate_b.jpeg|400px]]
<pre>
vzmigrate --dst-device /derv/sdg1 HN_target 123
</pre>

[[Image:Vzmigrate_c.jpeg|400px]]

Remove VE_DEVICE parameter from 123.conf and operate the same as shared-shared

Mount/unmount container's filesystem if appropriated.

[[Image:Vzmigrate_d1.jpeg|400px]]
<pre>
vzmigrate --dst-device /dev/sdm1 HN_target 123
</pre>

[[Image:Vzmigrate_d2.jpeg|400px]]
<pre>
vzmigrate HN_target 123
</pre>

If you use a shared dump filesystem between HN.
<pre>
vzmigrate --dump-device /dev/VG/dump --online HN_target 123
</pre>

== Undo actions ==
The issue has required a lot hard work for modifying vzmigrate to track undo actions when a error arises in the code. I felt free to reorganise undo actions in the function described on the following diagram.

[[Image:Vzmigrate_undo.jpeg|250px|center]]

== Other issues ==
Creating a container over a insulated filesystem is not possible straightly because of vzctl complains if the the device is previously mounted under VE_PRIVATE. To overcome this:
<pre>
vzctl create 123 --private /var/tmp/123
mkdir /vz/private/123;
mount /dev/sda1 /vz/private/123
mv /var/tmp/123/* /vz/private/123
# reflect this change in VE_PRIVATE parameter in /etc/vz/conf/123.conf
</pre>

== Links to modified vzmigrate ==
ftp://ftp.uma.es/pub/Linux/openvz/

[[Category:HOWTO]]

Vzmigrate filesystem aware

2012-06-08T10:52:41Z

Jcrey: /* Motivation */

== Motivation ==
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 something I thought about long ago, but I considered difficult to do in current
implementation. Now things 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 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 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 return the container to the 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.

I have modified migration script to adapt to these circumstances. I have named as '''shared''' those containers that share filesystem with others containers (legacy) and those with their own filesystem as '''insulated'''. With this in mind, there are four migration scenario.

* shared -> shared
* shared -> insulated
* insulated -> shared
* insulated -> insulated

To get Openvz to know a container is mounted on its own filesystem, optional parameter '''VE_DEVICE''' is defined in configuration file.

To get Openvz mount the filesystem before starting the container, '''vps.premount''' can have:
<pre>
source ${VE_CONFFILE}
[ -d ${VE_PRIVATE} ] || mkdir ${VE_PRIVATE}
[ -n "$VE_DEVICE" ] && mount ${VE_DEVICE} ${VE_PRIVATE} || echo -n " "
</pre>

Similarly to get the filesystem unmounted after the container is stopped, we can have in '''vps.postumount''':
<pre>
#!/bin/bash
source ${VE_CONFFILE}
if [ -n "$VE_DEVICE" ]; then
umount ${VE_PRIVATE} 2> /dev/null || echo -n ""
fi
</pre>

This configuration along the use of a SAN, gives interesting advantages when migrating containers that last so long at sincronization phase. If the same device is presented in both HN, we can skip sincronization phase. Migration only have to unmount filesystem in source HN and mount the filesystem in target HN avoiding this way the copy of data.

If we want to improve and minimize migration time, we could consider sharing another device for dump/undump container and share this way the file between HN. Using
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 context ==
[[Image:Vzmigrate_a.jpeg|400px]]

Migration in this case, as you would expect, is the same as always.

[[Image:Vzmigrate_b.jpeg|400px]]
<pre>
vzmigrate --dst-device /derv/sdg1 HN_target 123
</pre>

[[Image:Vzmigrate_c.jpeg|400px]]

Remove VE_DEVICE parameter from 123.conf and operate the same as shared-shared

Mount/unmount container's filesystem if appropriated.

[[Image:Vzmigrate_d1.jpeg|400px]]
<pre>
vzmigrate --dst-device /dev/sdm1 HN_target 123
</pre>

[[Image:Vzmigrate_d2.jpeg|400px]]
<pre>
vzmigrate HN_target 123
</pre>

If you use a shared dump filesystem between HN.
<pre>
vzmigrate --dump-device /dev/VG/dump --online HN_target 123
</pre>

== Undo actions ==
The issue has got me a lot hard work when modifying vzmigrate is to track undo actions when a error arised in the code. May I permit to restructure undo actions in a function that follows the next diagram.

[[Image:Vzmigrate_undo.jpeg|250px|center]]

== Other issues ==
Creating a container over a insulated filesystem is not possible straightly because of vzctl complains if the the device is previously mounted under VE_PRIVATE. To overcome this:
<pre>
vzctl create 123 --private /var/tmp/123
mkdir /vz/private/123;
mount /dev/sda1 /vz/private/123
mv /var/tmp/123/* /vz/private/123
# reflect this change in VE_PRIVATE parameter in /etc/vz/conf/123.conf
</pre>

== Links to modified vzmigrate ==
ftp://ftp.uma.es/pub/Linux/openvz/

[[Category:HOWTO]]

Vzmigrate filesystem aware

2012-06-08T10:51:08Z

Jcrey: /* Motivation */

== Motivation ==
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 something I thought about long ago, but I considered difficult to do in current
implementation. Now things 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 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 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 the container to the the same 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.

I have modified migration script to adapt to these circumstances. I have named as '''shared''' those containers that share filesystem with others containers (legacy) and those with their own filesystem as '''insulated'''. With this in mind, there are four migration scenario.

* shared -> shared
* shared -> insulated
* insulated -> shared
* insulated -> insulated

To get Openvz to know a container is mounted on its own filesystem, optional parameter '''VE_DEVICE''' is defined in configuration file.

To get Openvz mount the filesystem before starting the container, '''vps.premount''' can have:
<pre>
source ${VE_CONFFILE}
[ -d ${VE_PRIVATE} ] || mkdir ${VE_PRIVATE}
[ -n "$VE_DEVICE" ] && mount ${VE_DEVICE} ${VE_PRIVATE} || echo -n " "
</pre>

Similarly to get the filesystem unmounted after the container is stopped, we can have in '''vps.postumount''':
<pre>
#!/bin/bash
source ${VE_CONFFILE}
if [ -n "$VE_DEVICE" ]; then
umount ${VE_PRIVATE} 2> /dev/null || echo -n ""
fi
</pre>

This configuration along the use of a SAN, gives interesting advantages when migrating containers that last so long at sincronization phase. If the same device is presented in both HN, we can skip sincronization phase. Migration only have to unmount filesystem in source HN and mount the filesystem in target HN avoiding this way the copy of data.

If we want to improve and minimize migration time, we could consider sharing another device for dump/undump container and share this way the file between HN. Using
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 context ==
[[Image:Vzmigrate_a.jpeg|400px]]

Migration in this case, as you would expect, is the same as always.

[[Image:Vzmigrate_b.jpeg|400px]]
<pre>
vzmigrate --dst-device /derv/sdg1 HN_target 123
</pre>

[[Image:Vzmigrate_c.jpeg|400px]]

Remove VE_DEVICE parameter from 123.conf and operate the same as shared-shared

Mount/unmount container's filesystem if appropriated.

[[Image:Vzmigrate_d1.jpeg|400px]]
<pre>
vzmigrate --dst-device /dev/sdm1 HN_target 123
</pre>

[[Image:Vzmigrate_d2.jpeg|400px]]
<pre>
vzmigrate HN_target 123
</pre>

If you use a shared dump filesystem between HN.
<pre>
vzmigrate --dump-device /dev/VG/dump --online HN_target 123
</pre>

== Undo actions ==
The issue has got me a lot hard work when modifying vzmigrate is to track undo actions when a error arised in the code. May I permit to restructure undo actions in a function that follows the next diagram.

[[Image:Vzmigrate_undo.jpeg|250px|center]]

== Other issues ==
Creating a container over a insulated filesystem is not possible straightly because of vzctl complains if the the device is previously mounted under VE_PRIVATE. To overcome this:
<pre>
vzctl create 123 --private /var/tmp/123
mkdir /vz/private/123;
mount /dev/sda1 /vz/private/123
mv /var/tmp/123/* /vz/private/123
# reflect this change in VE_PRIVATE parameter in /etc/vz/conf/123.conf
</pre>

== Links to modified vzmigrate ==
ftp://ftp.uma.es/pub/Linux/openvz/

[[Category:HOWTO]]

Vzmigrate filesystem aware

2012-05-31T08:39:34Z

Jcrey: /* Motivation */

== Motivation ==
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 thought about long ago, but I considered difficult to do in my actual
implementation. Now things had 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 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 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 the container to the the same 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.

I have modified migration script to adapt to these circumstances. I have named as '''shared''' those containers that share filesystem with others containers (legacy) and those with their own filesystem as '''insulated'''. With this in mind, there are four migration scenario.

* shared -> shared
* shared -> insulated
* insulated -> shared
* insulated -> insulated

To get Openvz to know a container is mounted on its own filesystem, optional parameter '''VE_DEVICE''' is defined in configuration file.

To get Openvz mount the filesystem before starting the container, '''vps.premount''' can have:
<pre>
source ${VE_CONFFILE}
[ -d ${VE_PRIVATE} ] || mkdir ${VE_PRIVATE}
[ -n "$VE_DEVICE" ] && mount ${VE_DEVICE} ${VE_PRIVATE} || echo -n " "
</pre>

Similarly to get the filesystem unmounted after the container is stopped, we can have in '''vps.postumount''':
<pre>
#!/bin/bash
source ${VE_CONFFILE}
if [ -n "$VE_DEVICE" ]; then
umount ${VE_PRIVATE} 2> /dev/null || echo -n ""
fi
</pre>

This configuration along the use of a SAN, gives interesting advantages when migrating containers that last so long at sincronization phase. If the same device is presented in both HN, we can skip sincronization phase. Migration only have to unmount filesystem in source HN and mount the filesystem in target HN avoiding this way the copy of data.

If we want to improve and minimize migration time, we could consider sharing another device for dump/undump container and share this way the file between HN. Using
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 context ==
[[Image:Vzmigrate_a.jpeg|400px]]

Migration in this case, as you would expect, is the same as always.

[[Image:Vzmigrate_b.jpeg|400px]]
<pre>
vzmigrate --dst-device /derv/sdg1 HN_target 123
</pre>

[[Image:Vzmigrate_c.jpeg|400px]]

Remove VE_DEVICE parameter from 123.conf and operate the same as shared-shared

Mount/unmount container's filesystem if appropriated.

[[Image:Vzmigrate_d1.jpeg|400px]]
<pre>
vzmigrate --dst-device /dev/sdm1 HN_target 123
</pre>

[[Image:Vzmigrate_d2.jpeg|400px]]
<pre>
vzmigrate HN_target 123
</pre>

If you use a shared dump filesystem between HN.
<pre>
vzmigrate --dump-device /dev/VG/dump --online HN_target 123
</pre>

== Undo actions ==
The issue has got me a lot hard work when modifying vzmigrate is to track undo actions when a error arised in the code. May I permit to restructure undo actions in a function that follows the next diagram.

[[Image:Vzmigrate_undo.jpeg|250px|center]]

== Other issues ==
Creating a container over a insulated filesystem is not possible straightly because of vzctl complains if the the device is previously mounted under VE_PRIVATE. To overcome this:
<pre>
vzctl create 123 --private /var/tmp/123
mkdir /vz/private/123;
mount /dev/sda1 /vz/private/123
mv /var/tmp/123/* /vz/private/123
# reflect this change in VE_PRIVATE parameter in /etc/vz/conf/123.conf
</pre>

== Links to vzmigrate modified ==
ftp://ftp.uma.es/pub/Linux/openvz/

[[Category:HOWTO]]

Vzmigrate filesystem aware

2012-05-31T08:38:13Z

Jcrey: /* Motivation */

== Motivation ==
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 thought about long ago, but I considered difficult to do in my actual
implementation. Now things had 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 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 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 the container to the the same 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.

I have modified migration script to adapt to these circumstances. I have named as '''shared''' those containers that share filesystem with others containers (legacy) and those with their own filesystem as '''insulated'''. With this in mind, there are four migration scenario.

* shared -> shared
* shared -> insulated
* insulated -> shared
* insulated -> insulated

To get Openvz to know a container is mounted on its own filesystem, optional parameter '''VE_DEVICE''' is defined in configuration file.

To get Openvz mount the filesystem before starting the container, '''vps.premount''' can have:
<pre>
source ${VE_CONFFILE}
[ -d ${VE_PRIVATE} ] || mkdir ${VE_PRIVATE}
[ -n "$VE_DEVICE" ] && mount ${VE_DEVICE} ${VE_PRIVATE} || echo -n " "
</pre>

Similarly to get the filesystem unmounted after the container is stopped, we can have in vps.postumount:
<pre>
#!/bin/bash
source ${VE_CONFFILE}
if [ -n "$VE_DEVICE" ]; then
umount ${VE_PRIVATE} 2> /dev/null || echo -n ""
fi
</pre>

This configuration along the use of a SAN, gives interesting advantages when migrating containers that last so long at sincronization phase. If the same device is presented in both HN, we can skip sincronization phase. Migration only have to unmount filesystem in source HN and mount the filesystem in target HN avoiding this way the copy of data.

If we want to improve and minimize migration time, we could consider sharing another device for dump/undump container and share this way the file between HN. Using
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 context ==
[[Image:Vzmigrate_a.jpeg|400px]]

Migration in this case, as you would expect, is the same as always.

[[Image:Vzmigrate_b.jpeg|400px]]
<pre>
vzmigrate --dst-device /derv/sdg1 HN_target 123
</pre>

[[Image:Vzmigrate_c.jpeg|400px]]

Remove VE_DEVICE parameter from 123.conf and operate the same as shared-shared

Mount/unmount container's filesystem if appropriated.

[[Image:Vzmigrate_d1.jpeg|400px]]
<pre>
vzmigrate --dst-device /dev/sdm1 HN_target 123
</pre>

[[Image:Vzmigrate_d2.jpeg|400px]]
<pre>
vzmigrate HN_target 123
</pre>

If you use a shared dump filesystem between HN.
<pre>
vzmigrate --dump-device /dev/VG/dump --online HN_target 123
</pre>

== Undo actions ==
The issue has got me a lot hard work when modifying vzmigrate is to track undo actions when a error arised in the code. May I permit to restructure undo actions in a function that follows the next diagram.

[[Image:Vzmigrate_undo.jpeg|250px|center]]

== Other issues ==
Creating a container over a insulated filesystem is not possible straightly because of vzctl complains if the the device is previously mounted under VE_PRIVATE. To overcome this:
<pre>
vzctl create 123 --private /var/tmp/123
mkdir /vz/private/123;
mount /dev/sda1 /vz/private/123
mv /var/tmp/123/* /vz/private/123
# reflect this change in VE_PRIVATE parameter in /etc/vz/conf/123.conf
</pre>

== Links to vzmigrate modified ==
ftp://ftp.uma.es/pub/Linux/openvz/

[[Category:HOWTO]]

Vzmigrate filesystem aware

2012-05-31T08:36:13Z

Jcrey: /* Migrations depending on context */

== Motivation ==
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 thought about long ago, but I considered difficult to do in my actual
implementation. Now things had 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 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 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 the container to the the same 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.

I have modified migration script to adapt to these circumstances. I have named as '''shared''' those containers that share filesystem with others containers (legacy) and those with their own filesystem as '''insulated'''. With this in mind, there are four migration scenario.

* shared -> shared
* shared -> insulated
* insulated -> shared
* insulated -> insulated

To get Openvz to know a container is mounted on its own filesystem, optional parameter '''VE_DEVICE''' is defined in configuration file.

To get Openvz mount the filesystem before starting the container, '''vps.premount''' can have:
<pre>
source ${VE_CONFFILE}
[ -d ${VE_PRIVATE} ] || mkdir ${VE_PRIVATE}
[ -n "$VE_DEVICE" ] && mount ${VE_DEVICE} ${VE_PRIVATE} || echo -n " "
</pre>

Similarly to get the filesystem unmounted after the container is stopped, we can have in vps.postumount:
<pre>
#!/bin/bash
source ${VE_CONFFILE}
if [ -n "$VE_DEVICE" ]; then
umount ${VE_PRIVATE} 2> /dev/null || echo -n ""
fi
</pre>

This configuration along the use of a SAN, gives interesting advantages when migrating containers that last so long at sincronization phase. If the same device is presented in both HN, we can skip sincronization phase. Migration only have to unmount filesystem in source HN and mount the filesystem in target HN avoiding this way the copy of data.

If we want to improve and minimize migration time, we could consider sharing another device for dump/undump container and share this way the file between HN. Using
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 context ==
[[Image:Vzmigrate_a.jpeg|400px]]

Migration in this case, as you would expect, is the same as always.

[[Image:Vzmigrate_b.jpeg|400px]]
<pre>
vzmigrate --dst-device /derv/sdg1 HN_target 123
</pre>

[[Image:Vzmigrate_c.jpeg|400px]]

Remove VE_DEVICE parameter from 123.conf and operate the same as shared-shared

Mount/unmount container's filesystem if appropriated.

[[Image:Vzmigrate_d1.jpeg|400px]]
<pre>
vzmigrate --dst-device /dev/sdm1 HN_target 123
</pre>

[[Image:Vzmigrate_d2.jpeg|400px]]
<pre>
vzmigrate HN_target 123
</pre>

If you use a shared dump filesystem between HN.
<pre>
vzmigrate --dump-device /dev/VG/dump --online HN_target 123
</pre>

== Undo actions ==
The issue has got me a lot hard work when modifying vzmigrate is to track undo actions when a error arised in the code. May I permit to restructure undo actions in a function that follows the next diagram.

[[Image:Vzmigrate_undo.jpeg|250px|center]]

== Other issues ==
Creating a container over a insulated filesystem is not possible straightly because of vzctl complains if the the device is previously mounted under VE_PRIVATE. To overcome this:
<pre>
vzctl create 123 --private /var/tmp/123
mkdir /vz/private/123;
mount /dev/sda1 /vz/private/123
mv /var/tmp/123/* /vz/private/123
# reflect this change in VE_PRIVATE parameter in /etc/vz/conf/123.conf
</pre>

== Links to vzmigrate modified ==
ftp://ftp.uma.es/pub/Linux/openvz/

[[Category:HOWTO]]

Vzmigrate filesystem aware

2012-05-31T08:35:53Z

Jcrey: /* Migrations depending on the context */

== Motivation ==
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 thought about long ago, but I considered difficult to do in my actual
implementation. Now things had 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 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 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 the container to the the same 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.

I have modified migration script to adapt to these circumstances. I have named as '''shared''' those containers that share filesystem with others containers (legacy) and those with their own filesystem as '''insulated'''. With this in mind, there are four migration scenario.

* shared -> shared
* shared -> insulated
* insulated -> shared
* insulated -> insulated

To get Openvz to know a container is mounted on its own filesystem, optional parameter '''VE_DEVICE''' is defined in configuration file.

To get Openvz mount the filesystem before starting the container, '''vps.premount''' can have:
<pre>
source ${VE_CONFFILE}
[ -d ${VE_PRIVATE} ] || mkdir ${VE_PRIVATE}
[ -n "$VE_DEVICE" ] && mount ${VE_DEVICE} ${VE_PRIVATE} || echo -n " "
</pre>

Similarly to get the filesystem unmounted after the container is stopped, we can have in vps.postumount:
<pre>
#!/bin/bash
source ${VE_CONFFILE}
if [ -n "$VE_DEVICE" ]; then
umount ${VE_PRIVATE} 2> /dev/null || echo -n ""
fi
</pre>

This configuration along the use of a SAN, gives interesting advantages when migrating containers that last so long at sincronization phase. If the same device is presented in both HN, we can skip sincronization phase. Migration only have to unmount filesystem in source HN and mount the filesystem in target HN avoiding this way the copy of data.

If we want to improve and minimize migration time, we could consider sharing another device for dump/undump container and share this way the file between HN. Using
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 context ==
[[Image:Vzmigrate_a.jpeg|400px]]

Migration in this case, as you would expect, es the same as always.

[[Image:Vzmigrate_b.jpeg|400px]]
<pre>
vzmigrate --dst-device /derv/sdg1 HN_target 123
</pre>

[[Image:Vzmigrate_c.jpeg|400px]]

Remove VE_DEVICE parameter from 123.conf and operate the same as shared-shared

Mount/unmount container's filesystem if appropriated.

[[Image:Vzmigrate_d1.jpeg|400px]]
<pre>
vzmigrate --dst-device /dev/sdm1 HN_target 123
</pre>

[[Image:Vzmigrate_d2.jpeg|400px]]
<pre>
vzmigrate HN_target 123
</pre>

If you use a shared dump filesystem between HN.
<pre>
vzmigrate --dump-device /dev/VG/dump --online HN_target 123
</pre>

== Undo actions ==
The issue has got me a lot hard work when modifying vzmigrate is to track undo actions when a error arised in the code. May I permit to restructure undo actions in a function that follows the next diagram.

[[Image:Vzmigrate_undo.jpeg|250px|center]]

== Other issues ==
Creating a container over a insulated filesystem is not possible straightly because of vzctl complains if the the device is previously mounted under VE_PRIVATE. To overcome this:
<pre>
vzctl create 123 --private /var/tmp/123
mkdir /vz/private/123;
mount /dev/sda1 /vz/private/123
mv /var/tmp/123/* /vz/private/123
# reflect this change in VE_PRIVATE parameter in /etc/vz/conf/123.conf
</pre>

== Links to vzmigrate modified ==
ftp://ftp.uma.es/pub/Linux/openvz/

[[Category:HOWTO]]

Vzmigrate filesystem aware

2012-05-31T08:35:34Z

Jcrey: /* Migrations depending on the contexto */

== Motivation ==
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 thought about long ago, but I considered difficult to do in my actual
implementation. Now things had 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 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 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 the container to the the same 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.

I have modified migration script to adapt to these circumstances. I have named as '''shared''' those containers that share filesystem with others containers (legacy) and those with their own filesystem as '''insulated'''. With this in mind, there are four migration scenario.

* shared -> shared
* shared -> insulated
* insulated -> shared
* insulated -> insulated

To get Openvz to know a container is mounted on its own filesystem, optional parameter '''VE_DEVICE''' is defined in configuration file.

To get Openvz mount the filesystem before starting the container, '''vps.premount''' can have:
<pre>
source ${VE_CONFFILE}
[ -d ${VE_PRIVATE} ] || mkdir ${VE_PRIVATE}
[ -n "$VE_DEVICE" ] && mount ${VE_DEVICE} ${VE_PRIVATE} || echo -n " "
</pre>

Similarly to get the filesystem unmounted after the container is stopped, we can have in vps.postumount:
<pre>
#!/bin/bash
source ${VE_CONFFILE}
if [ -n "$VE_DEVICE" ]; then
umount ${VE_PRIVATE} 2> /dev/null || echo -n ""
fi
</pre>

This configuration along the use of a SAN, gives interesting advantages when migrating containers that last so long at sincronization phase. If the same device is presented in both HN, we can skip sincronization phase. Migration only have to unmount filesystem in source HN and mount the filesystem in target HN avoiding this way the copy of data.

If we want to improve and minimize migration time, we could consider sharing another device for dump/undump container and share this way the file between HN. Using
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 context ==
[[Image:Vzmigrate_a.jpeg|400px]]

Migration in this case, as you would expect, es the same as always.

[[Image:Vzmigrate_b.jpeg|400px]]
<pre>
vzmigrate --dst-device /derv/sdg1 HN_target 123
</pre>

[[Image:Vzmigrate_c.jpeg|400px]]

Remove VE_DEVICE parameter from 123.conf and operate the same as shared-shared

Mount/unmount container's filesystem if appropriated.

[[Image:Vzmigrate_d1.jpeg|400px]]
<pre>
vzmigrate --dst-device /dev/sdm1 HN_target 123
</pre>

[[Image:Vzmigrate_d2.jpeg|400px]]
<pre>
vzmigrate HN_target 123
</pre>

If you use a shared dump filesystem between HN.
<pre>
vzmigrate --dump-device /dev/VG/dump --online HN_target 123
</pre>

== Undo actions ==
The issue has got me a lot hard work when modifying vzmigrate is to track undo actions when a error arised in the code. May I permit to restructure undo actions in a function that follows the next diagram.

[[Image:Vzmigrate_undo.jpeg|250px|center]]

== Other issues ==
Creating a container over a insulated filesystem is not possible straightly because of vzctl complains if the the device is previously mounted under VE_PRIVATE. To overcome this:
<pre>
vzctl create 123 --private /var/tmp/123
mkdir /vz/private/123;
mount /dev/sda1 /vz/private/123
mv /var/tmp/123/* /vz/private/123
# reflect this change in VE_PRIVATE parameter in /etc/vz/conf/123.conf
</pre>

== Links to vzmigrate modified ==
ftp://ftp.uma.es/pub/Linux/openvz/

[[Category:HOWTO]]

Vzmigrate filesystem aware

2012-05-31T08:34:12Z

Jcrey: /* Other issues */

== Motivation ==
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 thought about long ago, but I considered difficult to do in my actual
implementation. Now things had 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 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 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 the container to the the same 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.

I have modified migration script to adapt to these circumstances. I have named as '''shared''' those containers that share filesystem with others containers (legacy) and those with their own filesystem as '''insulated'''. With this in mind, there are four migration scenario.

* shared -> shared
* shared -> insulated
* insulated -> shared
* insulated -> insulated

To get Openvz to know a container is mounted on its own filesystem, optional parameter '''VE_DEVICE''' is defined in configuration file.

To get Openvz mount the filesystem before starting the container, '''vps.premount''' can have:
<pre>
source ${VE_CONFFILE}
[ -d ${VE_PRIVATE} ] || mkdir ${VE_PRIVATE}
[ -n "$VE_DEVICE" ] && mount ${VE_DEVICE} ${VE_PRIVATE} || echo -n " "
</pre>

Similarly to get the filesystem unmounted after the container is stopped, we can have in vps.postumount:
<pre>
#!/bin/bash
source ${VE_CONFFILE}
if [ -n "$VE_DEVICE" ]; then
umount ${VE_PRIVATE} 2> /dev/null || echo -n ""
fi
</pre>

This configuration along the use of a SAN, gives interesting advantages when migrating containers that last so long at sincronization phase. If the same device is presented in both HN, we can skip sincronization phase. Migration only have to unmount filesystem in source HN and mount the filesystem in target HN avoiding this way the copy of data.

If we want to improve and minimize migration time, we could consider sharing another device for dump/undump container and share this way the file between HN. Using
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 ==
[[Image:Vzmigrate_a.jpeg|400px]]

Migration in this case, as you would expect, es the same as always.

[[Image:Vzmigrate_b.jpeg|400px]]
<pre>
vzmigrate --dst-device /derv/sdg1 HN_target 123
</pre>

[[Image:Vzmigrate_c.jpeg|400px]]

Remove VE_DEVICE parameter from 123.conf and operate the same as shared-shared

Mount/unmount container's filesystem if appropriated.

[[Image:Vzmigrate_d1.jpeg|400px]]
<pre>
vzmigrate --dst-device /dev/sdm1 HN_target 123
</pre>

[[Image:Vzmigrate_d2.jpeg|400px]]
<pre>
vzmigrate HN_target 123
</pre>

If you use a shared dump filesystem between HN.
<pre>
vzmigrate --dump-device /dev/VG/dump --online HN_target 123
</pre>

== Undo actions ==
The issue has got me a lot hard work when modifying vzmigrate is to track undo actions when a error arised in the code. May I permit to restructure undo actions in a function that follows the next diagram.

[[Image:Vzmigrate_undo.jpeg|250px|center]]

== Other issues ==
Creating a container over a insulated filesystem is not possible straightly because of vzctl complains if the the device is previously mounted under VE_PRIVATE. To overcome this:
<pre>
vzctl create 123 --private /var/tmp/123
mkdir /vz/private/123;
mount /dev/sda1 /vz/private/123
mv /var/tmp/123/* /vz/private/123
# reflect this change in VE_PRIVATE parameter in /etc/vz/conf/123.conf
</pre>

== Links to vzmigrate modified ==
ftp://ftp.uma.es/pub/Linux/openvz/

[[Category:HOWTO]]

Vzmigrate filesystem aware

2012-05-31T08:31:47Z

Jcrey: /* Undo actions */

== Motivation ==
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 thought about long ago, but I considered difficult to do in my actual
implementation. Now things had 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 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 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 the container to the the same 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.

I have modified migration script to adapt to these circumstances. I have named as '''shared''' those containers that share filesystem with others containers (legacy) and those with their own filesystem as '''insulated'''. With this in mind, there are four migration scenario.

* shared -> shared
* shared -> insulated
* insulated -> shared
* insulated -> insulated

To get Openvz to know a container is mounted on its own filesystem, optional parameter '''VE_DEVICE''' is defined in configuration file.

To get Openvz mount the filesystem before starting the container, '''vps.premount''' can have:
<pre>
source ${VE_CONFFILE}
[ -d ${VE_PRIVATE} ] || mkdir ${VE_PRIVATE}
[ -n "$VE_DEVICE" ] && mount ${VE_DEVICE} ${VE_PRIVATE} || echo -n " "
</pre>

Similarly to get the filesystem unmounted after the container is stopped, we can have in vps.postumount:
<pre>
#!/bin/bash
source ${VE_CONFFILE}
if [ -n "$VE_DEVICE" ]; then
umount ${VE_PRIVATE} 2> /dev/null || echo -n ""
fi
</pre>

This configuration along the use of a SAN, gives interesting advantages when migrating containers that last so long at sincronization phase. If the same device is presented in both HN, we can skip sincronization phase. Migration only have to unmount filesystem in source HN and mount the filesystem in target HN avoiding this way the copy of data.

If we want to improve and minimize migration time, we could consider sharing another device for dump/undump container and share this way the file between HN. Using
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 ==
[[Image:Vzmigrate_a.jpeg|400px]]

Migration in this case, as you would expect, es the same as always.

[[Image:Vzmigrate_b.jpeg|400px]]
<pre>
vzmigrate --dst-device /derv/sdg1 HN_target 123
</pre>

[[Image:Vzmigrate_c.jpeg|400px]]

Remove VE_DEVICE parameter from 123.conf and operate the same as shared-shared

Mount/unmount container's filesystem if appropriated.

[[Image:Vzmigrate_d1.jpeg|400px]]
<pre>
vzmigrate --dst-device /dev/sdm1 HN_target 123
</pre>

[[Image:Vzmigrate_d2.jpeg|400px]]
<pre>
vzmigrate HN_target 123
</pre>

If you use a shared dump filesystem between HN.
<pre>
vzmigrate --dump-device /dev/VG/dump --online HN_target 123
</pre>

== Undo actions ==
The issue has got me a lot hard work when modifying vzmigrate is to track undo actions when a error arised in the code. May I permit to restructure undo actions in a function that follows the next diagram.

[[Image:Vzmigrate_undo.jpeg|250px|center]]

== Other issues ==
Creating a container over a insulated filesystem is not possible straightly because of vzctl complains if the the device is previously mounted under VE_PRIVATE. To overcome this:
<pre>
vzctl create 123 --private /var/tmp/123
mkdir /vz/private/123;
mount /dev/sda1 /vz/private/123
mv /var/tmp/123/* /vz/private/123
# reflect this change in VE_PRIVATE parameter in /etc/vz/conf/123.conf
</pre>

[[Category:HOWTO]]

Vzmigrate filesystem aware

2012-05-31T08:31:25Z

Jcrey: /* Migrations depending on the contexto */

== Motivation ==
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 thought about long ago, but I considered difficult to do in my actual
implementation. Now things had 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 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 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 the container to the the same 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.

I have modified migration script to adapt to these circumstances. I have named as '''shared''' those containers that share filesystem with others containers (legacy) and those with their own filesystem as '''insulated'''. With this in mind, there are four migration scenario.

* shared -> shared
* shared -> insulated
* insulated -> shared
* insulated -> insulated

To get Openvz to know a container is mounted on its own filesystem, optional parameter '''VE_DEVICE''' is defined in configuration file.

To get Openvz mount the filesystem before starting the container, '''vps.premount''' can have:
<pre>
source ${VE_CONFFILE}
[ -d ${VE_PRIVATE} ] || mkdir ${VE_PRIVATE}
[ -n "$VE_DEVICE" ] && mount ${VE_DEVICE} ${VE_PRIVATE} || echo -n " "
</pre>

Similarly to get the filesystem unmounted after the container is stopped, we can have in vps.postumount:
<pre>
#!/bin/bash
source ${VE_CONFFILE}
if [ -n "$VE_DEVICE" ]; then
umount ${VE_PRIVATE} 2> /dev/null || echo -n ""
fi
</pre>

This configuration along the use of a SAN, gives interesting advantages when migrating containers that last so long at sincronization phase. If the same device is presented in both HN, we can skip sincronization phase. Migration only have to unmount filesystem in source HN and mount the filesystem in target HN avoiding this way the copy of data.

If we want to improve and minimize migration time, we could consider sharing another device for dump/undump container and share this way the file between HN. Using
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 ==
[[Image:Vzmigrate_a.jpeg|400px]]

Migration in this case, as you would expect, es the same as always.

[[Image:Vzmigrate_b.jpeg|400px]]
<pre>
vzmigrate --dst-device /derv/sdg1 HN_target 123
</pre>

[[Image:Vzmigrate_c.jpeg|400px]]

Remove VE_DEVICE parameter from 123.conf and operate the same as shared-shared

Mount/unmount container's filesystem if appropriated.

[[Image:Vzmigrate_d1.jpeg|400px]]
<pre>
vzmigrate --dst-device /dev/sdm1 HN_target 123
</pre>

[[Image:Vzmigrate_d2.jpeg|400px]]
<pre>
vzmigrate HN_target 123
</pre>

If you use a shared dump filesystem between HN.
<pre>
vzmigrate --dump-device /dev/VG/dump --online HN_target 123
</pre>

== Undo actions ==
The issue has got me a lot hard work when modifying vzmigrate is to track undo actions when a error arised in the code. May I permit to restructure undo actions in a function that follows the next diagram.

[[Archivo:Vzmigrate_undo.jpeg|250px|center]]

== Other issues ==
Creating a container over a insulated filesystem is not possible straightly because of vzctl complains if the the device is previously mounted under VE_PRIVATE. To overcome this:
<pre>
vzctl create 123 --private /var/tmp/123
mkdir /vz/private/123;
mount /dev/sda1 /vz/private/123
mv /var/tmp/123/* /vz/private/123
# reflect this change in VE_PRIVATE parameter in /etc/vz/conf/123.conf
</pre>

[[Category:HOWTO]]

Vzmigrate filesystem aware

2012-05-31T08:30:41Z

Jcrey:

== Motivation ==
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 thought about long ago, but I considered difficult to do in my actual
implementation. Now things had 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 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 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 the container to the the same 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.

I have modified migration script to adapt to these circumstances. I have named as '''shared''' those containers that share filesystem with others containers (legacy) and those with their own filesystem as '''insulated'''. With this in mind, there are four migration scenario.

* shared -> shared
* shared -> insulated
* insulated -> shared
* insulated -> insulated

To get Openvz to know a container is mounted on its own filesystem, optional parameter '''VE_DEVICE''' is defined in configuration file.

To get Openvz mount the filesystem before starting the container, '''vps.premount''' can have:
<pre>
source ${VE_CONFFILE}
[ -d ${VE_PRIVATE} ] || mkdir ${VE_PRIVATE}
[ -n "$VE_DEVICE" ] && mount ${VE_DEVICE} ${VE_PRIVATE} || echo -n " "
</pre>

Similarly to get the filesystem unmounted after the container is stopped, we can have in vps.postumount:
<pre>
#!/bin/bash
source ${VE_CONFFILE}
if [ -n "$VE_DEVICE" ]; then
umount ${VE_PRIVATE} 2> /dev/null || echo -n ""
fi
</pre>

This configuration along the use of a SAN, gives interesting advantages when migrating containers that last so long at sincronization phase. If the same device is presented in both HN, we can skip sincronization phase. Migration only have to unmount filesystem in source HN and mount the filesystem in target HN avoiding this way the copy of data.

If we want to improve and minimize migration time, we could consider sharing another device for dump/undump container and share this way the file between HN. Using
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 ==
[[Archivo:Vzmigrate_a.jpeg|400px]]

Migration in this case, as you would expect, es the same as always.

[[Image:Vzmigrate_b.jpeg|400px]]
<pre>
vzmigrate --dst-device /derv/sdg1 HN_target 123
</pre>

[[Archivo:Vzmigrate_c.jpeg|400px]]

Remove VE_DEVICE parameter from 123.conf and operate the same as shared-shared

Mount/unmount container's filesystem if appropriated.

[[Archivo:Vzmigrate_d1.jpeg|400px]]
<pre>
vzmigrate --dst-device /dev/sdm1 HN_target 123
</pre>

[[Archivo:Vzmigrate_d2.jpeg|400px]]
<pre>
vzmigrate HN_target 123
</pre>

If you use a shared dump filesystem between HN.
<pre>
vzmigrate --dump-device /dev/VG/dump --online HN_target 123
</pre>

== Undo actions ==
The issue has got me a lot hard work when modifying vzmigrate is to track undo actions when a error arised in the code. May I permit to restructure undo actions in a function that follows the next diagram.

[[Archivo:Vzmigrate_undo.jpeg|250px|center]]

== Other issues ==
Creating a container over a insulated filesystem is not possible straightly because of vzctl complains if the the device is previously mounted under VE_PRIVATE. To overcome this:
<pre>
vzctl create 123 --private /var/tmp/123
mkdir /vz/private/123;
mount /dev/sda1 /vz/private/123
mv /var/tmp/123/* /vz/private/123
# reflect this change in VE_PRIVATE parameter in /etc/vz/conf/123.conf
</pre>

[[Category:HOWTO]]

File:Vzmigrate undo.jpeg

2012-05-31T08:25:42Z

Jcrey: undo actions flowchart

undo actions flowchart

File:Vzmigrate d2.jpeg

2012-05-31T08:24:30Z

Jcrey: migration between insulated containers with share device

migration between insulated containers with share device

File:Vzmigrate d1.jpeg

2012-05-31T08:23:48Z

Jcrey: migration between insulated containers

migration between insulated containers

File:Vzmigrate c.jpeg

2012-05-31T08:23:19Z

Jcrey: migration from insulated container to shared container

migration from insulated container to shared container

File:Vzmigrate b.jpeg

2012-05-31T08:20:56Z

Jcrey: migration from shared container to a insulated container

migration from shared container to a insulated container

File:Vzmigrate a.jpeg

2012-05-31T08:20:17Z

Jcrey: migration between containers without separate partitions

migration between containers without separate partitions

Vzmigrate filesystem aware

2012-05-31T08:18:46Z

Jcrey: Created page with "== Motivation == Reading thoroughly quick installation documentation, it says "It is recommended to use a separate partition for container's private directories (by default /vz/p..."

== Motivation ==
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 thought about long ago, but I considered difficult to do in my actual
implementation. Now things had 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 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 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 the container to the the same 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.

I have modified migration script to adapt to these circumstances. I have named as '''shared''' those containers that share filesystem with others containers (legacy) and those with their own filesystem as '''insulated'''. With this in mind, there are four migration scenario.

* shared -> shared
* shared -> insulated
* insulated -> shared
* insulated -> insulated

To get Openvz to know a container is mounted on its own filesystem, optional parameter '''VE_DEVICE''' is defined in configuration file.

To get Openvz mount the filesystem before starting the container, '''vps.premount''' can have:
<pre>
source ${VE_CONFFILE}
[ -d ${VE_PRIVATE} ] || mkdir ${VE_PRIVATE}
[ -n "$VE_DEVICE" ] && mount ${VE_DEVICE} ${VE_PRIVATE} || echo -n " "
</pre>

Similarly to get the filesystem unmounted after the container is stopped, we can have in vps.postumount:
<pre>
#!/bin/bash
source ${VE_CONFFILE}
if [ -n "$VE_DEVICE" ]; then
umount ${VE_PRIVATE} 2> /dev/null || echo -n ""
fi
</pre>

This configuration along the use of a SAN, gives interesting advantages when migrating containers that last so long at sincronization phase. If the same device is presented in both HN, we can skip sincronization phase. Migration only have to unmount filesystem in source HN and mount the filesystem in target HN avoiding this way the copy of data.

If we want to improve and minimize migration time, we could consider sharing another device for dump/undump container and share this way the file between HN. Using
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 ==
[[Archivo:Vzmigrate_a.jpeg|400px]]

Migration in this case, as you would expect, es the same as always.

[[Archivo:Vzmigrate_b.jpeg|400px]]
<pre>
vzmigrate --dst-device /derv/sdg1 HN_target 123
</pre>

[[Archivo:Vzmigrate_c.jpeg|400px]]

Remove VE_DEVICE parameter from 123.conf and operate the same as shared-shared

Mount/unmount container's filesystem if appropriated.

[[Archivo:Vzmigrate_d1.jpeg|400px]]
<pre>
vzmigrate --dst-device /dev/sdm1 HN_target 123
</pre>

[[Archivo:Vzmigrate_d2.jpeg|400px]]
<pre>
vzmigrate HN_target 123
</pre>

If you use a shared dump filesystem between HN.
<pre>
vzmigrate --dump-device /dev/VG/dump --online HN_target 123
</pre>

== Undo actions ==
The issue has got me a lot hard work when modifying vzmigrate is to track undo actions when a error arised in the code. May I permit to restructure undo actions in a function that follows the next diagram.

[[Archivo:Vzmigrate_undo.jpeg|250px|center]]

== Other issues ==
Creating a container over a insulated filesystem is not possible straightly because of vzctl complains if the the device is previously mounted under VE_PRIVATE. To overcome this:
<pre>
vzctl create 123 --private /var/tmp/123
mkdir /vz/private/123;
mount /dev/sda1 /vz/private/123
mv /var/tmp/123/* /vz/private/123
# reflect this change in VE_PRIVATE parameter in /etc/vz/conf/123.conf
</pre>

[[Category:HOWTO]]