# zgetdump /dev/dasdd1 | ssh user@host "cat > dump.s390"
The zipl and zgetdump tools for channel-attached devices currently support single- and multi-volume ECKD DASD, single-volume Fixed Block Architecture (FBA) DASD, and 3480, 3490, 3590, and 3592 tape.
SCSI dump: Support was also added for Linux on System z guests and LPARs that have only Small Computer System Interface (SCSI) Fibre Channel Protocol (FCP) disk. Accessing these disks in a Storage Area Network (SAN) using zSeries FCP (ZFCP) is complex and support couldn’t be fitted into the first 64KB of memory, like for the DASD and tape dump tools. Instead, a second Linux kernel is used that’s conceptually similar to the Kdump approach. But unlike Kdump, this kernel isn’t loaded into guest memory in advance.
The ZFCP dump kernel is IPLed from SCSI disk using a new dump operand on IPL. With this operand, the first few megabytes of memory are saved in a hidden area the Processor Resource/Systems Manager (PR/SM) or z/VM hypervisor owns. The ZFCP dump kernel is then loaded into that saved memory region. Using a z-specific hardware interface, the ZFCP dump kernel can access the hidden memory. As with Kdump, the ZFCP dump kernel then exports all memory using a virtual file. A ZFCP dump user-space application running in a ramdisk then copies that file into a local file system on the SCSI disk where the dump tool was installed (see Figure 4).
Preparing a SCSI disk for ZFCP dumps requires these steps:
- Prepare partition on SCSI disk: fdisk /dev/sdb.
- Create ext3 file system: mke2fs -j /dev/sdb1.
- Mount file system: mount /dev/sdb1 /mnt.
- Install SCSI dump tool: zipl -D /dev/sdb1 -t /mnt.
When running in a Logical Partition (LPAR), IPLing that SCSI disk using the SCSI dump load type on the HMC triggers a dump.
When running under z/VM, the dump device must be defined using a cp command (the example shown uses WWPN=500507630300C562, LUN=401040B400000000):
# set dumpdev portname 50050763 0300C562 lun 401040B4 00000000