Choosing and Using a Virtual Machine Program, Part 1: Running Linux Mint 17.3 as Guest


Choosing a Virtualization Program

Trying to Configure a Prepackaged VM in VirtualBox
Trying to Install Linux from Scratch in VirtualBox
Trying to Create a New VM in VirtualBox
Considering VMware as an Alternative
Reconsidering KVM
Using VMware on Windows
Revisiting VirtualBox



As discussed in another post, Microsoft’s efforts to drive Windows 7 users toward Windows 10 resulted in my decision to return to Linux. My plan was to install Linux Mint 17.3, and use that to run Windows 7 in a virtual machine (VM).

At this point, I was only partly finished with that project. I was still learning how to install and configure Linux Mint. For instance, another post describes how I had recently screwed up my Linux installation while trying to get Wine to work.

So it was nice to think about eventually running Windows in a VM on Linux, but right now I wanted something different: I wanted to run Linux as a guest system in a VM, on a Windows or Linux host system, and I wanted to make copies of that Linux guest VM so that I wouldn’t have to reinstall Linux every time my tweaking experiments messed something up. I could just start up another copy of the Linux VM, and resume where I left off.

This post describes my exploration of and experimentation with Linux guest system VMs. The particular focus is on the choice of VM software — mostly on choosing between VMware, VirtualBox, and KVM to create, modify, and save Linux Mint VMs. Some of this exploration took place on a Windows host machine, some on a Linux host, but in any case the goal was to get Linux running as a guest system.

These notes provide a blow-by-blow account of the steps I took and the mistakes I made. If I write an update that simplifies this, I will probably come back and post a link to it from here. This account may be useful for people who are troubleshooting specific problems, and also for developers who are interested in user experiences with their software. The Conclusion summarizes what I found.

Choosing a Virtualization Program

My older blog describes my efforts to run Windows XP in a VM on Ubuntu. At that time, six to eight years ago, VMware Workstation seemed to be the best choice. My first question at present was whether it was still worth spending the money on VMware Workstation, or whether free or less expensive options had become more appealing.

On that question, my recent brief review concluded that the best and/or most popular virtualizers for Linux were VirtualBox, VMware, and perhaps KVM. AlternativeTo suggested that QEMU and Xen might actually be somewhat more popular than KVM. A search, and subsidiary searches from topics arising as a result, led to a number of findings and opinions:

  • Jim Henderson, working in a test lab, was very pleased with VirtualBox.
  • Savornicesei found KVM and QEMU confusing, with heavy use of the command line, whereas, in his experience back in 2005, as he recalled, VMware “worked flawlessly.”
  • Tsu2 felt that VMware was “rock solid,” KVM was best for running a VM on Linux because its core technology was “integrated into the mainline Linux kernel,” and VirtualBox was suspicious because it remained in perpetual beta mode. Tsu2 also replied to Savornicesei: he (Tsu2) had years of experience and realized that users without such experience might find KVM and QEMU intimidating; but “paravirtualization (and KVM) . . . [usually yielded a] big performance boost.”
  • Before continuing to review search results, I looked into that reference to paravirtualization. Wikipedia seemed to say that it was an innovation, built into Ubuntu and RedHat among others, developed by Xen and incorporated into other VM managers (e.g., VMware, KVM, VirtualBox). My net impression from this diversion was that VMware cost more because it did things better; for example, TechRepublic noted that VirtualBox 5.0 had problems with HiDPI displays (on e.g., the ThinkPad W550s).
  • Ben compared VirtualBox to KVM and apparently preferred VirtualBox for ease of use and responsiveness. This was the tendency of responses in another discussion as well.
  • Phoronix compared performance among KVM, Xen, and VirtualBox. VirtualBox was slower than the others in most tests. I was not sure whether the comparison of Linux kernel compilation time had real-world significance for the individual user. On the C-Ray test of floating-point CPU performance, VirtualBox was 46% slower than the other two. It was 12% slower on a test of FLAC audio encoding, 2% slower on LAME MP3 encoding, and 7% slower than KVM and 13% slower than Xen on FFmpeg video conversion.
  • For my purposes, VMware’s confusing main webpage yielded eventually to confusing and uninformative pages on vCenter Converter (a free program to convert Windows and Linux physical machines and third-party drive images to VMware VMs), VMware Workstation Player ($150), and VMware Workstation Pro ($250). (Note the possible existence of coupons.) Alerted to the possibility of a free version, a search led to a page offering the same download (for Windows and Linux) whether free or paid, depending on whether the user had a license key. From TechTarget’s comparison, I gathered that the key difference between the free Player and the paid Workstation, for my simple purposes, was just the ability to create clones and multiple snapshots. Elsewhere, TechTarget said VMware desktop products (presumably including both free and paid versions) offered a Unity Mode feature where applications running in a VM could be displayed on the host desktop.
  • Where cost was no object, a Spiceworks Community discussion leaned heavily toward VMware rather than VirtualBox.
  • Comments in a MalwareTips discussion were split, between the free VMware Player and VirtualBox. Advantages: for VMware Player, better integration of host and guest; for VirtualBox, better snapshot options, less system resource usage when inactive, and greater stability (contra DigitalTrends).
  • Dellvostro said VirtualBox ran like an application on the system, while VMware ran like a separate operating system. In the same discussion, JBL found VMware Player more polished and less clunky, and H20 felt VMware was stable but VirtualBox was easier to use.
  • Jimbo45 found KVM surprisingly easy to install on CentOS, with vastly better performance than VMware. He also spoke of using a GUI for KVM; a search suggested that virt-manager might be the leading option there. As of 2013, OpenNode found virt-manager incomplete for some purposes, but Tecmint and How-To Geek tutorials found it sufficient. Between those two tutorials, the latter made KVM look considerably less complex.
  • 5lulu compared the performance of KVM and Xen against bare metal — which, for my purposes, would mean installing Windows 7 directly on the computer. 5lulu found that KVM’s performance was better than that of Xen, and was within 1.5% of bare metal on almost all tests.
  • I had Acronis True Image Home 2011 images of installations of Windows XP, 7, 8, and 10. It could save me hours of installation time if my VM tool could import those images, and also if it could virtualize existing Windows installations. A pair of searches resulted in the impression that, for both VirtualBox and VMware, I might start by using VMware’s free vCenter Converter. There seemed to be potential difficulties in any case. It seemed I would have to get into the specifics in more detail to figure out whether and how to achieve these virtualizations.

