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: Mon, 25 Aug 2008 12:53:26 -0400 (EDT)
Cc: Stephan Seitz <s.seitz@xxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 25 Aug 2008 09:53:52 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <27772392.69541219682667850.JavaMail.root@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
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
----- "Stefan de Konink" <skinkie@xxxxxxxxx> wrote:

> > So I can reproduce it, how do you have it configured then? I'm not
> familiar with a sans-bootloader configuration.
> kernel = "/home/skinkie/xen/boot/gentoo";

Bingo! I've found that in your case, _configureBootloader() exits out almost 
immediately, and instead the root disk and hotplug scripts are run later-- 
probably in _createDevices()-- but I don't completely understand that code yet. 

My issue appears to be here someplace. Since the bootloader gets called before 
the devices are created, we need to create the one-off VBD early and get the 
kernel/ramdisk from it. At that point, we can either destroy the VBD and let 
the subsequent call to _createDevices() recreate it (which is slow) or carry it 
forward. I'm not sure what the best mechanism would be. (Someone on this list 
probably understands this logic better and may have a strong opinion which is 
the correct way.))

I think there is also a second "bug" in Xen 3.3.0 on blkif.py, line 59. Are you 
using 3.3.0 yet? I'd be curious to see if you come to the same conclusion.

                (typ, params) = string.split(uname, ':', 1)
                if typ not in ('phy', 'file', 'tap'):
                    raise VmError(
                        'Block device must have "phy", "file" or "tap" '
                        'specified to type')

That code appears to explicitly block any of the hotplug-type devices from 
working. I can get around this by adding "iscsi" to the supported types, and it 
works properly. I'm sure there's a better fix. (Perhaps, we scan the scripts 
directory to look for block-* and add exceptions for all that match. Perhaps, 
there is a better way.)

Anyway, I'm going to work up a revised patch now that I have a better inkling 
what is going on. My goal will be to get hotplug devices work with the 
bootloaders. (But, at least I have something that appears to work without 
needing that support.)

Also, you mentioned pvgrub. Can you tell me how to use this? I did a "grep -R 
-i pvgrub xen-3.3.0" and can't find it in the Xen 3.3.0 release. The only 
reference I can find to it is in the release notes. Can you give me a pointer 
where this lives and how it works, so that I can see if it suffers from the 
same problem? 



Xen-devel mailing list