[Resolved] Running VB on Intel-NUC box

[TheMattMan042574]

I am looking to setup a VB(VirtualBox) server on an Intel NUC device. Namely the newer BLKNUC7i7DNH1E with i7-8650U, 32 GB ram, 250gb SSD and an external USB 3 drive for the VM's. Any suggestions, hints, warning?

[socratis]

That looks like a nice computer with an i7-8650U (4 cores/8 threads), SSD, etc. The one thing I'm not clear about is the GPU used and its driver support. We used to have issues with older Intel integrated GPUs, but lately it seems that it's getting less of a problem...

What OS are you planing on installing on this? Because all the drivers I'm seeing are Win10 only...

[andyp73]

an external USB 3 drive for the VM's. Any suggestions, hints, warning?

Depending on what kind of external drive you have you may find the performance unacceptably slow.

-Andy.

[socratis]

Right, right... you're absolutely correct Andy, we had this discussion the other day: "Having my VMs on a USB key makes them slow". The OP in that thread had a USB key, I had an external HD, which is a more fair comparison to what "TheMattMan042574" will be doing...

[JEBjames]

I'm not recommending running anything mission critical off USB.

If you insist on using a USB attached SSD you ideally want a USB 3.x one that supports UASP and does trim pass through.

I did three automated Lubuntu vm installs in parallel at the same time on a few mini pcs in some USB scenarios:

PC #1 N3450
Celeron N3450 (4 core, 4 thread)
4 GB ram
Lubuntu host os installed on 32GB eMMC
Each guest has 1 cpu and 750MB ram.

On PC #1 I've done two tests:
- All guests installed on a USB 3 attached ancient SATA 3 laptop hard drive.
- All guests installed on a Sandisk Extreme 32GB USB 3 key. This is a good USB key. Most USB keys are pure garbage for random read/write performance and writes in general. Unless you know for sure your USB is one of the very few good ones don't even bother. And don't expect it to live a long life either way.

As expected, during the operating system install the disk is hammered. Cpu is pretty much pegged over 90%. I don't have performance numbers, but it wasn't too terrible in either scenario. Wasn't great either.

I've also did the same install on a very similar Intel Nuc:

PC #2
Celeron J3455 (4 core, 4 thread)
16 gb ram
Lubuntu host os installed on a 240GB sata attached Kingston ssd
Each guest has 1 cpu and 1.8 GB of ram.
Guests are also installed on the same internal Kinston SATA SSD hard drive.

I don't have any exact numbers, but as expected, faster internal SATA SSD runs better during the install.

But once everything is up and running and just sitting there idle, all the vms individually run okay. Application launching had noticeable speed differences. Sata attached SSD, as expected was best, then anything usb attached. With the old laptop drive being worst.

The other reliability factor for USB is gizmos and cables dangling off the USB ports. Accidentally bumping or unplugging a USB drive that's in Use. People randomly stacking stuff on your desk on top of your still-spinning mission critical hard disk shouldn't be a real thing. Lets just pretend that never happens.

For kicks I made a script that glues two attached storage devices...a faster and slower device together into one tiered "lvm cached" drive. I did a test with the Sandisk Extreme 32 USB caching the USB attached laptop drive. In "writeback" caching mode the disk IO to the laptop hard drive went from constant to me thinking the laptop drive must be unplugged...almost nothing hit the laptop drive everything hit the cache. I didn't measure performance, but the lack of constant hard drive rattling was almost worth the time looking up how lvm caching worked.

If you have a slow mechanical hard drive...using some of your SSD storage to cache it something to consider.

Yes...yes...using usb for any mission critical VM makes no sense. But it is convenient for doing some quick tests.

[socratis]

Here's what I do:
I have all my VMs in my internal SSD. All ~75 of them . Each one with a single snapshot, just used for the "Undo" cases, otherwise it's empty. But you can potentially ignore that step, as it's a tad more convoluted.

I have a duplicate of my VM folders on an external USB3 (and another computer for backup, but I digress).

The way that I have *both* my VMs *and* a limited SSD space for testing, is that I delete the VDIs/ISOs from my SSD, and I leave a copy only in my extHD (and that 3rd backup). So, I pretty much have 75 VMs, most of them inaccessible!

