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