I'm setting up the development / IT segment for a small company (100 worker bees, 4 code monkeys, 2 net ops people with crazy eyes) which has a lot of internal processes handled by custom software. The actual loads are not that great (your usual web forms and reporting) and normally I would be all about farming this off to some rented virtual iron in The Cloud but for various reasons most of the data has to be kept on in-house hardware. I really want to get the development environments (LAMP stacks with some Java thrown in for extra confusion) set up as virtual machine images so the IT folks can have the freedom to really break things and try out anything. I would also like to virtualize the staging and, most importantly, the production systems.
I've got to have at least 3 main servers, plus a few random ones for things like a wiki and the like.
Fortunately, I do have a few older blade servers which I can nab. They are made up of 2Ghz Xeons with about 4 Gb of RAM and reasonable hard drives for their class which currently have openSUSE on them and do apparently support Intel (VT-x). I am looking at getting KVM running and then putting 2-3 virtual guests on each blade. The sys admin is very familiar hacking on SUSE so I would like to stick with that for the host and guest OSs.
This seems like a fun project despite the older hardware so my question is: Does anyone have some experience to share regarding running KVM in such an environment? Will it be as slow as I suspect it would be?
(Score: -1, Troll) by Anonymous Coward on Thursday September 11 2014, @02:23PM
Yes, it will be slow, but forcing them to work with slower hardware will make them write better code. And if they don't, get them fired for being incompotent weenies.
(Score: 1, Interesting) by Anonymous Coward on Thursday September 11 2014, @02:42PM
Just a note from " for various reasons most of the data has to be kept on in-house hardware". That does not stop you from having external development.
All you need to do is to provide them with false data. In the past when I had the same barrier I randomized the data so that the content was no longer "real".
You should conduct testing off from the live server(s) anyway. Set up a blade server with KVM and test on it.
We run KVM on a server with 24 cores and 30G RAM. On that we have upwards of ten VMs running CentOS, which I think is more than you were planning to so that should work fine. You can dedicate cores to each KVM so one does not load down others. If your software supports multi threading then that will help as well.
(Score: 3, Informative) by E_NOENT on Thursday September 11 2014, @02:48PM
I'm going to go out on a limb and say that you'll be just fine.
KVM (particularly running with the VT extensions) is fairly performant, and your hardware may be "older" but is still probably far beefier than anything you're going to throw at it.
For your peace of mind (and for maximizing the amount you can learn through the process) though, it would be fun to experiment. Some suggestions:
- Set up a LAMP server VM and load-testing the holy hell out of it it (using something like ab [apache.org] or funkload [nuxeo.org])
- If you're using Java for extra confusion, pay attention to the JVM heap size and experiment with how load, heap size, and VM size affects its performance/stability -- depending on the application that JVM heap size may have a significant influence on the amount of RAM you dedicate to the VM.
- Now's a good opportunity to think about how you'd provision these KVM machines; maybe consider looking at scripting the creation/backup/maintenance of the VMs, using something like puppet/chef/cdist, or whatever.
Enjoy!
I'm not in the business... I *am* the business.
(Score: 2) by hemocyanin on Thursday September 11 2014, @05:57PM
I'd want to see at least 8gb of RAM. I like, though won't say it is necessary, to have about 4gb available to each OS running (I count the OS running the hypervisor). It might be somewhat overkill, but more RAM is always better.
There is also Virsh for scripting KVM which is straightforward: http://linux.die.net/man/1/virsh [die.net]
(Score: 1) by E_NOENT on Friday September 12 2014, @10:05AM
Thanks for mentioning Virsh. That's on my "list of things to learn." It looks soooo awesome. I hear people like the python bindings as well (http://libvirt.org/python.html).
I'm generally with you on the RAM thing, though I think people don't give the LAMP stack enough credit when it comes to responsible memory usage and footprint (Tomcat/Java/JVM is another discussion) -- especially for a limited-usage scenario like OP is proposing.
I'd take it as a personal challenge to see if you could run each VM with 512MB for the whole machine, but that's just me. Think of all the Amazon EC2 customers who run those t1.micro instances with ~600MB!
Let's hope the poster returns and tells us what they did.
I'm not in the business... I *am* the business.
(Score: 2) by LoRdTAW on Thursday September 11 2014, @02:53PM
It would help if we had the exact processor model numbers, e.g. $cat /proc/cpuinfo. If you have VT then hardware assisted virtualization should work. The biggest issue I see is the 4GB of RAM. You simply don't have enough for virtualization. Buying older RAM is more costly but is still probably a fraction of the cost for a new server. If each VM needs 2GB and you are running 4 VM then you want 2*4 GB for your VM's plus extra to run the host OS. My advice would be to simply buy 16GB or better yet, 32GB. In practice Linux is pretty light on RAM. Light use web servers can easily get away with 1GB. So you might be able to run two or three 1GB Linux VM's as long as the load is pretty light.
Also: KVM only exposes the hardware virtualization interface. It is not a VM. For example, QEMU is a virtualization application that can use the KVM interface to access VT. If you run a KVM kernel, you CPU's support VT with enabled in the BIOS, then your VM software can access VT through KVM. If you CPU does not support VT then software virtualization can be used which has both hardware (e.g. VM guests limited to one CPU core) and performance limitations (SLoooooooowwww).
(Score: 3, Informative) by strattitarius on Thursday September 11 2014, @03:31PM
Oh, wait, you weren't talking about a Keyboard-Video-Mouse switch...
Slashdot Beta Sucks. Soylent Alpha Rules. News at 11.
(Score: 2) by nitehawk214 on Thursday September 11 2014, @08:34PM
I read the entire thing and am still thought it was that kind of KVM.
A simple acronym expansion would help a lot of people out here.
"Don't you ever miss the days when you used to be nostalgic?" -Loiosh
(Score: 2) by Fnord666 on Friday September 12 2014, @03:58AM
And neither you nor the GP could be arsed to provide the acronym expansion that you are grousing about?
KVM = Kernel-based Virtual Machine [wikipedia.org]
(Score: 2) by nitehawk214 on Monday September 15 2014, @08:36PM
To be honest, I still wasn't sure what the hell it was until I read your post. Thank you.
It did not occur to me to try a Google search, as I figured I would only get things about keyboards. (turns out I was wrong, the entire first page of the results is what this article is referring to)
"Don't you ever miss the days when you used to be nostalgic?" -Loiosh
(Score: 2) by zeigerpuppy on Thursday September 11 2014, @05:12PM
Ive had good experience with Xen, if your processors have VT-d then you can even assign PCI cards to different VMs (DomUs in Xen speak).
Looks like performance between the two is similar but networking a bit more mature in Xen. I use it together with ZFSonLinux (Debian Wheezy hypervisor) running 10virtual machines on a dual Xeon E5 2660 with 90Gb of RAM. Heaps of headroom.
It's nice being able to assign the PCI Ethernet to a virtual machine and have it act as a gateway-firewall.
(Score: 1, Interesting) by Anonymous Coward on Thursday September 11 2014, @05:59PM
It's an open source VMware alternative.
http://www.ovirt.org/ [ovirt.org]
(Score: 2, Informative) by groovemonkey on Thursday September 11 2014, @08:54PM
I second that. oVirt is worth a look. Tons of cool features like live migration, high-availability + Load Balancing, Memory overcommit, etc.
Last time I was setting up virtualization I used Citrix Xen; now I would totally go with this, and not just because of the cost savings. Disclaimer: I haven't set this up in production.
(Score: 1) by blackpaw on Friday September 12 2014, @05:22AM
Last time I tried (oVirt 3.0) it was a nightmare to get setup and required a dedicated controller, though I think the controller can be self hosted now.
Proxmox is dead easy to setup, nice Web Interface supports KVM and Containers.
Given the OP hardware constraints, containers would be well worth exploring.
(Score: 2) by chewbacon on Thursday September 11 2014, @08:54PM
You could upgrade to slightly newer hardware and make this a bit easier. With 4GB of RAM, I'd really worry about speed.
(Score: 2) by SlimmPickens on Thursday September 11 2014, @09:25PM
You're pushing it as far as memory is concerned, but with virsh, some monitoring and the balloon driver you should be good. You can always suspend one of them if things are getting out of hand.
(Score: 2) by sjames on Thursday September 11 2014, @11:03PM
With the virtualization extensions, KVM has very little overhead to it, so performance should be pretty good as far as that goes.
You really should look in to increasing the memory on the blades if at all possible.
When you configure the VMs, be generous with the maximum allocation and stingy with the current allocation. You can change the latter without shutting down the guest.
(Score: 0) by Anonymous Coward on Friday September 12 2014, @10:30AM
You actually employ bees and monkeys? And the two crazy eyed net-ops, what are they? Spiders?
(Score: 2) by mtrycz on Friday September 12 2014, @12:02PM
It looks like a decent scenario for docker. I'm trying it out right now, and it does look handy. I'm not an expert, so you're best off checking out their documentation, but in simple words, docker does something like virtualizing processes instead of machines. There are some downsides and various advantages, for example it simplifies provisioning, and you can easily scale out your services if you need it. One cool feature is that you can do a diff between two machines, or a previous state of the machine, so configuration is also simplified.
Of course if you're already an expert with a different architecture, you should go with that. But check it out. It's kinda new technology, but it's already at version 1.2, so it's stable (in theory at least).
In capitalist America, ads view YOU!