This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Q on XendDomainInfo.py - _configBootloader for iSCSI booting

To: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Q on XendDomainInfo.py - _configBootloader for iSCSI booting (with sample patch)
From: jpranevich@xxxxxxxxxxx
Date: Thu, 21 Aug 2008 18:23:29 -0400 (EDT)
Delivery-date: Thu, 21 Aug 2008 15:23:55 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

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

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] Q on XendDomainInfo.py - _configBootloader for iSCSI booting (with sample patch), jpranevich <=