From Fedora Project Wiki
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 71: | Line 71: | ||
virt-df | virt-df | ||
Does the output agree with the free/used space for that guest? Do you see any error messages? | Does the output agree with the free/used space for that guest? Do you see any error messages? | ||
|- | |- | ||
| virt-cat | | virt-cat | ||
Line 87: | Line 86: | ||
| Make image | | Make image | ||
|| Choose a large tarball and construct a disk image from it. | || Choose a large tarball and construct a disk image from it. | ||
You have to set the size of the disk image in advance, large enough to fit the tarball with some headroom. eg. If the tarball was 10 MB, you might choose a 14 MB image | You have to set the size of the disk image in advance, large enough to fit the tarball with some headroom. eg. If the tarball was 10 MB, you might choose a 14 MB image. So: | ||
guestfish -x alloc output.img 14M : run : \ | guestfish -x alloc output.img 14M : run : \ | ||
sfdiskM /dev/sda , : \ | sfdiskM /dev/sda , : \ | ||
Line 96: | Line 95: | ||
guestfish -a output.img -m /dev/sda1 | guestfish -a output.img -m /dev/sda1 | ||
><fs> ls / | ><fs> ls / | ||
|- | |||
| virt-snapshot | |||
|| Snapshot, rollback and commit an existing virtual machine. Ensure the guest is shut down, then do: | |||
virt-snapshot <guest> | |||
Make some changes (including changing/adding/removing virtual hardware), shutdown the guest again, then do: | |||
virt-snapshot --rollback <guest> | |||
Check the guest is back in its original state. | |||
Shutdown, snapshot the guest again, make some more changes and shutdown again. Commit the changes with: | |||
virt-snapshot --commit <guest> | |||
Check the changes have persisted. | |||
|- | |||
| virt-v2v | |||
|| If you have any Xen Fedora/RHEL guests around, copy them their images over to the test box and export their libvirt domain XML on the remote box with: | |||
virsh dumpxml <guest> > <guest>.xml | |||
Make sure you copy the images to the same location on the test box as they were in on the origin box. Alternatively do some path surgery on the domain xml. Create the following basic virt-v2v.conf: | |||
[libvirtxml] | |||
bridge.xenbr1=virbr0 | |||
If the guest has a PV kernel, obtain an FV kernel relevant to the target OS and add something like the following to your virt-v2v.conf: | |||
[aliases] | |||
rhel.kernel-xen=kernel | |||
rhel.kernel-xenU=kernel | |||
fedora.kernel-xen=kernel | |||
fedora.kernel-xenU=kernel | |||
[files] | |||
rhel.5.kernel=/path/to/kernel.arch.el5.rpm | |||
See virt-v2v.conf(5) for more. Snapshot the images and convert them to run on KVM with: | |||
virt-snapshot -o <guest>-snapshot.xml -i libvirtxml <guest>.xml | |||
virt-v2v -s virt-v2v.conf -i libvirtxml <guest>-snapshot.xml | |||
Does the resulting guest boot? Does it give any errors on boot? Are the VirtIO drivers enabled? If anything looks wrong, please report any error messages, along with any config files in the guest which look broken. | |||
|- | |- | ||
| Advanced | | Advanced | ||
Line 111: | Line 140: | ||
|- | |- | ||
| || || [http://bugzilla.redhat.com/XXXXXX #XXXXX] || '''ASSIGNED''' | | || || [http://bugzilla.redhat.com/XXXXXX #XXXXX] || '''ASSIGNED''' | ||
|} | |} | ||
[[Category:Fedora_13_Test_Days]] | [[Category:Fedora_13_Test_Days]] | ||
[[Category:Virtualization]] | [[Category:Virtualization]] |