FreeBSD 8.2 i386 PV on XCP/XenServer

For now, there is no XVA image/template for FreeBSD. So, you must install a HVM based FreeBSD first.

In your FreeBSD HVM, create a bootable Xen domU kernel from source or get one from here

cd /usr/src
make KERNCONF=XEN buildkernel
make KERNCONF=XEN installkernel

Once you get the kernel, place the kernel in your XCP/XenServer Host.
scp /boot/kernel/kernel ${XCP_HOST}:/boot/guest/freebsd-domU

Remember this: For security concern, your guest OS kernel must place under /boot/guest/

Then, you have to rewrite /etc/fstab, to change /dev/ad1s1__ to /dev/xbd0s__
and add the line
xc0     ‘/usr/libexec/getty Pc’ vt100   on      secure
to /etc/ttys

Of course, you have to change your FreeBSD vbd position from 1 to 0(because we use xbd0 not xbd1)

Final step:
xe vm-param-clear uuid=${FreeBSD_HVM_UUID} param-name=HVM-boot-params
xe vm-param-set uuid=${FreeBSD_HVM_UUID} \
  HVM-boot-policy= \
  PV-kernel=’/boot/guest/freebsd-domU’ \
  PV-bootloader-args= \
  PV-bootloader= \

Tip for amd64: If you are using FreeBSD amd64, at present time( FreeBSD 8.2 Release ), there is no PV version AMD64, but there is PV driver on HVM in amd64 kernel.
Just do these two command under your /usr/src, and you should get it work easy
make KERNCONF=XENHVM buildkernel
make KERNCONF=XENHVM installkernel

Before you do this, you should take a snpshot and backup your HVM parameter

xe vm-param-list uuid=${FreeBSD_HVM_UUID} | grep HVM

HVM-boot-policy ( RW): BIOS order
HVM-boot-params (MRW): order: dc
HVM-shadow-multiplier ( RW): 1.000

Reference for changing HVM to PV

set hw.clflush_disable=1


Add new XCP sm backend – a trial for tapdisk ram driver

Recently, I try to figure out how to add a new tapdisk driver and integrate it into Xen Cloud Platform(XCP).  For the other Xen based product, the README in source tree is good enough. However, XCP has its own way. We much follow the Storage Manager API(SM API) and implement them under /opt/xensource/sm directory in your XCP/XenServer dom0 filesystem.

If your new storage backend does not rely on tapdisk, the and the under /opt/xensource/sm ) are good references. and you have no reason to read following. 😛

Here is a trivial dirty hack to show how to integrate SM API and ram type tapdisk. Before we start, you should know there are few tapdisk driver types not enabled in XCP/XenServer (In fact, they only enable aio and vhd by default). The ram type is one of them.

If you would like to give a try, please using the command tap-ctl create -a ram:/tmp/itone.img . The response is your new block device. Here is tap-ctl detail usage and sample.

And, here we go:

  1. Copy to Link to ramSR.
  2. edit, rename Dummy with ram.
  3. Find the line TYPE = ‘dummy’, this would be used in ramSR.handles(), in, it should be TYPE = ‘ram’
  4. Find load() method in class ramSR, only one statement in the method body, self.sr_vditype = ‘phy’. the sr_vditype will hint tapdisk to use which kind of driver type. So, here should be ‘ram
  5. next and the most dirty work: Find your method load() in class ramVDI, assign /tmp/itone.img to self.path
  6. Final, should allow new tapdisk driver type. So we add ‘ram’ to TYPES list in class Tapdisk, map ‘ram’  : ‘ram’ in VDI._tap_type() method, and add mapping ‘ram’  : ‘tap’, into VDI_PLUG_TYPE in class VDI.

Done. If someone try to integrate Parallax , this could, might, should help.

But I have another plan… ^^

If you have something share or correct me, you may write to my wordpress host(before the first dot part) AT gmail. Thank you.

supplement: self.path will bypass into your td_open() as the second parameter “const char* name“. ( normally, in the block-xxx_type.c file)

When Citrix XenServer Pool Master Fails

0. select a new host as new pool master, the xe host-list will not work, you may find host-uuid from /etc/xensource-inventory, the value of INSTALLATION_UUID

1. access other XCP/XenServer(s), run:

xe pool-designate-new-master host-uuid=<new-master-host-uuid>


Add new XCP sm backend – primitive trial and references(maybe)


  1. /opt/xensource/sm/DummySR is the starting reference.
  2. new SR script should be end naming in “SR"

if you need add new blktap2 driver, here: It is very similiar with README in blktap-1.0.0.src.rpm

But how to bridge sm beckend and blktap2, I’m not sure the formal way.

Enable stunnelng in XCP

XCP provides stunnelng(stunnel next generation) and allow user replace stunnel with stunnelng.

In order to enable this configuration, follow these steps:

1. Edit the file /etc/xensource/xapi.conf and add ‘stunnelng = true’ at the end
of the file or alternatively:

echo ‘stunnelng = true’ >> /etc/xensource/xapi.conf

2. Add ‘-v -l </path/to/logfile&gt;’ to the xapissl init script in line 93,
or alternatively using the following command:

sed -i ‘s/\/usr\/sbin\/stunnelng/& -v -l \/tmp\/xapi_log/g’ /etc/init.d/xapissl

3. Stop stunnel/start stunnelng:
pkill stunnel
/etc/init.d/xapissl start

The step 2 is optional, depends on do you need log.

The original guide is here:

Android x86 – tips

If you are using Google’s Android x86

  1. You should build your own Android x86 kernel, or copy prebuilt/android-x86/kernel/kernel to out/target/product/generic_x86/
  2. The VirtualBox config  is provide as default configuration. then config is under prebuilt/android-x86/kernel/, named kernel_config_VirtualBox
  3. If your VirtualBox only support ACHI(Maybe version 4 only), remember to modify kernel config, the default one from Google, miss that.
  4. You should enable PAE support in VirtualBox
  5. If your host is 32bits, and you get “You are attempting to build on a 32-bit system" , here is a fix:
  6. If your host is 64bits, to compile an Android kernel, you need use make ARCH=x86 to cross compile kernel

Android x86

To build android on x86 machine, you may mention to

However, it seems Google does the simliar work silently.
You may following the document, build/target/board/generic_x86/README.txt

Before you update your repo, may I have your attention:
If you are a Mac user, get a Linux box first. No such darwin-x86 cross compiler exist in repo.

Following is the instruction

The generic_x86 board target provides basic services on very basic
hardware (really for an emulation). To build with generic_x86, you will
need an appropriate kernel for your emulation (or device).

A1. Create a new top level directory and pull the AOSP repository
mkdir $HOME/AOSP
repo init -u git://
repo sync

A2. Copy in the kernel
cp ~/bzImage.your_device $HOME/AOSP/prebuilt/android-x86/kernel/kernel

A3. Build
source build/
lunch generic_x86-eng
make -j8

The build will generate some image files whose format may or may not be correct for your
device. You can build an installer image disk for the VirtualBox emulator using the command:

A4. Build a VirtualBox installer image
source build/
lunch generic_x86-eng
make -j8 installer_vdi