----- "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