1 |
On Wednesday, June 17, 2020 7:42:30 AM CEST n952162 wrote: |
2 |
> On 06/17/20 06:48, J. Roeleveld wrote: |
3 |
> > On Tuesday, June 16, 2020 11:08:23 PM CEST n952162 wrote: |
4 |
> >> On 06/16/20 22:36, J. Roeleveld wrote: |
5 |
|
6 |
<snipped> |
7 |
|
8 |
> > I have not come across MS HyperV outside of small businesses that need |
9 |
> > some |
10 |
> > local VMs. These companies tend to put all their infrastructure with one |
11 |
> > of |
12 |
> > the big cloud-VM providers (Like AWS, Azure, Googles,...) |
13 |
> > |
14 |
> > -- |
15 |
> > Joost |
16 |
> |
17 |
> Thank you for this excellent survey/summary. It tells me that vbox is |
18 |
> good for my current usages, but I should start exposing myself to Xen as |
19 |
> a possible migration path. |
20 |
|
21 |
I would actually suggest to read up on both Xen and KVM and try both on spare |
22 |
machines. |
23 |
See which best fits your requirements and also see if the existing management |
24 |
tools actually do things in a way that you can work with. |
25 |
|
26 |
My systems have evolved over the past 25-odd years and I started using Xen to |
27 |
reduce the amount of physical systems I had running. At the time, VMWare was |
28 |
expensive, KVM didn't exist yet and was missing some important features for a |
29 |
few years after it appeared (not sure if this exists yet, not found anything |
30 |
about it on KVM): |
31 |
- limit memory footprint of host-VM during boot. |
32 |
- Dedicate CPU-core(s) to the host |
33 |
|
34 |
Limiting the memory size is important, because there are several parts of the |
35 |
kernel (and userspace) that base their memory-settings on this amount. This is |
36 |
really noticable when the host thinks it has 384GB available when 370GB is |
37 |
passed to VMs. |
38 |
|
39 |
Dedicating CPU-cores exclusively to the host means the host will always have |
40 |
CPU-resources available. This is necessary because all the context-switching |
41 |
is handled by the host and if this stalls, the whole environment is impacted. |
42 |
|
43 |
For a lab-system, I was also missing the ability to save the full state of a |
44 |
VM for a snapshot. All the howto's and guides I can find online only talk |
45 |
about making a snapshot of the disks. Not of the memory as well. Especially |
46 |
when used to Virtualbox, you will notice this issue. When only snapshotting |
47 |
the disk, your snapshot is basically the state of when you literally pulled |
48 |
the plug of your VM if you want to restore back to this. |
49 |
|
50 |
For KVM, I have found a few hints that this was planned. But I have not found |
51 |
anything about this. Virt-manager does not (last time I looked) support Xen's |
52 |
functionality of storing the memory when creating snapshots either. Which is |
53 |
why I don't use that even for my lab/testing-server. |
54 |
|
55 |
As for tips/tricks (below works for Xen, but should also work with KVM): |
56 |
|
57 |
The way I create a new Gentoo-VM is simply to create a new block-device |
58 |
(Either LVM or ZFS), do all the initial steps in the chroot from the host and |
59 |
when it comes to the first-reboot, umount the filesystems, hook it up to a new |
60 |
VM and start that. |
61 |
|
62 |
Because of this, I can update the host as follows: |
63 |
- create new "partitions" for the host-system. |
64 |
- Install the latest versions, migrate the config across |
65 |
- reboot into the new host. |
66 |
|
67 |
If all goes fine, I can clean up the "old" partitions and prepare them for |
68 |
next time. If there are issues, I have a working "old" version I can quickly |
69 |
revert to. |
70 |
|
71 |
-- |
72 |
Joost |