On 17 June 2020 19:01:54 CEST, Michael <confabul...@kintzios.com> wrote: >On Wednesday, 17 June 2020 07:32:10 BST J. Roeleveld wrote: >> On Wednesday, June 17, 2020 7:42:30 AM CEST n952162 wrote: >> > On 06/17/20 06:48, J. Roeleveld wrote: >> > > On Tuesday, June 16, 2020 11:08:23 PM CEST n952162 wrote: >> > >> On 06/16/20 22:36, J. Roeleveld wrote: >> <snipped> >> >> > > I have not come across MS HyperV outside of small businesses that >need >> > > some >> > > local VMs. These companies tend to put all their infrastructure >with one >> > > of >> > > the big cloud-VM providers (Like AWS, Azure, Googles,...) >> > > >> > > -- >> > > Joost >> > >> > Thank you for this excellent survey/summary. It tells me that vbox >is >> > good for my current usages, but I should start exposing myself to >Xen as >> > a possible migration path. >> >> I would actually suggest to read up on both Xen and KVM and try both >on >> spare machines. >> See which best fits your requirements and also see if the existing >> management tools actually do things in a way that you can work with. >> >> My systems have evolved over the past 25-odd years and I started >using Xen >> to reduce the amount of physical systems I had running. At the time, >VMWare >> was expensive, KVM didn't exist yet and was missing some important >features >> for a few years after it appeared (not sure if this exists yet, not >found >> anything about it on KVM): >> - limit memory footprint of host-VM during boot. >> - Dedicate CPU-core(s) to the host >> >> Limiting the memory size is important, because there are several >parts of >> the kernel (and userspace) that base their memory-settings on this >amount. >> This is really noticable when the host thinks it has 384GB available >when >> 370GB is passed to VMs. >> >> Dedicating CPU-cores exclusively to the host means the host will >always have >> CPU-resources available. This is necessary because all the >> context-switching is handled by the host and if this stalls, the >whole >> environment is impacted. >> >> For a lab-system, I was also missing the ability to save the full >state of a >> VM for a snapshot. All the howto's and guides I can find online only >talk >> about making a snapshot of the disks. Not of the memory as well. >Especially >> when used to Virtualbox, you will notice this issue. When only >snapshotting >> the disk, your snapshot is basically the state of when you literally >pulled >> the plug of your VM if you want to restore back to this. >> >> For KVM, I have found a few hints that this was planned. But I have >not >> found anything about this. Virt-manager does not (last time I looked) >> support Xen's functionality of storing the memory when creating >snapshots >> either. Which is why I don't use that even for my lab/testing-server. > >As far as I know QEMU with KVM can take snapshots of the current state >of RAM, >disk(s), CPU - it can take snapshots of images while online. > >https://wiki.qemu.org/Features/Snapshots2
Can you point to where in the commands above the memory anf cpu state is actually stored and loaded back when reverting to the snapshot? From what I see, it is only fhe disk image. I really need this feature for lab environments where I need the ability to fully roll back to a running instance. >However, I've only taken snapshots of qcow2 images after I shut down >the VM. >These work as advertised and they are quite handy before major updates/ >upgrades as temporary backups. > > >> As for tips/tricks (below works for Xen, but should also work with >KVM): >> >> The way I create a new Gentoo-VM is simply to create a new >block-device >> (Either LVM or ZFS), do all the initial steps in the chroot from the >host >> and when it comes to the first-reboot, umount the filesystems, hook >it up >> to a new VM and start that. >> >> Because of this, I can update the host as follows: >> - create new "partitions" for the host-system. >> - Install the latest versions, migrate the config across >> - reboot into the new host. >> >> If all goes fine, I can clean up the "old" partitions and prepare >them for >> next time. If there are issues, I have a working "old" version I can >quickly >> revert to. >> >> -- >> Joost > >I've wanted to migrate a qemu qcow2 image file or two of different OS', >all >currently stored on an ext4 partition on my desktop, to a dedicated >partition >on the disk. Would this be possible - how? Would I need to change the >qcow2 >to a raw image? I don't know. One of the reasons I dislike file based images is the lack of transparency and tools. LVM is much simpler for disk based snapshots and management. -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
