On Thursday, 18 June 2020 00:09:45 BST William Kenworthy wrote: > On 18/6/20 3:55 am, J. Roeleveld wrote: > > On 17 June 2020 21:32:19 CEST, Michael <confabul...@kintzios.com> wrote: > >> On Wednesday, 17 June 2020 18:31:42 BST J. Roeleveld wrote: > >>> On 17 June 2020 19:01:54 CEST, Michael <confabul...@kintzios.com> > > > > This brings another problem I have with KVM/QEMU: all howtos and documents > > I find show long commandline options to just start the VM. I have not > > found one where I can provide all the config in a single file and use > > that. Allowing me to duplicate settings by simply copying the file and > > changing a few lines. > > > > KVM/Qemu seems to be written to be used together with virt-manager which, > > for me, lacks important features to make it usable in production. > > > > -- > > Joost > > Until a few months ago I was using Qemu/KVM/VirtManager with snapshots > for linux and Windows VM's running network services - the trick is > redundancy and suspend. > > Using libvirt, suspend the VM which copies ram to disk, then snapshot > ((I used btrfs) both the ram and storage and restart the VM - takes > seconds (so redundancy may be needed) - at this point I backup'ed the > snapshot and deleted it.
Ahh! Yes! I had seen the Virsh command which involves pausing a live image and then taking a snapshot of it. William's pointer makes sense. However, there is also the option to define a memory file as an object '-object memory-backend-file,size=1M,share,mem-path=/dev/shm/blah...' and this can be attached/detached/migrated/snapshoted/etc between hosts as desired. More details here (search for "Generic object creation"): https://qemu.readthedocs.io/en/latest/system/invocation.html > When using snapshots of live systems, I had problems restoring some of > the more active VM's which this avoids. > > > BillK Perhaps the technique with busy systems, other than pausing > snapshot, could involve using a migration of the image to a new location? As I understand it the newly migrated image will take over and start running in place of the old image, the moment the migration is completed. Scratching around I found the way to move an image from a qcow2 file on the host fs, to a raw format on a disk/partition. It is simpler than I thought (even with no libvirt): qemu-img convert -O raw image.qcow2 /dev/sda5 Or, the output can be 'image.raw' then keep a backup copy of it as a file and then dd it to a partition.disk.
signature.asc
Description: This is a digitally signed message part.
