diff options
Diffstat (limited to 'docs/src/user/migrating_domains.tex')
| -rw-r--r-- | docs/src/user/migrating_domains.tex | 70 |
1 files changed, 0 insertions, 70 deletions
diff --git a/docs/src/user/migrating_domains.tex b/docs/src/user/migrating_domains.tex deleted file mode 100644 index 42f141bd34..0000000000 --- a/docs/src/user/migrating_domains.tex +++ /dev/null @@ -1,70 +0,0 @@ -\chapter{Migrating Domains} - -\section{Domain Save and Restore} - -The administrator of a Xen system may suspend a virtual machine's -current state into a disk file in domain~0, allowing it to be resumed at -a later time. - -The ttylinux domain described earlier can be suspended to disk using the -command: -\begin{verbatim} -# xm save ttylinux ttylinux.xen -\end{verbatim} - -This will stop the domain named ``ttylinux'' and save its current state -into a file called \path{ttylinux.xen}. - -To resume execution of this domain, use the \path{xm restore} command: -\begin{verbatim} -# xm restore ttylinux.xen -\end{verbatim} - -This will restore the state of the domain and restart it. The domain -will carry on as before and the console may be reconnected using the -\path{xm console} command, as above. - -\section{Live Migration} - -Live migration is used to transfer a domain between physical hosts -whilst that domain continues to perform its usual activities --- from -the user's perspective, the migration should be imperceptible. - -To perform a live migration, both hosts must be running Xen / \xend\ and -the destination host must have sufficient resources (e.g.\ memory -capacity) to accommodate the domain after the move. Furthermore we -currently require both source and destination machines to be on the same -L2 subnet. - -Currently, there is no support for providing automatic remote access to -filesystems stored on local disk when a domain is migrated. -Administrators should choose an appropriate storage solution (i.e.\ SAN, -NAS, etc.) to ensure that domain filesystems are also available on their -destination node. GNBD is a good method for exporting a volume from one -machine to another. iSCSI can do a similar job, but is more complex to -set up. - -When a domain migrates, it's MAC and IP address move with it, thus it is -only possible to migrate VMs within the same layer-2 network and IP -subnet. If the destination node is on a different subnet, the -administrator would need to manually configure a suitable etherip or IP -tunnel in the domain~0 of the remote node. - -A domain may be migrated using the \path{xm migrate} command. To live -migrate a domain to another machine, we would use the command: - -\begin{verbatim} -# xm migrate --live mydomain destination.ournetwork.com -\end{verbatim} - -Without the \path{--live} flag, \xend\ simply stops the domain and -copies the memory image over to the new node and restarts it. Since -domains can have large allocations this can be quite time consuming, -even on a Gigabit network. With the \path{--live} flag \xend\ attempts -to keep the domain running while the migration is in progress, resulting -in typical `downtimes' of just 60--300ms. - -For now it will be necessary to reconnect to the domain's console on the -new machine using the \path{xm console} command. If a migrated domain -has any open network connections then they will be preserved, so SSH -connections do not have this limitation. |