Differences

This shows you the differences between two versions of the page.

--- virtualization:xenserver:xenserver_add_host_to_pool [2014/11/22 21:17]
gcooper
+++ virtualization:xenserver:xenserver_add_host_to_pool [2015/11/20 08:23] (current)
gcooper
@@ Line 1: / Line 1: @@
 ====== XenServer - Add a Host to a Pool ======
-When you add a host to a pool, most things are taken care of for you.
+:!: Be sure to (at least) **rename networks to the names used in the pool** before joining the new host!
-One exception is Network Names.
+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**.
-:!: Be sure to **rename networks to the names used in the pool** before joining the new host!
+===== On Pool Master =====
-On pool master:
+For reference:
 <file>
+ifconfig
 xe network-list
 </file>
-On host to be joined, configure the same labels as on the pool master:
+===== On Host to Be Joined =====
+Configure the same labels as on the pool master changing the MTU if necessary for your storage networks:
 <file>
@@ Line 20: / Line 24: @@
 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 uuid=<UUID-xenbr2>
+xe network-param-set name-label=BlockStorage MTU=9000 uuid=<UUID-xenbr2>
-xe network-param-set name-label=FileStorage uuid=<UUID-xenbr3>
+xe network-param-set name-label=FileStorage MTU=9000 uuid=<UUID-xenbr3>
 </file>
-Then join the new host.
+:!: 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:
+<file>
+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>
+</file>
+Then join the new host using XenCenter.
+===== Heterogeneous CPU Pooling =====
+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:
+<file>
+xe host-cpu-info > server1.txt
+</file>
+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:
+<file>
+wget http://www.cl.cam.ac.uk/xen/XenE/host-cpu-info/compare-cpu
+chmod +x compare-cpu
+</file>
+Now we run the script against the two text files:
+<file>
+compare-cpu -v server1.txt server2.txt
+</file>
+Then, if compatibility is determined and a mask given, we apply the mask on the pool (master first):
+<file>
+xe host-set-cpu-features features=<mask> uuid=<host_uuid>
+reboot
+</file>
+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: {{ :virtualization:xenserver:xenserver_incompatible_hardware_message.png?direct&500|Incompatible Hardware}}
+<file>
+xe host-reset-cpu-features
+</file>
+==== CPU Masking Problems ====
+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:
+<file>
+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
+</file>
+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.

Virtual Architects Support Wiki

User Tools

Site Tools

Differences

Page Tools