Editing Virtual Machine vInception (section)

== Which Type To Use? ==
As with everything in the homelab, it depends!

=== Type 1 ===
Assuming you don't have the budget for a scale out physical solution, a Type 1 nested hypervisor is a great option! It allows you to test and run all of the main features of your chosen hypervisor both natively on physical hardware, as well as virtually when layered inside of your "root" host. Most commonly a Type 1 vInception config is based in a single host with [[Storage#Local Storage|local storage]], but this does not have to be the case!

Bear in mind of course that every time you want to do any maintenance on your Type 1 vInception host, you will need to suspend or stop all of your VMs, which can be a pain. Typically this should not be too often though, as you are running a hypervisor instead of a client OS, which means patches are relatively irregular, and as this is non-production you will not be under the same pressure to keep completely up-to-date on the patching front.

Some people will actually run a Type 1 vInception configuration even if they have a physical cluster. The main benefit of this is if you want to test other hypervisors and newer versions of your current hypervisor without rebuilding your lab; for example, many people ran vSphere 6 on top of vSphere 5.5 during the beta period. With a Type 1 hypervisor in a scale-out cluster and some shared storage, you have the ability to vMotion or live migrate VMs between hosts, thereby mitigating any issues with patching and maintenance.

=== Type 2 ===
If you are on a very small budget and cannot afford a dedicated homelab host, or simply need portability for your homelab (i.e. a laptop), then it makes a lot of sense to run using a Type 2 [[hypervisor]] on top of your existing working machine. Typically this would be either a Windows Client OS (Windows 7/8/10), Mac OSX, or Linux.

As with Type 1 vInception, every time you want to do any maintenance on your Type 2 host, you will need to suspend or stop all of your VMs. Similarly the regularity with which you need to patch the client OS of your type 2 host means again you have to either suspend or stop all of your VMs. Lastly you will not have access to any enterprise features in a type 2 [[hypervisor]], such even vMotion or Live Migration, which would mitigate the maintenance downtime. If you are looking for consistent uptime on your lab, a type 2 hypervisor probably isn't for you.

That said, the great things about Type 2 [[hypervisors]] is that they're very inexpensive, or even free, and very fast to setup You could probably run up a mini lab on the machine you're viewing this page on right now, assuming it is Intel/AMD based! Most homelab users probably started with a Type 2 hypervisor setup!

If you only plan to run a handful of VMs then why run to the complexity of a Type 1 setup, especially when a Type 2 is often more than adequate?