virtual guest OS in a virtual guest OS in a virtual guest OS in a ...

has anyone tried doing infinite virtualizations inside virtual machines.

will it even work? I guess only the first stage host---> first guest can take advantage of processor VTx enhancements ( i guess ultimately they all will but less and less effecient and more and more cpu intensive overall), but it should work right?

 

Should work fine if you have infinite memory, and as long as the virtualization software doesn't care that it's being run inside a container. The problem you run into is you're taking a, say, 8GB RAM host system and you give the guest 4GB. It has to run in some of that memory, as does the virtual host inside it, so you can give 3GB to the guest. And that guest can give 2GB to it's guest. And eventually you run out of memory and likely processing speed.

But theoretically nothing is stopping you from running all the way down the rabbit hole as long as the guest OS can act as a virtual machine host.

 

lol the performance should be interesting. not just processor but the network also. id imagine internet will be quite slow if it even works.

 

It depends on your virtualization technology. If you have a traditional virtualization like VirtualBox or VMWare it doesn't work, because the host's CPU is not emulated but directly handed over to the VM. This creates some security risks that need to be handled by the VM software. Therefore a VM inside a VM can't access all features of the CPU and will not start due to that.

If you use an emulator like qemu, even the CPU will be emulated which means you can run infinite emulations because every VM sees a full CPU. But this CPU emulation comes with a huge performance loss, even without multiple VMs.

I don't know if there is a software that uses some mixed strategy (or if this is even possible at all) that does not emulate the whole CPU but only the missing parts.

 

like debguy said, it depends on what you are using.

I once tried running Virtualbox under Hyper-V and it cannot boot.

 

In theory it's doable. But the real question is why would you want to do this. Beyond just trying it for fun I can't see why anyone would want to go for more than 2 layers deep.

The 'big 3' packages (VM, VB, and HX) are all able to detect cascaded/embedded virtualization and will tend to refuse to run (but not always). I don't know how Parallels treats cascaded setups like this.

Hardware hypervisors like you see on Dell servers (and IBM Intel & Power servers too) are even more strict. You need to run the client OSs within a strict config envelope. Step outside of that and at best you're unsupported and at worse the hypervisor will refuse to start to OS in anything other than safe mode.

Every time you toss in a layer of virtulization you're adding performance overhead and complexity. Both tend to add a lot to the risk of crashing the client and/or host.

The job of the virtualization package is not to support unnecessary complexity. Job One is to ensure the stability of not just the individual clients but of the complete overall system/host.

 

Seems pointless when you can just run additional VM's alongside the first one instead of inside it.

Gary

 

oh, and anyone who is thinking that running a 'deep' layer of VMs will mask their net identity or location is fooling themselves.

Your VM session will always be traceable to the network adapter on the host machine.

 

i've done this. virtualized windows 98se in virtual pc 2007 inside virtualized windows xp in virtualbox with windows 7 64bit as host. it was interesting and awful.

background info: i have win7 64bit with windows vpc installed and needed to virtualize win98se with guest additions. i tried to install vpc2007, but could not because windows vpc was installed. so i did the nested virtualization and it sucked, big time. the worst part was the mouse - it was all over the place: i move my mouse a little to the left and the cursor did a crazy up and left arc motion. it really pissed me off as i couldn't get anything done with the mouse and ended up strictly using the keyboard. i haven't had to do that in years and had since forgotten most of the keyboard shortcuts. i ended up grabbing the vpc2007 additions .iso from vpc2007 and used it to install guest additions inside windows vpc. its a convoluted mess, and i probably didn't do a good job describing it, but i got the job done and will never waste time nesting virtualizations, again. i would not suggest anyone else do it either.

 

Didn't they do a movie about this some time ago?


...Inception

 

this is more of an academic inquisition than a practical one of course.

i wonder what its like if someone is switching up the virtualization packages as well as the OSs along each step of the virtual machine. this will make it even more complex.

an exploit must be very well thought out to penetrate to the host via this multilayer implimentation

LOL true

 

And before that was The Thirteenth Floor.

 

Yes, you can run the VBox UI inside of VBox, but if you try to start a VM within the VM it will complain about insufficient rights to access certain CPU registers (don't remember which ones). At least that is what happens under Linux and I doubt that this is any different under Windows.

No they aren't. Because VBox deals with them. If it wouldn't and you'd run an compromised guest you could compromise the host too (e.g. via null pointer exceptions that execute arbitrary code within the CPU registers).

 

Nested virtualization can and has been done using various hypervisors, although it depends on the virtual machine package used and the processor you have. You may need to do some modding/hack than just rely on a user friendly install process. I havent tried this, but I wonder if you can simply import virtual machine files into the guests and run them inside t he guest, since most of the time the problem is with installing OSs inside the 1st level guest.

There are practical and software development advantages to nested virtualization. Security is one for the practical, and debugging for software development.

 

so techincly you can have the ultimate netbook simulator from the safety of your good laptop/desktop??

 

I've done this on the mainframe scene, using IBM's VM(Virtual Machine) operating system. Not to be confused with VMware, or any MSFT stuff. VM was the original hypervisor, created in the 1960's, and somewhat used as a pattern for VMware and all of the other present day virtual machine opsys.

Not a big deal to do so. You just have to lay out and map how you want your disk setup to look, along with memory, etc.

Now, each level takes a cut of mips(and all other resources), such that things get progressively slower as you go along. Eventually, you'll bog down.

Been a long time since I did this, but I think I went 3 or 4 levels deep. Any more than 2 or 3 levels and it's the same old thing, next round. I believe I read of someone going 7 levels deep, but it really doesn't matter any once you get to level 3.

 

VMware Workstation officially supports ESXi as a guest, which, under this configuration, further offically supports a couple of versions of Windows (I think it was XP, Vista, and 7).

Performance was acceptable after VMware Tools was installed (with Vista SP2, I was getting Conroe-era performance and responsiveness on a Sandy Bridge host), but VMware made it very clear that this was mainly for salespeople and consultants to do demos of ESXi, not for real-world usage.

 

Yes but then how will you know which is virtual and which is real?

 

Actually you could by looking at the drivers or machine name, etc. There are ways. Some exploits know not to execute in virtual machines so as to prevent security analysts from purposely infecting virtual machines to generate fixes for the bugs.

Although the real question is, how will the exploit know how deep of a virtual OS they are in?

 

It doesn't have to.
If the CPU is not emulated but only passed through every instance from the host to the last guest will be affected by that exploit, no matter in which instance it will be executed. If the CPU is emulated only the instance on which the exploit was applied will be affected.