DokuWiki

Processes will be different for machines with Debian and/or RedHat ancestry. We will avoid RedHat as it seems t oexist mainly for the purpose of generating headaches. Debian docs may be better because Debian doesn't profit from offering their own certification courses.

This could be as simple as a PC or a laptop computer, but there are certain attributes which are profitable in a VM server – mainly CPU and RAM. RAM is probably more important than CPU but CPU becomes more important if you plan to run more heavily-utilized virtual machines. Disk space is a distant third unless you're only running a single VM server.

If your VMs are low-use, they can be shared amongst a relatively small number of physical CPUs without this being noticed by VM users. This sharing of a small number of CPUs amongst VMs which have substantially more virtual CPUs is called “CPU Over-committing.” It almost always works well, unless there is one or more VMs which hog sufficient CPUs to create a shortage on the VM server.

Over-committing RAM (i.e., VMs are setup to have, collectively, more RAM than the VM server has) is dangerous as it can lead to thrashing on the VM server which like any other sort of memory shortage can draw the server down into a locked/useless state.

If using local disks, make them fast, RAID1 or RAID10. Hardware RAID is unnecessary as well as expensive. Remember to leave some RAM on your VM server for the OS to use. The more spare RAM, the more local disk cache will be available, and the further away from resource starvation you will be.

(creating a BRIDGE in Debian, discussion with examples)

# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

allow-hotplug eno1

auto br0
iface br0 inet dhcp
   bridge_ports eno1
   bridge_stp off
   bridge_fd 0
   bridge_maxwait 0
   bridge_hw eno1