Abstract: The disclosure provides an approach for a non-disruptive system upgrade. Embodiments include installing an upgraded version of an operating system (OS) on a computing system while a current version of the OS continues to run. Embodiments include entering a maintenance mode on the computing system, including preventing the addition of new applications and modifying the handling of storage operations on the computing system for the duration of the maintenance mode. Embodiments include, during the maintenance mode, configuring the upgraded version of the OS. Embodiments include, after configuring the upgraded version of the OS, suspending a subset of applications running on the computing system, transferring control over resources of the computing system to the upgraded version of the OS, and resuming the subset of the applications running on the computing system. Embodiments include exiting the maintenance mode on the computing system.

Abstract: In a process for hot-swapping operating systems, an original operating system (OS) instance is executing on and controlling hardware of a computer. The original OS instance generates updated launch code that defines a division of the hardware into a source logical partition and a target logical partition. The original OS instance quiesces processes hardware of the target logical partition so that the original OS instance and an application running thereon are contained by the source logical partition. The original OS instance launches the updated OS instance so that it executes on the target logical partition. The application is moved from the source logical partition to the target logical partition. The original OS instance terminates. The updated OS instance claims hardware freed by the termination.

Abstract: A hypervisor-exchange process includes: suspending, by an “old” hypervisor, resident virtual machines; exchanging the old hypervisor for a new hypervisor, and resuming, by the new hypervisor, the resident virtual machines. The suspending can include “in-memory” suspension of the virtual machines until the virtual machines are resumed by the new hypervisor. Thus, there is no need to load the virtual machines from storage prior to the resuming. As a result, any interruption of the virtual machines is minimized. In some embodiments, the resident virtual machines are migrated onto one or more host virtual machines to reduce the number of virtual machines being suspended.

Abstract: A computer system is rebooted upon crash without running platform firmware and without retrieving all of the modules included in a boot image from an external source and reloading them into system memory. The reboot process includes the steps of stopping and resetting all of the processing units, except one of the processing units that detected the crash event, selecting the one processing unit to execute a reboot operation, and executing the reboot operation to reboot the computer system.

Abstract: A computer system is rebooted after updating a boot image without running platform firmware with its power-on self-test of system hardware devices and without retrieving all of the modules included in a boot image from an external source and reloading them into system memory. The reboot process includes the steps of loading one or more updated modules of the boot image into the system memory, executing the boot loader module to load for execution modules of the boot image including a system software kernel and the updated modules, and transferring execution control to the system software kernel.

Abstract: An “old” hypervisor is upgraded to or otherwise replaced by a “new” hypervisor without migrating virtual machines to a standby computer. The old hypervisor partitions the computer that it controls between a source partition and a target partition. The hypervisor and its virtual machines initially run on the source partition, while a new hypervisor is installed on the target partition. The virtual machines are migrated to the new hypervisor without physically moving the in-memory virtual-machine data. Instead, the old hypervisor sends memory pointers, and the new hypervisor claims the respective memory locations storing the virtual-machine data. After all virtual machines are migrated, the old hypervisor bequeaths the hypervisor memory and a last processor that the old hypervisor requires to run. The new hypervisor claims the bequeathed processor and hypervisor memory after the old hypervisor terminates to complete the upgrade/exchange.

Abstract: A hypervisor-exchange process includes: suspending, by an “old” hypervisor, resident virtual machines; exchanging the old hypervisor for a new hypervisor, and resuming, by the new hypervisor, the resident virtual machines. The suspending can include “in-memory” suspension of the virtual machines until the virtual machines are resumed by the new hypervisor. Thus, there is no need to load the virtual machines from storage prior to the resuming. As a result, any interruption of the virtual machines is minimized. In some embodiments, the resident virtual machines are migrated onto one or more host virtual machines to reduce the number of virtual machines being suspended.

Abstract: A computer system is rebooted after updating a boot image without running platform firmware with its power-on self-test of system hardware devices and without retrieving all of the modules included in a boot image from an external source and reloading them into system memory. The reboot process includes the steps of loading one or more updated modules of the boot image into the system memory, executing the boot loader module to load for execution modules of the boot image including a system software kernel and the updated modules, and transferring execution control to the system software kernel.

Abstract: A computer system is rebooted upon crash without running platform firmware and without retrieving all of the modules included in a boot image from an external source and reloading them into system memory. The reboot process includes the steps of stopping and resetting all of the processing units, except one of the processing units that detected the crash event, selecting the one processing unit to execute a reboot operation, and executing the reboot operation to reboot the computer system.

Abstract: An “old” hypervisor is upgraded to or otherwise replaced by a “new” hypervisor without migrating virtual machines to a standby computer. The old hypervisor partitions the computer that it controls between a source partition and a target partition. The hypervisor and its virtual machines initially run on the source partition, while a new hypervisor is installed on the target partition. The virtual machines are migrated to the new hypervisor without physically moving the in-memory virtual-machine data. Instead, the old hypervisor sends memory pointers, and the new hypervisor claims the respective memory locations storing the virtual-machine data. After all virtual machines are migrated, the old hypervisor bequeaths the hypervisor memory and a last processor that the old hypervisor requires to run. The new hypervisor claims the bequeathed processor and hypervisor memory after the old hypervisor terminates to complete the upgrade/exchange.

Abstract: In a process for hot-swapping operating systems, an original operating system (OS) instance is executing on and controlling hardware of a computer. The original OS instance generates updated launch code that defines a division of the hardware into a source logical partition and a target logical partition. The original OS instance quiesces processes hardware of the target logical partition so that the original OS instance and an application running thereon are contained by the source logical partition. The original OS instance launches the updated OS instance so that it executes on the target logical partition. The application is moved from the source logical partition to the target logical partition. The original OS instance terminates. The updated OS instance claims hardware freed by the termination.

Abstract: A method, apparatus, and system of virtual machine migration using local storage are disclosed. In one embodiment, a method includes creating a current snapshot of an operating virtual machine on a source physical server, storing a write data on a low-capacity storage device accessible to the source physical server and a destination physical server during a write operation on the destination physical server, and launching the operating virtual machine on the destination physical server when a memory data is copied from the source physical server to the destination physical server. The current snapshot may be a read-only state of the operating virtual machine frozen at a point in time. A time and I/O that may be needed to create the current snapshot that may not increase with a size of the operating virtual machine.