[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Q on XendDomainInfo.py - _configBootloader for iSCSI booting (with sample patch)


I'm still playing with getting block-iscsi working in a stock Xen 3.2.1 install 
on Centos. The stock code appears to not be working correctly, though 
distributions (SuSE, at least) have their own patches to address this. I have 
been having some difficulty getting the SuSE patches to work on my own, so I 
set about to make the change in a minimal way for my own uses. (But, others are 
welcome to find value in it.)

In short, I am changing _configureBootloader to notice that it is getting a 
iscsi: parameter as a disk (in theory, this should be changed to any device 
type that isn't phy or tap) and then it creates a dummy VBD object. That 
triggers the hotplug event and causes the disk to be added to the xenstore. I 
then iterate over the VBDs in XenStore until I find the matching UUID, take the 
'node' parameter from there (which contains the real local disk), and pass that 
to the bootloader. So far, this code works with "xm create" but not with my 
Xen-API-based start script... but it's as likely to be a problem in the latter 
as the former. 

Is there anything fundamentally wrong with this approach? Should I do it 
another way? In specific, I don't like creating the dummy VBD, but I don't know 
how to trigger the hotplug process without providing a device node. (I'm using 
dom0.create_vbd() and that always assumes you have the node already.)

(Should I overwrite the 'dev' leaf in xenstore to match the 'node' leaf? I 
suspect I should, but I don't do this yet.)

I've attached the patch and I look forward to any feedback you can provide. 

Joe Pranevich


--- original-XendDomainInfo.py  2008-08-21 16:40:40.000000000 -0400
+++ XendDomainInfo.py   2008-08-21 18:14:35.000000000 -0400
@@ -2113,7 +2113,50 @@
             fn = blkdev_uname_to_file(disk)
             taptype = blkdev_uname_to_taptype(disk)
             mounted = devtype == 'tap' and taptype != 'aio' and taptype != 
'sync' and not os.stat(fn).st_rdev
-            if mounted:
+            # Check for iSCSI first
+            match  = re.match('^(.*?):(.*)$', disk);
+            access_type = match.group(1)
+            access_location = match.group(2)
+            # Todo: Change this to access_type != known types (phy, etc)
+            if (access_type == 'iscsi'):
+                log.info("Mounting %s using %s.", (access_location, 
+                from xen.xend import XendDomain
+                dom0 = XendDomain.instance().privilegedDomain()
+                # We need a bogus VBD at this point...
+                vbd = {
+                   'mode': 'RO',
+                   'device': '/dev/null'
+                }
+                vbd_uuid = dom0.create_vbd(vbd, disk)
+                # Now, we need to find out what the REAL device node is, to 
pass to the bootloader
+                from xen.xend.XendDomain import DOM0_ID
+                from xen.xend.xenstore.xsutil import GetDomainPath
+                dom_path = GetDomainPath(DOM0_ID)
+                real_device = 0
+                vbds = xstransact.List("%s/backend/vbd/0" % dom_path)
+                for x in vbds:
+                    uuid = xstransact.Read("%s/backend/vbd/0/%s/uuid" % 
(dom_path, x))
+                    if (uuid == vbd_uuid):
+                        found = 1
+                        real_device = 
xstransact.Read("%s/backend/vbd/0/%s/node" % (dom_path, x))
+                        break
+                else:
+                   msg = "Unable to find VBD: %s" % vbd_uuid
+                   log.error(msg)
+                   raise VmError(msg)
+                msg = "ISCSI Device Detected: %s on %s" % (disk, real_device)
+                fn = real_device
+                log.info(msg)
+            elif mounted:
                 # This is a file, not a device.  pygrub can cope with a
                 # file if it's raw, but if it's QCOW or other such formats
                 # used through blktap, then we need to mount it first.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.