Fix No Networking Issue for CentOS Under VirtualBox

The first argument inside the quotes of the rule you created is the rule name. You can delete the rule by name like this:

VBoxManage modifyvm xp --natpf1 delete guestrdp

To find these kind of things out the fastest place to look is VBoxManage --help | less.

As per my answer to this U&L Q&A titled: Can VirtualBox run under Xen Dom0? the answer here is no, you cannot run VM technologies such as this on top of XEN or Proxmox/OpenVZ. You can likely run OpenVZ within a VM inside of VirtualBox.

But I'm assuming you're asking your question mainly around the desire to allow Jenkins the ability to access more architectures.

KVM

What we do where I work is we setup multiple KVM instances of Linux (doesn't matter what distro) and on top of this run many VMs. You could do the same. This would be identical to using Vagrant + VirtualBox, so I'm not sure if that helps.

An alternative?

If you truly do not want to have to run this on physical hardware the 2 technologies that might allow you to do this are Docker and LXC. These are similar to Proxmox & OpenVZ, but allow for much more granular control. You still will not be running VirtualBox within these either, but perhaps you can conceive of a solution where you could leverage these 2 technologies instead.

excerpt LXC

LXC is a userspace interface for the Linux kernel containment features. Through a powerful API and simple tools, it lets Linux users easily create and manage system or application containers.

Features

Current LXC uses the following kernel features to contain processes:

• Kernel namespaces (ipc, uts, mount, pid, network and user)
• Apparmor and SELinux profiles
• Seccomp policies
• Chroots (using pivot_root)
• Kernel capabilities
• Control groups (cgroups)

As such, LXC is often considered as something in the middle between a chroot on steroids and a full fledged virtual machine. The goal of LXC is to create an environment as close as possible as a standard Linux installation but without the need for a separate kernel.

excerpt Docker

Docker is an open-source engine that automates the deployment of any application as a lightweight, portable, self-sufficient container that will run virtually anywhere.

Docker containers can encapsulate any payload, and will run consistently on and between virtually any server. The same container that a developer builds and tests on a laptop will run at scale, in production*, on VMs, bare-metal servers, OpenStack clusters, public instances, or combinations of the above.

Common use cases for Docker include:

• Automating the packaging and deployment of applications
• Creation of lightweight, private PAAS environments
• Automated testing and continuous integration/deployment
• Deploying and scaling web apps, databases and backend services

Vagabond?

This might be another way out for you instead of utilizing Kitchen you could use Vagabond here instead. In looking at the website it claims to integrate with LXC (same technology mentioned above).

excerpt

Vagabond is a tool integrated with Chef to build local nodes easily and most importantly, quickly. It uses Linux containers instead of full blown VMs which means things are faster. Lots faster.

Vagabond is built for Chef. The tooling within Vagabond is targeted at Chef. After the initial development has slowed, the Chef specifics will be pulled into a plugin.

Also according to the website it claims to have support with Kitchen 1.0.

Vagabond provides test kitchen 1.0 support. It will map boxes defined within platforms to platform templates available (to the best of its ability). No need to spin up vagrant VMs, or use another tool. Point vagabond at the cookbook, and let it handle the details.