First off: There are other, similar questions to this (e.g. Why is it I can't use my Windows installation both as a host and a guest?), but the questions either don't provide enough information, and/or the answers are technically and factually incorrect (as with that example). It is possible - technically and legally - to boot the same physical Windows instance both natively and virtually (obviously not at the same time), without having to reactivate, and without having to legally buy two licenses. I just need help accomplishing it (as I imagine scores of others would like to do). I also imagine this could become be an interesting or useful reference for others, especially given the lacking and/or incorrect information about it elsewhere.
I once found an exhaustive walkthrough on how to do it several years ago (which worked), using VirtualBox, but I can't seem to find any guides now. But surely this nut has been cracked, and others would like to know how?
I should provide a good amount of detail with this question - to head off the inevitable, well-intentioned, and occasionally wrong comments such as:
- "It can't be done" (it can and has - quite robustly and reliably)
- "It would violate the Windows EULA" (possibly with Windows 10 but not older versions)
- "Why not just use Wine, or a fully virtual Windows image, or comparable Linux apps" etc. (I'll get to that.)
- "Why not use two computers and a KVM?" (My main computer is a laptop with two mSATAs and always on the go; can't be tied to one desk. Also I regularly copy and paste between OS instances, can't do that with a KVM. Plus, how boring is a KVM? And a desk?)
Table of Contents
- Desired scenario and high-level use-case
- Evidence that it is possible, robust, and useful
- Evidence that it is legal
- My specs (just in case asked).
Desired scenario and high-level use-case
- One machine, two drives.
- One drive has Windows installed (specific version up for debate), the other has Linux (Xubuntu 16.04.1).
- Boot up Windows, then load the physical Xubuntu instance in a virtual machine (via VirtualBox 5.1, a raw vmdk pointing to physical drive, and a robust custom CMD script to set it up and launch it).
- Exit both, physical reboot.
- Boot up Linux, then run the physical Windows instance in a virtual machine. (Preferably also VirtualBox but I'm open to suggestions.) Also with similar script helpers, but bash (which also exists).
I already have #s 1 through 4 in place and working flawlessly, reliably, every day, for years.
The bash script is already written to make #5 work. It already works for running a physical installation of Linux in a virtual machine... on a (different) real running instance of Linux. (Why that is a very different story and related to a secure, portable, traveling development environment.)
(BTW - the scripts [CMD or bash] are needed to set up the raw VMDK instances [which become invalid after every boot], connect them to the VM, and start the VM. It just makes it painless, easy, and reliable. This scenario also works absolutely brilliantly for installing and running an OS on, say, an SD card or thumbdrive [which is challenging to do the "traditional" way]. Just point a raw VMDK to the entire thumbdrive, attach the VMDK to a VM, boot the VM to a live CD ISO, and install the OS to the "thumbdrive" just as if it were a regular hard drive - which it thinks it is. After that, you can boot the OS on the removable media either in a VM, or for real. At least, if it is Linux. Works like magic, but writes are slow depending on how cheap the media is.)
What I don't have working for #5, is the Windows VM not squawking about drivers or activation when switching back and forth between booting natively, and booting virtually. (And again - this is perfectly possible and proven so below. I just don't know how to accomplish it.)
- Linux is my main OS, going back to Ubuntu Feisty Fawn. It has most of my productivity apps and data. I vastly prefer it to Windows for numerous reasons. I use it most of the time natively.
- I also have a series of required communications and development programs that only run in Windows, so I currently run those in a "regular" Windows VM - a fully virtualized Windows 7 instance on a regular virtualized HDD image.
- Keep in mind, the above point only applies to applications that don't run reliably or at all on Wine, and have no Linux counterparts that meet the same requirements. But there are plenty of other Windows applications I use, that do run just fine on Wine, and obviously I have found acceptable or superior Linux replacements for the rest.
- I occasionally must spend long sessions in native Windows, for low-latency, hardware-accelerated photo/video/audio editing. (At which time I also need access to my Linux productivity apps, hence the physical Linux install running in a VM, which as I said has worked flawlessly for years.)
- My "real" Windows install is currently Windows 10, but I'd gladly wipe it with an old Windows 7 or 8.1 installation (with their own non-upgraded licenses). I'm not crazy about 10 anyway. Or like I said, even down to Vista64 and I could probably even get XP64 to work with my hardware and software. I honestly don't care what Windows version I'm running, I only need it for a few important applications.
- Maintaining two copies of Windows (real and virtual) is a major pain, and is causing problems with some not-very-well-thought-out software packages which are beyond the scope of this, other than to say it would be a major time-saver to have just one install of Windows work either physically or virtually, at will, back and forth, just as my Linux install does.
- I like technical challenges. It took lots of effort to get the "physical Linux in a VM" working, mainly due to challenges with Windows security. (Linux itself doesn't care and is quite happy figuring out whether it needs paravirtualized or native hardware drivers at boot-time.) Once I solved the problems, it "just works" and is rock-solid, back and forth either in Windows or Native. There's a good deal of personal satisfaction just in that.
Evidence that it is possible, robust, and useful
- Parallels running on Mac OS [/X] supports, or at least did support for many years, doing exactly what I'm talking about: Booting to Windows on a "Bootcamp" partition natively, or booting to Mac OS and running the same physical Windows installation virtually via Parallels hypervisor - without a single Windows Activation and/or driver complaint. I used to work at a company where most people did just that. (Note that there is nothing magic about Apple Bootcamp. It's just a partitioning scheme and a utility. Bootcamp is special only because it emulates BIOS & MBR for Windows in a native EFI/GPT setup, and it also automates the tricky and laborious partitioning and installation chores. But all of that can also be done manually.)
- I have an old Macbook triple-booting with Mac OSX Snow Leopard, Ubuntu 12.04, and Windows 7. (All on the same disk in an elaborate partitioning scheme that has worked flawlessly for years.) In Mac OSX, I run the same physical Windows 7 install in a virtual machine, via Parallels. I used to do fairly intensive photo editing session in Windows that way. It's pretty cool, even though I rarely use Mac OSX any more. This is all older software so I'm not sure the same setup is still supported, but this is living proof - right now - that it is not just possible, but actually exists in the wild. Windows under Parallels/Mac is arguably way more stable than Windows on it's own (possibly due to Apple's buggy Macbook hardware drivers for native Windows). Windows never complains about licensing, nor did I have to activate it twice. (And it's within the EULA, at least for Windows 7.) Sounds like magic, but it was all thanks to Parallels - it had (has?) a wizard that figures out what Windows needs to "see" in order to not complain, and configures the hypervisor settings accordingly. With no hacking of Windows involved, other than installation of guest additions / paravirtualization drivers. (Strangely, Parallels uses a virtual ATA interface, while natively Windows is on SATA - so I'm not sure how Windows doesn't complain about that. Maybe the paravirtualized drivers take care of all that.)
- Parallels explains it: http://kb.parallels.com/en/112941
- So that's incontrovertible evidence that it can work, right? (Because I can see it and touch it with my own eyes and hands, and Parallels' website shows you how to do it.)
- Admittedly weaker evidence that the same magic works with other hypervisors, is that there used to be more than one online guide findable through Google, that explained how to do it with VirtualBox. (And IIRC Vmware Workstation.) The steps included manually editing a .vbox definition file, to override attributes VirtualBox provides to Windows about the environment. (To make it look more like what it sees natively.) All perfectly well supported by VirtualBox, there's just no GUI interface to the specific parameters involved, because it's such a fringe use-case for them. I'm not sure how the network adapter MAC address issue gets solved, but it is solvable. (Basically both virtual and real have to have the same MAC address for activation reasons, without conflicting on the network.)
Evidence that it is legal
I understand that for legal licensing issues, it may not be possible with the Windows 10 EULA. I do need to be legal, and more importantly, I'd like this to not get sidetracked over licensing debates as every other similar question has. I still own every version of Windows from 95 through 10 (except ME), I will literally downgrade to Vista64 or XP64 if necessary to be in legal compliance. I'm pretty sure that with some versions of Windows 7, this is legally possible. Maybe or maybe not the way they intended, but in violation of no license clause.
I tried to paste the specific relevant quotes from both Vista's and Windows 7's EULAs that make it pretty clear this setup is OK, but superuser is flagging them as spam for some reason.
Dell Latitude laptop, Core i7, 2.7 GHz, 16gb RAM, Two internal mSATA cards. Have two docks in two different locations with two different monitor configurations and USB accessories, also often run undocked.