Citrix Systems server 4 Manual Do Utilizador
Separate Storage Network for XenServer (Optional)
107
labels "cloud-guest" and "cloud-guest2". After the management server is installed and running, you
must add the networks and use these labels so that CloudPlatform is aware of the networks.
must add the networks and use these labels so that CloudPlatform is aware of the networks.
Follow this procedure on each new host before adding the host to CloudPlatform:
1.
Run xe network-list and find one of the guest networks. Once you find the network make note of
its UUID. Call this <UUID-Guest>.
its UUID. Call this <UUID-Guest>.
2.
Run the following command, substituting your own name-label and uuid values.
# xe network-param-set name-label=<cloud-guestN> uuid=<UUID-Guest>
3.
Repeat these steps for each additional guest network, using a different name-label and uuid each
time.
time.
8.10.3. Separate Storage Network for XenServer (Optional)
You can optionally set up a separate storage network. This should be done first on the host, before
implementing the bonding steps below. This can be done using one or two available NICs. With two
NICs bonding may be done as above. It is the administrator's responsibility to set up a separate
storage network.
implementing the bonding steps below. This can be done using one or two available NICs. With two
NICs bonding may be done as above. It is the administrator's responsibility to set up a separate
storage network.
Give the storage network a different name-label than what will be given for other networks.
For the separate storage network to work correctly, it must be the only interface that can ping the
primary storage device's IP address. For example, if eth0 is the management network NIC, ping -I
eth0 <primary storage device IP> must fail. In all deployments, secondary storage devices must be
pingable from the management network NIC or bond. If a secondary storage device has been placed
on the storage network, it must also be pingable via the storage network NIC or bond on the hosts as
well.
primary storage device's IP address. For example, if eth0 is the management network NIC, ping -I
eth0 <primary storage device IP> must fail. In all deployments, secondary storage devices must be
pingable from the management network NIC or bond. If a secondary storage device has been placed
on the storage network, it must also be pingable via the storage network NIC or bond on the hosts as
well.
You can set up two separate storage networks as well. For example, if you intend to implement iSCSI
multipath, dedicate two non-bonded NICs to multipath. Each of the two networks needs a unique
name-label.
multipath, dedicate two non-bonded NICs to multipath. Each of the two networks needs a unique
name-label.
If no bonding is done, the administrator must set up and name-label the separate storage network on
all hosts (masters and slaves).
all hosts (masters and slaves).
Here is an example to set up eth5 to access a storage network on 172.16.0.0/24.
# xe pif-list host-name-label='hostname' device=eth5
uuid(RO): ab0d3dd4-5744-8fae-9693-a022c7a3471d
device ( RO): eth5
#xe pif-reconfigure-ip DNS=172.16.3.3 gateway=172.16.0.1 IP=172.16.0.55 mode=static
netmask=255.255.255.0 uuid=ab0d3dd4-5744-8fae-9693-a022c7a3471d
8.10.4. NIC Bonding for XenServer (Optional)
XenServer supports Source Level Balancing (SLB) NIC bonding. Two NICs can be bonded together to
carry public, private, and guest traffic, or some combination of these. Separate storage networks are
also possible. Here are some example supported configurations:
carry public, private, and guest traffic, or some combination of these. Separate storage networks are
also possible. Here are some example supported configurations:
• 2 NICs on private, 2 NICs on public, 2 NICs on storage
• 2 NICs on private, 1 NIC on public, storage uses management network