Scalable compute services.
Simple object storage.
Run managed Kubernetes clusters.
Tools & Integrations
Automate your infrastructure.
Deploy pre-built applications.
Connect, share and learn
DevOps and development guides
Questions & Answers
Development and systems Q&A
by Justin Ellingwood
This would allow users to run KVM virtual machines inside these wonderful KVM virtual machines.
(Yo dawg, I heard you like KVM VMs...)
Live migrate VM's from my premises to DO. This would be helpfull when performing maintenance, upgrades, high traffic just to name a few.
Nested KVM is now available in NYC1 and NYC3, another locations will be available in the future.
Would have many issues with bridging out the networking unfortunately.
Are you specifically anticipating collision with the upcoming private IP feature, or just with people expecting that nested KVM would also get them new public or private IP addresses for their droplets?
I didn't have any problem with running LXC and assigning a 10.0.0.0/8 RFC 1918 address on an Ubuntu 12.04 LTS machine.
I'd like this to run Windows inside your Linux VMs. I have Microsoft MSDN subscription and need test with Windows instances sometimes. Appears to be working, but I'm not sure how to verify this is using full hardware virtualization vs. emulated processor etc. (been googling). Seems kinda slow, so I assume probably my Windows VM is emulated right now.
This needs to be enabled if you are to fully support this article:
With the nested vm feature disabled it's not possible to run 64-bit guests under virtualbox or kvm for that matter.
Since all Windows 2008 R2 + 2012 servers are 64-bit only, I think this should be a feature to be considered. Would be so nice to be able to move some virtual Windows servers to digital ocean :)
Here's my 2 cents: https://www.digitalocean.com/community/questions/support-hardware-virtualization
This will become easier when IPv6 is enabled in terms of networking.
I'd love this to be able to create a big droplet and install a virtual build/test farm on it: Linux x64, Linux x86, Windows x32, Windows x64, even MacOSX.
It will give good platform for testing and training needs
Would be a killer feature! +3
For our use case (a pxe lab for students) the vms can rely on the host vm performing nat
I have enabled KVM nested virtualization on my Ubuntu Zesty server (using libvirt/virt-manager) and the corresponding VMs can access the Internet without any issue...
I don't see the problems you may face while "bridging out": the inner VMs access the outside with NAT, which is a common setup.
is this feature available? I am getting VT-X not enabled error.
This doesn't just apply to Linux and KVM, there's also bhyve on FreeBSD.
@Moisey What kind of networking issues are referring to? Enabling hardware virtualization doesn't require networking changes in and of itself... Network changes would only be requires for those who chose to use nested virtualization. And no networking changes should necessarily be required on DO's end--VM traffic could just be forwarded to the VM from the Droplet's public facing IP.
For use case, I was considering running an OpenBSD VM within a Droplet as there's functionality in OpenBSD that isn't available elsewhere.
From a cost prospective, there's a practical limit to how many VMs, and the types of VMs, that can run in a given Droplet. That is, DO still gets paid for resource usage and there's limited benefit to cramming a bunch of nested VMs into a single Droplet--the primary use case I personally see and would use is to provide services that aren't natively supported by the Droplet types you currently offer.
This also happens to be a barrier for me to move all my services to DO as I require OpenBSD for a few things.
You won't be notified about changes to this idea.