When I want to run a VM, I simply copy the corresponding VDI from the extHD to my internal SSD, in the VM's directory. I have about 10 of my often used VMs sort of permanent like that. The rest? I swap them in and out. I get a lot of high I/O rates like that (about 5-10 sec for each VM), so copying a VDI from the extHD is a no-brainer.

So, if I want to run the older Win10-32 VM, that I haven't had a need to use in the last 3 months? I copy the "Windows 10.vdi" from the extHD to my internal USB. Done testing? Delete the VDI and I'm done. Back to my normal free SSD levels...

[JEBjames]

Socratis,

That's a neat approach with copying the vm in and out.

Personally, I'm afraid of snapshots. I have bad memories of "another" virtualization software way back...an accidental click and without confirmation (or without paying attention?) I was instantly back in time. Everything I did in the last few days since the previous snapshot was gone. In this case it was a document management vm...and I was very lucky. I'd done a full document checkout a day earlier. So I could copy my checkout folder, re-check it out, manually copy over any documents changed in the last few days and then check everything back in. Then wise up, back everything up, and stop using snapshots ever again.

"Snapshots are not backups" got stuck in my head.

No doubt, for some testing/use cases snapshot "undo" is great. But for me, not so much.

Your copying idea to put a vm on the storage shelf until needed is similar to what I want to do.

By coincidence, yesterday I added file copy/zip backups to the web admin gizmo I'm making.

I have two main pcs running VMs. If one of the PCs goes down I move the VMs to my other one, or worst case one of my Linux mini pcs.

I have a second linux script that installs virtualbox, creates my testing vms with known mac addresses so in theory the dhcp server will give them a consistent ip no matter what pc they spin up on...I've run this from both my linux mini pcs and it works. But my main two pcs are on Windows so I have to think about that part.

What I really want to know...is if the windows 10 bash shell is just the shell, or if it pulls down hyper-v in some way and will cause a conflict with virtualbox?

My admin tool... It's like lego for vms. It gives you keyboard/screen remote access...without needing RDP. Anything you can do from the web admin can be recorded into a script. And you can also run your pre-made scripts from the web gui too. So...you record all the steps to install an os, and then you can run this script any time and rebuild the OS. And since the script is just doing a web pull...you can have a cron job in your vm that shuts itself down via acpi, backs it self up, then restarts itself. Madness. Or Sparta. One of the two.

I was thinking about using the windows Bash environment and then using that so that I won't have to build parallel scripts for windows/linux. Does anybody know if "windows 10 bash" pulls in hyper-v or conflicts with virtualbox in any way?

[socratis]

Personally, I'm afraid of snapshots.

Me too. That's why I said there's only one snapshot, not primarily to keep the changes piling up, but to prevent the changes from piling down. My snapshots are empty, virgin, there's nothing to be lost there.

"Snapshots are not backups" got stuck in my head.

Tha't the motto around here as well!!!

What I really want to know...

That's a completely different subject, no? Nothing to do with the thread. And since the thread isn't titled "JEBjames' questions about VirtualBox", I suggest you create a new thread. One issue per thread, one thread per issue. Appropriately titled.

To briefly answer your question:

if "windows 10 bash" pulls in hyper-v or conflicts with virtualbox in any way?

I don't see why bash would need VT-x (aka hardware acceleration) to do whatever you have to do. I really highly doubt it...

But please don't answer here if you have to. In a new thread...

[TheMattMan042574]

Thank you one and all for the wonderful replies and suggestions. I have the unit now and am installing Ubuntu 18.04. I did run the VM's for a while on an older full tower system using the very USB3 WD drives I am attaching to the NUC and the VM's worked wonderfully, so issue of slow down at all. What I am having an issue with is installing VB on the NUC. I keep having issues of "no kernel driver" and the like, very odd.

[TheMattMan042574]

Update: I believe the issue was that the hardware of the NUC was reporting i386 to the VB installer. I used that version and it seems to be working.

[socratis]

Glad you got it going! \o/
I would like a confirmation that everything is working before marking the thread as [Resolved](?).

[TheMattMan042574]

Everything is working great at this point. I have the main VM start about 90 seconds after boot/reboot of NUC server. The plex library plays at full 4k if that is what the media file is encoded at that rate.

[socratis]

Great, thanks for the feedback. Marking as [Resolved].