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: 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.