Abstract: A Virtual Tape Emulation (VTE) application is able to be updated without disrupting IO operations by hosts on a set of virtual tape drives managed by the VTE application. When an old VTE application is to be replaced with a new VTE application, the new VTE application is provided with the same configuration information as the old VTE application. Each time a host unmounts a virtual tape from a virtual tape drive on the old VTE application, device management for that virtual tape drive is migrated from the old VTE application to the new VTE application. Specifically, path and channel information for the virtual tape drive is transferred to the new VTE application, and applied by the new VTE application to a respective device on the new VTE application. Once device management for all virtual tape drives has been transferred, the old VTE application is terminated.

Abstract: A Virtual Tape Emulation (VTE) application is able to be updated without disrupting IO operations by hosts on a set of virtual tape drives managed by the VTE application. When an old VTE application is to be replaced with a new VTE application, the new VTE application is provided with the same configuration information as the old VTE application. Each time a host unmounts a virtual tape from a virtual tape drive on the old VTE application, device management for that virtual tape drive is migrated from the old VTE application to the new VTE application. Specifically, path and channel information for the virtual tape drive is transferred to the new VTE application, and applied by the new VTE application to a respective device on the new VTE application. Once device management for all virtual tape drives has been transferred, the old VTE application is terminated.

Abstract: A virtual tape library system includes multiple copies of a LockFS that are mounted on all nodes. One of the LockFSs is designated as the active copy. A primary node manages recovery when a secondary node signals loss of connectivity with the active copy by posting a sync request file to at least one of the LockFSs. The primary node posts status request files to the LockFSs and the secondary nodes respond by writing status to the status request files. A LockFS that is reachable by all nodes is selected as the new active LockFS. Switchover is accomplished by the primary node posting a disable request file to the selected LockFS and waiting for all secondary nodes to acknowledge by writing to the disable request file. The primary node then posts an activate request file to the selected LockFS and waits for all secondary nodes to acknowledge by writing to the activate request file.

Abstract: Virtual tape emulation software on a Virtual Tape Emulator (VTE) assigns file systems labels based on the tape library name, the logical name of the storage array (from the VTE perspective), and the logical unit number (LUN) of the device on the VTE on which the file system is created. To prevent name conflicts within the VTE Operating System (VTEOS), a UDEV label translation process in the VTEOS creates a new label for the virtual tape file system that will be used by the VTEOS to identify the virtual tape file system. The label is created by concatenating the tape library ID, and the storage system identifier and the device identifier derived from the device World Wide Name (WWN). Since the label is unique within the VTE, UDEV label translation enables the VTEOS to differentiate between multiple replicated copies of the same virtual tape file system.

Abstract: A virtual tape library system includes multiple copies of a LockFS that are mounted on all nodes. One of the LockFSs is designated as the active copy. A primary node manages recovery when a secondary node signals loss of connectivity with the active copy by posting a sync request file to at least one of the LockFSs. The primary node posts status request files to the LockFSs and the secondary nodes respond by writing status to the status request files. A LockFS that is reachable by all nodes is selected as the new active LockFS. Switchover is accomplished by the primary node posting a disable request file to the selected LockFS and waiting for all secondary nodes to acknowledge by writing to the disable request file. The primary node then posts an activate request file to the selected LockFS and waits for all secondary nodes to acknowledge by writing to the activate request file.

Abstract: Migrating virtual tapes between different virtual tape storages without host involvement is described herein. A system as described herein can include a local tape library comprising respective storage devices; a memory that stores executable components; and a processor that executes the executable components stored in the memory. The executable components can comprise a connection component that establishes a first connection to a host system and a second connection to an external tape library; a request processing component that receives an access request for a requested storage device from the host system via the first connection; and a proxy component that accesses the requested storage device at the outside tape library via the second connection and enables access to the requested storage device by the host system via the first connection in response to the requested storage device being determined to be absent from the local tape library.

Abstract: Migrating virtual tapes between different virtual tape storages without host involvement is described herein. A system as described herein can include a local tape library comprising respective storage devices; a memory that stores executable components; and a processor that executes the executable components stored in the memory. The executable components can comprise a connection component that establishes a first connection to a host system and a second connection to an external tape library; a request processing component that receives an access request for a requested storage device from the host system via the first connection; and a proxy component that accesses the requested storage device at the outside tape library via the second connection and enables access to the requested storage device by the host system via the first connection in response to the requested storage device being determined to be absent from the local tape library.

Abstract: A mechanism for transparent (or non-disruptive) virtual tape engines restart. Specifically, the disclosed mechanism entails preserving a pre-restart state prior to restarting a virtual tape engine, followed by restoring the pre-restart state after the restarting in order to achieve transparency.

Abstract: A mechanism for transparent (or non-disruptive) virtual tape engines restart. Specifically, the disclosed mechanism entails preserving a pre-restart state prior to restarting a virtual tape engine, followed by restoring the pre-restart state after the restarting in order to achieve transparency.