Thanks for the feedback on this functionality. We will review the functionality requested and the implementation efforts.

Ed

Ed Reidenbach Manager, Data ONTAP, Multiprotocol and High Availability Network Appliance Phone: 408-822-6167 Email: edr@netapp.com

-----Original Message----- From: Manny Kaiser [mailto:mkaiser@mmcnet.com] Sent: Saturday, September 16, 2000 1:11 AM To: Jeffrey Krueger Cc: toasters@mathworks.com Subject: Re: RFE: Network boot capavility in NetApp firmware

Hi,

I have offically raised this request with Netapp about a year ago. Anyone from Netapp wish to comment?

Jeffrey Krueger wrote:

I'd like to propose an RFE and see what everyone else things about it. If everyone would just add their comments on, that would be great. I suppose this is an RFC for an RFE. =)

Once we all feel comfortable with the RFE, it would be great if we could all forward it up our sales/support channels. Something tells me we aren't the only customer who would like to see this feature. =)

-- Jeff

---

RFE: Network boot capability in NetApp firmware

WHAT:

Add the ability to boot the OS from the network using a command such as "boot net" from the filer firmware "ok>" prompt.

WHY:

Current booting options are from floppy disk or from SCSI/FC-AL primary storage. Adding the ability to do this over the network from a BOOTP/TFTP server would allow:

1) Quicker/easier ONTAP upgrades and repairs
2) Ease of use in a lab environment

Quicker/easier ONTAP upgrades and repairs:

Currently, upgrading between some major OS releases requires booting at least once from floppies. Considering that with ONTAP 6.0 three floppies are necessary, it is extremely difficult for one person to simultaneously upgrade many machines in one physical location and impossible to upgrade machines in different physical locations. Additionally, when a NetApp has a non-bootable root volume due to corruption or less than n-1 disks visible, the only option is to boot with a floppy. This means downtime until someone can build the correct boot disks to resolve the problem and physically reach the machine with those floppies. Even in a single building this process can take several minutes. On a large campus, a trip to the filer could take up to an hour, and for remote sites it could be days.

With network booting, the new OS image could be put into place and several machines in any location can be upgraded in lockstep simply by accessing the serial console and executing "boot net" on each one. NetApp advertises 5 minute downtime for upgrades which is true in the single-filer environment. Any customer with 30+ filers in more than one location knows that a full production upgrade can take much longer. Repairing a machine would be much easier with Network boot since disks would not have to be built, yet the filer could be booted from any image necessary without anyone physically traveling to the machine. Network booting also removes the risk of having built a bad floppy which occurs frequently.

Ease of use in a lab environment:

Our lab environment is also difficult to manage with the current set of boot options. We run several variants of ONTAP in the lab including one or two versions that are currently in production for testing new hardware and configuration changes and many new versions for testing new hardware and new features. To manage this, we do a boot from floppy and menu choice #4, initialize all disks, to two NetApp hard drives for each OS. This approach has many disadvantages including a massive consumption of hard drives in our lab, the tedious and time consuming process of initialize and setting up a new filer, and the maintenance of configuration across several different OS's on the same machine.

With network booting we would not have to waste a pair of disks ONTAP for each new ONTAP version we test - a single pair will do. The disk initialization process would only have to be executed once instead of once per ONTAP version. Finally, we could manage one set of configuration files for all different versions.

Granted, some major OS versions have incompatible WAFL formats and configuration files; however, maintaining a different set of disks between major releases is much easier than doing it between each release, no matter how minor.

HOW:

We'll leave the implementation up to Network Appliance; however, we suggest that they use standards based ways of doing this. Filer IP resolution could be done using RARP/BOOTP and/or DHCP. The former are probably easier and are fairly standard for "in-firmware" address resolution. DHCP is probably more code to write, but might be necessary for NT-only customers. For boot-file transmition, TFTP would work just fine and servers are available for both UNIX and NT.