What is the cleanest approach to export a vm (disk image along with associated xml file) to an external media, then re-importing that vm back into virt-manager? Some combination of virt-create with --import and virt-convert?
I've got some test vm's that I made clones of, and I would like to back them up to an external source and reimport them at a later time should I need to.
Thanks.
On Sun, Aug 22, 2010 at 04:27:14PM -0400, Kenneth Armstrong wrote:
What is the cleanest approach to export a vm (disk image along with associated xml file) to an external media, then re-importing that vm back into virt-manager? Some combination of virt-create with --import and virt-convert?
virsh dumpxml guest > guest.xml
then copy each disk (eg. with 'dd'). You can get the source disk names by examining the XML above by hand, or by using an xpath query along these lines:
virsh dumpxml guestname | xpath /domain/devices/disk/source
To import, you copy the disks back, and recreate the domain with:
virsh define guest.xml
(If you want to make a clone, rename the disks and edit the XML accordingly).
Now there are issues with this, some of them are philosophical.
The libvirt XML describes a specific running instance of a guest, in that it contains various hard-coded paths. The XML + disk image is not an independent description of the guest (whereas OVF is). There's a format called virt-image which tries to resolve this, but it hasn't really gained much traction.
http://people.redhat.com/dlutter/virt-image/
Also the XML describes the resources that the guest was using, not what it requires. For example, the guest might be able to use either an e1000 network card or virtio-net, but the XML will just say that the guest was using e1000 last time it ran. The only way to tell what a guest requires is to go in and do a detailed examination of the disk image (virt-inspector q.v.). OVF, for all its other failings, does some of this right.
http://libguestfs.org/virt-inspector.1.html
Finally a guest may require modification if you import it into another environment. For example, its network configuration might be wrong when it is imported on another host. Or you might want to change the hostname, give the filesystems new UUIDs, or "sysprep" a Windows guest. Currently you can do some of these sorts of modifications (libguestfs) but it's very much a manual process where you have to know what you're doing and know what needs to be changed.
Some of these issues can be solved by ensuring that your guests are reproducible, using a configuration tool like RHN or Puppet. The approach is that you treat your guests (and physical systems too) as throwaway items that you can sure you can reproduce on demand, typically from a simple kickstart + puppet configuration. This is great if you are disciplined enough to make it work, but in the real world there's just too much ad hoc stuff that sysadmins do, or you have software (often proprietary and expensive) that defies good packaging.
Rich.
Thanks for the info. What i was looking to acheive was trying to do was something along the lines of a single image that contains the xml and disk image (along the lines of OVF) and have the ability to being it back in through something like virt-manager.
On Aug 22, 2010 6:12 PM, "Richard W.M. Jones" rjones@redhat.com wrote:
On Sun, Aug 22, 2010 at 04:27:14PM -0400, Kenneth Armstrong wrote:
What is the cleanest approach t...
virsh dumpxml guest > guest.xml
then copy each disk (eg. with 'dd'). You can get the source disk names by examining the XML above by hand, or by using an xpath query along these lines:
virsh dumpxml guestname | xpath /domain/devices/disk/source
To import, you copy the disks back, and recreate the domain with:
virsh define guest.xml
(If you want to make a clone, rename the disks and edit the XML accordingly).
Now there are issues with this, some of them are philosophical.
The libvirt XML describes a specific running instance of a guest, in that it contains various hard-coded paths. The XML + disk image is not an independent description of the guest (whereas OVF is). There's a format called virt-image which tries to resolve this, but it hasn't really gained much traction.
http://people.redhat.com/dlutter/virt-image/
Also the XML describes the resources that the guest was using, not what it requires. For example, the guest might be able to use either an e1000 network card or virtio-net, but the XML will just say that the guest was using e1000 last time it ran. The only way to tell what a guest requires is to go in and do a detailed examination of the disk image (virt-inspector q.v.). OVF, for all its other failings, does some of this right.
http://libguestfs.org/virt-inspector.1.html
Finally a guest may require modification if you import it into another environment. For example, its network configuration might be wrong when it is imported on another host. Or you might want to change the hostname, give the filesystems new UUIDs, or "sysprep" a Windows guest. Currently you can do some of these sorts of modifications (libguestfs) but it's very much a manual process where you have to know what you're doing and know what needs to be changed.
Some of these issues can be solved by ensuring that your guests are reproducible, using a configuration tool like RHN or Puppet. The approach is that you treat your guests (and physical systems too) as throwaway items that you can sure you can reproduce on demand, typically from a simple kickstart + puppet configuration. This is great if you are disciplined enough to make it work, but in the real world there's just too much ad hoc stuff that sysadmins do, or you have software (often proprietary and expensive) that defies good packaging.
Rich.
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top
-
Kenneth Armstrong -
Richard W.M. Jones