service o2cb unload
service o2cb configure

heartbeat dead threshold 151 #Iterations before a node is considered dead
network idle timeout 120000 #Time in ms before a network connection is considered dead
network keepalive delay 5000 #Max time in ms before a keepalive packet is sent
network reconnect delay 5000 #Min time in ms between connection attempts

service o2cb load

service o2cb status #will show new configuration if OVS in server pool; or it will show offline

PS:

SaaS

PaaS

IaaS

losetup -f #to check the next usable loop device

losetup <output of losetup -f> System.img #associate loop devices with regular file System.img. Read/Write to /dev/loop<x> will be redirected to System.img

fdisk -l /dev/loop0

vi /mnt/etc/rc.local #echo password | passwd –stdin root

umount /mnt

vgchange -a y <VGroup> #if LVM is implemented in Virtual Machine, do this to de-activate all known volume groups in the system

kpartx -d /dev/loop0

losetup  -d /dev/loop0

vi /etc/rc.local #comment out “echo welcome1 | passwd –stdin root”

A hyperthreaded processor has the same number of function units as an older, non-hyperthreaded processor. It just has two execution contexts, so it can maybe achieve better function unit utilization by letting more than one program execute concurrently. On the other hand, if you’re running two programs which compete for the same function units, there is no advantage at all to having both running “concurrently.” When one is running, the other is necessarily waiting on the same function units.

A dual core processor literally has two times as many function units as a single-core processor, and can really run two programs concurrently, with no competition for function units.

A dual core processor is built so that both cores share the same level 2 cache. A dual processor (separate physical cpus) system differs in that each cpu will have its own level 2 cache. This may sound like an advantage, and in some situations it can be but in many cases new research and testing shows that the shared cache can be faster when the cpus are sharing the same or very similar tasks.

In general Hyperthreading is considered older technology and is no longer supported in newer cpus. Hyperthreading can provide a marginal (10%) for some server workloads like mysql, but dual core technology has essentially replaced hyperthreading in newer systems.

A dual core cpu running at 3.0Ghz should be faster then a dual cpu (separate core) system running at 3.0Ghz due to the ability to share the cache at higher bus speeds.

The examples below details how we determine what kind of cpu(s) are present.

The kernel data Linux exposes in /proc/cpuinfo will show each logical cpu with a unique processor number. A logical cpu can be a hyperthreading sibling, a shared core in a dual or quad core, or a separate physical cpu. We must look at the siblings, cpu cores and core id to tell the difference.

If the number of cores = the number of siblings for a given physical processor, then hyperthreading is OFF.

/bin/cat /proc/cpuinfo | /bin/egrep ‘processor|model name|cache size|core|sibling|physical’

Example 1: Single processor, 1 core, no Hyperthreading

processor	: 0
model name	: AMD Duron(tm) processor
cache size	: 64 KB

Example 2: Single processor, 1 core, Hyperthreading is enabled.

Notice how we have 2 siblings, but only 1 core. The physical cpu id is the same for both: 0.

processor	: 0
model name	: Intel(R) Pentium(R) 4 CPU 2.80GHz
cache size	: 1024 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 1
processor	: 1
model name	: Intel(R) Pentium(R) 4 CPU 2.80GHz
cache size	: 1024 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 1

Example 3. Single socket Quad Core

Notice how each processor has its own core id. The number of siblings matches the number of cores so there are no Hyperthreading siblings. Also notice the huge l2 cache – 6 MB. That makes sense though, when considering 4 cores share that l2 cache.

processor	: 0
model name	: Intel(R) Xeon(R) CPU           E5410  @ 2.33GHz
cache size	: 6144 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 4
processor	: 1
model name	: Intel(R) Xeon(R) CPU           E5410  @ 2.33GHz
cache size	: 6144 KB
physical id	: 0
siblings	: 4
core id		: 1
cpu cores	: 4
processor	: 2
model name	: Intel(R) Xeon(R) CPU           E5410  @ 2.33GHz
cache size	: 6144 KB
physical id	: 0
siblings	: 4
core id		: 2
cpu cores	: 4
processor	: 3
model name	: Intel(R) Xeon(R) CPU           E5410  @ 2.33GHz
cache size	: 6144 KB
physical id	: 0
siblings	: 4
core id		: 3
cpu cores	: 4

