Creating a Local ISO Storage Repository on XenServer

Trying to find a quick and painless way to add an ISO storage repository to your XenServer without using CIFS or NFS? I was searching for just that after attaching an external USB drive with all my ISOs to my XenServer (running version 5.6 FP1, aka “Cowley”, in my case). Since there’s no direct method for this I used a little trial-and-error and came up with the following steps, to be run at the CLI. First, you need to identify and prepare the disk so after plugging it into your XenServer run the following commands (replacing /dev/sdb with the /dev node returned in the first command).

ls -l /dev/disk/by-id | grep usb

fdisk /dev/sdb

If you’re unfamiliar with fdisk on Linux, use the following documentation for guidance, http://tldp.org/HOWTO/Partition/fdisk_partitioning.html. You’ll need to format the partition for Linux (Partition ID = 83). The final step in preparing the disk is to create an EXT3 filesystem on your desired partition. In my case I created a single partition, so it looks like this.

mkfs -t ext3 /dev/sdb1

With everything prepped and ready to go you need to create a mount point and then mount the drive.

mkdir /mnt/wd500gb/ISO

mount /dev/sdb1 /mnt/wd500gb/ISO

This will be enough to run through the rest of the tutorial, but you’ll need to add the USB drive to the /etc/fstab in order for it to be mounted every time the XenServer reboots and attempts to reconnect the Storage Repository. The following commands will create the actual Storage Repository (use the UUID returned by the pbd-create command as input for the pbd-plug command — it will differ from the below). You can change the name-label for the SR to something appropriate for your environment and you’ll need to change the name-label in the host-list command to match your XenServer as well as the mount point you used (I’ve bolded them for clarity):

UUID=$(uuidgen)

xe sr-introduce name-label=“ldf-xs-01:/mnt/wd500gb/ISO” content-type=iso shared=false type=iso uuid=${UUID}

xe sr-param-set other-config:auto-scan=true uuid=${UUID}

xe pbd-create host-uuid=`xe host-list name-label=ldf-xs-01 —minimal` sr-uuid=${UUID} device-config:location=“/mnt/wd500gb/ISO” device-config:options=”-o bind”

xe pbd-plug uuid=8f5d37c8-775e-aff1-0943-e470576372d2

Keep in mind that this was tested in a single server resource pool, isn’t intended for production usage and you’ll only be able to access the ISOs from the XenServer where you attached the USB drive.

-LF

Internal Routing with XenServer and Vyatta

A couple weekends ago I spent some time getting Vyatta Core 6.1, vyatta-xenserver_VC6.1-2010.10.16_i386 to be precise, deployed in my lab. I found a few tutorials for configuring Vyatta with VMware products, but didn’t really see anything for XenServer. Citrix highlighted the possibilities fairly soon after the XenSource acquisition in a blog post, but that was a couple years ago. Since then Vyatta and Citrix have announced a closer partnership and Vyatta was even part of the C3 Cloud Bridge blueprint. All positive signs that it should be fairly painless, so off we go.

First and foremost you need to download the latest version of their XenServer virtual appliance. If you’re a newbie to Vyatta, like I was, you’ll probably want to grab some documentation as well. The great thing about the appliance is you don’t need to muck about with a custom installation. Once you’ve imported the virtual appliance you should have a new template ready for VM deployments (in my case it was called: vyatta-xenserver_VC6.1-2010.10.16_i386).

XenServer Networks

You can see in the screenshot above that I’m using 3 physical NICs in my XenServer. The on-board NIC is a dedicated management interface (highlighted in the screenshot) and I’ve bonded a pair of Intel NICs for VM traffic. The third network, without a physical NIC associated to it, is an internal-only network and the primary reason I want the Vyatta router.

With my networks outlined, I’ll walk through the process of configuring the Vyatta router so that the internal-only network (remember: 192.168.48.x/24) can access the lab network (remember: 192.168.24.x/24).

New VM

Using the imported template, create a new VM, adjusting the settings as appropriate until you get to the networking configuration. Ensure a virtual interface is added for both the lab and internal-only network(s). Treat the router like you would any other VM; it doesn’t need an interface on the management network, unless you’re using it for VM traffic as well.

Networking Config

Complete the VM setup and have it boot up automatically. To login, use the default credentials: vyatta/vyatta.

Vyatta Console

Initially, we’re going to configure each interface with an IP address and enable SSH access. You’re not required to use SSH to complete the configuration, but it will allow you to access the CLI without XenCenter in the future.

configure
set interfaces ethernet eth0 address 192.168.24.254/24
set interfaces ethernet eth1 address 192.168.48.254/24
set service ssh
commit

You should now have a rudimentary configuration up and running. The two networks won’t be able to communicate with each other yet, but you should definitely be able to ping each interface from another device on the same network segment. In order to get the internal-only network talking to the lab network we’ll configure a NAT rule to pass traffic back and forth.

set service nat rule 1 source address 192.168.48.0/24
set service nat rule 1 outbound-interface eth0
set service nat rule 1 type masquerade
commit

If you were to stop here, any VM on the internal-only network using 192.168.48.254 as its default gateway would have access to the lab network, BUT it won’t be able to access the Internet. This may not be a big deal in your environment, but I still wanted to access OS updates, software installs, etc. without jumping through too many hoops. To achieve that we need to configure the router to use the default gateway on the lab network.

set system gateway-address 192.168.24.1
commit

Test your setup. From a VM on the internal-only network you should be able to ping hosts on the lab network and the Internet. To save the configuration so it persists after a reboot, run this final command in the CLI.

save

The last thing I did in my environment was configure a static route on my wireless router so that devices on the lab network can access the internal-only network without any client-side modifications. I’m running Tomato v1.28 on a Linksys WRT54G, so adding the static route is under Advanced -> Routing. The exact method for performing this step depends on your wireless router, but the gist of it is that you want all traffic destined for the internal network (192.168.48.x in my case) to use the Vyatta router’s interface as its gateway (192.168.24.254 if you’re following my example).

And with that, you should now have an internal-only network that’s completely accessible from the lab network, but allows you to retain greater control of the isolation. Need a DHCP server for PVS? Want to test the Branch Repeater VPX on separate networks? Start exploring and leave me your feedback in the comments.

-LF