Note: It has been reported that there may be issues doing this with a drive larger than 2 TB. Please see comments below. I have not tested with a larger drive so if you have one to try please do and let us know.
In my home XenServer I have a drive that is dedicated for my OpenMediaVault (OMV) NAS virtual machine (VM). I originally had this drive provisioned as an EXT3 storage repository with the disk allocated to single large VHD that I kept growing until it was almost as large as the physical disk. However, I eventually wanted to do something in order to pass the whole disk through to the VM. I searched and searched online and it seems like there are basically three approaches to this configuration:
- Use PCIe pass-through to give an entire RAID controller to the VM
- Add an entry to udev.d scripts to link a disk into the XenServer removable disk repository
- Create a separate udev repository and manually link the disk to a user created directory
Option (1) was definitely overkill for my home server since I don’t have a nice RAID card, or any plans to put one physically in the XenServer host. Options (2) and (3) were both found at http://techblog.conglomer.net/sata-direct-local-disk-access-on-xenserver/.
Option 2 is basically the following code added to /etc/udev/rules.d/50-udev.rules. These rules take the device and have the server create the link from /dev to the XenServer hosts removable device repository on boot. You just make sure and replace “sdb” with the appropriate /dev entry for your disk.
ACTION=="add", KERNEL=="sdb", SYMLINK+="xapi/block/%k", RUN+="/bin/sh -c '/opt/xensource/libexec/local-device-change %k 2&amp;gt;&amp;amp;1 &amp;gt;/dev/null&amp;amp;'" ACTION=="remove", KERNEL=="sdb", RUN+="/bin/sh -c '/opt/xensource/libexec/local-device-change %k 2&amp;gt;&amp;amp;1 &amp;gt;/dev/null&amp;amp;'"
The reason I don’t love the option (2) approach is that if you stick your disk into the built in removable storage repository you can’t get any separate performance reporting for it, and its just named incorrectly. As a programmer by training it really bothers me when a variable is poorly named.
My Preferred Approach to XenServer Whole Disk Passthrough
I therefore have settled on option (3) as my preferred method. Option (3) is basically a manual version of option (2) where you also create your own storage repository for the disk. Option (3) was offered by the user “makstex” in a comment on the same post at http://techblog.conglomer.net/sata-direct-local-disk-access-on-xenserver/#comment-6404. Option (3) requires running the following commands from the XenServer host shell.
mkdir /srv/YOUR_SR_NAME xe sr-create name-label=”MY BLOCK SR” name-description=”MY BLOCK SR” type=udev content-type=disk device-config:location=/srv/YOUR_SR_NAME ln -s /dev/sdb /srv/YOUR_SR_NAME/sdb xe sr-scan uuid=YOUR_NEW_UUID xe vdi-list sr-uuid=YOUR_NEW_UUID
The actions in the lines above are:
- Create a new directory under /srv for your new storage repository. You can choose another directory location if you prefer.
- Create a new Storage Repository (SR) with the name of your choosing that points to the directory you just created
- Create a soft link from the /dev entry for your disk to the directory of the SR
- Tell XenServer to scan the new repository
- List the disks in the new repository
You can now use the XenCenter GUI or other management tool to add the disk in the SR to the VM of your choice. I have tested this and the storage repository and mapping persist across reboots. However, the configuration won’t persist across all upgrades to make sure and document this so you can put it back after an upgrade.
I can say that the performance in this configuration is pretty close to theoretical maximums for the disk in my testing. The other peace of mind I have is that if the XenServer host gives up the ghost, I can take this disk as is and put it in another server to read from the filesystem on the disk directly.