...my place on the web

  • Increase font size
  • Default font size
  • Decrease font size

Install CUCM on Xen

Studying for the Cisco voice certifications it was needed to have a lab environment with CUCM, Cisco Unified Communication Manager. CUCM is only approved to run in lab environments on VMWare, but with my Xen cluster already in place, with 2 nodes each with 8GB of RAM, that was where I wanted to run it. Plus, it was also a challenge to get it working. This article will describe how to get CUCM running on Xen by first installing it in VMware and then transferring it to Xen.

Install CUCM on VMWare

I am not going to go through this step in any detail as it is purely Windows click-click stuff. Wink
I used the free version of VMWare Server together with an iso-file with CUCM 7.x. Basically any VMWare product will do as the only thing we are looking for in this step is to have CUCM installed on a virtual disk.

Important thing to notice is to configure the hard disk for the virtual machine to have at least 80GB of space. Less space and you will most likely run into trouble. I used 85GB for my setup. Select the disk as IDE. I tried with SCSI but couldn't start the install, was complaining about missing disk drives. Choose single file location and do not allocate all disk space at once.

During CUCM installation I selected static IP. For the rest mainly defaults. I didn't select to configure SMTP or DNS.

After install, make sure the system boots in VMWare and that everything looks OK. Then shutdown the virtual machine.

Convert VMWare disk to a flat disk

Next, use a Windows VMWare tool called "vmware-vdiskmanager.exe" to turn the disk into a flat disk. In my Windows with default install of VMWare Server this tool was located in: C:\Program Files\VMware\VMware Server. This tool is not available in VMWare Player. But you can get it when downloading Virtual Disk Development Kit from VMWare.

Run something like:

vmware-vdiskmanager.exe -r "c:\temp\CUCM Pub.vmdk" -t 0 z:\Temp\cucmpubflat.vmdk

The last parameter is the destination location. In my case I put this on z: drive, which is a samba share located on my XEN host.

In case you cannot save the file directly to the XEN host copy it by any other means.

Make image file

Next step is to create the image file on the XEN host with a tool called "qemu-img".

qemu-img convert cucmpub.vmdk /temp/cucmpub.img


The image could be used directly in XEN if you prefer, but in this setup the CUCM VM will use a Logical Volume as its disk. Create an LV with the same size as configured in VMWare above. In this example, 85G.

lvcreate -L 85G -n cucm-pub vg

Copy image file to the LV

Next we take the image file and copy the data over to the LV with dd.

dd if=cucmpub.img of=/dev/vg/cucm-pub

This step can take some time to complete. Sometimes very long, several hours, depending on the disk transfer speed.

Remove CUCM Hardware Check

There is a script executed during boot that checks for compliant hardware. So disable the script before trying to run the VM.

Mount the CUCM disk:

mount -o loop,offset=$((63*512)),rw /dev/vg/cucm-pub /mnt

The offset might differ depending on your disk layout. Have a look here for a quick guide how to check it: http://blog.leenix.co.uk/2010/07/howto-mount-kvmxen-virtual-disk-image.html

Edit the rc.local file:

nano /mnt/etc/rc.d/rc.local

Un-comment the line like below, the line that calls the hardware-check script:

#/usr/local/bin/base_scripts/hardware_check.sh reboot

Unmount the disk:

umount /mnt

Create and start the CUCM VM

Create the DomU config file for a HVM using the LV create above for the disk configuration.

Named my DomU cucm-pub. Please see below for my full DomU config file.

Start the CUCM VM and hopefully everything will run as expected:

xm create cucm-pub

DomU config, /etc/xen/cucm-pub:

Below is the full HVM DomU config file.
VNC is enabled and all connections allowed, password is set to: password
VNCdisplay is set to 5 so connect to it with vnc-viewer with "XEN-hostIP:5"

Adjust the config to your own needs.


