Running Vagrant (Virtualbox) inside of a Qubes AppVm

[David Schissler]

I'm interested in running Vagrant from within an AppVM.  All of the Vagrant VMs would be running different versions of the same software in a particular VM so there would not be a security issue there.

Would the CPU virt extensions be available to a virtualbox VM?

How large of a speed improvement would there be if I passed a mSATA drive to the AppVM with VT-d?

I can see it maybe being easier to keep my more complicated work environment on a mSATA that could survive Qubes updates without much juggling.  Then I could just reformat my main drive to start clean each time with only some routine Firefox tweaks and Firewall settings.  I would then pass my mSATA into a AppVM and work through any version conflicts in the new template.

Does anyone do something similar?

I'm waiting for the v2 RC or v2 Final before I seriously consider switching to Qubes for good as the current F18 situation is not so great.  Eventually in a year or two I'd hope to have a reasonable set of Qubes templates to choose from and that would be better for me than Vagrant.

I think that I could have a friend bring me a Evo mSATA in several months so no rush.  Is this a viable plan and timeline for finally taking the big plunge?

[David Schissler]

Actually I'm thinking that maybe it makes more sense to symlink or to mount the mSATA with fstab than to pass it in.  I'm not sure of that and either of the three ways is easy enough so the best way is best.

[David Schissler]

Can someone please answer if VT-i is available for a virtualbox VM running within a Qubes AppVM.

[Marek Marczykowski-Górecki]

I assume you meant VT-x.
No, nested VT-x isn't supported in Qubes. If VirtualBox can run in software
emulation only mode, it should work, but of course there will be performance
impact.

--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[David Schissler]

Thanks for the answer and I'll counter with another question.

Is there a fundamental reason why VT-x is not or cannot be available from within a AppVM or is it simply not implemented?

[David Schissler]

On Wednesday, March 12, 2014 5:07:58 PM UTC+2, Marek Marczykowski-Górecki wrote:

Also is it true that VT-x is required for 64 bit guests?

[Marek Marczykowski-Górecki]

On 12.03.2014 22:10, David Schissler wrote:
> Is there a fundamental reason why VT-x is not or cannot be available from
> within a AppVM or is it simply not implemented?

Both: Nested VT-x isn't implemented in Xen 4.1 (which is used in Qubes). It is
available in newer versions (AFAIR 4.2+), but even then we don't want to
enable it (at least by default). Is has quite complicated, so have large
attack surface.

> Also is it true that VT-x is required for 64 bit guests?

Depending on definition of "required". Technically it is possible to emulate
64 bit machine in pure software, but I haven't seen any implementation of it.

[David Schissler]

So my Vagrant idea sucks pretty bad.  A bit of typing saved me a lot of install dialogs and BS.

[Vít Šesták]

In theory, Vagrant supports multiple virtualization backends. The most straighforward way to support Vagrant seems to be writing a new virtualization backend. However, this would require manipulating with one AppVM from another AppVM. This requires some permission system – maybe some ACL (maybe that is too complex) or just some “child AppVMs”. Any AppVM would be allowed to manage only its child AppVMs. The child AppVM might inherit some settings (e.g. color) by default and get corresponding prefix from the parent AppVM.

[spta...@gmail.com]

Is this still accurate (for R3.2 and/or R4)? Does the inability to use VT-x apply to HVMs or only to AppVMs? Is this state of affairs expected to change in the foreseeable future? (Any design considerations that might make it less unsafe?)

If I understand correctly, full/faithful hw-accelerated nested virtualization is not possible in Qubes, but vagrant using e.g. LXC backend could be used for development?

[pixel fairy]

On Monday, March 10, 2014 at 7:05:52 PM UTC-7, David Schissler wrote:
> I'm interested in running Vagrant from within an AppVM.  All of the

...

>
> Does anyone do something similar?

https://gist.github.com/xahare/0f2078fc8c52e7ddece1e5ba70c6d5fc

in short, yes, this works fine with the libvirt provider if your willing to take a performance hit from using qemu without kvm. vagrant-mutate can convert virtualbox based vagrant boxes to libvirt ones.

i've done virtualbox in an hvm using software emulation. it also works, but only for 32bit boxes. since most are 64 bit, your better off with libvirt. had to use an hvm for virtualbox because the kernel module wont compile otherwise. maybe an older version in the package repo could work.

lxc is fast, but i havent done more than a vagrant up on a base box with it.

while i have this setup, and it works well, i mostly ssh to a box i built just for running vagrant. its also libvirt. if you want to co exist with virtualbox, i suggest nesting that in vmware. one should concider the vagrant server untrusted anyway. an advantage of this approach is you can use virt-manager and tmux and have vagrant sessions, graphical or not, that you can detach from, share access with others etc.

another approach you could take is running mac/windows/linux and using packer and ansible to make and control VMs to do all your work, and also run vagrant either in that host, or in a vm if that vm is vmware, or possibly kvm. havent tried virtualbox in kvm in a while. of course, if your used to vagrant, you probably already have all or many of your project in vagrant environments anyway.

if you take this approach, and your host is not linux (where you have other options) you can get basic protection against malicious usb devices by using virtualboxes usbfilter and putting a hold on all devices except, specifically your mouse and/or keyboard. but, if an adversary knows the id of those, they can clone them in their malicious versions.