My turn to ask a question: Why are you gathering this information - do you have any sort of plans for a VM app or maybe a new VM project?

Following up from the plans for a multicore app, I'm pondering deploying it in a VM to avoid the cost of porting to Windows.

BTW, passthrough of GPUs to the VM isn't possible with VirtualBox (the only supported configuration is QEMU and a Tesla/Quadro)

Matt

I wanted to mention one more thing that occurred to me, regarding VMs. There are sort of 2 different ways of handling the downloading/uploading of the work.

Method 1:
The way it was intended by the BOINC devs (used by RNA World): BOINC downloads the VM and the work, and the VM is fired up to run that 1 task. A "shared folder" is setup within the slot directory, where BOINC deposits input files (used by the VM), and later grabs output files (given by the VM). When the task is done, the VM is fired down and the result it uploaded by BOINC.

Method 2:
The way where downloading/uploading of work is managed within the VM (used by Test4Theory): BOINC downloads the VM, but the VM does some network connections to get 1-or-more tasks, or even get new tasks in serial after the prior task completes, and the VM runs indefinitely or it runs until it has been configured to shutdown.

Test4Theory uses method 2, where they run a VM for 24 hours, and in that time frame, the VM uses networking to get a task, run it, report it, get another, etc., several times within that 24 hours.

I've personally had some problems with the way Test4Theory does this. There are times when their servers (called "copilot"?) aren't working, and then an entire CPU is completely wasted, because BOINC "allocated/gave" that task the CPU, and the VM doesn't utilize it. That was a bitter pill for me to swallow, since I desperately desire to keep all of my resources fully-utilized.

Method 1 is preferred, so far as I know.

Regards,
Jacob

I suggest you release a native Linux app first, and test it in the wild.
Then build a VM to facilitate Windows only crunchers, if you think you need to.
Then, and only if the VM doesn't hold up, port to Windows.

Anyone using Windows can download VirtualBox, install Ubuntu as a VM, install Boinc and attach to whatever CPU projects they like, without any need for projects to build VM's. Other benefits include better resource control for the user (cruncher), a simplified system (with potential for isolation of GPU and CPU projects), no project VM download overhead, no project work involved and no waiting for further development.

Is that so much harder for a GPU cruncher (who can install cards, drivers, tools and configure Boinc) than downloading the Boinc client along with VirtualBox?

There has been Linux images with Boinc already installed for years, not that installing a VM or Boinc is in any way difficult.

The big issue with the Boinc+VirtualBox on Windows is that each Boinc project has to use a separate VM to run apps. That means big overheads, more potential bugs and problems, and lesser isolation from Windows. In a years time people could be attached to 5 or 10 projects using VMs. They would need plenty of RAM to run anywhere near capacity and a plump disk drive. While the VM development have facilitated the likes of RNA World, it brings more problems and generally increases complexity of Boinc crunching. I don't think every project need add to that with a bespoke VM.

When the app is out and tested in a native Linux environment vs a manual VM, you will then know what the performance difference is and whether or not it's worth the trouble building and testing for Windows environments (XP, Vista, W7, W8, servers). BTW some apps such as SLinCA@Home don't run well in VM's (reasonable for one task, bad for two, terrible for many).

The early users of VM's do so for good reasons (to enable a sort of checkpoint in the case of RNA World), and setup their VM's accordingly.


PS. I thought that VT-d capable processors might allow VM I/O to the GPU, but they have been around since 2008, and nothing yet. It makes sense that there is a GPU dependency too (GPU's also have to facilitate this, and they don't unless its a Tesla/Quadro). Presumably it's been removed from the other GK110's (Titan, 780, 780Ti).

---

FAQ's

HOW TO:
- Opt out of Beta Tests
- Ask for Help

Your concerns regarding numerous VMs, one from each of several projects, is valid. If that trend continues it won't turn out well for any project. A better approach is one (maybe two) VMs that can run any and all projects that need to run in a VM.

