[ale] mint 13 vm running out of storage space

James Taylor James.Taylor at eastcobbgroup.com
Mon Oct 14 10:27:48 EDT 2013


I would agree, with one additional suggestion.
If you create the VM with two cpu's it will install an smp kernel.
You can drop the cpu's back to one after the install, then if you need to add an additional cpu later, you will already have smp available.
-jt

 

James Taylor
678-697-9420
james.taylor at eastcobbgroup.com



>>> JD <jdp at algoloma.com> 10/14/2013 9:59 AM >>> 
On 10/13/2013 10:21 PM, Don Kramer wrote:
> Glad it worked Ron! Yeah you cut out one step. The way I described it I've done
> once virtually which was just repeating something I've done physically with
> external USB drives on multiple occasions. One other thing to look at on your VM
> is the number of cores you got allocated, for some reason I've read the optimal
> number of CPUs to assign a guest equals the number of physical cores on the host
> minus 1. So in the case on my i7 that is quad core (but hyper-threaded so on the
> host it appears there's eight CPUs), but it's really four cores physically, I
> give my VMs three CPUs.  I don't know the rationale behind doing that, but if
> someone else does or has a different take would enjoy the feedback.

How many CPUs to give a VM?

The answer is "it depends", but generally, 1 is the correct answer on a system
running multiple VMs.  If you have an 8 core CPU, and want to run 4 VMs, you do
have some leeway. I'd start with 1 vCPU for each AND leave 1 for the hostOS.  If
1 or 2 VMs seemed slow, I'd add 1 more vCPU to those.

Workload matters too, especially if the apps are multi-threaded. Generally, I
start with 1 vCPU and only add 1 more if needed.

Leaving 1 free for the hostOS is a best practice.  Also, if the hostOS is doing
10G networking ANd filling the pipe, leave another vCPU for just the networking.

These are rules of thumb. Nothing short of testing the setup in your exact
settings will tell you what works best. Too many unknowns to consider over an
email list.

However, if you give a VM 7 of 8 vCPUs and it runs fine, how will you ever know
if it would perform just as well on a single vCPU or 2?  Start small, add when
needed.

Changing the number of vCPUs on a Linux VM isn't a big deal.  1, 2, 24 vCPUs ...
the VM OS will see that change at boot and adjust.  Start with 1 and add when
"indicated."

If you only run 1 VM, it doesn't matter too much, but when you are running more
than 1 and have oversubscribed the vCPUs beyond what is physically in the
machine, it will matter more and more and more as workload increases.

5 yrs ago, most servers at a very large company ran at 13% average utilization,
so oversubscribing vCPUs is very possible. RAM is more of a concern these days.
 The rules for RAM allocation to a VM are similar.  Allocate what is needed, not
more.  For my Ubuntu desktop, which runs inside a KVM VM, it has 1.5G of RAM
allocated. The hostOS has much more, but it is also running 8 other VMs. Most
get 512MB or RAM, but Zimbra is a hog and needs 15.G ... Ruby on Rails is also a
relative hog - 1G or rubygems cannot be maintained.  Perl + Dancer (a Rails
copy?) is happy on 384M of RAM.  Know your workload and RAM needs to make good
decisions.

Be a good citizen on the VM host - only ask for what is needed, nothing more.

_______________________________________________
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


If this is an unsolicited spam message, please click this link to report it: http://control.eastcobbgroup.com:49285/contents/spamreport.shtml?rptid=37869&srvid=16vl15t





More information about the Ale mailing list