Tag Archives: NetApp

Migrating NetApp cloned LUNs for iSCSI boot

Leave a reply

If you are booting a Linux system via iSCSI (using Broadcomm or Intel iSCSI-bootable Ethernet), certain information specific to your system is embedded in the Linux configuration during the OS installation. If you then clone that LUN and try to boot it with another system, all hell breaks loose. The system starts to boot and then “learns” during the boot process it’s old IP and MAC and iSCSI IQN information, which essentially makes it switch boot luns mid way through! Imagine the disaster that makes when you boot from LUN X and it starts to modify LUN Y!

Here are my quick notes on what it takes to “break” the relationships embedded on the boot/root LUN.

  • Install CentOS to HostA, booting from iSCSI NetApp LUN “lunA”
  • Create a lun clone “lunB”, and then do a non-space-efficient lun clone split in order to get rid of the snapshot dependencies between the systems.
  • Boot the HostA from the clone/copy “lunB”
  • Edit /boot/grub/grub.conf for new IP, new Ethernet MAC, new IQN. MAC addresses must be lowercase!
  • Edit /etc/iscsi/initiatorname.iscsi
  • Edit /etc/sysconfig/network-scripts/ifconfig-eth*  with the updated ethernet macs, IPs
  • Edit /ets/sysconfig/network for new hostname
  • Shutdown -h
  • boot the second host (HostB) from the modified copy (LunB) to test.

This is for a non-GUI system. If you are running a GUI and the second host doesn’t have the same video card, that will break and you will have to reconfigure X.

 

Installing Windows 2008 R2 to an iSCSI target (Broadcomm NetExtreme II)

5 Replies

We have a lab at work for the various sales engineers to use. We’ve done a home-brew boot-from-iSCSI farm of servers so we can change boot luns pretty easily, based on a NetApp FAS270 (old cheap but reliable for the moment.)

I had the iSCSI initiator in the BIOS set up and could see it logging into the FAS270. The problem was that if I had the CDROM selected as secondary boot (so I could install an operating system to the new LUN), it would attempt to boot from iSCSI (good!), fail (normal, no OS yet), and then log out of the iSCSI connection before continuing to boot from the CDROM (secondary device). Windows wouldn’t see the target device for installation.

If I put the CDROM first, then the NetExtreme BIOS wouldn’t log into the iSCSI target, so Windows installation again would not see the target device for installation. This differs from IBM x3650 M2/M3 servers which will initialize the iSCSI connection first, no matter what order the boot device is, and work “as expected”.

The trick is to put the CDROM second, but hit “CTRL-D” after the initial login to the iSCSI initiator. The iSCSI boot ROM actually warns you “Hit Ctrl-D if you don’t want to boot from the iSCSI target” or similar. Hitting Ctrl-D tells the Broadcomm chipset to skip iSCSI boot, but stay logged in to the target. So the target LUN is visible, the system boots from CDROM, and the Windows installation can install to the iSCSI device.