Re: [Xen-users] Xen and iSCSI - options and questions

[jpranevich@xxxxxxxxxxx]

----- "Stefan de Konink" <skinkie@xxxxxxxxx> wrote:

> Do you here mean that the bootloader falsely assumes that the uri is a
> file?!
> 
> Stefan

I traced my problem down to: (Xen 3.2.1)

./tools/python/xen/xend/XendBootloader.py:

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"
        log.error(msg)
        raise VmError(msg)
    if not os.access(disk, os.R_OK):
        msg = "Disk isn't accessible"
        log.error(msg)
        raise VmError(msg)


In the second os.access() check, I added additional debugging to see what it 
was trying to access. Using the iscsi://IQN url which worked on my SuSE 
install, "disk" was set to: 
'//iqn.2001-05.com.equallogic@0-8a0906-4bbfbc101-51f41f3a27647d08-jpranevich ' 
(Clearly, just the config line with iscsi: ripped off. I didn't trace the code 
to see where that happened.)

Checking the same file on the SuSE install, I noticed that it was very 
different and I found the patch that made it different. It is possible 
(likely?) that some other change in the patch may have been the "fix" since now 
that I read more thoroughly, it seems to have similar logic, but does the check 
later. (So, perhaps the switch to a local device name happens earlier in the 
process. I don't understand the flow enough and there are other changes to 
blkif and such which could be the real fix. It could have been simply fortunate 
that I picked the right patch.)

I hope this helps. I'm still having some issues, but it makes the iSCSI 
connection properly, so I'm much of the way there. 

Joe

Attachment: xen-domUloader.diff
Description: Binary data

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users