Is it possible to resize the storage for a xen guest in RHEL5, If yes how?

This is a million dollar question. The answer can be "yes" and "no" and highly depends upon the configuration of the guest backend and how it has been partitioned inside the guest. Most people want to resize without initiating a reboot of the guest system, but most of these people make wrong choice while configuring the guest backend intially and end up having to reboot the guest or not being able to resize partitions inside the guest.

A lot things need to be taken into consideration to decide how to resize the guest storage. Before proceeding into how to resize, it's good explain different types of backends that can be used for guest.

1 - Block device. A block device in Dom0 can be used as a backend for the guest. It can be raw partitions, LVMs, raid devices and etc. It can even be a unpartitioned disk as a whole (like "sda" which is not recommended).

2 - File based storage. A file built with a specific size using zeros in Dom0 can be used as the backend of the guest. While using a file based storage it can be any of the below two types.

2.1 - Sparse file. While using a sparse file, disk blocks are not pre-allocated while creating the file, but are allocated only when data is written to the disk fom the guest. This is not recommended for production uses due to performance issues.

2.2 - Fully allocated file. Entire blocks are allocated while creating the file based image. This gives more performance and is recommended for production usage if using block devices are not an option.

I would explore different types of storage configurations and how resizing can be done in those scenarios. I prefer to abstain from explaining the nasty methods of resizing partitions using "parted" or "fdisk" inside the guest. So I prefer to say, if LVM is not used inside the guest, resizing a partition is not possible. Only new partitions can be created after extending the backend. If resizing using parted or fdisk is preferred for anyone, it's upto them.

Different Scenarios and How to resize.
----------------------------------------------

1- LVM is used in both Host and Guest. The backend for the guest is an LVM device in Dom0 and this has been repartitioned in guest using LVM. There are two ways to resize it.

1.1 - Create a new LV in Dom0 and attach it to the guest as a second disk. Repartition the second disk in guest, extend the Volume Group using the new disk, then extend the LV using the additinal free space in the VG. This method does not require a reboot of the guest and is preferred for most xen users.

1.2 - Extend the LV device which is already attached to the guest in Dom0. After the LV is extended in Dom0, the guest should be rebooted to see the new size. There is currently no way to let the guest now that the size of backend has changed without a reboot. Once the guest is rebooted, it would show the new size as free. Create a new partition using the free space, make it a PV, extend the Volume Group using that PV, then extend the LV using the free space in VG. Most people don't like this method since it requires a guest reboot, but most people resize the LVM in Dom0 expecting that the guest would recognize the new space without a reboot and end up rebooting the guest and keep blasting the company that delivers the product.

2 - Raw partition - Eg, sda1 - is used in Host as the backend of the guest and LVM is used inside the guest.

2.1 - Attach a new partition to the guest - Eg, sdb1 - as a second disk. Repartition the second disk in guest, extend the Volume Group using the new disk, then extend the LV using the additinal free space in the VG. This method does not require a reboot of the guest and is preferred.

2.2 - The other method may be to extend the raw partition in the host using parted or fdisk. Reboot the guest to see the new size and extend LVM inside the guest. This is not preferred and may be dangerous.

3 - Fully allocated file based images are used as the guest backend.

3.1 - Create a new fully allocated file based image in Dom0 and attach it to the guest as a second disk (see 3.2 for details on how to create it). Repartition the second disk in guest, extend the Volume Group using the new disk, then extend the LV using the additinal free space in the VG. This method does not require a reboot of the guest and is preferred.

3.2 - Extend the fully allocated file image in Dom0 which is already attached to the guest. It's recommended to shutdown the guest while doing this.

A fully allocated 5 GB /vm/images/guest.img disk is created using the below command initially while creating the guest.

# dd if=/dev/zero of=/vm/images/guest.img bs=1M count=5120

To extend and make it 10G without losing data, the below command can be executed which is the safest method, I think.

# dd if=/dev/zero bs=1M count=5120 >> /vm/images/guest.img

OR

# dd if=/dev/zero of=/vm/images/guest.img bs=1M count=5120 oflag=append

Then create new partitions inside the guest and extend the LVs which already exist or use the new partitions individually.

4 - Sparse File based images are used as the guest backend.

4.1 - Create a new sparse file image in Dom0 and attach it to the guest as a second disk (see 4.2 for more details on how to create it). Repartition the second disk in guest, extend the Volume Group using the new disk, then extend the LV using the additinal free space in the VG. This method does not require a reboot of the guest and is preferred.

4.2 - Extend the sparse file image in Dom0 which is already attached to the guest It's recommended to shutdown the guest while doing this.

A sparse file image with 5 GB of size - Eg, /vm/images/guest.img - is created using the below command initially while creating the guest.

# dd if=/dev/zero of=/vm/images/guest.img bs=1M count=0 seek=5120 conv=notrunc

To extend and make this 10G without losing data, the below command can be executed which is the safest method, I think.

# dd if=/dev/zero of=/vm/images/guest.img bs=1M count=0 seek=10240 conv=notrunc

Then create new partitions inside the guest and extend the LVs which already exists or use the new partitions individually or to create new VGs and LVs.

Note: Sparse files are not recommended for production system due to preformance reasons. Always use fully allocated file based images.

- In all x.1 above, it's ok to use all possible options. Eg, in 4.1, new LVM in Dom0 can be created and attached to the guest, a new raw partition can be created and attached to the guest and a new fully allocated file based image can be attached to the guest to extend the volumes inside it. This is applicable for all x.1 explained above. I used only one option for my convenience.

- The task "attach it to the guest as a second disk" can be achieved by following either of the below two methods. This is applicable only for x.1 above, not x.2.

1 - virt-manager -> Open -> View -> Details -> Hardware -> Add -> Storage Device -> Simple File/Normal Partition -> Device Type - Virtual Disk. This is the hassle free method.

2 - Edit guest configuration file and add the second disk details to the configuration file. See examples from the sample configuration file. Can also be attached live by the xm command as below.

# xm block-attach

Eg, to attach a new lvm block device as xvdb to guest named "guest1" with read-write, below command need to be used.

# xm block-attach guest1 phy:/dev/VolGroup00/LV1 /dev/xvdb w

or

# virsh attach-disk guest1 --driver phy /dev/VolGroup00/LV1 xvdb

To attach a new file based image as xvdb to guest named guest1 with read-write, below command can be used.

# xm block-attach guest1 tap:aio:/vm/images/image1.img /dev/xvdb w

Or

# virsh attach-disk guest1 --driver tap --subdriver aio /vm/images/image1.img xvdb

- Reszing of guest LVs can be achieved without a reboot if x.1 is followed, but a reboot of the guest is necessary if x.2 is followed for the guest to see the new disk size.

- The online attaching of disks may not work as expected for fully virtualized guests which doesn't have PV drivers installed.

How to migrate guests using virsh commands?

Usually "xm migrate -l" is used to migrate a guest from one system to other system. There is no option in virt-manager to migrate a guest from one host to another. Libvirt based virsh command can be used to do this. The syntax of "virsh migrate" is a bit confusing to a lot of beginners. Details given below would help in solving those confusions.

- There are two systems - HostA and HostB. HostA is the source machine and HostB is the destination machine.

1 - If you are currently logged into HostA as root, below command can be used to migrate a guest to HostB.

# virsh migrate --live xen+ssh://HostB

Replace HostB with its ip or FQDN. You would be asked for the root password of HostB. Upon entering the right password for HostB, migration would happen successfully.

2 - If you are currently logged into a third system in the network which has "virsh" command available in it, the below command can be used to migrate a guest from HostA to HostB.

# virsh --connect xen+ssh://HostA migrate --live xen+ssh://HostB

Replace HostA and HostB with its ip addresses or FQDNs. You would be asked for the root password of HostA first, then the HostB. Upon entering the right password for both hosts, migration would happen successfully.

3 - If you are currently logged into HostB and want to migrate a guest from HostA to HostB, can this be done using virsh? Try it out yourself.

Libvirt connection over ssh (xen+ssh) is the the method used in the above example. Libvirt remote TLS connection can also be established using certificates. Since that needs a bit more deails to setup, that is apt for another doc.

Can't access serial devices in Dom0. How to fix it?

A lot of xen users report that when they access a serial device while running xen kernel, they get "Cannot get serial info: Invalid argument", but while running the generic kernel (non-xen kernel), they have no problem to access the serial device. Eg,

[root@xen ~]# setserial /dev/ttyS0
Cannot get serial info: Invalid argument

To solve this, kernel output need to be redirected to xen console by adding "console=xvc console=tty0 xencons=xvc" to "module /vmlinuz" line in grub.conf as below.

module /vmlinuz-2.6.18-92.1.13.el5xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet console=xvc console=tty0 xencons=xvc

Reboot the host and everything would work fine after that.

[root@xen ~]# setserial /dev/ttyS0
/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 7

I can't access the PV guest serial console via "xm console" or "virsh console" in RHEL5 xen. How can I fix it?

This would work out of the box in most cases, but in certain scenarios it may not work as expected. If someone hits such a situation, please make sure below things are done correctly.

1 - Edit /boot/grub/grub.conf of the guest and add "console=tty0 console=xvc0" to the kernel line, if you wanted the boot messages to appear on the serial console.

Eg, RHEL4 PV guest grub.conf would look like as below.

title Red Hat Enterprise Linux ES (2.6.9-78.ELxenU)
root (hd0,0)
kernel /boot/vmlinuz-2.6.9-78.ELxenU ro root=LABEL=/ console=tty0 console=xvc0
initrd /boot/initrd-2.6.9-78.ELxenU.img

2 - Add the below line to /etc/inittab under "Run gettys in standard run levels" if a login prompt is needed on serial console after system is booted.

co:2345:respawn:/sbin/agetty xvc0 9600 vt100-nav

3 - Add "xvc0" to /etc/securetty if root to log in need to be allowed from this console.

Make sure that the guest is rebooted after checking the abov three points.

How to install a fully virtualized guest using multiple cds which requires cdrom media change during installation?

RHEL3 and RHEL4 till U6 comes in multiple cds. With RHEL-5.2, a fully virtualized guest can be installed using these multiple cds. CD change is possible whenever requested by anaconda. Steps are similiare to the methods we follow in Vmware. Below are the steps.

- Start the installation of the Fully virtualized guest from the first CD, as usual from virt-manager.

- When anaconda requests to change the cd and insert 2nd cd, please do the following.

- On the virt-manager console click View -> Details -> Hardware -> Select "Disk hdc" (the one with the cdrom icon in the right side) -> Click "Disconnect" in the right side-> The button would change to "Connect". Click "Connect" -> Select the 2nd cd from the Brwose list and click OK -> Click "OK" in the disk change window from anaconda.

This should work fine and the installation would resume from the second cd. Follow the same steps for all cds till installation is finished. The same steps would work for windows guests as well if a media change is required.

Note: You may need to edit /etc/xen/guest configuration file and change,

boot = "d"

to

boot = "c"

to properly start the guest after the installation is finished.

What is pci-passthrough and how to do it with xen in RHEL5?

The informations below are specific to RHEL5 and could be applied to fc6 and above.

Pci passthrough is used to exclusively export a pci device to a paravirtualized or fully virtualized guest rather than sharing that for guests and dom0. While doing this, the exported pci device wouldn't be available for dom0 and any other guests. Ex, NIC.

Paravirtualized guests: Pci passthrough should work on RHEL5 guests. It's not expected to work on rhel4 PV guests. PCI passthrough requires support in both dom0 (backend) and in the guest (front end). This front end support has not been implemented in RHEL4 PV kernel yet.

Fully Virtualized guest: Not supported. PCI passthrough to fully virtualized guests requires special hardware support. This is called VT-d on intel paltform and IOMMU on AMD platform. (AMD is yet to release such a hardware). Even if someone possesses this hardware, it requires support in xen code and the RHEL version of xen doesn't have this code.

Bottom line. PCI passthrough would work only if the guest is RHEL5 PV and fc6 and above guests. Below is details on how to configure this.

- Get the pci id of a pci device in dom0 by running "lspci".

- Hide the pci device from dom0. I added the below entry in my /etc/modprobe.conf to hide my Broadcom network card from dom0 which uses bnx2 driver and rebooted dom0. Change it to suite your requirement

install bnx2 /sbin/modprobe pciback ; /sbin/modprobe --first-time --ignore-install bnx2
options pciback hide=(0000:09:00.0) verbose_request=1

- Pass the deivce through by adding the below line in /etc/xen/ file.

pci = [ "0000:09:00.0" ]

Authenticating Linux to AD using idmap_ldap.

If Active Directory schema is not extended to define linux/unix attributes, the best and hassle free mehtod of authenticating a Linux system to AD is by using idam_rid backend. Since idmap_ldap can also be used for this purpose, where sid-to-uid/gid mapping would be saved in a backend ldap server and retrieved from the ldap database whenever required, and it was dominant before developing idamp_rid plugin, I wish to include details on how to configure this.

The problem with idmap_ldap backend is that it requires an additional ldap server to be running, possibly more than one for redundancy purposes, which makes administration and managing of services a bit complex. If there already is an ldap server in the network, using that ldap server would be fine. Below is step-by-step instructions on how to configure ldap server and samba for this purpose. Openldap is used as the ldap server in this setup.

How to setup the ldap server?

1 - Install openldap-servers package.

#yum install openldap-servers

2 - Below is my slapd.conf after removing comments.

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/samba.schema
allow bind_v2
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
TLSCertificateFile /etc/pki/tls/certs/slapd.pem
TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem
database bdb
suffix "dc=samba,dc=example,dc=com"
rootdn "cn=admin,dc=samba,dc=example,dc=com"
rootpw password
directory /var/lib/ldap
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub

3 - Below is details of how I created slapd.pem

# cd /etc/pki/tls/certs
# rm -f slapd.pem
# make slapd.pem

Give details on every prompt as appropriate.

#chown ldap.ldap slapd.pem

4 - Use the simple ldif file given below to initialize the ldap database.

dn: dc=samba,dc=example,dc=com
dc: samba
objectClass: top
objectClass: domain

dn: ou=idmap,dc=samba,dc=example,dc=com
ou: idmap
objectClass: top
objectClass: organizationalUnit

Initialize the database using the below command.

# slapadd -d 3 -l ldif-file

If you already have an ldap server running in your network, Just add an OU named idmap under the ldap name space heirarchy, add a user in the ldap databse and give that user write permission to the OU.

5 - Start ldap server. service ldap start.

How to setup the Samba server.

I only include my smb.conf and some basic details on setting this up.

[global]
workgroup =
netbios name =
realm = SAMBA.EXAMPLE.COM
server string = RHEL4 Idmap Ldap Backend
security = ads
password server =
log file = /var/log/samba/%m.log
max log size = 50
printcap name = /etc/printcap
ldap admin dn = cn=admin,dc=samba,dc=example,dc=com
ldap delete dn = yes
ldap idmap suffix = ou=idmap
ldap suffix = dc=samba,dc=example,dc=com
idmap backend = ldap:"ldaps://ip or hostname of ldap server"
idmap uid = 1500-100000
idmap gid = 1500-100000
winbind separator = +
winbind use default domain = yes
cups options = raw
template shell = /bin/bash
winbind enum users = yes
winbind enum groups = yes

[homes]
comment = Home Directories
read only = No
browseable = No

[printers]
comment = All Printers
path = /var/spool/samba
printable = Yes
browseable = No

Add the password for "ldap admin dn" to samba tdb databse.

# smbpasswd -w password

password is what we defined in the slapd.conf in the earlier step.

Now what happens is, suppose you have 1000 users named user1 to user1000 in AD, when user1 logs in to system1, samba would check whether a sid/uid mapping is already present in the ldap database. If it finds one, it would assign that uid to user1. If it does not find one, it would take the next free uid from the range defined, assign that to user1 and save the sid/uid mapping in the ldap database. Now, after sometime, if user1 tries to log in from machine B, samba in machine B would check whether an sid/uid mapping is there in the ldap database. It should find one and assign that uid to user1.

Below is an example of how sid/uid mapping is represented in ldap database.

dn: sambaSID=S-1-5-21-2913803998-3319354983-1616611311-1001,ou=Idmap,dc=samba,dc=samba,dc=com
objectClass: sambaIdmapEntry
objectClass: sambaSidEntry
uidNumber: 1504
sambaSID: S-1-5-21-2913803998-3319354983-1616611311-1001

The above entry implies that the AD user with SID S-1-5-21-2913803998-3319354983-1616611311-1001 should be assigned the uid 1504.

Restart winbind and verify that everything works as expected.

Authenticating Linux to AD using idmap_rid with base_rid

I only paste my smb.conf here which I think may be useful for others. This smb.conf works fine on RHEL4-U6 and RHEL5 which uses idmap_rid module for mapping AD users/groups sids to linux uids/gids. idmap_rid plugin generates uid/gid mapping for AD users by adding a configurable minmum value to the rid of an AD user after substracting the base_rid specified from user rid. Eg,

Suppose if I define idmap config range as "1500 - 10000" in my smb.conf and base_rid as 500 and the rid of the AD user is 1546, then the uid of that user would be 1546 - 500 + 1500 which is 2546.

Sid for user "u1" would look like as below.

# wbinfo -n u1
S-1-5-21-2913803998-3319354983-1616611311-1106 User (1)

Here the rid of the u1 is 1106 and his uid = 1106 - 500 + 1500 which is 2106

In this configuration we assume that our AD domain is test.example.com

[global]
workgroup = WORKGROUP
netbios name = netbiosname
realm = REALM
server string = RHEL4 Test Server
security = ads
password server =
log file = /var/log/samba/%m.log
max log size = 50
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
printcap name = /etc/printcap
idmap domains = EXAMPLE
idmap config EXAMPLE: default = yes
idmap config EXAMPLE: backend = rid
idmap config EXAMPLE: base_rid = 500
idmap config EXAMPLE: range = 1500-10000
winbind separator = +
winbind use default domain = yes
cups options = raw
winbind nss info = rfc2307 sfu template

[homes]
comment = Home Directories
read only = No
browseable = No

[printers]
comment = All Printers
path = /var/spool/samba
printable = Yes
browseable = No

Configure /etc/krb5.conf appropriately, if using kerberos for authentication.

Join the system to Active Directory Domain.

# net ads join -U administrator

Run authconfig and chose winbind for name service and kerberos for authentication. Don't join the system to domain in this attempt since we have already joined it.

Restart winbind. Now every ad user should be able to log in to linux system.

Another configuration with idmap_rid without specifying base_rid

I only paste my smb.conf here which I think may be useful for others. This smb.conf works fine on RHEL4-U6 and RHEL5 which uses idmap_rid module for mapping AD users/groups sids to linux uids/gids. idmap_rid plugin generates uid/gid for AD users by adding a configurable base value to the rid of an AD user. Eg,

Suppose if I define idmap config range as "1500 - 10000" in my smb.conf and the rid of the AD user is 1546, then the uid of that user would be 1500 + 1546 which is 3046.

Sid for user "u1" would look like as below.

# wbinfo -n u1
S-1-5-21-2913803998-3319354983-1616611311-1106 User (1)

Here the rid of the u1 is 1106 and his uid = 1500 + 1106 which is 2606

In this configuration we assume that our AD domain is test.example.com

[global]
workgroup = WORKGROUP
netbios name = netbiosname
realm = REALM
server string = RHEL4 Test Server
security = ads
password server =
log file = /var/log/samba/%m.log
max log size = 50
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
printcap name = /etc/printcap
idmap domains = EXAMPLE
idmap config EXAMPLE: default = yes
idmap config EXAMPLE: backend = rid
idmap config EXAMPLE: range = 1500-10000
winbind separator = +
winbind use default domain = yes
cups options = raw
winbind nss info = rfc2307 sfu template

[homes]
comment = Home Directories
read only = No
browseable = No

[printers]
comment = All Printers
path = /var/spool/samba
printable = Yes
browseable = No

Configure /etc/krb5.conf appropriately, if using kerberos for authentication.

Join the system to Active Directory Domain.

# net ads join -U administrator

Run authconfig and chose winbind for name service and kerberos for authentication. Don't join the system to domain in this attempt since we have already joined it.

Restart winbind. Now every ad user should be able to log in to linux system.

Samba - How to authenticate linux system via winbind using idmap_rid

I only paste my smb.conf here which I think may be useful for others. This smb.conf works fine on RHEL4-U6 and RHEL5 which uses idmap_rid module for mapping AD users/groups sids to linux uids/gids. idmap_rid plugin generates uid/gid for AD users by adding a configurable base value to the rid of an AD user. Eg,

Suppose if I define "idmap uid = 1500 - 10000" in my smb.conf and the rid of the AD user is 1546, then the uid of that user would be 1500 + 1546 which is 3046. If there are multiple domains which are trusted, then the smb.conf wouldn't work. I would create a separate post for that.

Sid for user "u1" would look like as below.

# wbinfo -n u1
S-1-5-21-2913803998-3319354983-1616611311-1106 User (1)

Here the rid of the u1 is 1106.

In this configuration we assume that our AD domain is test.example.com

[global]
workgroup = WORKGROUP
netbios name = netbiosname
realm = REALM
server string = RHEL4 Test Server
security = ads
password server =
log file = /var/log/samba/%m.log
max log size = 50
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
printcap name = /etc/printcap
idmap backend = idmap_rid:EXAMPLE=1500-100000
idmap uid = 1500-100000
idmap gid = 1500-100000
allow trusted domains = no
winbind separator = +
winbind use default domain = yes
cups options = raw
winbind nss info = rfc2307 sfu template

[homes]
comment = Home Directories
read only = No
browseable = No

[printers]
comment = All Printers
path = /var/spool/samba
printable = Yes
browseable = No

Configure /etc/krb5.conf appropriately, if using kerberos for authentication.

Join the system to Active Directory Domain.

# net ads join -U administrator

Run authconfig and chose winbind for name service and kerberos for authentication. Don't join the system to domain in this attempt since we have already joined it.

Restart winbind. Now every ad user should be able to log in to linux system.

Samba for authentiation with AD - win2003 R2 using idmap_ad

I only paste my smb.conf here which I think may be useful for others. This smb.conf works fine on RHEL4-U6 and RHEL5 which uses idmap_ad module for getting user/group information.

[global]
workgroup = WORKGROUP
netbios name = netbiosname
realm = REALM
server string = RHEL4 Test Server
security = ads
password server =
log file = /var/log/samba/%m.log
max log size = 50
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
printcap name = /etc/printcap
dns proxy = No
idmap backend = ad
idmap uid = 1500-100000
idmap gid = 1500-100000
winbind separator = +
winbind use default domain = yes
cups options = raw
winbind nss info = rfc2307

[homes]
comment = Home Directories
read only = No
browseable = No

[printers]
comment = All Printers
path = /var/spool/samba
printable = Yes
browseable = No

Configure /etc/krb5.conf appropriately, if using kerberos for authentication.

Join the system to Active Directory Domain.

# net ads join -U administrator

Run authconfig and chose winbind for name service and kerberos for authentication. Don't join the system to domain in this attempt since we have already joined it.

Restart winbind. Now every ad user should be able to log in to linux system. Note that for idmap_ad to work, you should have Active Directory schema extended and Unix Attributes for AD users defined in advance.

Bonding with xen

1 - Stop all guests. Reboot dom0 after running "chkconfig xend off" and "chkconfig xendomains off".
2 - Configure bond0 by enslaving eth0 and eth1 to it. I added the below two entries to /etc/modprobe.conf.

alias bond0 bonding
options bond0 mode=1,miimon=100

Content of /etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE=eth0
USERCTL=no
ONBOOT=yes
MASTER=bond0
SLAVE=yes
BOOTPROTO=none

Content of /etc/sysconfig/network-scripts/ifcfg-eth1

DEVICE=eth1
USERCTL=no
ONBOOT=yes
MASTER=bond0
SLAVE=yes
BOOTPROTO=none

Content of /etc/sysconfig/network-scripts/ifcfg-bond0

DEVICE=bond0
IPADDR=
NETMASK=
ONBOOT=yes
BOOTPROTO=static
USERCTL=no

Did "modprobe bond0" and "service network restart" after that.

3 - Edit /etc/xen/xend-config.sxp

Change

(network-script network-bridge)

To

(network-script 'network-bridge netdev=bond0')

4 - Start xend. "service xend start".

5 - chkconfig xend on.

6 - Create guest images as usual and bridge it to xenbr0.