In prior posts (1 & 2), I reviewed Microsoft’s determination to force Windows 7 users to switch to Windows 10, perhaps against their own best interests. As discussed in another post, it seemed advisable to respond by reducing the user’s dependence on Microsoft. The best way to do this appeared to be to shift at least some of one’s workload to another operating system. Linux appeared to offer a solution. Among the various Linux distributions, a separate post tentatively concluded that Linux Mint with the KDE desktop environment (DE) might be especially appealing to a Windows 7 power user.
The next question was, where and how should this Linux Mint KDE download be installed? Normally, the user would install an operating system on a hard disk drive (HDD) or solid state drive (SSD) mounted internally in the computer. If the disk already had Windows or some other operating system installed on it, then a dual-boot partitioning arrangement would have to be made, so that either operating system (OS) could be booted up.
Dual-booting had the drawback of making only one OS available at a time. That would be problematic if the user could not set aside days or weeks to install, learn, and modify the new Linux system to replace the old Windows system. It could be frustrating to have to quit what one was doing in one OS, and reboot into the other, every time a need arose for the other OS.
A virtual machine (VM) setup might provide a workable response. The user could install Windows in a VM (or possibly save his/her Windows installation as a VM); install Linux; and then run the Windows VM inside Linux. While developing his/her Linux installation, s/he would have immediate access to Windows as well.
Within a system running a version of Linux (e.g., Mint), it would be possible to run more than one VM. A system’s hardware and software might not tolerate running multiple VMs at the same time. Even so, it would ordinarily be faster to stop one VM and start another, than to reboot the system entirely into a different OS.
A user could have various reasons for wanting to run different operating systems within VMs. For example, s/he might find that Windows 7 was ordinarily the tool of choice, but there might be an occasional old Windows XP solution that could not be made to work as desired in Windows 7. Or the user might want to fire up a Windows 10 VM to explore some new program that was not available in Win7. An unstable guest OS (e.g., Windows 10), running in a VM, would not jeopardize the stability of the host OS (i.e., Mint).
There were different ways to create a VM. One way would begin within the program that would be running the VM (e.g., VirtualBox or VMware). The user would create a new, empty VM within that program, and then use the OS installation CD to install that OS (e.g., Windows 7) within that new VM. Another approach was to virtualize an existing physical installation. So if the user had Windows 7 installed on drive C, this approach would create a VM containing that Windows 7 installation. That VM could then run inside a system booted from Linux. As a third approach, it was also possible to convert some OS backup images into VMs.
The scenario being developed here, then, was that I would install Linux Mint; I would run Windows 7 in a VM on that Mint installation; and I would use this setup to work toward a satisfactory post-Windows 7 computing environment. The previous post describes the options in somewhat more detail, but the general idea was that there would be five possibilities, when trying to do Windows work in a Linux installation:
- Some tools were cloud-based, and would therefore work from a browser in any operating system. Simple example: the many webpages that offered currency exchange calculators would work the same from a web browser in any VM or native OS.
- Some Windows programs had Linux versions. For instance, Google Earth was not a Windows-only program; Google had also created a version for Linux.
- Linux tools like Wine could enable some Windows programs to run in Linux, even without a Linux version.
- For some Windows programs, there were Linux programs that did the same job just as well as the Windows program, or perhaps even better.
- Some Windows programs were not going to be replaced, substituted, or run in Linux.
The last category was why I would need a Windows VM: there were, and would probably always be, programs that I wanted or needed, that would have to be run within Windows. So I expected that I would continue to run Windows 7, for at least some programs, for the foreseeable future. But for the rest, running Win7 inside a VM would let me continue to nibble away at the project of transitioning various functions to Linux.
I would also probably need or want to keep a native Windows 7 installation, at least for a while. Doing so would give me a fallback, to protect against complications or delays in the Linux setup: I would still want to be able to get work done in Windows, without being dependent on developments in the Linux situation. Besides, I had heard about potential Linux hardware incompatibilities, and about the potential slowness of VMs. I suspected there would be times when a native Windows 7 installation would be convenient if not essential, for purposes of getting things done.
So I was looking at some redundancy. I was going to dual-boot Windows 7 and Linux Mint; and at the same time, within Mint, I would be running Windows 7 in a VM. There might be even more redundancy: if it was not difficult to install Windows XP and/or Windows 10, then I might add them to the mix: have a multi- rather than dual-boot system, and create VMs for those OSs too.
I could imagine that, eventually, I might need the native Win7 installation for only a few specific tasks. It was possible that, at that time, I might start over, rebuild it from scratch, and add things only as needed. For reasons of space and/or performance, the same might be true of the Windows 7 VM, and of any other VMs I might build. But I did not want to spend time on that sort of pruning at this point. Instead, for the time being, I planned to continue to use a large Windows 7 installation. That meant the VM created by virtualizing that Win7 installation would also be large. It seemed likely that my Linux installation would grow too, as I discovered more Linux programs to take the place of the old familiar Windows programs. I might also want to use copies of those VMs, for purposes of experimenting with new arrangements or unfamiliar programs.
With all these native installations and VMs, my 240GB SSD could get crowded. I could sell it and buy a larger one, or I could buy a second SSD, and put at least some of these native installations and/or VMs on it. Unfortunately, my laptop did not have space for another drive. Nor did I want to buy another SSD for each computer I might use.
There was another possibility: buy one external SSD, and see if I could share it among multiple computers. I couldn’t boot multiple computers with a single SSD at the same time, but I probably wouldn’t need to. But it would be convenient if I could shut down one computer, unplug the SSD, plug it into another computer, and boot that one. In other words, this external drive could contain various VMs, and might also contain bootable OS installations: for Linux Mint, at least, and possibly also for Windows XP and Windows 10, if I decided I needed to boot either of those.
For purposes of booting Mint, at least, the external SSD would evidently function like a live CD or USB drive. My understanding was that, if the external SSD was plugged in, the system would be set to boot from it. If it was not plugged in, the system would boot Windows 7 from the internal SSD, as usual. It might thus be unnecessary to partition the internal SSD to permit dual booting.
The external SSD option raised a number of issues and unknowns. I didn’t know whether it would function as hoped. I also didn’t know whether cables and ports would limit its speed. In my browsing, I encountered a variety of conflicting opinions. It seemed my next step was to set up an external SSD and try it out.