\\
**[[cluster:0|Back]]**

==== Virtual HPCC services ====

Thoughts on how to create virtual compute nodes in the HPCC stack. Specifically, trying to solve the need for tiny, but many, compute nodes for the nano physic applications. Like virtual compute nodes with a single core CPU with 128 MB or less of memory running a lean Scientific Linux operating system.  Here is a good introduction: [[http://www.slideshare.net/gpaterno1/comparing-iaas-vmware-vs-openstack-vs-googles-ganeti-28016375]]

==== Building Ganeti ====

I'll select Ganeti to start with as it appears the simplest to setup.  I've no need for services like fail-over or migration.  Just the ability to rapidly many tiny nodes from a template.  It also appears that Ganeti clusters can be embedded with Openstack later.

Update: On hold, these Xen tools (virt-manager, virt-clone, virsh) are very nice, no need for Ganeti up front .

==== Building Xen ====

<code>

yum install -y --nogpgcheck xen kernel-xen \
virt-manager libvirt libvirt-python python-virtinst

chkconfig xend on

# disable selinux /etc/selinux/config

# add to xen kernel grub line some stuff
title CentOS (2.6.18-371.6.1.el5xen)
        root (hd0,0)
        kernel /xen.gz-2.6.18-371.6.1.el5 dom0_mem=2048M,max:2048M dom0_max_vcpus=1 dom0_vcpus_pin allow_unsafe 
        module /vmlinuz-2.6.18-371.6.1.el5xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet 
        module /initrd-2.6.18-371.6.1.el5xen.img

# hostname fully qualified (in case we go to Ganeti later)

# edit some settings in /etc/xen/xend-config, consult links below

# turn off some services with chkconfig
# cups, iptables, ip6tables, autofs, crond, sysstat, bluetooth
# firstboot, ipmi, iscsi, iscsid

reboot

</code>

  * [[http://www.howtoforge.com/paravirtualization-with-xen-on-centos-5.6-x86_64]]
  * [[http://docs.ganeti.org/ganeti/current/html/install.html#installing-the-hypervisor]]
  * [[https://github.com/jfut/ganeti-rpm/blob/master/doc/install-rhel.rst]]

Then launch ''virt-manager'' to look at your Dom0.

Build a base clone and install what you need (like the Lava scheduler files). Give it a static IP via /etc/rc.local so that when you clone it you can send it ssh commands. Then shut it down.  The Xen block device turned out to be 5 GB in size, a full CentOS install with X11 booting to runlevel 3.

Now you build a script to clone and post prep new clones build from it.

<code>

#/bin/bash

# automate this

virt-clone --original vmdemo --name bvm7 --file /var/lib/xen/images/bvm7.img
# wait 3 mins
sleep 180

virsh start bvm7
# wait 2 mins
sleep 120

# clobber vmdemo rc.local that sets up a static ip that you know rather than dhcp for automation
cd /root
scp rc.local vmdemo:/etc

ssh vmdemo "cat /etc/sysconfig/network | sed s/vmdemo/bvm7/g > /tmp/network"
ssh vmdemo "scp /tmp/network /etc/sysconfig/"

ssh vmdemo "cat /etc/sysconfig/network-scripts/ifcfg-eth0 | sed s/192.168.150.0/192.168.150.7/g > /tmp/ifcfg-eth0"
ssh vmdemo "scp /tmp/ifcfg-eth0 /etc/sysconfig/network-scripts/"

# this is the clone
ssh vmdemo reboot
# wait 2 mins
sleep 120

</code>

==== Testing Xen ====

^  3d Lennard-Jones melt: for 10,000 steps with 32,000 atoms  ^^^
^  Queue, node, HT  ^  Jobs/Node, Loop Time  ^  Comment  ^
|  hp12, n15, no-HT  |  01 jobs, 481  |  |
|  hp12, n15, no-HT  |  07 jobs, 482  |  |
|  hp12, n2, yes-HT  |  01 jobs, 470  |  |
|  hp12, n2, yes-HT  |  16 jobs, 804  |  known penalty  |
|  bss24, many, no-HT  |  01 jobs, 844  |  equivalent to hp12, yes-HT  |
|  bss24vm, bvm1, VM  |  01 jobs, 776  |  1 vcpu, 100 ram  |
|  bss24vm, bvm1, VM  |  02 jobs, 850  |  2 vcpus, 100 ram  |
|  bss24vm, bvm1, VM  |  04 jobs, 1735  |  4 vcpus, 512 ram  |
|  bss24vm, bvm2, VM  |  08 jobs, 3582  |  8 vcpus, 1024 ram  |
|  bss24vm, bvm1, VM  |  32 jobs, 13661  |  32 vcpus, 1024 ram  |
|  bss24vm, bvm1, VM  |  03 jobs, 1273  |  3 vcpus, 256 ram, make it 128  |
|  bss24vm, bvm1, VM  |  05 jobs, 2108  |  5 vcpus, 256 ram  |
|  bss24vm, bvm1, VM  |  31 jobs, 13844  |  31 vcpus, 21504 ram  |
^  multiple vms  ^^^
|  bss24vm, bvm1-4, VM  |  4x01jobs, 1818  |  4x1vcpu, 4x128 ram  |
|  bss24vm, bvm1-8, VM  |  8x01jobs, 3745 (1 hour) |  8x1vcpu, 8x128 ram  |
|  bss24vm, bvm1-6, VM  |  6x32jobs, 82457 (22hrs)  |  6x32vcpu, 6x1024 ram  |
^  optimal physical to virtual cpu ratio for best performance according to Xen  ^^^
|  bss24, many, no HT  |  02 jobs,  826  |  equivalent to hp12, yes-HT  |
|  bss24vm, bvm2-3, VM  |  2x02jobs, 1708  |  2x2vcpus, 2x128 ram,   |
|  bss24vm, bvm2-5, VM  |  4x02jobs, 3497  |  4x2vcpus, 4x128 ram, optimal physical to virtual cpus ratio  |
|  bss24vm, bvm1-8, VM  |  8x02jobs, XXXX  |  8x2vcpus, 8x128 ram, optimal physical to virtual cpus ratio  |


==== Hmmm... ====

We have some very old hardware here that does not support virtualization in the BIOS (hardware level).  So we use paravirtualization with nodes that contain 2 AMD Opteron Model 250 CPUs and 24 gb of memory.  The latter was the reasoning for virtualizing. But it seems not to work.  I can start multiple VMs (with either 1 vpcu or up to 32 vcpus) but the results are the same. When you run 2 VMs the performance is twice that of 1 VM, and so on. Odd.  I can observe the processes running and being actively busy, but the penalty for running more than one is staggering.  Must be an underlying hardware limitation.  Too bad.

The 6vms with 32vcpus finished work after 22 hours. That would imply one of these nodes could run say 20 VMs with 20x32=640 job slots. And we have 20 servers (12,800 job slots) that could be virtualized but there is no performance gain. Those servers will finish the 12,800 jobs in the same time not being virtualized. Too bad really.

Following that thought, we could virtualize (KVM at hardware level) one of the new Asus servers; at 256 gb of memory this would yield 8,192 job slots for one node 128 mb per vcpu). That might be an option. 

\\
**[[cluster:0|Back]]**