Forget about the outer virtualisation for a moment. In a bare metal world, vagrant+vb are used to build testing environments. It is used to run unit and functional tests.
Let's take a simple web project as an example:
- the project has ansible playbooks tied to it
- the playbooks define a web and a database server
- to be able to run the tests inside the specified environment, jenkins needs to build the servers according to current specifications
- all this is done to ensure the code runs in the currently defined systems (e.g. there may be php upgrades in the feature branch or any other nasty things)
As far as I know, it is common practice to use vagrant for that scenario. Vagrant is also used for development. So the pretty much same environment is used for development, for tests and later also for deployment. Production and staging servers are not deployed using vagrant and they do not run inside virtual box, but the ansible-playbooks provision them the same way, as the virtual boxes in development or during tests in Jenkins are.
Does that make sense so far?
I think vagrant is the best solution for that. This is why there are vagrant plugins for jenkins, I guess.
Now we come to nested virtualisation:
---------------------------------------------------
Our operations department would like us to run Jenkins inside a KVM domain, because they want to avoid to maintain a bare metal box. This is the business requirement and this is also why I tried to set up things inside KVM. I found everything is working inside the KVM domain, but virtual box performs weak. Although the performance of the web project would be good enough for development, it is too weak for unit tests. The tests should run as fast as possible.
After some investigation, people tend to say virtual box does not like to be nested. Well, according to my findings, this may be true.
This is what brings us to the cloud:
----------------------------------------------
If the bare metal scenario with vagrant+vb+jenkins is common practice, I wonder how people do this in a cloud environment. I do not want to move Jenkins to the cloud, nor do I care why other people do it. But I am sure there are people out there who run jenkins in the cloud. This is the only thing, that counts at the moment.
And if they do it in the cloud, they would run VB inside a VM, as any cloud server is virtualised, isn't it? Is anybody able to follow my arguments?
So one of the following is true:
1) People do not use VB to build their testing environments, neither bare metal nor in the cloud (what else do they do to make sure the test system is well defined?)
2) People use VB to build the testing environments and so they use it in the cloud.
If 1) applies, I am eagerly interested in what they use instead of VB? When doing it in the cloud, do they set up new EC2 instances for any test run?!?!
If 2) applies, it is an indicator that our local setup with KVM is wrong. This does not yet prove it is possible with KVM, but at least we know that virtual box is able to be run as a nested hypervisor somehow.
I need some people to tell me about their experience running Jenkins+vagrant+vb in the cloud. People having this setup run in KVM are also welcome, but it is probably easier to find someone doing this in the cloud. Experiences of somebody having done (or having tried) this in in the cloud, would give me valuable hints.
Where is the failure in the line?
PS: Docker is not an option, as we are not able to deploy containers to our production servers.
Thank you, too!