Can't run VB and Parallels simultaneously

[michaln]

Update: Yes, I can run VMWare Fusion and VBox 4.2.16 at the same time.

Good to know.

[Perryg]

@michaln,

So it appears that Mac users can run simultaneous VMX aware hypervisors. This leads to another question of why just Mac? We see that it is not so much the hypervisor that is not playing nice since they all seem to work on a specific environment. It should not be due to the processor since Macs use Intel and so does Linux or Windows.
I know there is sanity code in VBox that looks for VMX root mode and reject loading if VBox senses it which I presume is why it fails in Linux and Windows. (This can also be seen looking at bugtracker)

So when you say play nicely is it Windows OS and Linux OS that is not allowing this or the way VBox addresses the stack?

[michaln]

So it appears that Mac users can run simultaneous VMX aware hypervisors. This leads to another question of why just Mac?

Windows too.

I know there is sanity code in VBox that looks for VMX root mode and reject loading if VBox senses it which I presume is why it fails in Linux and Windows. (This can also be seen looking at bugtracker)

It's not just sanity code. VT-x is designed such that there can only be one entity using it at a time. That's why you can't use VT-x when it's already in use by, say, Hyper-V (and why Type 1 hypervisors suck ).

So when you say play nicely is it Windows OS and Linux OS that is not allowing this or the way VBox addresses the stack?

One relatively minor difference with OS X is that it's currently the only OS which has APIs to enable and disable VT-x. Windows/Linux/Solaris just don't care and everything is up to the hypervisor. But that is really a minor difference.

The short story is that VT-x is not designed to be shared (that's meant to be a security feature). Because operating systems typically do not offer VT-x management APIs, one and only one hypervisor "owns" VT-x on a given logical processor at any moment. The way to "share" VT-x is to initialize and un-initialize VT-x (aka enter/leave VMX root mode) around every execution of guest code. Hypervisor A comes in, enables VT-x, runs guest code, disables VT-x. Hypervisor B does the same. If both/all hypervisors do this, VT-x can be "shared". This obviously isn't for free and reduces performance. That's the reason why don't do it on Linux.

Just don't ask me why VirtualBox can run simultaneously with VMware on OS X but not with Parallels. I have no idea. Obviously we can't look at Parallels' code and see what they're doing. Though they can look at ours.

[jgeorge]

Just don't ask me why VirtualBox can run simultaneously with VMware on OS X but not with Parallels. I have no idea. Obviously we can't look at Parallels' code and see what they're doing. Though they can look at ours.

Well, if I downgrade to VBox 4.2.12, I can run VBox and Parallels at the same time, that is, run VBox 4.2.12 with the version of Parallels that VBox 4.2.14+ results in a reboot with.

I take your point about performance etc, however, in a desktop situation, performance often takes a back seat to convenience...

[michaln]

Well, if I downgrade to VBox 4.2.12, I can run VBox and Parallels at the same time, that is, run VBox 4.2.12 with the version of Parallels that VBox 4.2.14+ results in a reboot with.

That doesn't explain why 4.2.14/16 still has no trouble running alongside VMware...

Again, we don't know what Parallels is doing. Parallels can look at our code if they care.

[EssenceVal]

I disabled VT-x from the system acceleration settings and my parallels windows VM is no longer having issues booting up.

[ngocphamm]

It would be great if either VirtualBox or Parallels team figure out this problem. I'm experiencing this and having to turn off another program is very annoying. I cannot turn off VT-x because it says that I need it for a 64-bit guest OS

[mpack]

Well, as Michal has pointed out, VBox is open source, so the Parallels people can take a look at any time if they want to know what VBox is doing. So, perhaps this site is not where you need to direct your wishes.

[plonka2000]

Came in here specifically to add:

This is apparently been fixed in Parallels v10, details here.

Resolution
For KVM:
Set the KVM module variable vmm_exclusive to 0.

for Virtual Box:
Upgrade Parallels Desktop to version 10.

I hope this is helpful to some future wanderer looking for a solution.

[Krazy Glew]

The details matter. If the VM requires VT-x then you can't run another VM platform (or any other software for that matter) if the other platform also needs VT-x.

That's actually not true. It is possible for two hypervisors to share VT-x, but both have to "play nice". VirtualBox tries to. I believe (not 100% sure) VMware does too.

As somebody who worked for a while on Intel VT, I can assure you that it SHOULD be possible for Parallels to run VirtualBox as a guest, and vice versa. Even if they don't "play nice".

So you SHOULD be able to run two virtual machine managers on the same MacOS host, one on top of the other:

#1:
SHARED: MacOS host
SHARED: VirtualBox virtual machine manager
Windows guest

#2:
SHARED: MacOS host
SHARED: VirtualBox virtual machine manager
virtualizing Parallels guest VMM
Windows guest

But this requires the base level virtual machine manager, Parallels in this case, to fully virtualize. Which, I am guessing, it does not do.

Note also that the 2VMM MacOS/Parallels/VirtualBox/Windows might be pretty slow, since VT hardware for nested/extended page tables only supports 2 layers, guest and host. Whereas in the 2VMM configuration you probably have three layers that need page table translation (base VMM, guest VMM,ultimate guest OS). Lacking such support the base VMM would probably need to fall back to shadow page tables - although that could be avoided by careful SW structure.

Also, the tools that run on MacOS that allow MacOS apps to invoke Windows guest OS apps probably would get confused as to which VMM they are traversing.

---

I say this with a certain degree of confidence because I was assured by other developers on the VT team that VT as shipped would support this.

But also with a certain degree of pissed-offedness, because

1) although supposedly possible, my VT team members did not think such usage models were likely. Well, this thread proves otherwise. And I am here because I want to run VirtualBox and Parallels on the same Mac laptop. I.e. I am pissed because I WANT TO USE THIS FEATURE.

2) one of the reasons I left the VT team is that I thought that the VT structure made such arbitrary composition of virtual machines harder than it needed to be.

Or, rather, I eventually figured out that the IBM mainframe SIE instruction, Start Interpretive Execution, made such layering of virtual machines much easier. IBM mainframes commonly nest 2 virtual machine managers deep, apparently with hardware support, and reports can be found of 7 layers working, albeit with performance loss.

E.g. A Comparative Analysis of Nested Virtualization in x86_64 and S390x Hypervisors Version 1.0 14 December 2014 Document Owner: Daniel FitzGerald
Interestingly, this reports that IBM KVM does nested virtualization on x86.

E.g. the Turtles Project, at IBM Haifa - Running multiple unmodified hypervisors
With their associated unmodified VM’s
Simultaneously
On the x86 architecture
Which does not support nesting in hardware. . .
. . . but does support a single level of virtualization

[loukingjr]

Not exactly sure why you posted to a two year old thread but, as it said at the beginning of the post you can indeed run two VM managers along with guests on Mac hosts. Even back then. And, I can't speak for Parallels but one can run VirtualBox along with a guest inside a guest running in VMWare Fusion because Fusion can be set to pass VX to VirtualBox.

[mpack]

As somebody who worked for a while on Intel VT, I can assure you that it SHOULD be possible for Parallels to run VirtualBox as a guest, and vice versa.

Eh? Did you even read the thread? This discussion had nothing to do with nesting.