On the Merits of Virtualization

WetGeek

WHY I CARE
I've read post after post describing the troubles folks are having with dual-boot schemes. One drive or two? Disconnect drives or change partition flags? And when done, what remains are just two systems that can only be booted one-at-a-time. On one system you need to close all all of its applications after saving work-in -progress, then the second system can be booted. Going back to the first system requires doing the same thing on the one you're now using.

WHY VIRTUALIZATION
Virtualization, specifically virtual machines, or VMs, offer significant advantages over dual-boot schemes, and I'll list here some of those advantages. All of them are available using VirtualBox from Oracle Software, the full implenentation of which is free for personal use, even within a business. And it's in the Solus repository as well as available for free on Windows.

1. Only one HDD or SSD is needed. Your main system is the "host" for the "guest" VMs that you create. There's no second disk drive to interfere with the first. No need to disconnect one system or change its partition flags in order to install the second (or third, or fourth ...) system.

2. VMs are small. Not only do the guest systems not need a disk of their own, they start out very small and only grow as required, as they're used. Choosing to create a dynamic virtual disk drive to support your VM is all you need to do in order to make this work. As an example, these are the VMs currently on my Plasma laptop, as seen in VirtualBox's Virtual Media Manager:

3. Snapshots make backups trivial. If you enable shapshots in the VirtualBox Manager, you can make a backup of the current state of a VM in just a few seconds. I take a shapshot of every system after I've first installed the OS, and another snapshot after any major changes I've made to it. That way, if I even do something really stupid and crash the machine, I can instantly revert to the last working state and try not to crash it agin! Snapshots are stored as diffs, so they aren't full copies of the system, and thus don't take up a lot of sppace.

4. VMs can easily be erased. Whatever space a VM does use on your disk drive can easily be recovered when the VM has served its purpose and is no longer needed. Some VMs are intended to live forever, such as the Windows 10 VM that serves as my "dual-boot" with Solus. Others, however, are created to explore an interesting distro, or a different DE than you use, or some other purpose that's temporary in nature. The Virtual Machine Manager can completely remove a VM from your host system's disk in a matter of seconds, freeing all its storage, and it only takes a couple mouse clicks.

5. Performance is excellent. Unlike a simple emulator, VirtualBox can use the hardware virtualization feature of your processor, whether Intel or AMD. So performance differs very little from that of the host machine, assuming your're running just one VM at a time. For tasks done at human speeds, such as writing this post (as I am on one of my VMs now), there's no noticeable diffeence. Running more than one VM at a time causes more performance degration due to the necessary context switching. But any dual-boot scheme allows you to run only one system at a time, at most.

6. Host and guest systems co-exist. As hinted in the previous paragraph, both the host machine and the virtual machine run concurrently. A simple keypress (RightCtrl+F by default) toggles full-screen mode on and off. So if your VM is not at full-screen, you can change from host to guest just by clicking on one or the other with the mouse. If your VM is at full-screen, you can press that key combination to make it smaller. So both systems are always running at the same time, and it's a simple matter to switch from one to the other. Always. Not so with a dual-boot scheme. Obviously, you don't need to abandon your work-in-progress on one in order to change to the other.

7. Host/Guest communication. Although they may be two different operating systems, VirtualBox offers the option to share a clipboard between the host and its guest systems, or to allow drag-and-drop to operate between them. These options can remain disabled by default, or they can be enabled as host-to-guest, guest-to-host, or both ways.

8. No need to burn a USB drive. You create a VM directly from the .ISO file you downloaded. There's no need to write it to a USB drive.

SUMMARY
There are almost certainly even more advantages to VMs that won't occur to me until after I've posted this. But even just considering all the above, I think I've made a good case for giving the idea a fair trial. You could install VirtualBox for free in a few seconds, and create your first VM in a few minutes. And if you decide that you still want to limit yourself to a dual-boot scheme, you can delete the VM, get rid of the VirtualBox Manager, and be none the worse off than you were.

More than a few of us here in the forum use VirtualBox, and would be glad to help anyone who wants to get started with it. At the Solus forum, help will be given to all who ask for it. (Sorry, Professor Dumbledore.)

brent

but it's virtual installation and not a real installation, right? What if you want to keep it?
Cue Morpheus: define 'real,' Neo😉

WetGeek

brent What if you want to keep it?

It lives on your hard drive. You can keep it as long as you like, just as if it were a document you've created with a word processor.

brent

WetGeek but it doesn't live on a partition? you did not make /root, /boot, and space for the operating system per se? Or is it like a bare metal install in concept? Hell, I'd consider anything at this point. You said what would happen if the VM distro audition was over and you wanted to keep the distro installed? Can one have a virtual install distro indefinitely like a bare metal?
Conceptually is the part that's kicking my a** about VM. Once that part falls in place I will get it.

WetGeek

brent but it doesn't live on a partition?

Not a partition of its own. It just lives on the file system, by default in your home directory. Like I said, it's essentially like a word processing document.

Technically, it's actually two files. One is the virtual disk drive that represents its file system, and the other is the virtual machine itself -- the settings and drivers that make up the rest of the VM. In fact, you can create a new VM and have it use a virtual disk drive that already exists. Or you could create the virtual disk drive and later on create one or more VMs to use that file system.

I say "technically," because normally you don't need to know all that. The VirtualBox Manager links the two files, and lists the complete VM with its file system. When you click to run the VM, it's the complete package that's executed. When you run the installer (the .ISO file loaded into the VM's virtual CD drive), it creates the file system just as it would if you burned it to a USB stick and installed it onto a hard drive. Exactly like that.

Everything will fall into place very quickly the first time you give it a try. And it only gets easier with every new VM you create. Given an .ISO file that's already been downloaded, I can create a typical VM in less than 5 minutes. Of course, my first one took a bit longer, but the learning curve really isn't very steep.

brent

I see it as a great way to explore distros. But if you can use that distro daily, and it stores everything, then you never have to sweat out a bare metal install again? I mean you could back up VM distro /home files to Restic and use it everyday? How I'm understanding this is its an identical experience as bare metal just executed differently?
Thanks for your patience. I'll get there someday.

edit: give you a for instance. say ultramarine was enjoyable and a great #2, and you decided to keep it in case an update or human error borked Solus. It's the same ultramarine in VM or bare metal form, as far as functionality, and being a backup #2 OS?

murbert

brent But if you can use that distro daily, and it stores everything, then you never have to sweat out a bare metal install again?

You need sufficient ram to use VMs as a daily (or at all really). 8 GB ram at a minimum on your machine, IMO. 16GB would much better. 8 for the host and 8 for the VM

murbert

brent edit: give you a for instance. say ultramarine was enjoyable and a great #2, and you decided to keep it in case an update or human error borked Solus. It's the same ultramarine in VM or bare metal form, as far as functionality, and being a backup #2 OS?

If you bork the OS the VM is running in, the VM is gone too

murbert

brent For clarity:
Bare metal install = host os
VM = file inside host os
If you lose (bork) the host os, any files/VMs in it are subject to loss. A VM inside a host os cannot be considered a safety net for it's host as you wont be able to run it if the host isn't running

WetGeek

murbert 8 GB ram at a minimum on your machine, IMO. 16GB would much better.

That's certainly true. But the more ram you have available, and the faster your CPU, the better performance you'll get while doing anything with your computer. The Dell laptop I used to create all my VMs has 8 GB of RAM and a 4-core CPU, and it's several years old -- definitely not a powerhouse.

A VM isn't ideal for all-day intensive computing, but that's not what I do with my VMs (or suggest that anyone else do with VMs). I use them for exploring other distros or alternative DEs and to try out various themes, and I configure them with Thunderbird and Vivaldi so I can check out a distro doing typical daily tasks. And I use my Windows VM for running software that simply isn't available for Linux, like the Nook ebook reader I occasionally use.

I'm not suggesting that anyone use a VM to replace their host system for tasks that are computing-intensive. But having one or more VMs on a computer doesn't prevent it from doing anything it could do without the VMs on it.

The only way you can find out if virtualization is useful for you and your hardware is to give it a try. If it doesn't make you happy, you can easily remove it.

WetGeek

murbert If you bork the OS the VM is running in, the VM is gone too

Very true. Just as if you bork your OS, whatever else you were working on is gone, too. Backups are important.

But that scenario is very unlikely to begin with. How many times have you crashed your computer while you were writing a letter? Or checking your email? For me, that answer is "never."

If it ever happens to you, it won't be the VM that caused the problem.

synth-ruiner

I do use VMs every day, but mostly for work (development web server), compiling/testing executables for Windows, and general testing (checking out a distro, alternative OS, etc.) but my computers are all about a decade old and virtualisation performance isn't that good. I can do a bunch of stuff with VMs but I couldn't really get a full day-to-day desktop experience on one.

WetGeek

synth-ruiner I do use VMs every day, but mostly for work (development web server)

I used to do that as well. I was working for a company (Vertafore, Inc.) that provides software to automate insurance offices. It was all client/server stuff. On a relatively powerful workstation that I built, I could run several servers (webservices and SQL servers) and one or more clients at the same time on VMs to test office scenarios.

