1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
|
\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.
|