#  -*- mode: python; -*-
# Python configuration setup for 'xm create'.
# This script sets the parameters used when a domain is created using 'xm create'.
# You use a separate script for each domain you want to create, or
import os, re
arch = os.uname()[4]
if re.search('64', arch):
arch_libdir = 'lib64'
arch_libdir = 'lib'
# Kernel image file.
kernel = "/usr/lib/xen-4.1/boot/hvmloader"
# The domain build function. HVM domain uses 'hvm'.
# Initial memory allocation (in megabytes) for the new domain.
# WARNING: Creating a domain with insufficient memory may cause out of
# memory errors. The domain needs enough memory to boot kernel
# and modules. Allocating less than 32MBs is not recommended.
memory = 1024
# Shadow pagetable memory for the domain, in MB.
# If not explicictly set, xend will pick an appropriate value.
# Should be at least 2KB per MB of domain memory, plus a few MB per vcpu.
# shadow_memory = 8
# A name for your domain. All domains must have different names.
name = "cucm-pub"
# 128-bit UUID for the domain.  The default behavior is to generate a new UUID# on each call to 'xm create'.
#uuid = "06ed00fe-1162-4fc4-b5d8-11993ee4a8b9"
# The number of cpus guest platform has, default=1
# Enable/disable HVM guest PAE, default=1 (enabled)
# Enable/disable HVM guest ACPI, default=1 (enabled)
# Enable/disable HVM APIC mode, default=1 (enabled)
# Note that this option is ignored if vcpus > 1
# List of which CPUS this domain is allowed to use, default Xen picks
#cpus = "" # leave to Xen to pick
#cpus = "0" # all vcpus run on CPU0
#cpus = "0-3,5,^1" # run on cpus 0,2,3,5
#cpus = "1"
# Optionally define mac and/or bridge for the network interfaces.
# Random MACs are assigned if not given.
#vif = [ 'type=ioemu, mac=00:16:3e:00:00:11, bridge=xenbr0, model=ne2k_pci' ]
# type=ioemu specify the NIC is an ioemu device not netfront
#vif = [ 'type=ioemu, bridge=xenbr0' ]
#vif = [ 'type=ioemu' ]
vif = [ 'type=ioemu, bridge=eth0 ]
# Define the disk devices you want the domain to have access to, and
# what you want them accessible as.
# Each disk entry is of the form phy:UNAME,DEV,MODE
# where UNAME is the device, DEV is the device name the domain will see,
# and MODE is r for read-only, w for read-write.
#disk = [ 'phy:hda1,hda1,r' ]
#disk = [ 'drbd:trixbox,hda,w', 'file:/usr/src/trixbox-,hdc:cdrom,r' ]
#disk = [ 'phy:/dev/drbd14,hda,w' ]
disk = [ 'phy:/dev/vg/cucm-pub,hda,w' ]
#, 'file:/usr/src/trixbox-,hdc:cdrom,r' ]
# Configure the behaviour when a domain exits. There are three 'reasons'
# for a domain to stop: poweroff, reboot, and crash. For each of these you
# may specify:
# "destroy", meaning that the domain is cleaned up as normal;
# "restart", meaning that a new domain is started in place of the old
# one;
# "preserve", meaning that no clean-up is done until the domain is
# manually destroyed (using xm destroy, for example); or
# "rename-restart", meaning that the old domain is not cleaned up, but is
# renamed and a new domain started in its place.
# The default is
# on_poweroff = 'destroy'
# on_reboot = 'restart'
# on_crash = 'restart'
# For backwards compatibility we also support the deprecated option restart
# restart = 'onreboot' means on_poweroff = 'destroy'
# on_reboot = 'restart'
# on_crash = 'destroy'
# restart = 'always' means on_poweroff = 'restart'
# on_reboot = 'restart'
# on_crash = 'restart'
# restart = 'never' means on_poweroff = 'destroy'
# on_reboot = 'destroy'
# on_crash = 'destroy'
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
# New stuff
#device_model = '/usr/' + arch_libdir + '/xen/bin/qemu-dm'
device_model = '/usr/lib/xen/bin/qemu-dm'
# boot on floppy (a), hard disk (c), Network (n) or CD-ROM (d)
# default: hard disk, cd-rom, floppy
# write to temporary files instead of disk image files
# enable SDL library for graphics, default = 0
# enable VNC library for graphics, default = 1
# address that should be listened on for the VNC server if vnc is set.
# default is to use 'vnc-listen' setting from /etc/xen/xend-config.sxp
# set VNC display number, default = domid
# try to find an unused port for the VNC server, default = 1
# enable spawning vncviewer for domain's console
# (only valid when vnc=1), default = 0
# set password for domain's VNC console
# default is depents on vncpasswd in xend-config.sxp
# no graphics, use serial port
# enable stdvga, default = 0 (use cirrus logic device model)
# serial port re-direct to pty deivce, /dev/pts/n
# then xm console or minicom can connect
# Qemu Monitor, default is disable
# Use ctrl-alt-2 to connect
# enable sound card support, [sb16|es1370|all|..,..], default none
# set the real time clock to local time [default=0 i.e. set to utc]
# set the real time clock offset in seconds [default=0 i.e. same as dom0]
# start in full screen
# Enable USB support (specific devices specified at runtime through the
# monitor window)
#   Enable USB mouse support (only enable one of the following, `mouse' for
# PS/2 protocol relative mouse, `tablet' for
# absolute mouse)
# Set keyboard layout, default is en-us keyboard.
Last Updated on Tuesday, 08 May 2012 17:23  
Comments (5)
Nice Post
1 Tuesday, 12 June 2012 20:22
I have followed your post right up to "Convert VMWare disk to a flat disk" from this point i used Xen GUI to do the rest, double clicked and off we go. this works pretty much perfectly however I've come across the weirdest "bug".

Im running CUCM 8.6.2 with XenServer 6.0.2

Everything works perfectly apart from TFTP, now this is a large problem as you can imagine xP

Even via different TFTP clients (TFTPd and Windows7 inbuilt) im unable to download anything! i just get timeout.... running within VMWare Player (where this CUCM was initially installed) the system works perfectly!

If you could shine any light on this odd problem i would be very grateful XD currently in the process of installing in VMware Player to see if that works/portsover without problems Smile

Re: Nice Post
2 Thursday, 14 June 2012 11:38
I have only tried this setup with soft phones and it works. Don't know if the way a soft phone uses TFTP is different from a real phone. But at least it works. Will try shortly with a real phone or a plain tftp client.
Re: Nice Post
3 Saturday, 23 June 2012 17:00
Don't seem to have any issues with TFTP. Tried with a 3rd party TFTP client and it connects without problem. Also monitoring TFTP within RTMT everything looks normal.

Did you check your TFTP service just to make sure it is running?
And check your syslogs for any errors related to TFTP.

Possibly there is a difference with the version of CUCM.
How did it go with 7.1?
Re: Nice Post
4 Monday, 23 July 2012 21:16

I bit the bullet in the end and now run a separate VMware ESX environment on a separate Server.

I think it was an undocumented bug. All services appears to work however TFTP just wouldn't work (it said "Started" with the GUI and CLI tools). I forget now what RTMT said however it was pretty generic -- as if... there was no problem to report.

I never got around to trying version 7.1.5 on Xen
I understand that 8.6.2 is quite a "rushed" build -- e.g. there's a problem whereby "Dependency Records" doesn't show anything under certain tabs, now this to me sounds like testing didn't truly take place; so i wouldn't be surprised if other sections such as my TFTP problem were "missed" also Razz

Regards, Dan.
@DAN - TFTP Problem
5 Wednesday, 28 August 2013 19:31
Jose M
Dan, TFTP is pretty much replaced by HTTP, meaning, if your phones can run firmware 9.2.1 they will first attempt to download their stuff through http port 6970, including their config file, locale, sip dial rules, etc. In fact, try downloading something from your CM TFTP repository using a URL such as http://CUCM-IP:6970/SEP112233445566.cnf.xml

That should take care of the TFTP problem =)