[ale] Speeding up VMs

Sun Jan 10 13:47:25 EST 2016

I had already used fixed vHDD allocation instead of dynamic.  The GPU
was maxed out at 128 MB although it shouldn't have been necessary for a
text console based installation.  Guest additions are already preloaded
in the latest version of Virtualbox according to the documentation
(version 5.0.12).

The VM guest OS, once finally loaded, actually ran reasonably well so it
seems only the installer had an issue.  I wiped out the VM and tried
again but one thing I did change was the chipset using ICH9 instead of
the default PIIX3 the second time around.  This time the installer ran
smoothly.  Since that was the only change it appears that the
installation kernel/busybox just doesn't like the PIIX3 emulation.
Guest OS still runs fine with ICH9 so I'll just leave it that way.

On 2016-01-10 05:12, DJ-Pfulio wrote:
> Virtualization is an exercise in sharing resources and making management of
> those resources as easy as possible.
> 
> The single most important item for performance is to re-allocate the virtual HDD
> for the VMs. It has gotten better over the years if you don't, but during
> installation of the OS, a prebuilt vHDD takes 11 minutes and a sparse
> (grow/shrink) vHDD over 30 minutes.  Of course, of your vHDD is on SSDs, it
> doesn't matter and I'd use sparse every time.  No SSDs here.  Changing this
> setting later is a hassle and forces you to use VboxManage from a command line.
> Not _hard_, but that just feels weird on Windows.
> 
> Next is to start out without any GPU acceleration enabled, but for desktops,
> maximize the available video-card RAM to 128MB.  This will prevent most desktops
> from trying to do high-end GPU stuff.  It isn't so bad anymore, but you can
> always enable 2d and 3d accel modes later, after you've gotten the VM performing
> well for non-GPU workloads. These settings can be enabled/disabled later.
> 
> Guest Additions - for virtualbox, installing the guest additions really does
> help, but be careful to read the license agreement. It isn't the same as for the
> main Vbox program.  There are some nasty bit (last time I read it) that Oracle
> had added.
> 
> I've run most of the virtualization tools over the years. Used to give
> talks/presentation about optimizing performance for VMs internationally. My last
> Everything I know about Virtualization talk was in the fall of 2014. Covered
> VMware (player, workstation, ESX, ESXi, Server), Vbox, Xen, KVM.
> Since around 2013, I've been 100% KVM for production uses.  Haven't powered up
> virtualbox on my systems since then. Used Xen for 4 yrs in production, it was
> fast and stable, once running, but hostOS kernel updates would prevent guestOSes
> from booting a few times yearly.  Never had that issue with KVM (using it since
> 2010).
> 
> If you'd like 1-on-1 help with this stuff, come out any Sunday and sit next to
> me with your workstation (or remote connection to the VM system) and I'm happy
> to help. For small scale stuff, I don't think anything has really changed except
> that containers have been getting much more press than they deserve (IMHO).
> Container security just isn't to a point that I'd trust outside a safe, test,
> network for trusted people.  Perhaps in another 5 yrs, Docker, LXC, LXD will be
> mature enough to trust on the internet - I dunno. No amount of claims about
> security can replace years of ACTUALLY BEING secure.
> 
> 
> IMHO.
> 
> 
> 
> On 01/10/2016 01:43 AM, Steve Litt wrote:
>> On Sat, 9 Jan 2016 14:29:32 -0800
>> Alex Carver <agcarver+ale at acarver.net> wrote:
>>
>>> I'm playing with VMs on a home Win 7 computer so I can practice using
>>> the same setup with a work Win 7 computer (the idea being to run Linux
>>> in the VM for certain tasks).
>>>
>>> Right now I've started using VirtualBox but it seems a bit slower
>>> than I expected (I know it's going to be slower than bare metal).  Any
>>> suggestions for improving the speed/efficiency of the VM?
>>
>> My setup is different from yours, but I'll tell you what I've seen.
>>
>> Keep in mind that my host is Linux, and my guests are Linux.
>>
>> Just before leaving Debian Wheezy for Void, I was using Virtualbox. It
>> was nice, but it frequently aborted without warning or error message
>> while doing big installs like Gentoo. I switched to Qemu, and it was
>> rock solid.
>>
>> My experience with Qemu (and as I remember with Virtualbox) was that
>> they were noticably faster than bare metal. This is subjective, but I'm
>> pretty sure true.
>>
>> I've always made my guest systems as simple as possible.
>>
>>>
>>> The test machine is a Core i7 with 16 GB RAM so I've given the VM 4 GB
>>> of RAM.  
>>
>> Yes, that's what I do.
>>
>>> The installation process for the guest Linux is exceptionally
>>> slow, though, which is why I suspect I've set something up wrong or
>>> maybe VirtualBox isn't the best choice?
>>
>> If it's *exceptionally* slow, I'd start to suspect lack of hardware
>> acceleration, either because your mobo/processor isn't capable of it,
>> or because you didn't put the hardware acceleration whatever into
>> VirtualBox (in Qemu it's -enable-kvm ).
>>>
>>> According to the guest machine properties, VT-x, nested paging and KVM
>>> Paravirtualization are all enabled.
>>
>> Ugh! That shoots down that theory.
>>
>>> For the installation, I'm using this as an experimental platform to
>>> learn how to install and manage LVM (and some other experiments on
>>> something that I don't care if I have to wipe).  So I have one virtual
>>> HDD of 20 GB split into three partitions (/boot, LVM PV, and swap),
>>> the PV is part of a single VG and there's a single LV on top of that
>>> VG for root.
>>
>> Just for fun, why don't you lay down Lubuntu 14.04LTS in a VM, taking
>> all the defaults, and see if *that's* slow. If not, you can start to
>> exploit the differences.
> 
> 
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
> 