Vzmigrate filesystem aware - Revision history

Jcrey: /* Other issues */

2012-06-08T11:24:52Z

‎Other issues

2012-06-08T11:24:32Z

‎Other issues

2012-06-08T11:22:50Z

‎Other issues

2012-06-08T11:22:27Z

‎Other issues

2012-06-08T11:19:16Z

‎Migrations depending on context

2012-06-08T11:17:56Z

‎Migrations depending on context

2012-06-08T11:15:51Z

‎Motivation

2012-06-08T11:01:14Z

‎Undo actions

2012-06-08T10:52:41Z

‎Motivation

2012-06-08T10:51:08Z

‎Motivation

@@ Line 95: / Line 95: @@
 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
+# reflect these changes in /etc/vz/conf/123.conf
 ...
 VE_PRIVATE="/vz/private/$VEID"

@@ Line 95: / Line 95: @@
 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
+# reflect these changes in VE_PRIVATE parameter in /etc/vz/conf/123.conf
 ...
-VE_DEVICE=/dev/sda1
+VE_PRIVATE="/vz/private/$VEID"
 ...
 </pre>

@@ Line 96: / Line 96: @@
 mv /var/tmp/123/* /vz/private/123
 # reflect this change in VE_PRIVATE parameter in /etc/vz/conf/123.conf
 ...
 VE_DEVICE=/dev/sda1

@@ Line 96: / Line 96: @@
 mv /var/tmp/123/* /vz/private/123
 # reflect this change in VE_PRIVATE parameter in /etc/vz/conf/123.conf
 </pre>

← Older revision		Revision as of 11:19, 8 June 2012
Line 62:		Line 62:

	Remove VE_DEVICE parameter from 123.conf and operate the same as shared-shared		Remove VE_DEVICE parameter from 123.conf and operate the same as shared-shared
−
−	~~Mount/unmount container's filesystem if appropriated.~~

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

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

← Older revision		Revision as of 11:01, 8 June 2012
Line 84:		Line 84:

	== Undo actions ==		== 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.	+	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.

@@ Line 9: / Line 9: @@
 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.
+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.

@@ Line 2: / Line 2: @@
 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 current
+This is something I thought about long ago, but I considered difficult to do in current
-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.
+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 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.
+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.