This information provoked me to review my reasons for virtualization. Since I had decided to reduce my dependence on Microsoft, I didn’t plan to have a lot going on in the Windows 7 VM. This suggested that performance was not as important as convenience and features. In that case, I was inclined to choose VMware Player or VirtualBox. Between those two, I decided to start with VirtualBox, for what I understood were its advantages of ease of use and better snapshot options.

Trying to Configure a Prepackaged VM in VirtualBox

Installing VirtualBox on my Windows 7 machine was as easy as installing any other program. I also had a machine with Linux Mint KDE 17.3 already installed. I decided to install VirtualBox there too. The initial installation was more complicated on Linux, mostly because of installation instructions that proved to be incorrect. I tried again, this time using Synaptic Package Manager, already installed on KDE 17.3. A search in Synaptic for virtualbox produced many choices, among which I went with the advice to choose virtualbox-nonfree. That worked: Oracle VirtualBox was now available as a System application.

Now I needed to get Linux into a VirtualBox VM. One way to do that might be to put it there from an image backup of a working Linux system. I did have a few images that might work. My version of Acronis had proved unable to make efficient backups of Linux partitions, but I had an image of a Linux Mint installation made with Redo Backup & Recovery, and SPhillips had found a way to restore a Redo image to a VirtualBox VM. A search also produced suggestions on restoring a Clonezilla image to VirtualBox; I had one of those too. But I decided not to pursue those options because I had not gotten very far on configuring those systems. It was just about as easy to set up a new Linux installation. And a new installation might be better. I wasn’t sure whether those previous installations had any hidden problems that might complicate my current efforts to resolve various Linux issues.

