public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Michael <confabulate@kintzios.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] virtualbox in headless configuration broken after update: delayed echo [ RESOLVED, kinda ]
Date: Wed, 17 Jun 2020 18:01:54 +0100	[thread overview]
Message-ID: <1665222.VLH7GnMWUR@lenovo.localdomain> (raw)
In-Reply-To: <1745811.atdPhlSkOF@eve>

[-- Attachment #1: Type: text/plain, Size: 3996 bytes --]

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


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?

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2020-06-17 17:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-10 13:19 [gentoo-user] virtualbox in headless configuration broken after update: delayed echo n952162
2020-06-16 19:07 ` [gentoo-user] virtualbox in headless configuration broken after update: delayed echo [ RESOLVED, kinda ] n952162
2020-06-16 20:36   ` J. Roeleveld
2020-06-16 21:08     ` n952162
2020-06-17  4:48       ` J. Roeleveld
2020-06-17  5:42         ` n952162
2020-06-17  6:32           ` J. Roeleveld
2020-06-17 17:01             ` Michael [this message]
2020-06-17 17:31               ` J. Roeleveld
2020-06-17 19:32                 ` Michael
2020-06-17 19:55                   ` J. Roeleveld
2020-06-17 23:05                     ` Michael
2020-06-17 23:09                     ` William Kenworthy
2020-06-18  9:21                       ` Michael

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1665222.VLH7GnMWUR@lenovo.localdomain \
    --to=confabulate@kintzios.com \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox