Be sure to (at least) rename networks to the names used in the pool before joining the new host!

When you add a host to a pool, most things are taken care of for you. However, you will need to configure 'management' interfaces (interfaces with IP addresses) ahead of time or the pool join operations will not work as expected.

For reference:

ifconfig

xe network-list

Configure the same labels as on the pool master changing the MTU if necessary for your storage networks:

xe network-list

xe network-param-set name-label=Management uuid=<UUID-xenbr0>
xe network-param-set name-label=GuestPublic uuid=<UUID-xenbr1>
xe network-param-set name-label=BlockStorage MTU=9000 uuid=<UUID-xenbr2> 
xe network-param-set name-label=FileStorage MTU=9000 uuid=<UUID-xenbr3>

The Management interface is configured during XenServer installation, usually eth0.

NICs for VM traffic don't get IP addresses (are not 'management' networks).

Configure IP addresses and storage network parameters for other 'management' networks:

xe pif-list host-name-label=<New XS Host Name>
xe pif-reconfigure-ip IP=<ip-on-storage-net> mode=static netmask=<subnet-mask-of-storage-net> uuid=<storage-nic-uuid>
xe pif-param-set disallow-unplug=true other-config:management_purpose="Storage" uuid=<storage-nic-uuid>

Then join the new host using XenCenter.

http://support.citrix.com/article/CTX127059

If you are joining a newer, more capable host to an older, less capable pool, XenCenter will automatically offer to apply the appropriate mask to the new host when it is added.

If you are joining an older, less capable host to a newer, more capable pool, you will have to apply a feature mask to the existing pool before you can join the host to the pool. You will have to reboot the pool member servers after applying the mask.

When hardware differs, and it can differ easily even with CPUs from the same vendor, you must use a technique called CPU masking.

On each host, dump the contents of this command into a text file:

xe host-cpu-info > server1.txt

You'll want both server1.txt and server2.txt on the same XenServer host.

Then download a comparison tool to the same XenServer host that will tell you if the hosts are compatible and output the feature mask you will need to use:

wget http://www.cl.cam.ac.uk/xen/XenE/host-cpu-info/compare-cpu
chmod +x compare-cpu

Now we run the script against the two text files:

compare-cpu -v server1.txt server2.txt

Then, if compatibility is determined and a mask given, we apply the mask on the pool (master first):

xe host-set-cpu-features features=<mask> uuid=<host_uuid>

reboot

Once the mask is applied and the member servers rebooted, you can use XenCenter to add the new host and it will offer to apply the appropriate mask to the new server.

To reset the CPU Features mask:

xe host-reset-cpu-features

If you have problems getting the CPU mask to 'stick' after a reboot of a particular XenServer, try this:

Edit /boot/extlinux.conf.

Add xsave=1 in the Xen options (first grouping before the three dashes) like in this snippet:

label xe
  # XenServer
  kernel mboot.c32
  append /boot/xen.gz dom0_mem=4096M,max:4096M watchdog dom0_max_vcpus=4 crashkernel=128M@32M cpuid_mask_xsave_eax=0 xsave=1 console=vga vga=mode-0x0311 cpuid_mask_ecx=0x00802009 cpuid_mask_ext_ecx=0x000037ff --- /boot/vmlinuz-3.10-xen root=LABEL=root-rwtanwlk ro hpet=disable xencons=hvc console=hvc0 console=tty0 quiet vga=785 splash --- /boot/initrd-3.10-xen.img

Then apply your mask again and see if it 'sticks' after a reboot.

This worked at least once on a newer XenServer host with a fully patched XenServer 6.5 installation and an AMD Opteron 6320 CPU.