When I ran VirtualBox, on both the Windows and Linux computers, I noticed its File > Import Appliance option. This inspired me to conduct a search, leading to OSBoxes, which offered prepackaged Linux Mint 17 images for VirtualBox and VMware. (See also Using a preformed image would save me the hassle of doing my own installation. From OSBoxes, I downloaded the 1.4GB 64-bit Mint KDE 17.3 VirtualBox image. Before unzipping that file, I used File Check MD5 (or could have used any similar tool) to calculate that download’s MD5 value, and compared that value against the one shown on the OSBoxes download page, to make sure they were identical, indicating that the file had survived the voyage unscathed. Then, on the Windows and Linux machine alike, I right-clicked on the downloaded zip (.7z) file, used the relevant tool to unzip or extract its contents, deleted the zip file, and stored the resulting .vdi file in the folder where I was storing VMs. Later, I would refine that: a subfolder to hold downloaded VMs, in case I needed them again, and another subfolder for their installed counterparts.

Back in VirtualBox, I discovered that the File > Import Appliance option would only accept files in .ova or .ovf format. The unzipped download was a .vdi file. The advice in that case was to choose Machine > New > provide information corresponding to the download (e.g., 64-bit Linux). But on the Windows machine, the only options were for 32-bit Linux. A search led to (1 2 3) sources identifying possible causes of this limit:

  • In the BIOS, Intel Virtualization Technology and VT-d (or AMD-V) should be enabled.
  • A BIOS update may be necessary.
  • In the Windows Features list, Hyper-V (not necessarily available in Windows 7) needs to be disabled, as does any other virtualization software (e.g., VMware).
  • In Windows 10, a reinstall/repair of VirtualBox may be necessary.

For me, the BIOS enable was the only one of those changes that my system needed. Now 64-bit options were available. I wasn’t sure why there was no problem on the Linux machine; perhaps I had already made the BIOS change there.

So now, on both the Linux and Windows computers, I was able to set up that new 64-bit Linux Mint 17.3 KDE machine in VirtualBox, once again using the menu option Machine > New. In that process, the “Create Virtual Machine” dialog still didn’t offer Mint as an eligible version. One source advised choosing 64-bit Ubuntu at that point, and I went with that; another suggested the generic (“Other Linux”) option. I had some spare RAM, so I allocated 2048MB. When I got to the question about the default 8GB virtual hard drive, I clicked the Expert Mode button; based on advice, I chose the Dynamically Allocated option; and based on other advice, I chose VMDK format.

That seemed to complete the installation. I found myself back at what appeared to be an information screen for my simple new Linux Mint VM. Now I had an opportunity to adjust its other settings. Chapter 3 of the VirtualBox User Manual had relevant advice. I decided on these changes: in General > Advanced, I made the clipboard and mouse bidirectional; in System > Processor, I allocated two cores (the window showed how many I had altogether); in USB, I clicked USB 3.0; and in User Interface, I clicked Show at Top of Screen. I decided against enabling Display > Video Capture right now; it was enough to know it was there if I needed it. In Display > Screen, I tried to enable 2D and 3D acceleration, but I noticed the words “Invalid settings detected” near the OK button. Mousing over that gave me this message:

The virtual machine is set up to use Video Stream Acceleration. As this feature only works with Windows guest systems it will be disabled.

For the Display > Screen setting, I needed to know how much video memory the system had available. That was easy to find in Windows: I used the built-in dxdiag.exe program, and then consulted the reportedly more accurate GPU-Z utility. But in Linux, I had to do a search and some additional surfing to find an AskUbuntu discussion recommending several different command-line variations, and then I had to try those recommendations to find which would work for me. I wound up with these alternatives:

sudo dmesg | grep "graphics device"


grep -i mem /var/log/Xorg.0.log

In any case, I had more than enough video RAM to allocate the maximum 128MB permitted by the Display > Screen > Video Memory option. I was ready to exit from the Settings dialog, but then I noticed another “Invalid settings detected” message:

USB 2.0/3.0 is currently enabled for this virtual machine. However, this requires the Oracle VM VirtualBox Extension Pack to be installed. Please install the Extension Pack from the VirtualBox download site or disable USB 2.0/3.0 to be able to start the machine.

I clicked OK to close the dialog, and then went to the VirtualBox download site. I was not sure how the installation process might differ, between Linux and Windows. But then I saw an explanation that the VirtualBox Extension Pack is not an installer, but is rather installed from within VirtualBox. The download webpage said, “Please install the extension pack with the same version as your installed version of VirtualBox!” So I started by going, in VirtualBox, to Help > About VirtualBox. It said I was running version 5.0.20 on the Windows machine and 5.0.2 on Linux. So, for the Windows machine at least, I was able to get the Extension Pack for my Windows installation right there on the download webpage. I went ahead and downloaded it.

The download webpage also said, “After upgrading VirtualBox it is recommended to upgrade the guest additions as well.” I hadn’t done anything about the Guest Additions yet. They didn’t repeat the warning about matching “the same version” for the Guest Additions, and I saw they were offering version 5.0.16 of the Guest Additions — not 5.0.2 or 5.0.20. So I downloaded that too. This left the question of what to do for VirtualBox 5.0.2 on my Linux machine. A search led to an Old Builds webpage, and there I scrolled down to VirtualBox 5.0.2 and downloaded via the Extension Pack link.

Then, in VirtualBox (on both the Linux and Windows machines), I went into File > Preferences > Extensions > click on the blue and yellow “Add” arrow at the right side > navigate if necessary to where the download landed. I proceeded with the installation. I got a message: “The extension pack Oracle VM VirtualBox Extension Pack was installed successfully.”

Now I turned to Chapter 4 of the VirtualBox User Manual. It said I should install the Guest Additions by going into the VM’s menu and selecting Devices > Insert Guest Additions CD Image. But now a funny thing happened. In VirtualBox, in order to start up the VM and see that menu, I highlighted the VM that I had just configured and clicked Start. It asked me where I wanted to install from. Install? I thought the 1.4GB download from OSBoxes (above) already was an installed version of Linux Mint. I fooled around with this a bit, starting and quitting, and now the VM was only giving me, “FATAL: No bootable medium found! System halted.” That was apparently because I was not putting an installation CD into the computer’s CD drive. I thought maybe I could fix this by going ahead with the Guest Additions installation, so I chose Devices > Insert Guest Additions CD Image. But no, when they said “System halted,” they really meant it. Nothing happened. Same thing exactly on both the Linux and Windows computers.

Trying to Install Linux from Scratch in VirtualBox

I wondered if maybe my explorations with the Settings and the Extension Pack had somehow ruined the original OSBoxes machine. Well, I thought, now that the device was asking for a bootable medium, why not go ahead and just install Linux Mint after all? It seemed I had already taken care of all the configuration except the Guest Additions. I happened to have the Linux Mint 17.3 KDE x64 installer on my YUMI USB drive, so I decided to point the VM toward that, and get back later to this whole question of the prepackaged OSBoxes VM.

I powered off the VM, plugged the YUMI drive into the computer, clicked Start in VirtualBox, and hit F12 as soon as the VM started up. It didn’t seem to be detecting the USB device. It only listed the hard disk, which I assumed was the 8GB virtual HDD I had configured during installation (above), a floppy disk, a CD-ROM, and a LAN. I tried both the HDD and the floppy disk. Nope: fatal crash. A search clarified: I should go into Settings > USB > click on the plus icon at the right side > add the desired USB drive. Same thing on startup. But then I got a message from the host Windows installation (i.e., not inside VirtualBox) indicating that it had recognized the drive. That was weird; it had already recognized it earlier, else it wouldn’t have appeared in that Settings > USB dialog. I tried Startup again, and it happened again. Now I understood: the USB drive was being returned from VirtualBox to Windows when I closed the VM, so each time it was being re-recognized by Windows. Interesting, but that didn’t help solve the problem.

I tried again. In Settings > USB, I switched to enabling USB 2.0 instead of 3.0. That didn’t help. A search led to the suggestion that, in the host operating system, I had to unmount or eject the USB drive (not “Safely remove hardware”) before trying the VM. I tried that. It didn’t make any difference. I noticed, at this point, that (a) a lot of people seemed to be having this problem and (b) someone recommended trying VMware Player instead. That was tempting.

Trying to Create a New VM in VirtualBox

I decided to start all over. In VirtualBox on the Windows machine, I created a VM with the same settings as above. In a variation on the previous try, I started the machine right after configuring those settings (i.e., before installing the Extension Pack). I didn’t have a chance to do anything with F12: it went immediately to the dialog that had appeared only the first time in the previous try, asking me for a physical or virtual CD from which to install. It offered the Guest Additions as an option, so I went with that. It may have installed them — I couldn’t tell — but then it went back to the Fatal error message. I restarted several times, trying both the Save the Machine State and Power Down options at shutdown, but the outcomes were the same as before. I hadn’t done anything deliberate to install the Extension Pack, but now I saw in File > Preferences > Extensions > that it was indeed installed.

It seemed I could go ahead and install, if I had Linux Mint on a CD. I didn’t, and I didn’t want to burn a CD for that purpose. A search led to this statement:

VirtualBox itself does not support booting from a USB device. In order to boot from a USB device, another bootloader is required.

The solutions offered there seemed to entail more complexity than I cared to explore at this time, as attested by the problems that others reported when trying to implement those suggestions.

Another option, of course, was to skip the step of putting an operating system ISO (for e.g., Linux Mint installation) on a USB drive — instead, just install the OS from the ISO directly, and leave out the USB step. But how to do this? VirtualBox wasn’t offering that option either. A search led to advice to go into VirtualBox > select the desired VM > Settings > Storage > Controller: IDE (i.e., the top one) > click the round CD icon with a plus on it > Choose Disk > navigate to the desired (e.g., Linux Mint) ISO > OK > Start. That worked: I was looking at the Mint installation disc. But — what’s this? an error:

VirtualBox – Error

An error has occurred during virtual machine execution! The error details are shown below. You may try to correct the error and resume the virtual machine execution.


Unable to allocate and lock memory. The virtual machine will be paused. Please close applications to free up memory or close the VM.

That was weird. This computer had 16GB of RAM and 4GB of video RAM, and Moo0 System Monitor reported more than 7GB of system RAM free. A search led to the unsurprising advice to reduce RAM allocated to the VM, though plainly that didn’t answer the question. That pretty much exhausted the relevant results from that search.

In these last several steps, I was working solely on the Windows machine. I might have had different results if I had tried the same thing on the Linux machine. But it seemed to me that these problems, and the lack of clear solutions, were substantial arguments against my original premise: so far, VirtualBox was not in fact offering “ease of use” (above). I felt it was time to consider VMware as an alternative.

Considering VMware as an Alternative

As mentioned above, I found VMware’s product information webpages confusing and uninformative. As an example, consider the page (as archived) titled “VMware Workstation Player (formerly known as Player Pro).” My first question: were the people at VMware running out of words? Were they somehow stuck in a sort of Groundhog Day world in which their only choices were to keep reusing the same terms — notably Workstation and Player — over and over again, in befuddlingly overlapping combinations? Could someone perhaps suggest the possibility of moving on?

That page about Workstation Player began with a comparison of Workstation 12 Player against Player 7 Pro. Excuse me, but didn’t the title just say that Player Pro had been renamed Workstation Player? Was this, then, a comparison of the product against itself? If so, it seemed to lack some features that it had.

Next, the page compared unlicensed vs. licensed versions of VMware Workstation 12 Player. The unlicensed version, it said, was “Licensed for Personal Use Only.” Possibly the vocabulary pathology was more acute than I had realized. It appeared that someone might usefully explain, to VMware, that “unlicensed” would tend to entail not being “licensed.”

The page next offered an extensive contrast of Workstation 12 Player vs. Pro. It appeared that Player had virtually no “Key Features,” raising the question of why anyone would bother with it. I, for example, had pulled away after seeing (as noted above) that it had no “Snapshot tool.” But if GoNewSoft was to be believed, this was a misrepresentation, intended perhaps to persuade people to go for the full (i.e., expensive) Pro version. GoNewSoft had lately reported that

Player allows a complete virtual machine to be copied at any time by copying a directory; while not a fully featured snapshot facility, this allows a copy of a machine in a particular state to be stored, and reverted to later if desired. By default changes (including proxy settings, passwords, bookmarks, installed software and malware) made in a VM are saved when it is shut down . . . .

But then, that was a year ago. Back then, GoNewSoft was reporting on VMware Player 12.1.1. That version 12 bore an unknown relationship to the Workstation 12 Player and Player 7 Pro products now being discussed on the VMware comparison page (above). It appeared Player had gone backwards five versions, from 12 to 7, in the space of one year. Confusing!

No doubt the Vmware people were intelligent. But a person can reasonably look for clues as to whether someone is paying attention. The point of this criticism was that VMware was having problems, and it was showing in its Workstation product. As of May 2016, VMware’s CEO was apparently planning to leave the company, after being linked to “a number of missteps”; in January 2016 VMware’s Workstation group was reportedly hit by job cuts (“immediately fired,” according to Wikipedia) presaging an offshoring of the Workstation product to an entirely new team; ZDNet reported that, in fact, the entire Workstation team was sacked and that the “award-winning and profitable” Workstation and Fusion products were “probably not long for this world.” There were worries, in addition, that Dell’s recent acquisition of VMware would bring new problems. In short, one could doubt whether Workstation (and Player) products would continue to be developed at all, or what their quality might be. Of course, there were no guarantees in anything. PearlSeattle said,

Let’s not forget that VirtualBox is an Oracle product – the Oracle corporation could decide anytime to stop support/development of VirtualBox and at that point you would have to hope that somebody forks it in some intelligent way, or otherwise you would have to re-implement everything.

Sobering words, in light of the fact that VirtualBox started out being owned by Innotek in 2007, became Sun VirtualBox in 2008, and then traveled to Oracle in 2010. It certainly could travel further. For that matter, one might consider the Forbes comment, “Industry analysts believe that there is more to the [current partnership between Microsoft and Red Hat] than just collaboration” — or, as Darrow suggested back in 2014, “Microsoft should just pack it in and buy Red Hat.” Consider, similarly, Canonical’s recent collaboration with Microsoft. These thoughts certainly resonated as I contemplated the situation, at present, in which it appeared Microsoft might be seeking to sabotage Windows 7, prompting my own recent decision to return to Linux. In other words, for many Linux users, it was conceivable that even the underlying Linux distribution could be subject to corporate wheeling and dealing.

In such circumstances, it made sense to lean toward free and open-source software (FOSS). As in PearlSeattle’s remark (above), when the software is FOSS, one can at least “hope that somebody [will fork it] in some intelligent way,” thereby continuing its development and use, rather than leave users at a dead end.

Not that such corporate developments would necessarily have any immediate impact. One could start with VMware, use its products at present if they seemed worthy, and switch later as needed. Given that company’s significance in the virtualization market, it was very likely that future VM programs would offer means of migrating or importing VMs. On the other hand, my current struggle to reduce dependence on Microsoft reminded me of the power of inertia: I would be very likely to stay with familiar software longer than ideal, just to avoid the time and effort of switching to something that might be better. It did seem advisable to try to make the most reasonable long-term choice now — to make a start toward what I would continue to need long-term — and not merely to kick the can down the road a little further.

Reconsidering KVM

Against my concerns about VMware, it was refreshing to read an Open Virtualization Alliance article (Jollans, 2015) stating,

As more and more enterprises are making big commitments to open source versus proprietary tools, KVM is well positioned as the hypervisor of choice in a number of new and exciting ways.

I wondered, that is, whether I had run away too soon from the KVM FOSS option in favor of the eye candy of VirtualBox and VMware. According to InfoWorld (Asay, 2015), Red Hat Linux (apparently heavily invested in KVM) was oriented toward a simple goal: “Kill VMware and pricey, proprietary virtualization.” Granted, InfoWorld seemed to be talking about enterprise-level virtualization, but the thought remained: which side do I want to be on? At my own level, it was interesting to read these remarks from LinuxCareer:

[W]e believe in the “right tool for the job” concept. KVM offers some features that VirtualBox does not and the other way around. There is no such thing in the IT world as a universal tool, so it’s important to use something that fits your needs. The basic idea is : if you want to install a binary Linux distribution as a guest, use KVM. It’s faster and its’ drivers are included in the official kernel tree. If your guest involves lots of compiling and needs some more advanced features, and/or isn’t a Linux system, better go with VirtualBox. The technical reasons are quite simple : KVM is better integrated with Linux, it’s smaller and faster, and while you can use it with other guests besides Linux, we found the experience to be quite troublesome . . . .

It appeared, though, that when LinuxCareer referred to “other guests besides Linux,” its experience seemed primarily limited to “Unix(-like) guests besides Linux.” I could hope, at least, that KVM could do a decent job with a Windows guest.

Using VMware on Windows

I decided to try working with KVM once I got my Linux system set up. But to help me get that system set up — to experiment within Linux VMs — I wanted a virtualization solution that would run on Windows. KVM was evidently not available for Windows, so unless I wanted to struggle with VirtualBox some more, the next thing to try (at least on the Windows machine) was VMware. On the relevant downloads page, I went to the bottom (“Download Free Products”) and selected VMware Workstation Player 12.1.1. They were offering 64-bit versions for both Windows and Linux, so I downloaded both.

Installing the Windows version was easy. It gave me options to create a new VM or open a VM. When I tried the latter, it indicated that its supported file types were .vmx, .vmc, .ovf, and .ova. I didn’t have any of those for Linux Mint, so I went back to OSBoxes and downloaded their 2.3GB VMDK file for 64-bit Linux Mint 17.3 KDE. (When the download finished, I would see that that turned out to be a zip file containing not only a .vmdk but also an .ovf and an .mf file. But for now, I proceeded as described below.)

I was not sure how the .vmdk format would relate to those four formats that VMware Player supported. In Player, I went to the Player menu option and selected Help > Help Topics. This took me to the VMware Workstation 12 Player for Windows Documentation Center. I searched there for VMDK. None of the four search results seemed relevant. Other searches (1 2 3) turned up nothing obvious. OSBoxes itself just pointed me to a Wikipedia entry.

A video led me to think maybe the solution, in Player, was to choose Create a New Virtual Machine > I will install the operating system later > Ubuntu 64-bit (?) > name it Linux Mint 17.3 KDE x64 > Store virtual disk as a single file > Customize hardware (as desired; see notes above and VMware Documentation Center; mostly I went with the defaults) > Finish. Then choose Edit Virtual Machine Settings > select Hard Disk (which wasn’t there before) > Add > add a Hard Disk (already selected) > SCSI type > Use an existing virtual disk > browse to and select the downloaded .vmdk file > Open > Finish > select and Remove the 20GB (or whatever size) hard disk created during setup > OK > Play virtual machine. I followed those steps — and yet, as with VirtualBox, I got an error:

Not enough physical memory is available to power on this virtual machine with its configured settings.

I got that even though, this time, I went with the default RAM allocation instead of trying to allocate 2GB. A search led to a StackOverflow discussion offering multiple solutions that also appeared in other posts. Here are suggestions from that discussion and from some of those others:

  • Run VMware Player as Administrator. For me, that option was available by right-clicking on the Player icon in my Start Menu. I wasn’t sure whether that option was something that had been added somehow, or was available on any Windows 7 system. Anyway, it didn’t solve the problem for me. Another route: right-click the Player icon > Properties > Compatibility tab > Run this program as an administrator.
  • Uninstall “Update for Microsoft Windows (KB2995388)” via Control Panel > Windows Update > View update history > Installed Updates link > right-click > Uninstall. That update did not appear to be installed on my system. It was apparently only for Windows 8.1 systems.
  • Make sure you are running the latest version. I had just downloaded and installed Player from the VMware site, so this did not seem to be a solution for me.
  • Installation created a file called C:\ProgramData\VMware\VMware Workstation\config.ini. That “Workstation” folder was created even though I had only installed Player. The advice was to edit that config.ini file (right-click > Open with Notepad) to contain an additional line: vmmon.disableHostParameters = "TRUE"  The advice was then to save and close that file and reboot. Someone, apparently using a different version of Player, did have a Player (not Workstation) folder at C:\ProgramData\VMware. That person also added that line to C:\Users\[username]\AppData\Roaming\VMware\config.ini, but that file did not exist on my system. At any rate, the advice was to reboot after editing the config.ini file.
  • Someone reported that the problem with RAM went away after just letting the machine sit for an hour.
  • Others suggested that the problem may be solved by reinstalling Player or, instead, that problems that seemed fixed might recur after reboots. Some of the foregoing suggestions called for a reboot. Possibly a cold shutdown (i.e., leaving the computer off for a minute before restarting) would make a difference.

It appeared that editing the config.ini and rebooting were sufficient to get me past that error message. Unfortunately, now I had a new one, when I tried to start the newly created VM:

The keyboard hook timeout is not set to the value recommended by VMware Player. This can cause keystrokes to be lost when the host is under stress. We recommend that you allow this application to update the value. Once this value is updated, you must log out and log in again in order to have the value take effect.

I said OK, and then immediately got another error:

You do not have write access to a partition.

Select Allow to override access rights for this write.

Select Allow All to override access rights for this and subsequent writes to all raw disk partitions during this run of the virtual machine.

Select Deny to refuse this write.

Select Deny All to refuse this and all subsequent writes to all safe raw disk partitions which do not have write access during this run of the virtual machine.

A search indicated that this error was rarely encountered. A discussion regarding a parallel Mac VMware product contained a reply, apparently from someone at VMware, in October 2015: “We’re aware of this one, working on a product fix as we speak, sorry for the bug!” So possibly my problem was still there because the Workstation team was fired a few months later. I guessed that Player was either trying to access an encrypted partition on my system (which would explain the reference to a “raw” partition, since that was how diskmgmt.msc saw such partitions) or, more likely, I hadn’t yet entered the password to get into the OSBoxes download. In any event, a couple other people said the correct answer was Deny All, so I went with that. This gave me another message:

Selecting Deny or Deny All will return a fatal disk error to the boot program (e.g., LILO) or guest operating system running in the virtual machine. The boot program or guest operating system might not be able to handle the errors. This might prevent the virtual machine from powering on or continuing to run. Do you want to continue?

I wondered if I was getting these messages because of another message appearing at the bottom of the Player window, inviting me to install VMware Tools. I clicked on Install Tools. Nothing happened, except the error window flickered: evidently I had to answer that question first. I said Yes. Sure enough, in the main Player window, I got another error. It was gone before I could copy it. Other messages followed, culminating in this:

Could not start the X server (your graphical environment) due to some internal error. Please contact your system administrator or check your syslog to diagnose. In the meantime this display will be disabled. Please restart MDM when the problem is corrected.

Meanwhile, I had another dialog, informing me that it was possible for me to connect my printer and my WLAN network device to the VM. I clicked OK on that. Now I tried again to install VMware Tools. That proceeded. I had a new message:

Make sure that you are logged in to the guest operating system. Mount the virtual CD drive in the guest, launch a Terminal, and use tar to uncompress the installer. Then, execute to install VMware Tools.

I was not sure what those instructions meant, but that was OK as I was unable to log into the Linux Mint guest anyway. I clicked Player > Menu > Shut down guest.

So, wow, that had gone really well. What a mess! Part of me wanted to troubleshoot those various issues. But another part of me had become aware, somewhere during this process, that (as noted above) the unzipped OSBoxes download did include an .ovf file. And then there was the part of me that had belatedly discovered the obvious relevant instructions at the OSBoxes website.

I decided to try those OSBoxes instructions. They told me to start by choosing Open a Virtual Machine and locating the .vmx image. But this was confusing, because the OSBoxes VMware file I had downloaded on this date did not have a .vmx file. Since the program was also receptive to .ovf files, I assumed that’s what they meant, so I chose that. I designated the downloaded VM and clicked Import. This produced an error message:

The import failed because [the .ovf file] did not pass OVF specification conformance or virtual hardware compliance checks.

Click Retry to relax OVF specification and virtual hardware compliance checks and try the import again, or click Cancel to cancel the import. If you retry the import, you might not be able to use the virtual machine in VMware Player.

I clicked Retry. After a few minutes, that gave me this message:

Failed to open virtual machine: SHA1 digest of [.vmdk file] does not match manifest.

I had checked the MD5 but not the SHA1 value. I still had the zipped download, so I used the Microsoft File Checksum Integrity Verifier to check the SHA1 value now. The values matched. Perhaps my unzipper (WinRAR) had introduced an error. I went back to the downloaded VM and tried again, this time unzipping with 7-Zip. I navigated to its .ovf and proceeded, again, as just described. I got the same error message about OVF specification conformance, and clicked Retry again. This time it worked. It was possible that my various machinations had caused a problem, but at the moment it appeared that I should have unzipped the download using 7-Zip rather than WinRAR.

So now I was looking at VMware Player, and it was offering to let me play or edit a machine whose name captured what I had worked out so far: LinuxMint_17.3_KDE-64bit_OSBoxes_7zip. Following the OSBoxes instructions, I chose “Edit virtual machine settings.” This put me back into the Virtual Machine Settings dialog on the Hardware tab. The advice there was to set Network Adapter > Bridged. I opted to make other changes as well:

  • Processors: Number of processor cores: 2.
  • Display: Increase graphics memory from 256MB default to 768MB (recommended).

I clicked OK and then Play virtual machine. Linux Mint booted. I couldn’t believe it. I entered the password (, and I was in. At first, it was terribly slow, but then apparently it finished loading itself in RAM, and after that its speed seemed fine. I clicked to install VMware Tools, went into the Dolphin file manager, selected VMware Tools under Devices in the left-hand pane, right-clicked on the tar.gz file, and chose Extract > Extract Archive Here, Autodetect Subfolder. It seemed like nothing happened. I tried again, this time choosing Extract Archive To and designating the 96GB hard drive that evidently came included in the OSBoxes download. I selected the other options as well: “Open destination folder after extraction” and “Close Ark after extraction.” Again, the outcome was not clear. It seemed to be extracting to /media/osboxes/VMware Tools, but I thought that was the starting point, where the Tools were coming from.

It seemed that I could probably finish troubleshooting that situation in VMware Player. But now I was thinking about what I had read about VMware, and was realizing that VirtualBox probably would have worked with the OSBoxes download in the first place, if I had just thought to look for instructions on the OSBoxes website. Now that I had those instructions, I decided to turn back to VirtualBox.

Revisiting VirtualBox

Encouraged by my near-success with VMware Player and OSBoxes, I decided to try again with VirtualBox, this time using the instructions provided by OSBoxes.

To do that, I started by zipping up the VirtualBox VMs that I had tried creating so far. I wanted them out of the way. That left me with only the downloaded OSBoxes .vdi for Linux Mint 17.3 KDE x64. Then I started VirtualBox. The entries for the two VMs I had tried to create were now marked as Inaccessible. I right-clicked and removed them.

Then, in VirtualBox, I clicked New > Expert Mode > provide a name etc. > Use an existing virtual hard disk file > click the little icon at the right side to navigate to the .vdi file > Create > Settings. The only settings I changed from the default were:

  • General: Advanced tab: Shared Clipboard and Drag’n’Drop: both Bidirectional.
  • System: Processor tab: 2 CPUs.
  • Display: Screen tab: 128MB video memory (the most available on this system, for some reason), and enable 3D but not 2D Acceleration.
  • Network: Adapter 1 tab: Attached to: Bridged Adapter. Name: Not Selected was the only available option. But for some reason, when I saved and closed the Settings dialog at this point and then came back to it, other options were available. I went with the default, which in my case was a 802.11n USB Wireless LAN Card #3, because that matched up with what I saw as my actual Internet connection in Control Panel > Network and Sharing Center > Change Adapter Settings. (In a later installation (of Portable VirtualBox), the “Not Selected” option remained. To fix that, I tried various suggested solutions, but without success.) In the Advanced area, I changed nothing. I clicked OK to exit Settings.

The next instruction was to click Start. After a few introductory notes, Linux Mint booted, and gave me the opportunity to log in. The OSBoxes login’s password was shown right there in the login dialog: Next, the advice was to go to the top menu bar and choose Devices > Insert Guest Additions CD Image. The OSBoxes instructions seemed to say that something was supposed to happen, or at least that I would be getting further instructions from the system. But nothing happened. I moused over the disc icon shown toward the bottom right corner of the screen. It seemed to acknowledge that the Guest Additions ISO was mounted.

I guessed that maybe the OSBoxes instructions were referring to their own “following instructions.” In that case, in the Linux VM, I opened the Dolphin file manager (bottom left corner of screen) > click on VBOXADDITIONS in the left panel (under Devices). There didn’t seem to be a “Run Software” button at the upper right corner of Dolphin, so I opened a session of Terminal. In Mint KDE, that meant going to the Start button (bottom left corner of screen) > Konsole. That opened a command box and gave me the osboxes@osboxes prompt. This seemed to be where I should be. I typed the command as instructed: sudo ./  . It required me to enter the password again. But then I got an error: “sudo: ./ command not found.” Apparently I wasn’t in the right place.

I looked at the address bar in Dolphin. It said “media > osboxes > VBOXADDITIONS_5.0.20_106931.” I tried “cd /media/osboxes/VBOXADDITIONS_5.0.20_106931.” Looking closer at the files listed in Dolphin, I saw that there was indeed one called It didn’t have a period in front of it. I thought maybe I should retry the command without that period or the slash: sudo  .  But then I saw that, somehow, the slash had disappeared from the command I was actually giving. I tried again with the correct command. That ran. It gave me this message:

You appear to have a version of the VBoxGuestAdditions software on your system which was installed from a different source or using a different type of installer. If you installed it from a package from your Linux distribution or if it is a default part of the system then we strongly recommend that you cancel this installation and remove it properly before installing this version. If this is simply an older or a damaged installation you may safely proceed.

Do you wish to continue anyway? [yes or no]

So, OK, apparently the Guest Additions got installed without any announcement at all. I said “no” and exited Terminal. That marked the end of the OSBoxes instructions for the downloaded VirtualBox VM. I shut down the Linux process in VirtualBox and shut down VirtualBox itself. I saw that the VM had not been installed in exactly the folder where I wanted it, so I moved it to the desired folder. Back in VirtualBox, this resulted in the VM being marked as Inaccessible. I removed that icon and went to Machine > Add > navigate to the .vbox file > Open. The Linux VM was working once again. I exited Linux and VirtualBox again, and this time I made a zip of the folder holding the .vbox file, with all its contents, so I would have that zip as a backup.

The remaining task was to set up a shared folder, so that I could swap files between the Windows host and the Linux guest. My interpretation of relevant advice was as follows:

  1. The folder on my Windows drive D that I wanted to share with this Linux VM was named “Current,” so in the Linux file manager, I created a /home/osboxes/Current folder. This would not duplicate the contents of the actual shared folder; it would just be a mount point, something like a Windows shortcut.
  2. In VirtualBox, with the Linux guest running, I went to the top menu bar > Machine > Settings > Shared Folders > click the blue folder icon with the plus on it, at the right side > Folder Path > Other > navigate to the folder being shared (i.e., Current) > check the Make Permanent and Auto-mount options (and, if desired, Read-only).
  3. To avoid getting an error message (“Could not enter folder /media/sf_Current”) when I tried to navigate to that folder in the file manager, run this command: “sudo adduser $USER vboxsf.” Then reboot Linux.

On the first reboot, Linux froze. But on the retry, the Current folder was available as /media/sf_Current.


In the course of writing this post, I tried or at least thought about several VM possibilities. Eventually, I was going to want a VM that would run Windows on Linux. My sense, at this point, was that I would probably use KVM or VirtualBox for that.

But before I was ready to rely on Linux, I needed to do more testing — and to do that, I needed to be able to run Linux in a VM. That way, I could make mistakes and just throw away the Linux installation I had been playing with, and try again with a fresh one. I couldn’t use KVM to run a VM on a Windows system. I could use VMware. But, looking to the future, I felt that VirtualBox might be the wiser choice.

To make VirtualBox work on Windows 7, there were various possibilities. I could start with an empty VM and install Windows in it; I could start with an empty VM and restore Windows to it from an image backup; I could convert an image backup or a live system (such as my current working Windows 7 installation) to a VM, and run that in VirtualBox; or I could download a preconfigured Linux VM and run that.

I was probably going to be curious about all those options, when it came time to run Windows in a VM. But for right now, to set up a Linux test bed inside Windows, all I needed was one working solution. The last of the foregoing options seemed best: just use the preconfigured OSBoxes VM that I had already downloaded. OSBoxes provided simple and relatively clear instructions.

Amidst the multiple VM possibilities and my eagerness to try different possibilities, and without the benefit of a focused sense of what I was trying to do in the first place, I wound up flailing around and missing those instructions. Doing so incidentally familiarized me with various issues. Among other things, I was still not sure what had gone wrong with my attempts to install Linux Mint in VirtualBox from scratch. But now, at any rate, I had a working VM, and it was time to get on with my Linux testing.

This entry was posted in Uncategorized and tagged , , , , , , , , , . Bookmark the permalink.

2 Responses to Choosing and Using a Virtual Machine Program, Part 1: Running Linux Mint 17.3 as Guest

  1. Honigmelone says:

    Hey thanks for this blogpost.

  2. Marc says:

    I have run Windows 7 corporate images on both Virtualbox 4/5 (on Ubuntu 14.04/16.04) and on KVM (on CentOS 7) without issue for many months.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.