======Libvirt======
=====Resize qcov2 image=====
<code>
# Shut down vm

# On host (to grow 8GB):
qemu-img resize /images/myimage.qcow2 +8GB

# Start vm
# Assuming lvm logical volume inside extended partition...
# fdisk -l should now show the new disk size.
# run parted
(parted) resizepart 2
16GB
(parted) resizepart 5
16GB
(parted) quit

# resize volume group
pvresize /dev/sda5 # on lvm partition

# extend lvm
lvextend -l +100%FREE /dev/mapper/devuan--vg-root

# finally resize file system
resize2fs /dev/mapper/devuan--vg-root
</code>

=====List VMs=====
<code>
virsh list --all
</code>

=====Copy a VM=====
====Export====
In this example a running VM named 'foobar' is exported:
<code>
cd /my/backup/dir/foobar
virsh dumpxml foobar > foobar.xml
</code>

In order to copy the virtual harddrive the VM probably needs to be shut down. Otherwise the running state will need a memory dump as well and we don't want that now.
So; shut down the VM and run the following command:
<code>
# Find location of image:
virsh dumpxml foobar | grep '\.img'

cd /my/backup/dir/foobar
cp /location/of/image/foobar.img .
</code>

====Import====
Now we can import it again. First copy the harddrive image to the correct location and make sure to modify the xml accoringly (if it was moved). Optionally change the name if so desired by modifying the contents of the <name> tag in line 2.
Now import the VM:
<code>
cd /my/backup/dir/foobar
virsh define foobar.xml
</code>

=====Backup a running VM=====
====Store====
<code>
cd /my/backup/dir/foobar

# Dump the state (memory, network etc...)
virsh save foobar foobar.state

# Dump the VM configuration
virsh dumpxml foobar > foobar.xml

# Copy the virtual harddrive
# Find location of image:
virsh dumpxml foobar | grep '\.img'
cp /location/of/image/foobar.img .
</code>

At this point the complete VM state has been stored but the VM is stopped.
In order to resume the VM from the point where it left off, it must be resumed from the just saved state:
<code>
virsh restore foobar.state
</code>

**IMPORTANT**: After restoration, the VM will have its RTC (clock) set to whatever it was on store time. This means that the clock will be out of sync by probably a couple minutes (depending on how long it took to copy the virtual harddisk) and this must be handled by the VM by for example using ntpd.

**NOTE**: Using ntpd to sync a clock that is more than a matter of seconds out-of-sync might require special attention to its config file as it might refuse to synchronize the clock because it is too much out of sync.

FIXME: Use "virsh blockcopy" for harddrive backup, which will reduce downtime to a matter of seconds in the VM.
====Restore====
<code>
cd /my/backup/dir/foobar

# Copy the virtual harddrive
virsh dumpxml foobar | grep '\.img'
cp /location/of/image/foobar.img .

# Recreate VM configuration from file:
virsh define foobar.xml

# Restore the state (memory, network etc...)
virsh restore foobar.state
</code>

**WARNING**: After restoration the rtc (clock) will be set to whatever it was on store time. Set the date manually by calling ntpdate (on centos call: "service ntpdate start")