Re: [Xen-API] XCP 1.6 - iSCSI root, does it work?

[bearon@xxxxxxxxx]

I've verified ths.  I can boot into single mode an the system is "alive".  In my case eth5 is the iSCSI interface and it is up with the correct IP address.  Walking through the rc3.d sysinit files, firstboot init script is the one that is removing the IP from eth5 and building a xenbr5 with no IP on it, as well.

I went ahead and mounted the filesystem externally and did the following,

vi /mnt/etc/firstboot.d/data/initial-ifcfg/ifcfg-eth5
DEVICE=eth5
HWADDR=00:26:9E:82:1F:DF
XENMANAGED=no
> BOOTPROTO=static
IPADDR=1.1.2.6
NETMASK=255.255.255.0
USERCTL=no

However, XAPI looks to be taking control of eth5 anyways on reboot of the system.

How can I get XAPI to exclude eth5 from it's initial interface-rename/db.network structure build?  Is there someplace I can blacklist that port?

On Tue, Apr 30, 2013 at 7:32 AM, James Bulpin <James.Bulpin@xxxxxxxxxxxxx> wrote:

Someone in Citrix tried this on a previous XS version, his notes from the experiment were:

initrd

A small number of changes to mkinitrd will be required, in order to support iBFT in such a way that the LUN can be relocatabled and still booted (assuming that the iBFT is changed to point at it).

• If the rootfs depends on a LUN in the iBFT mkinitrd should add code to the initrd that processes the iBFT
• The initrd should attach all LUNs in the iBFT
• The initrd should use the NIC(s) specified in the iBFT with the IP config specified in the iBFT
• The initrd should create explicit routes for the targets hosting the LUN(s) so that later IP changes do not alter the path taken by iSCSI traffic to these LUNs

dom0fs

There should be a minimal number of changes necessary to the dom0 filesystem:

• If it detects the root disk is iSCSI, rc.sysinit will create a dummy SR for that IQN to prevent the iSCSI SR backend from bringing that session down .
• /etc/init.d/open-iscsi:start() needs to reconfigure the iBFT nodes as "onboot" nodes so that stop() does not log out of them.
• If the iBFT nodes have a multipath device on top of them then /etc/init.d/open-iscsi:start() must change their timeouts for speedy failover.
• The SM backend must be modified to never overwrite the config for nodes that are in the iBFT
• Currently, xapi does not know anything about the iSCSI interface as it is not added to the firstboot data by the installer.  However, this means that a pif-introduce and pif-reconfigure-ip could cause access to the root disk to be lost.  Xapi needs to be modified to be told that this interface is reserved and cannot be introduced. TODO!

Maybe there is something in the above that could be useful to you. Unfortunately I have no more knowledge of this than what I’ve pasted.

 

My guess is that in your case xapi/xcp-networkd is re-plugging the PIF being used for iSCSI therefore interrupting the session and losing the root disk. The final bullet point above may be relevant.

 

Regards,

James

 

From: xen-api-bounces@xxxxxxxxxxxxx [mailto:xen-api-bounces@xxxxxxxxxxxxx] On Behalf Of bearon@xxxxxxxxx
Sent: 29 April 2013 23:12
To: xen-api@xxxxxxxxxxxxx
Subject: [Xen-API] XCP 1.6 - iSCSI root, does it work?

 

So I have intel cards that support iBFT.  I have all the settings in the card and I have installed XCP 1.6 by doing the following,

at boot off ISO, typing shell

then running

/opt/xensource/installer/init --use_ibft

This finds my iscsi device fine, installs XCP onto the iscsi device fine (I have mounted it on another machine to verify).

On reboot after install the machine boots up fine, mounts the filesystem/starts daemons,etc.

At that point it gets to

"Performing remaining startup actions:"

and it hangs.  After a while I get

"task XXXX blocked for more than 120 seconds" this is kjournald, flush, etc.  So it looks like it LOST the filesystem.  I can additionally verify that the IP address that WAS on the ethernet port for the iscsi boot to work is now gone.  I can arp -d 1.1.1.1 off my SAN box and the arp never returns until reboot.  Once rebooted, it does it all over again.

What am I missing here?  The install went fine, the boot mounts the directories and starts XAPI/etc fine (I can tell by running in fallback mode).  I see no DHCP requests on the port or anything.  It just drops the IP for some reason.

Anyone else have this issue?

_______________________________________________
Xen-api mailing list
Xen-api@xxxxxxxxxxxxx
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api