[clug] Seeking FOSS Hypervisor and Management GUI

[Bob Edwards]

On 01/10/14 12:37, George at Clug wrote:
>      From the discussion so far, I may stay with KVM, Virt-Manager (not
> sure if it would be a good idea (could cause stability issues) for me
> to manually install later versions of virt-manager and required
> dependencies?.
>
> The virtualisation features that I want are a short list, just
> snapshots are an important item on the list, so Virt-Manager supports
> most of what I want to do, and with a few command line commands, my
> needs could be answered.  More experimentation and more experience
> will help me learn the limitations and reliability of Linux
> virtualisation.

Of course, "snapshots", as you are wanting to use them, are just a
"convenience".

You can almost as easily just shutdown your VM when it is good, run dd
etc. into gzip to get a copy of the VM disk image, then start it back
up and go ahead and break it.

When you want the original back, just gunzip and dd the saved image
back over the broken VM filesystem and you effectively have the same
result as a snapshot...

Do it again and again, until you get bored...

Script it all up, for more convenience...

Cheers,

Bob Edwards.

>
> And not sure when Debian or CentOS are likely to update to
> Virt-Manager > 1.0 and thus support snapshots from GUI. So as
> suggested, learning the command line for virsh may be the way to go.
>
>
> I find command lines difficult, slower to learn, I can never remember
> the syntax, and I am prone to type the wrong thing, whereas using a
> GUI, you can look for the feature you want to use, and then select
> it.  For me, I find the GUI method of managing systems is much faster
> and less prone to user error.  Keeping  scripts of commands for
> specific tasks (for working on your servers), and running these
> scripts when needed, is one way to minimize user typing errors. Maybe
> I can write a script for each virtual machine that "takes snapshot,
> installs update, validates services are still available,
> removes/consolidates snapshot, or automatically roles back, and then
> emails me the result" ? and then schedule this script for 2:00am each
> day or week or month depending on the frequency I want updates to be
> installed.
>
> If anyone else out there is using virtualisation, I would be
> interested in reading about your adventures.  Bob, Stephen if you
> have any other personal experiences you are willing to share, it will
> make fun reading too.
>
> _Here is bit more of my (continuing) research;_
>
> https://wiki.archlinux.org/index.php/libvirt#Live_snapshots
> Live snapshots A feature called external snapshotting allows one to
> take a live snapshot of a virtual machine without turning it off.
> Currently it only works with qcow2 and raw file based images.
>
> http://cuckoo.readthedocs.org/en/latest/installation/guest/saving/
> https://nsrc.org/workshops/2014/sanog23-virtualization/raw-attachment/wiki/Agenda/ex-debian-kvm-libvirt.htm
> Snaphots are supported using the qcow2 format; the disk image file
> contains both the disk snapshots and the CPU/RAM state.
>
> VM snapshots can be managed using the following commands.
> $ virsh snapshot-create
> $ virsh snapshot-list “VM-Name”
> $ virsh snapshot-revert
> $ virsh snapshot-delete “VM-Name” 1234567890
>
>
> http://docs.fedoraproject.org/en-US/Fedora/18/html/Virtualization_Administration_Guide/chap-Virtualization_Administration_Guide-Managing_guests_with_virsh.html
>
> This table contains virsh command options for snapshots:
> Table 15.7. Snapshot options
> Command     Description
> snapshot-create  Create a snapshot.
> snapshot-current  Get the current snapshot.
> snapshot-delete  Delete a domain snapshot.
> snapshot-dumpxml  Dump XML for a domain snapshot.
> snapshot-list  List snapshots for a domain.
> snapshot-revert  Revert a domain to a snapshot.
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Administration_Guide/chap-Virtualization_Administration_Guide-Managing_guests_with_virsh.html
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Administration_Guide/sect-snapshot-management.html
>
>
> _Other sites_
> http://wiki.qemu.org/Features/Snapshots
> http://blog.mattbrock.co.uk/virtualisation-with-kvm-and-lvm-on-centos-6-via-the-command-line/
> http://wiki.qemu.org/Features/Livebackup
> http://vitobotta.com/kvm-lvm-virtual-machines-backup-cloning/#sthash.iUJpDIhv.dpbs
> https://nsrc.org/workshops/2014/sanog23-virtualization/raw-attachment/wiki/Agenda/ex-debian-kvm-libvirt.htm
> https://nsrc.org/workshops/2014/sanog23-virtualization/raw-attachment/wiki/Agenda/ex-debian-kvm-libvirt.htm
> http://nickbeare.com/redhat.html
>
> yum install tigervnc-server
>
>
> http://kashyapc.com/2011/10/04/snapshotting-with-libvirt-for-qcow2-images/
> _There are several different types of snapshots possible_. Some idea
> on that:
>
> Internal snapshot: A type of snapshot, where a single QCOW2 file will
> hold both the ‘saved state’ and the ‘delta’ since that saved
> point. ‘Internal snapshots’ are very handy because it’s only a
> single file where all the snapshot info. is captured, and easy to
> copy/move around the machines.
>
> External snapshot: Here, the ‘original qcow2 file’ will be in a
> ‘read-only’ saved state, and the new qcow2 file(which will be
> generated once snapshot is created) will be the delta for the changes.
> So, all the changes will now be written to this delta file.
> ‘External Snapshots’ are useful for performing backups. Also,
> external snapshot creates a qcow2 file with the original file as its
> backing image, and the backing file can be /read/ in parallel with the
> running qemu.
>
> VM State: This will save the guest/domain state to a file. So, if you
> take a snapshot including VM state, we can then shut off that guest
> and use the freed up memory for other purposes on the host or for
> other guests. Internally this calls qemu monitor’s ‘savevm’
> command. Note that this only takes care of VM state(and not disk
> snapshot).
>
>
>
>
>
>
>