I didn't actually use them for building the .EXEs, but for testing and even remote debugging, they were ideal.

brent

tomscharbach I got all WetGeek Wetgeek's stuff, but thank for going the extra mile conceptually. I did need that push. and murbert thanks for if you die in the matrix you die in youer physical form (that's how I heard it!).
I'm satisfied with how this works. From everything I've read I'm more comfortable exploring with Gnome Boxes than true VM ware.

But, at the end of the day, if you want a physical #2 backup OS in case your primary fails, then you have to sweat out a white-knuckled anxiety-filled fingers-crossed bare metal install like the rest of us😉.

edit: All 3 of yous: thanks for the great info

tomscharbach

@brent I've been following this thread carefully. @WetGeek has done an excellent job of describing virtual machines.

I'm going to contribute a schematic and a bit of additional information about VM's to help you conceptualize how VM's work, because a few of the comments you've made suggest to me that additional information might be helpful.

First the diagram:

Now the additional information:

(1) HYPERVISOR

VM's create a software-based version of a computer, with dedicated CPU resources, memory and storage. VM's are created by a "Hypervisor", a software layer that allows the VM to interact with the host computer's hardware.

(2) HYPERVISOR TYPES

Two types of Hypervisors exists, commonly referred to as "Type 1" and "Type 2".

Type 1 hypervisors (or direct hypervisors) directly interface with the host computer's hardware, and are used in almost all enterprise VM hosting systems (Amazon, Google, Microsoft and so on). While the host computer's OS is needed to run the computer on which the hypervisor runs, the host computer's OS is not directly involved with the hypervisor or the way in which VM's created by the hypervisor interact with the host computer's hardware. Instead, the hypervisor directly interfaces with the host computer's hardware.

Type 2 hypervisors (or hosted hypervisors) run on the host computer's operating system, interface with the host computer's hardware indirectly "through" the host computer's OS, and are used in consumer and other smaller installations. In this thread, and in every other VM thread I've read on this forum, the discussion is focused on Type 2 hypervisors like VirtualBox, VMWare and Gnome Boxes.

I mention Type 1 hypervisors only because if you start looking around the web for information (and I know you will), you will find resources related to both types, and it is easy to get the two confused. Be aware of Type 1, but focus on Type 2.

The diagram shows the difference (in simple form) between Type 1 and Type 2. In Type 2 installations, the bare metal host OS is directly involved with the way the hypervisor runs and the VM's interface with the host computer's hardware.

For example, when I set up a Gnome Boxes VM, the Gnome Boxes hypervisor connects the VM OS to the internet through a "virtual ethernet" connection created between the VM and the bare metal host OS, which in turn connects to the internet through the wifi adapter used by the bare metal host OS. The situation is similar for almost all hardware interactions between the VM and the host computer's hardware. In very simple terms, the "whole works" in a VM is virtual.

I think that the best way to think about Type 2 hypervisors is the explanation that @WetGeek gave us. The hypervisor (VirtualBox, VMWare, Gnome Boxes) is a program/application running on the bare metal OS (the "Host OS"), which in turn creates and runs other OS's (in each case, a "Guest OS") running independently of the bare metal host OS.

Accordingly, if you think it through:

(1) The Guest OS running in a VM is isolated from the bare metal Host OS, and the Host OS will not be screwed up no matter what you do with the Guest OS.

(2) If the bare metal Host OS crashes and burns, the hypervisor will also crash and burn, as well all the Guest OS VM's created by the hypervisor.

(3) If the hypervisor crashes and burns but the Host OS does not, the Host OS will be unaffected but the Guest
OS VM's created by the hypervisor will almost certainly crash and burn.

(4) Because the Guest OS running in the VM does not directly interface with the host computer's hardware, VM's should not be used to evaluate whether

Be aware, as well, as others have pointed out, the hypervisor "borrows" the host computer's hardware resources -- CPU/GPU cycles, RAM, disk space -- to create and run a Guest OS VM. If the Guest OS requirements are 4 GB RAM and 30GB disk space, then the host computer will be running on whatever it has minus whatever is "borrowed" for the Guest OS (e.g. if the host computer has 8 GB RAM and you run a Guest OS with 4 GB RAM, the host computer will effectively be running on 4 GB).

Usually that's okay when you are running Linux VM's on a Linus Host OS (because both run fine on 4 GB), but keep in mind that the Host OS doesn't stop running when you run a VM, so your computer will need sufficient resources to accommodate both. What is true of RAM is also true of disk space and CPU/GPU. So keep resources in mind.