exporting a vm image

[Kenneth Armstrong]

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.

[Richard W.M. Jones]

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.

http://www.puppetlabs.com/

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]

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(a)redhat.com&gt; 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.

http://www.puppetlabs.com/

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