I have an old VMWare guest which is openSUSE 12.2 which has 2 virtual hart disks (one of which split in several .vmdk files). I want to boot this guest in order to make a mysql dump of 2-3 db’s and copy a few files. However I am not willing to install VMWare on my fresh 13.2 host system as I am not planning to use it. My attempts to run the guest in KVM failed. Maybe it is possible but it seems I don’t know how to do it properly. That’s why I installed a new Win7 x64 guest inside KVM and then a VMWare Workstation hypervisor nested inside it. I added the option
vmx.allowNested = TRUE
in the guest. However when I try to run it VMWare says:
Binary translation is incompatible with long mode on this platform. Disabling long mode. Without long mode support, the virtual machine will not be able to run 64-bit code. For more details see http://vmware.com/info?id=152.
and I click OK and then:
This virtual machine is configured for 64-bit guest operating systems. However, 64-bit operation is not possible.This host does not support Intel VT-x. For more detailed information, see http://vmware.com/info?id=152.
and this time clicking OK simply closes the guest without booting it.
I have read on some sites that the solution to that is to enable VT-x in BIOS. However in this particular case there is no BIOS because of the nesting inside KVM. I unchecked the checkbox “Virtualize Intel VT-x/EPT or AMD-V/RVI” in the guest’s settings but t hat didn’t help.
How can I solve this without installing VMWare on the root host? All I need is to get my data from the guest.
That’s not possible today (running a VMware Guest in a KVM).
A relatively new feature in almost all VMs is “nested” virtualization, which essentially configures the Guest to bypass the Host and access the CPU directly for hardware virtualization support(resulting in fairly decent although degraded performance), but in almost all current implementations you still need to run the same virtualization.
Virtualbox 5.x seems to be the only exception because even if you select a different “interface” virtualization for the Guest, VBox seems to still run its own hypervisor but can impersonate other hypervisors by exposing an interface consistent with the other hypervisors. In other words, since you’re still running the VBox hypervisor you’d still be subject to its performance and security but a Guest configured to run using another hypervisor would still be able to run.
You can always try creating a KVM guest using a vmdk which is VMware’s native virtual disk format (because KVM will recognize and read), and create new machine settings. This would be somewhat similar to migrating a real, physical installation from one machine to another with dissimilar hardware… graphics and other virtualized hardware would have to be re-discovered and new installed,
Is why I <always> don’t accept the default and instead specify a single disk file.
AFAIK multiple disk files would be a consideration only when deployed on 32-bit file systems (then you’d have a 2.2GB file size limit).
It’s bad enough having to deal with snapshots (which I always merge before porting the vm elsewhere).