Regarding Tesla and Quadro working in a VM, try GeForce GTX780 to Tesla K20 . There are links for GK104 too, gonna try it on my 660Ti soonest. I'll be buying as many 780 as I can and keeping copies of recent drivers because nVidia will put a stop to this somehow.

---

BOINC <<--- credit whores, pedants, alien hunters

Regarding the potential use of GPU's within a VM,
A quote from, http://askubuntu.com/questions/202926/how-to-use-nvidia-geforce-m310-on-ubuntu-12-10-running-as-guest-in-virtualbox

PCI passthrough

PCI passthrough is experimentally supported in recent Virtual Box closed source (PUEL) versions. However there are several limitation, i.e. for a graphics card we can read from the Virtual Box User Manual:

AGP and certain PCI Express cards are not supported at the moment if they rely on GART

I cant tell if this is the case with the Nvidia M310, you will have to figure this out first before you try.

To get PCI passthrough working we also need a motherboard with an enabled IOMMU from BIOS settings (i.e. VT-d for Intel, AMD-Vi for AMD).

There are several additional prerequisites to be met (see Virtual Box Manual for details):

Your motherboard has an IOMMU unit.
Your CPU supports the IOMMU.
The IOMMU is enabled in the BIOS.
The VM must run with VT-x/AMD-V and nested paging enabled.
Your Linux kernel was compiled with IOMMU support, DMA remapping, and the PCI stub driver.
Your Linux kernel recognizes and uses the IOMMU unit.

We can then attach a PCI device with its bus:device.function properties read from lspci to our virtual machine using:

VBoxManage modifyvm "VM name" --pciattach <host-bus>:<host-device>.<host-function>@<guest-bus>:<guest-device>.<guest-function>.

See in the guest with lspci if the device was attached properly before installing drivers for this device.

Please also refer to the Virtual Box Manual for further limitations.

My CPU is a K model (not VT-d), a show stopper for me!

PS. I think the existing VM CPU projects also require VT-x/AMD-V. While some motherboards have this automatically enabled, you have to set it in others. To an amateur cruncher configuring the Bios is probably just as hard as installing Boinc in a VM. While most modern CPU's have either VT-x or AMD-V some Intel processors dont.
For reference.
List of Intel processors with VT-X
List of Intel processors with VT-d
List of Intel processors without VT-d
- Might be useful for projects to test for VT-x/AMD-V before downloading an 800MB VM!

I had read about the GK104 hacks before but not the GK110 hacks.

---

FAQ's

HOW TO:
- Opt out of Beta Tests
- Ask for Help

I have solved my "Host responsiveness" issue that I reported as #8 in my list.
Basically, Oracle VirtualBox has had a bug since v4.2, and the bug still affects the current release, v4.3.2. Read on for a solution.

The bug manifests itself as huge DPC Latencies in the host environment, possibly only on x64 Windows hosts. For me, this meant that the mouse cursor acceleration was misinterpreted, my mouse cursor skipped around irregularly, my music sometimes skipped, and my windows/controls sometimes lagged when being painted/refreshed/moved. My workaround had been to only allow 1 VM to run at a time, since the problem dissipated with just 1 VM running (problem still existed, just not as bad). Keep reading for that solution.

The bug is documented a bit in this thread:
https://forums.virtualbox.org/viewtopic.php?f=6&t=58030&sid=029eb906ea896f79a218b8d33ed399cf

The VirtualBox devs believe they've fixed the problem, and they gave a link to a 4.3.3 Test version at the top of page 2 in that thread.

That 4.3.3 Test version does indeed resolve my host responsiveness issue. I can now run 3 VMs, plus 4 other non-VM CPU tasks, plus 3 GPU tasks, while listening to music, while playing a game.... all without a single problem. Life is good again.

I expect the 4.3.3 official release (no ETA yet) will include this bug fix.

Regards,
Jacob