Posts Tagged ‘virtual machine’

RedHat cluster on RHEL6 and KVM-based VMs

Wednesday, August 1st, 2012

The concept of running a virtual machine, KVM-based, in this case, under RHCS is acceptable and reasonable. The interesting part is that the <vm/> directive replaces the <service/> directive and acts as a high-level directive for VMs. This allows for things which cannot be performed with regular 'service', such as live migration. There are probably more, but this is not the current issue.

An example of how it can be done can be shown in this excellent explanation. You can grab whatever parts of it relevant to you, as there is an excellent combination of DRBD, CLVM, GFS and of course, KVM-based VMs.

This whole guide assumes that the VMs reside on a shared storage, which is concurrently accessible by both (all?) hosts. When this is not the case, like when the shared filesystem is ext3/4 and not GFS, and the virtual disk image file is located on it. In this particular case, you would want to connect the VM to the mount. This cannot be performed, however, when using the <vm/> as a top directive (like <service/>), as it does not allow for child-resources.

As the <vm/> directive allows to be defined (with some limitations) as a child resource in a <service/> group, it inherits some properties from its parent (the <service/> directive), while some other properties are not mandatory and will be ignored. A sample configuration would be this:

<resources>
     <fs device="/dev/mapper/mpathap1" force_fsck="1" force_unmount="1" fstype="ext4" mountpoint="/images" name="vmfs" self_fence="0"/>
</resources>
<service autostart="1" domain="vm1_domain" max_restarts="2" name="vm1" recovery="restart">
     <fs ref="vmfs"/>
     <vm migrate="pause" name="vm1" restart_expire_time="600" use_virsh="1" xmlfile="/images/vm1.xml"/>
</service>

This would do the trick. However, the VM will not be able to live migrate, but will have to shutdown/startup for each cluster takeover.

New version of Cacti, and using spine

Monday, January 21st, 2008

A while ago, a newer version of Cacti became available through Dag’s RPM repository. An upgrade went without any special events, and was nothing to write home about.

A failure in one of my customer’s Cacti system lead me to test the system using “spine” – the “cactid” new generation.

I felt as if it acts faster and better, but had no measurable results (as the broken Cacti system did not work at all). I have decided to propagate the change to a local system I have, which is running Cacti locally. This is a virtual machine, dedicated only to this task.

Almost a day later I can see the results. Not only the measurements are continuous, but the load on the system dropped, and the load on the VM server dropped in accordance. Check the graphs below!

MySQL CPU load reduces at around midnight
as well as the amount of MySQL locks
and innoDB I/O
A small increase in the amount of table locks
A graph which didn’t function starts working
System load average reduces dramatically
Also comparing to a longer period of time
And the virtual host (the carrier), which runs several other guests in addition to this one, without any other change, shows a great improvement in CPU consumption

These measures talk for themselves. From now on (unless it’s realy vital), spine is my perfered engine.

A note about VMware-Server machine security

Saturday, November 10th, 2007

VMware allow setting a virtual machine as a private machine. By doing so, it actually adds to “/etc/vmware/vm-list-private” an additional comment, stating who is the owner of the machine. For example:

cat /etc/vmware/vm-list-private
# This file is automatically generated.
# Hand-editing this file is not recommended.
config “/vmware/Centos4-01/Centos4-01.vmx|root”
config “/vmware/Centos4-02/Centos4-02.vmx|user”

While it is very effective when used with VMware-Console (the nice GUI) – you cannot see machines which are not owned by your own user (in our example – “user”). it has nothing to do with actual permissions on the machine.

Using vmware-cmd you can control machines which are not yours, and are supposed to be private. For example, using

vmware-cmd /vmware/Centos4-01/Centos4-01.vmx stop

as the user “user”, you might be able to turn it off, overriding the obvious, or so you think, permission scheme set up by VMware through the “private guest” settings done above.

This actually has to do with the permissions and ownership on the actual vmx file. To revoke the ability to control your machines or even list them by using vmware-cmd, by an unauthorized user.

The best practice I can suggest is by setting a directory for each user (for example: /vmware for production causes, /qa for QA machines, /user1 for user1 machines, etc), and granting, recursively, permissions on this directory only to the user or group who should have the ability to control these machines. That way, even “vmware-cmd -l” which lists the available guests on an host, will not be able to view guests not owned by the invoking users.

To sum things up, private guests are all about how the GUI decides if and when to display them. eXecute permissions on the vmx files will set who can actually control a guest machine.

Expanding ks.cfg tweaks

Monday, July 9th, 2007

For the latest (and currently whole) ks.cfg I use, check this link. I have extended the logic there, and got the following out of it. Showing only the %pre section:

%pre
# By Ez-Aton http://www.tournament.org.il/run
for i in `cat /proc/cmdline`; do
echo $i >> /tmp/vars.tmp
done
grep “=” /tmp/vars.tmp > /tmp/vars
# Parse command line. Using only vars with type var=value (doesn’t matter
# what the actual value is)
KS=/tmp/ks.cfg
update=””
name=””
pkg=””
. /tmp/vars
# Shall we update the system during the %post section?
if [ ! -z “$update” ]; then
echo “yum update -y” >> $KS
fi
# Shall we reboot the system after the installation?
if [ ! -z “$reboot” ]; then
echo “reboot” > $KS.tmp
cat $KS >> $KS.tmp
cat $KS.tmp > $KS
fi
# What is the machine’s hostname?
if [ ! -z “$name” ]; then
value=”dhcp –hostname $name”
cat $KS | sed s/dhcp/”$value”/ > $KS.tmp
cat $KS.tmp > $KS
fi
# Shall we add another package to the installation preset?
if [ ! -z “$pkg” ]; then
pkg_line=`grep -n ^%packages $KS | cut -f 1 -d :`
max_line=`wc -l $KS | awk ‘{print $1}’`
head -n $pkg_line $KS > $KS.tmp
for i in `echo $pkg | sed s/,/ /g`; do
echo $i >> $KS.tmp
done
let tail_line=$max_line-$pkg_line
tail -n $tail_line $KS >> $KS.tmp
cat $KS.tmp > $KS
fi
# Is it a virtual machine running on VMWare? If so, we’ll install vmware-tools
if [ ! -z “$vmware” ]; then
# We need vmhttp value for server. It can be the name and path
# of the web server
if [ -z “$vmhttp” ]; then
# my defaults
vmhttp=”centos4-01″
fi
# The name of the rpm is always vmware.rpm
echo “wget http://$vmhttp/vmware.rpm” >> $KS
echo “rpm -i vmware.rpm” >> $KS
fi

RHEL 4 / Centos 4 on VMware ESX 2.1

Sunday, July 9th, 2006

While trying to install RHEL 4 on VMware ESX 2.1 I’ve had the pleasure of seeing Linux installation which was unable to detect disks.

A quick search in VMware’s web site resulted in a download page for RHEL 4 Update 2, which, unfortunately, wasn’t the version I was using.

Before running around and searching the nearest download of RHEL 4 Update 2, I’ve noticed that VMware configuration for each virtual machine defines vxmbuslogic SCSI adapter which requires, as it appears, special driver for Linux RHEL 4. However, changing the adapter to vmxlsilogic solved the issue, and required no special Linux driver.