Example 3a. Single socket Dual Core

Again, each processor has its own core so this is a dual core system.

processor	: 0
model name	: Intel(R) Pentium(R) D CPU 3.00GHz
cache size	: 2048 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 2
processor	: 1
model name	: Intel(R) Pentium(R) D CPU 3.00GHz
cache size	: 2048 KB
physical id	: 0
siblings	: 2
core id		: 1
cpu cores	: 2

Example 4. Dual Single core CPU, Hyperthreading ENABLED

This example shows that processer 0 and 2 share the same physical cpu and 1 and 3 share the same physical cpu. The number of siblings is twice the number of cores, which is another clue that this is a system with hyperthreading enabled.

processor	: 0
model name	: Intel(R) Xeon(TM) CPU 3.60GHz
cache size	: 1024 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 1
processor	: 1
model name	: Intel(R) Xeon(TM) CPU 3.60GHz
cache size	: 1024 KB
physical id	: 3
siblings	: 2
core id		: 0
cpu cores	: 1
processor	: 2
model name	: Intel(R) Xeon(TM) CPU 3.60GHz
cache size	: 1024 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 1
processor	: 3
model name	: Intel(R) Xeon(TM) CPU 3.60GHz
cache size	: 1024 KB
physical id	: 3
siblings	: 2
core id		: 0
cpu cores	: 1

Example 5. Dual CPU Dual Core No hyperthreading

Of the 5 examples this should be the most capable system processor-wise. There are a total of 4 cores; 2 cores in 2 separate socketed physical cpus. Each core shares the 4MB cache with its sibling core. The higher clock rate (3.0 Ghz vs 2.3Ghz) should offer slightly better performance than example 3.

processor	: 0
model name	: Intel(R) Xeon(R) CPU            5160  @ 3.00GHz
cache size	: 4096 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 2
processor	: 1
model name	: Intel(R) Xeon(R) CPU            5160  @ 3.00GHz
cache size	: 4096 KB
physical id	: 0
siblings	: 2
core id		: 1
cpu cores	: 2
processor	: 2
model name	: Intel(R) Xeon(R) CPU            5160  @ 3.00GHz
cache size	: 4096 KB
physical id	: 3
siblings	: 2
core id		: 0
cpu cores	: 2
processor	: 3
model name	: Intel(R) Xeon(R) CPU            5160  @ 3.00GHz
cache size	: 4096 KB
physical id	: 3
siblings	: 2
core id		: 1
cpu cores	: 2

PS:
For explanation about flags in linux /proc/cpuinfo, you can refer to following:
http://blog.incase.de/index.php/cpu-feature-flags-and-their-meanings/

rpm -qa|sort|uniq|sort

The result is like:

acl-2.2.39-8.el5
acpid-1.0.4-12.el5
alacarte-0.10.0-1.fc6
alsa-lib-1.0.17-1.el5
alsa-lib-devel-1.0.17-1.el5
amtu-1.0.6-2.el5
anacron-2.3-45.el5.centos
apr-1.2.7-11.el5_6.5
apr-util-1.2.7-11.el5_5.2

But now I only want the package names without version number, that is like:

acl
acpid
alacarte
alsa-lib
alsa-lib-devel
amtu
anacron
apr
apr-util

Here’s the perl script to fulfill this:

#!/usr/bin/perl
open($temp1,”<”,”/doxer/test/package-names.txt”) or die(“error opening”);
while(<$temp1>){
if($_ =~ /([a-zA-Z].*?)\-[0-9]{1,}\.[0-9]{1,}.*/){
print $1.”\n”;
}
}

