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


Re: [Xen-devel] Almost working iSCSI booting, need advice

To: Stefan de Konink <skinkie@xxxxxxxxx>
Subject: Re: [Xen-devel] Almost working iSCSI booting, need advice
From: jpranevich@xxxxxxxxxxx
Date: Fri, 22 Aug 2008 18:53:57 -0400 (EDT)
Cc: Stephan Seitz <s.seitz@xxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 22 Aug 2008 15:54:22 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <48AF3AA7.6010409@xxxxxxxxx>
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

Without these changes, or at least similar changes, I was never getting the 
hotplug scripts called in my config. Maybe it's because I'm using pygrub. Maybe 
it's some other reason. I traced the offending code to bootloader:


def bootloader(blexec, disk, dom, quiet = False, blargs = '', kernel = '',
               ramdisk = '', kernel_args = ''):


    if not os.access(blexec, os.X_OK):
        msg = "Bootloader isn't executable"
        raise VmError(msg)
    if not os.access(disk, os.R_OK):
        msg = "Disk isn't accessible"
        raise VmError(msg) 

In this case, "disk" was set to the IQN and not a real file, so the second 
check always failed. I could also show that at this point, the block-* scripts 
hadn't been called yet, so no real device existed to give it.

I backtracked further into the code and looked at how the SuSE patches worked. 
In that case, the SuSE version of the code also made changes to 
_configureBootloader() to create the VBD early so that it could pass a valid 
disk name in the bootloader() call. It also added a bunch of other things which 
they found it necessary to add for domUloader support, which I don't believe is 
relevant to what I'm doing now. I admit to not understanding everything they 
were doing.

If you tell me where in the python code the hotplug scripts are supposed to get 
called from, I'll add copious debugging around that point in stock Xen to see 
what it's doing in my configuration and report back or provide a fix.

There are no problems with your block-iscsi scripts. Those are perfectly fine. 
They need tweaked a bit because the kernel maintainers keep changing the format 
and layout of /sys between versions, but it should be a simple matter to select 
the right file location. (It seems to be one of two.) I was going to send you a 
patch to do this once I got further along.


----- Original Message -----
From: "Stefan de Konink" <skinkie@xxxxxxxxx>
To: jpranevich@xxxxxxxxxxx
Cc: "Stephan Seitz" <s.seitz@xxxxxxxxxxxx>, "xen-devel" 
Sent: Friday, August 22, 2008 6:16:07 PM GMT -05:00 US/Canada Eastern
Subject: Re: [Xen-devel] Almost working iSCSI booting, need advice

jpranevich@xxxxxxxxxxx schreef:
> This is the code that I've mimiced. Here,
> "BOOTLOADER_LOOPBACK_DEVICE" is always "/dev/xvdp". But, in the case
> of 'tap' devices, it gets destroyed later. (I don't want to destroy
> it later since the iSCSI mount needs to be kept around.)

You are working at the wrong layer... there are block-scripts... don't
edit the xend python stuff!

And you understand that /dev/xvdp is for INSIDE the host?

But there is some other news... with Xen 3.3 pvSCSI is possible. Thus it 
might be better to pass along a scsi generic device instead of a disk.


Xen-devel mailing list

Xen-devel mailing list