Hello,
So that it can be documented for the next generation of Xen users that have
this problem and come to the list via Google, I wanted to say that I've tracked
down my hotplug issue with the block-iscsi scripts on Centos 5.x and I have the
system nearly working. (It doesn't work yet, but at least it's triggering the
hotplug scripts properly now.)
The "bug" is in XendBootloader.py where it appears to check os.access() too
early when the "disk" parameter for iSCSI is the IQN. Since the IQN doesn't
exist as a local file, it was bombing out.
The relevant fix is in the "xen-domUloader.diff" patch in the SuSE SRPM. When
applied to the stock install, my hotplug scripts are triggering happily. I have
to debug some issues with them under Centos and the iscsiadm paths are
different from SuSE, but I'm on the right path now. (There's a ton of other
SuSE fixes in their SRPM as well, but I was trying to keep a minimal change set
so as to be as "stock" as possible.)
I'll put up a SRPM for Centos 5.x once I have this working, if anyone is
interested.
Thanks for everyone's assistance with this.
Joe
----- Original Message -----
From: jpranevich@xxxxxxxxxxx
To: xen-users@xxxxxxxxxxxxxxxxxxx
Sent: Thursday, August 7, 2008 7:48:57 PM GMT -05:00 US/Canada Eastern
Subject: Re: [Xen-users] Xen and iSCSI - options and questions
Hello,
By way of an update, I now have a working block-iscsi test domain on SuSE. (It
took me a day or two because I've been busy with other work and it needed a
little massaging on my part. My images were written for pyGrub and I just
didn't know the magic incantation to use the SuSE domUloader.)
Unfortunately, I've still no luck with the exact same configs on my stock Xen
3.2.1 on Centos 5.2. From what I can tell, 'block-iscsi' is never getting run
(I added debugging that writes to temp files) and nothing ever appears in the
xen-hotplug.log.
Is there a doc someplace or a message board posting here that I can't find yet
which describes the hotplug process in 3.2? (Especially where it decides what
scripts to execute.) I don't really know where to start, whether this is
handled in the Python code or in the C, etc. Since Stefan and others have this
working perfectly well on 3.2.x, I'm sure that it's something easy... but no
dice yet. I will just start diffing SuSE code with the stock code soon and see
if I find any hints that way.
(And, as an aside, when I poke and prod at the running block-iscsi instances
using the xen-api, it's not how I expect. VDI.get_all() doesn't return anything
and the VM object for my instance has a proper VBD, but that VBD doesn't have a
VDI. This could be a xen-api artifact of starting the instance using "xm"
rather than the api, but doesn't get me any closer to seeing how to start a
iscsi instance from the api alone or to understanding how it funds its block
device after a live migration. More to dig, more to dig.)
And Stefan, I apologize if you felt I was dissing your documentation. My remark
was aimed at the SuSE maintainer who went and added an incorrect note in the
SuSE doc, rather than at you. I have the utmost respect and admiration for your
work.
Thanks again for all your help,
Joe
----- Original Message -----
From: "Stefan de Konink" <skinkie@xxxxxxxxx>
To: jpranevich@xxxxxxxxxxx
Cc: xen-users@xxxxxxxxxxxxxxxxxxx, "Antibozo" <xen-users@xxxxxxxxxxxx>, "Todd
Deshane" <deshantm@xxxxxxxxx>
Sent: Wednesday, August 6, 2008 4:21:41 AM GMT -05:00 US/Canada Eastern
Subject: Re: [Xen-users] Xen and iSCSI - options and questions
On Tue, 5 Aug 2008 jpranevich@xxxxxxxxxxx wrote:
> The good news is that, using your suggestion (which doesn't match the
> documentation, but whatever), I'm able to apparently get my
> iSCSI-as-root VBD working on a SuSE test machine. (It doesn't boot, but
> that's because I need to reconfigure for the SuSE bootloader rather than
> Redhat's pygrub. I at least get kernel messages and a "can't mount root"
> message.)
So now you are complaining to me, the developer, that you didn't read the
mailinglist?
> I did have to make a change in the script which worries me: (in find_sdev())
>
> #dev=`readlink $session/device/target*/*:0:*/block*`
> dev=`basename $session/device/target*/*:0:*/block*/*`
That line is *pretty* kernel specific... libvirt had many problems with it
too. Are you running .18 or .21?
> Unfortunately, I do not have the same luck on my stock Xen 3.2.1
> install. I've added some simple debu gging and realized that block-iscsi
> doesn't seem to be called at all and there are no lines written to
> /var/log/xen-hotplug.log when I try an d start my domain, though I do
> get lines there on my SuSE instance.
No extra config is required.
Stefan
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home