Update 2013-03-11: A reader was kind enough to inform me that sharing wasn’t working for him. I looked into it and indeed it was no longer working. I opened an issue with the xapi developers over at github and it seems that some changes went into xapi between releases and a number of properties were ignoring user supplied values (see here ). They fixed it pretty quickly and I applied the changes to my local dev environment and can confirm it is working again, but it will probably be sometime before the new code gets merged into a release. If you are using XCP, let me know and I’ll get you updated RPMS XCP 1.6, here is a tar file you can use. Instructions are inside.
In recent XenServer/XCP versions, there is a little undocumented feature that allows you to share VDIs between VMs. If you examine /opt/xensource/sm/blktap2.py – you’ll see what i’m talking about
#!/usr/bin/env python import os import re import time from lock import Lock import util import xmlrpclib import errno import subprocess import syslog as _syslog import glob import xs_errors import XenAPI from syslog import openlog, syslog from stat import * # S_ISBLK(), ... from SR import SROSError import vhdutil PLUGIN_TAP_PAUSE = "tapdisk-pause" ENABLE_MULTIPLE_ATTACH = "/etc/xensource/allow_multiple_vdi_attach" NO_MULTIPLE_ATTACH = not (os.path.exists(ENABLE_MULTIPLE_ATTACH)) .....
As you can see, the code is simply checking for the presence of /etc/xensource/allow_multiple_vdi_attach.
To allow multiple VMs to attach to the same VDI, just execute touch /etc/xensource/allow_multiple_vdi_attach. Then create your shared VDIs from the command line using xe as follows:
[root@xenserver-asbed]# xe vdi-create virtual-size=$((500*1024*1024*1024)) sr-uuid=fd847166-0456-615d-1a61-2754cb6d0ecd sharable=true type=user name-label="HA-GURU-DOT-COM LUN 0" sm-config:type=raw
Note: If the target SR is shared (lvmohba or lvmoiscsi), you’ll need to create the VDI on the pool master
That command spits out the uuid of the vdi. Now create a vbd against that vdi. You’ll need the uuid of the vm that you wish the vdi to be attached to.
xe vbd-create vdi-uuid=115e1db0-ee63-4494-a107-85761352a698 device=xvdc vm-uuid=20cdacf9-1e05-a9ac-3fb0-991ea1e40e3e
That code now spits out the uuid of the virtual block device you just created.
At this point you can reboot the VM and it will attach to the vbd automatically, or if the VM has the the xstools installed, we can “plug” it in using the vbd-plug command e.g.:
xe vbd-plug uuid=313c69d1-0685-8ece-f4b3-127cadd1b2b2
Now repeat the vbd-create and the vbd-plug commands for any additional VMs that need access to that block device, configure your cluster stack, lay down your shared filesystem and there you go! No more having to use iSCSI inside of your VMs… at least if you don’t want to 😉
by 
Good tip, well, actually it does not work. Have you really tried this and its working? because on my XenServers i can launch first server with shared VDI but not the second VM with same shared VDI.
Reading XenServer forums, it seems, its actually impossible.
That’s interesting then because it’s possible with XCP (i have it working in production) and I doubt Citrix would give you free functionality for XCP and not give it for XenServer.
I’ve only tested this using a local SR on a stand alone server though.
Does ENABLE_MULTIPLE_ATTACH exist in /opt/xensource/sm/blktap2.py for you?
It does exists. When i am starting second VM with shared VDI, its says error.
My SR is coming from SAN network (hardware HBA), shared LUN from storage system. XenServer version latest 6.1 with all (public) hotfixes installed.
Looks like some changes went into xapi between releases. I opened an issue to try and see exactly what’s going on here..
So I raised an issue with the xapi developers on github and they got it fixed pretty quickly. I created a dev environment and recompiled xapi and installed the necessary rpms and it is working again.
Now you are on XenServer so I’m not sure how you can apply the same fix.
Hello, guru. I’m using XCP 1.6. Could you send me an updated rpms to my email – aleksey.kashin (at) gmail.com. Thank you!
I updated the site and added a link at the top to the RPMs. Just to be clear however, there is no warranty or guarantee that these rpms will not blow up XenServer/XCP for you. You will certainly want to test before deploying them to production systems.
Hello,
does this procedure work on Xenserver 6.2?
Yes it should. There were some bugs that were recently fixed in 6.1 that I assume made it into the 6.2 release. I’m still testing 6.2 (just upgraded a couple of hosts) so I haven’t tested yet.
Is it can support in xenserver7 ? Thanks
Is it can support in xenserver7? Thanks