Ziel ist es, hier eine Migration einer bestehenden VM auf einen anderen XEN-Server ohne Shared Storage vorzunehmen. Keine Live-Migration, sondern Offline, um die Integrität zu wahren.
Bestimmen der uuid unserer zu migrierenden Maschine und aller Parameter
[root@xen211 ~]# xe vm-list params=all uuid=742ba99e-5f8b-b29d-e5a4-2f0e647838cb
uuid ( RO) : 742ba99e-5f8b-b29d-e5a4-2f0e647838cb
name-label ( RW): xtradius .178.14
name-description ( RW):
user-version ( RW): 1
is-a-template ( RW): false
is-a-snapshot ( RO): false
snapshot_of ( RO): <not in database>
snapshots ( RO):
snapshot_time ( RO): 19700101T00:00:00Z
is-control-domain ( RO): false
power-state ( RO): running
memory-actual ( RO): 268435456
memory-target ( RO): 268435456
memory-static-max ( RW): 268435456
memory-dynamic-max ( RW): 268435456
memory-dynamic-min ( RW): 268435456
memory-static-min ( RW): 16777216
suspend-VDI-uuid ( RO): <not in database>
VCPUs-params (MRW):
VCPUs-max ( RW): 1
VCPUs-at-startup ( RW): 1
actions-after-shutdown ( RW): Destroy
actions-after-reboot ( RW): Restart
actions-after-crash ( RW): Restart
console-uuids (SRO): 1814bfe2-510e-bbc5-64f0-9100ac1f94d0
platform (MRW): nx: false; acpi: true; apic: true; pae: true; viridian: true
allowed-operations (SRO): snapshot; pause; clean_shutdown; clean_reboot; hard_shutdown; hard_reboot; suspend; changing_VCPUs_live; pool_migrate
current-operations (SRO):
blocked-operations (MRW):
allowed-VBD-devices (SRO): <expensive field>
allowed-VIF-devices (SRO): <expensive field>
possible-hosts ( RO): <expensive field>
HVM-boot-policy ( RW):
HVM-boot-params (MRW):
HVM-shadow-multiplier ( RW): 1.000
PV-kernel ( RW):
PV-ramdisk ( RW):
PV-args ( RW):
PV-legacy-args ( RW):
PV-bootloader ( RW): pygrub
PV-bootloader-args ( RW):
last-boot-CPU-flags ( RO):
last-boot-record ( RO): <expensive field>
resident-on ( RO): 14b1b468-6294-4f7f-8af6-c7d5c5e86d63
affinity ( RW): 14b1b468-6294-4f7f-8af6-c7d5c5e86d63
other-config (MRW): last_shutdown_time: 20090311T11:44:01Z; last_shutdown_action: Destroy; last_shutdown_initiator: external; last_shutdown_reason: halted; linux_template: true; install-methods: ; mac_seed: fafd65c2-fa2a-7cbd-49e4-d2770a34fdf5
dom-id ( RO): 3
recommendations ( RO): <restrictions><restriction field="memory-static-max" max="34359738368" /><restriction field="vcpus-max" max="8" /><restriction property="number-of-vbds" max="7" /><restriction property="number-of-vifs" max="7" /></restrictions>
xenstore-data (MRW):
ha-always-run ( RW): false
ha-restart-priority ( RW):
blobs ( RO):
start-time ( RO): 20090312T20:21:00Z
install-time ( RO): 20090130T20:36:09Z
VCPUs-number ( RO): 1
VCPUs-utilisation (MRO): <expensive field>
os-version (MRO): name: Debian 5.0; uname: 2.6.18.8.xs5.0.0.10.439; distro: debian; major: 5; minor: 0
PV-drivers-version (MRO): major: 5; minor: 0; micro: 0; build: 10918
PV-drivers-up-to-date ( RO): true
memory (MRO):
disks (MRO):
networks (MRO): 0/ip: 192.168.178.14
other (MRO):
live ( RO): true
guest-metrics-last-updated ( RO): 20090312T20:21:07ZDurchführen eines “Safe-Shutdown” unserer Virtuellen Maschine
xe vm-shutdown uuid=742ba99e-5f8b-b29d-e5a4-2f0e647838cb
Herausfinden aller Virtual Disks der VM
[root@xen211 ~]# xe vbd-list params=all vm-uuid=742ba99e-5f8b-b29d-e5a4-2f0e647838cb
uuid ( RO) : 2af47033-2fc8-e377-d4c1-7b77a25833af
vm-uuid ( RO): 742ba99e-5f8b-b29d-e5a4-2f0e647838cb
vm-name-label ( RO): xtradius .178.14
vdi-uuid ( RO): df44a238-b528-48be-b870-58bb73e217d3
vdi-name-label ( RO): 1
allowed-operations (SRO): pause; unpause; attach
current-operations (SRO):
empty ( RO): false
device ( RO): xvdb
userdevice ( RW): 1
bootable ( RW): false
mode ( RW): RW
type ( RW): Disk
unpluggable ( RW): false
currently-attached ( RO): false
attachable ( RO): <expensive field>
storage-lock ( RO): false
status-code ( RO): 0
status-detail ( RO):
qos_algorithm_type ( RW):
qos_algorithm_params (MRW):
qos_supported_algorithms (SRO):
other-config (MRW): owner:
io_read_kbs ( RO): <expensive field>
io_write_kbs ( RO): <expensive field>
uuid ( RO) : 460b14ee-b566-d622-ed69-4ff765074b7b
vm-uuid ( RO): 742ba99e-5f8b-b29d-e5a4-2f0e647838cb
vm-name-label ( RO): xtradius .178.14
vdi-uuid ( RO): <not in database>
vdi-name-label ( RO): <EMPTY>
allowed-operations (SRO): insert; pause; unpause; attach
current-operations (SRO):
empty ( RO): true
device ( RO):
userdevice ( RW): 3
bootable ( RW): false
mode ( RW): RO
type ( RW): CD
unpluggable ( RW): false
currently-attached ( RO): false
attachable ( RO): <expensive field>
storage-lock ( RO): false
status-code ( RO): 0
status-detail ( RO):
qos_algorithm_type ( RW):
qos_algorithm_params (MRW):
qos_supported_algorithms (SRO):
other-config (MRW):
io_read_kbs ( RO): <expensive field>
io_write_kbs ( RO): <expensive field>
uuid ( RO) : d4f56044-e7f3-17fb-9149-268fdd0fe302
vm-uuid ( RO): 742ba99e-5f8b-b29d-e5a4-2f0e647838cb
vm-name-label ( RO): xtradius .178.14
vdi-uuid ( RO): 854c68ca-ce5c-4e02-8101-3dce30e847dd
vdi-name-label ( RO): 0
allowed-operations (SRO): pause; unpause; attach
current-operations (SRO):
empty ( RO): false
device ( RO): xvda
userdevice ( RW): 0
bootable ( RW): true
mode ( RW): RW
type ( RW): Disk
unpluggable ( RW): false
currently-attached ( RO): false
attachable ( RO): <expensive field>
storage-lock ( RO): false
status-code ( RO): 0
status-detail ( RO):
qos_algorithm_type ( RW):
qos_algorithm_params (MRW):
qos_supported_algorithms (SRO):
other-config (MRW): owner:
io_read_kbs ( RO): <expensive field>
io_write_kbs ( RO): <expensive field>Für uns interessant sind alle Zeilen, die die vdi-uuid enthalten, und dort auch nur die, die in der Datenbank vorhanden sind, also auch im LVM sichtbar sind.
xe vbd-list params=vdi-uuid vm-uuid=742ba99e-5f8b-b29d-e5a4-2f0e647838cb | awk '/[:alnum:]/ && !/not in database/{print $NF}'Die zugehörigen LVs heißen dann
lvs | grep -E $(echo $(xe vbd-list params=vdi-uuid vm-uuid=742ba99e-5f8b-b29d-e5a4-2f0e647838cb | awk '/[:alnum:]/ && !/not in database/{printf "|%s",$NF}' | cut -c2-)) | awk '{print $1}'Soweit so gut. Jetzt müssen wir die virtuellen Platten noch exportieren, am besten auf unseren lokalen Storage (wenn auch NFS oder eine Pipe ebenfalls möglich wäre). Hierzu sollten wir (generell) eine lokale Datenpartition nutzen.
lvcreate -n datalv -L 20G VG_XenStorage-fa726b3d-8ba1-dc56-e22a-2bec0b519663
mkfs.ext3 /dev/VG_XenStorage-fa726b3d-8ba1-dc56-e22a-2bec0b519663/datalv
tune2fs -c0 -i0 /dev/VG_XenStorage-fa726b3d-8ba1-dc56-e22a-2bec0b519663/datalv
mount /dev/VG_XenStorage-fa726b3d-8ba1-dc56-e22a-2bec0b519663/datalv /data
Damit wir allerdings auf die LVs der virtuellen Maschinen überhaupt zugreifen können, müssen wir
die VG erneut einlesen.
Jetzt kann der Export stattfinden.
dd if=/dev/VG_XenStorage-fa726b3d-8ba1-dc56-e22a-2bec0b519663/LV-854c68ca-ce5c-4e02-8101-3dce30e847dd of=/data/xtradius-4G.img bs=1M
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB) copied, 219.663 seconds, 19.6 MB/s
Diesen bringen wir mittels scp auf den neuen Server (auf dem bereits eine datalv gemountet ist).
Im Gigabit Netzwerk klappt das für unser 4GB Image in wenigen Minuten (ca 20-30MB/sec).
Auf der anderen Maschine erzeugen wir uns wieder eine VM in der wir die Images in die entsprechenden lokalen LVs hineinbringen.
Soweit EDV zu Fuß. Viel gelernt, viel Skripting, aber es geht auch einfacher mittels xe vm-export 
!