• Paused

This state preserves the machine’s current settings and application
states without releasing system resources, allowing the machine to resume
this state with a short load period. In this state, the virtual machine
consumes memory and disk resources but very little CPU resources. When
in the paused state, you can unpause the virtual machine.

• Suspended

In this state, the machine’s current settings and application

states are preserved by saving them to respective files and essentially
turning off the virtual machine, releasing system resources and allowing
the machine to resume the same settings, applications, and processes upon
leaving the state. In this state, the virtual machine only consumes disk
resources. From the suspended state, you can resume the virtual machine.

• Summary

Both the paused and suspended states offer the ability to stop the virtual machine
in its exact current operating state and to return the machine to that state upon
resuming. The difference between the two states is the manner in which the
machine’s settings are preserved and how the resources that the virtual machine
uses are affected.
Putting a virtual machine into the paused state simply stops the execution of
further commands momentarily, much like a Windows desktop enters Sleep mode.
In the paused state, the machine’s applications and settings are left in the state that
they were in when the paused state was entered—simply stopped. The settings and
application states are not saved to files that are then used upon resuming; they are
simply stopped as they are. This allows for a fairly short load period upon resuming,
but the virtual machine also continues to utilize (some of) the machine’s resources.
If the desire is to simply halt execution of the virtual machine for a short period
of time and to restart it quickly, then you should choose to pause. This option
provides a fast restart but will hold system resources. If the VM Server were to fail,
the paused system will be lost and require recovery if applicable.
Suspending a virtual machine essentially turns the machine off while preserving
its current settings. Application states, data, and other settings are copied to their
respective files and any resources used by the virtual machine are released. Upon
resuming a suspended virtual machine, after an initial load period, during which the
machine retrieves its settings and application states from these saved files and resumes
use of the server resources, all applications resume the same state they were in.
Suspending a system is a good option if you want to stop the system at a
particular point in time and keep it in that state for an extended period of time.
However, if you want to not use the system for a while, simply shutting it down
might be a better option.

Xen hypervisor itself doesn’t has any networking support (in fact, no any other device drivers except the console). All the networking infrastructure is done in dom0.

Dom0 and domU use the split network driver to communicate. Dom0 will create vif. using netback, and connect it with the virtual interface in domU, which is initialed by netfront.

Dom0 also has vif0.0, vif0.1, etc and veth0, veth1, etc. But it’s absolutely different things, and nothing to do with netback/netfront. They are created by the net loopback driver, mainly for dom0 to communicate with the bridged networking. The net loopback driver is obsolete in xen 3.2+ (dom0 will use the bridge directly).

The net loopback driver usually compiled to the kernel. To prevent it from creating the looped vifs, by passing “netloop.nloopbacks=0″ to the kernel command line.

You can attach virtual network interface to Dom0, just as for domU:

# xm network-attach 0

By default, the newly attached vif will named vif0.0. So the name will fail duo to conflicting with the loopback vifs. To make it work, either prevent the net loopback driver from creating these vifs, or specify a different vif name when attaching:

# xm network-attach 0 vifname=<uniq-vif-name>

Even after netback create the vif, then netfront driver in Dom0 still cannot initial it. See the codes in drivers/xen/netfront/netfront.c:netif_init:

if (is_initial_xendomain())
    return 0;

PS:

You can find more details on http://www.oracle.com/technetwork/articles/servers-storage-admin/networking-ovm-x86-1873548.html (about Oracle VM, but applicable to XEN)

Because of the interaction between domU and dom0, several communication channels are created between the two.

• In a PV environment, a communication channel is created between dom0 and each domU, and a shared memory channel is created for each domU that is used for the backend drivers.
• In an HVM environment, the Qemu-DM handles the interception of system calls that are made. Each domU has a Qemu-DM daemon, which allows for the use of network and I/Os from the virtual machine.