WildWestDesigns
Active Member
While I'm a big believer in VMs, shoot I've been known to run 3 VMs at one time (that's 4 OSs going on at the same time (this is including the Host OS) and that's with one VM inside another one, this actually isn't totally true.
OS support in VM software can be deprecated. Example would be Win 98 (a VM that I run within another VM). It has been deprecated in VMWare, and Parallels. Not removed yet, but removal can happen within any new release. Win 98 hasn't been supported at all, not just deprecated, but removed, in Microsoft's own hypervisor since VirtualPC 2007. HyperV (which is available in Win 10) doesn't support it or anything before XP PRO SP3. Yep, with HyperV its not only a certain version of XP, but Service Pack as well. No support for HOME versions of later Win OSs after XP as well. Business/Pro and up only if I'm reading Guest requirements right.
Bare in mine anything before XP has not been truly supported in VirtualBox (which I use since I run Linux, but VMWare can also be used on Linux), that's why I have to run a VM of Vista and then within Vista run VirtualPC 2007 (last version to support Win 98) to run Win 98. If I were to try to run Win 98 directly in VirtualBox, booting the VM, it may crash 9 out of 10 times before it successfully launched. Every now and again after that success, after so long it would blue screen. It wouldn't kill the session, but it would blue screen. It also moved much much slower since it didn't have the support within "Guest Additions". Now running it inside another VM, it's a totally different story and pretty close to parity performance wise if it was to have been installed on bare metal (which is ironic considering it's running inside 2 other OSs).
Now as far as transferring the Guest OS from one computer to another. Yes, since it is one file, it's easier to transfer/backup. However, since in a VM you are passing through info about the MB and other hardware to it, it can still be locked to a specific host computer, so OSs and programs that required activation/deactivation may break when transferring from one computer to the next. If the OS breaks activation, typically the programs will follow as well. But not always the case, depends on how "sensitive" the programs are to this as well. Sometimes they can break activation, but not the OS.
In general with VMs to, you want to make sure that your computer is spec'ed out for VMing. Your needs are twice as much running a VM (at minimum, more if running more then one VM at the same time), then they would be just running one OS. Depending on what OS you are running as Host and as Guest (and the Guest programs needs) would determine that need. Windows is the one with most bloat in it (that's what happens when "you" have a lot of legacy support still in the OS) as a host. Mac is too as well. Depending on what DE you use, Linux (even a 64 bit version) may come in as the lightest for a host OS, I have one version that idles at 500 MBs of RAM for the 64 bit version, that's not happening with Win 10. I'm not running slow hardware either, but using a Host OS like that, I'm able to put forth more resources to the VM, which is a good thing.
This isn't going into the "fun" that it takes to VM MacOS (remember the EULA on MacOS doesn't allow for it to be run on non Apple hardware (Hackintosh) or virtualized). Some functionality can actually be broken when VMing OSX (that functionality may or may not be needed by the user, so it may be a non issue, also can apply to a Hackintosh use case as well) unless one goes through a lot of hoops. Again, that "broken" functionality may or may not matter to the user.
One lat thing, virtualizing is not the same thing as emulation. Even though a lot of people think that it is and use those terms interchangeably (no one in this thread has done that just throwing this out there). Virtualizers (VirtualBox, VMWare, Parallels) cannot emulate, while emulators (QEMU, Bochs, Limbo (which is actually based off of QEMU)) can also virtualize. The biggest difference is that VM software uses the physical hardware that's on the machine. Emulators, through software, can actually spoof hardware that isn't on the computer. That's how we are able to run ARM software on X86 hardware and vice versa (I have run Win 98 on an Android phone). Emulation takes a greater hit performance wise then VMing due to that ability. For production efficiency, you want to virtualize not emulate if you have to go this route.
Last edited: