Installation of virtual service processor to computer system having existing operating system

System and method for installation of a virtual service processor (VSP) are disclosed. The system include a computer that has a processor, a physical drive having a first partition and a master boot record (MBR) with initial settings indicating the first partition as an active bootable partition, and a non-transitory computer storage medium having computer-executable instructions. The instructions cause the processor to (a) load and execute a hypervisor from the computer storage medium, the hypervisor having a privileged domain and an unprivileged domain; (b) initiate a VSP in the privileged domain, the VSP being configured to manage at least one health, operation, or performance related aspect of the computer system; (c) configure the unprivileged domain to allow an operating system to run therein, the operating system (OS) being executable directly on the computer system; and (d) load and execute the OS in the unprivileged domain.

FIELD

The present disclosure relates to the field of computer systems and particularly to installation of a virtual service processor (VSP) to a computer system having an existing operating system (OS).

BACKGROUND

A service processor (SP) or a baseboard management controller (BMC) refers to a specialized microcontroller that manages the interface between system management software and platform hardware. The SP can be embedded on the motherboard of a computer, generally a server. Thus, different types of sensors can be built into the computer system, and the SP reads these sensors to obtain parameters such as temperature, cooling fan speeds, power status, operating system (OS) status, etc. The SP monitors the sensors and can send alerts to a system administrator via the network if any of the parameters do not stay within preset limits, indicating a potential failure of the system. The administrator can also remotely communicate with the SP to take some corrective action such as resetting or power cycling the system to get a hung OS running again.

A VSP virtualizes a complete SP or BMC hardware and the functionality. Installation of the VSP environment, however, may create problems. Therefore, a heretofore unaddressed need still exists in the art to address the aforementioned deficiencies and inadequacies.

SUMMARY

Certain aspects of the present disclosure are directly to a non-transitory computer storage medium. The non-transitory computer storage medium stores computer-executable instructions. When the computer-executable instructions are executed by a processor of a computer system that has a physical drive having a first partition including an operating system (OS) and a master boot record (MBR) with initial settings indicating the first partition as an active bootable partition, the computer-executable instructions cause the processor to: (a) load and execute a hypervisor from the non-transitory computer storage medium, the hypervisor having a privileged domain and an unprivileged domain, (b) initiate a virtual service processor (VSP) in the privileged domain, the VSP being configured to manage at least one health, operation, or performance related aspect of the computer system, (c) configure the unprivileged domain to allow the operating system to run therein, the operating system (OS) being executable directly on the computer system, and (d) load and execute the OS in the unprivileged domain.

In certain embodiments, the computer-executable instructions also cause the processor to: (a) initiate a virtual drive in the unprivileged domain, and (b) instruct a virtue CPU of the hypervisor, in accordance with the virtual MBR, to load an OS from the virtual partition and execute that OS of the virtual partition in the unprivileged domain. The virtual drive has (a) a virtual partition that includes a reference to the OS stored in the physical drive and (b) a virtual MBR that indicates the virtual partition as an active bootable partition. The computer-executable instructions further cause the processor to: (a) load the OS from the first partition of the physical drive, and (b) execute the hypervisor to provide the loaded OS to the virtual CPU.

In certain embodiments, the computer-executable instructions also cause the processor to: (a) configure the virtual MBR to have same settings as the initial settings of the MBR of the physical drive, and (b) configure the unprivileged domain to emulate hardware configurations of the computer system.

In certain embodiments, the computer-executable instructions cause the processor to: (a) create a second partition in the physical drive, (b) copy a virtual SP environment file including a hypervisor file and a virtual SP file from the non-transitory computer storage medium to the second partition of the physical drive, wherein the virtual SP environment file is a bootable file instructing the processor to initiate the hypervisor and to initiate the VSP in the privileged domain of the hypervisor, and (c) modify a partition table of the MBR of the physical drive to have settings indicating that the second partition of the physical drive is an active bootable partition. The computer-executable instructions cause the processor to: (a) create a second partition in the physical drive, (b) copy a virtual SP environment file including a hypervisor file and a virtual SP file from the non-transitory computer storage medium to the second partition of the physical drive, wherein the virtual SP environment file is a bootable file instructing the processor to initiate the hypervisor and to initiate the VSP in the privileged domain of the hypervisor, and (c) modify a partition table of the MBR of the physical drive to have settings indicating that the second partition of the physical drive is an active bootable partition.

In certain embodiments, the computer-executable instructions also cause the processor to: (a) store configurations of the virtual MBR in a configuration space of the physical drive for the unprivileged domain, such that in a next booting process the hypervisor initiates the virtual MBR to have the initial settings of the MBR of the physical drive and to indicate that the virtual partition having a reference to the OS in the physical drive is an active bootable partition, and (b) store configurations of the unprivileged domain in a configuration space of the physical drive for the unprivileged domain, such that in a next booting process the hypervisor initiates the unprivileged domain to emulate hardware configurations of the computer system.

In certain embodiments, the non-transitory computer storage medium is a detachable bootable data storage medium. The detachable bootable data storage medium includes a universal serial bus (USB) disk, a memory card, a soft disk drive, a portable hard drive, an optical disk drive, a data cartridge, or a network storage device.

Certain aspects of the present disclosure are directly to a method for installation of virtual service processor to a computer system. The computer system has a processor, a physical drive having a first partition including an operating system (OS) and a master boot record (MBR) with initial settings indicating the first partition as an active bootable partition. The method includes: (a) loading computer-executable instructions from a non-transitory computer storage medium and executing a hypervisor having a privileged domain and an unprivileged domain, (b) initiating a virtual service processor (VSP) in the privileged domain, the VSP being configured to manage at least one health, operation, or performance related aspect of the computer system, (c) configuring the unprivileged domain to allow the operating system directly on the computer system, and (d) loading and executing the OS in the unprivileged domain.

In certain embodiments, the method includes: (a) initiating a virtual drive having (i) a virtual partition that includes a reference to the OS stored in the physical drive in the unprivileged domain, and (ii) a virtual MBR that indicates the virtual partition as an active bootable partition, (b) instructing a virtue CPU of the hypervisor, in accordance with the virtual MBR, to load an OS from the virtual partition and execute that OS of the virtual partition in the unprivileged domain, (c) loading the OS from the first partition of the physical drive, and (d) executing the hypervisor to provide the loaded OS to the virtual CPU.

In certain embodiments, the method also includes: (a) configuring the virtual MBR to have same settings as the initial settings of the MBR of the physical drive, (b) configuring the unprivileged domain to emulate hardware configurations of the computer system, (c) creating a second partition in the physical drive, (d) copying a virtual SP environment file including a hypervisor file and a virtual SP file from the non-transitory computer storage medium to the second partition of the physical drive, where the virtual SP environment file is a bootable file instructing the processor to initiate the hypervisor and to initiate the VSP in the privileged domain of the hypervisor, and (e) modifying a partition table of the MBR of the physical drive to have settings indicating that the second partition of the physical drive is an active bootable partition.

In certain embodiments, the method includes: (a) storing configurations of the virtual MBR in a configuration space of the physical drive for the unprivileged domain, such that in a next booting process the hypervisor initiates the virtual MBR to have the initial settings of the MBR of the physical drive and to indicate that the virtual partition having a reference to the OS in the physical drive is an active bootable partition, and (b) storing configurations of the unprivileged domain in a configuration space of the physical drive for the unprivileged domain, such that in a next booting process the hypervisor initiates the unprivileged domain to emulate hardware configurations of the computer system.

Certain aspects of the present disclosure are directly to a system for installation of a virtual service processor. The system includes a computer system that has a processor, a physical drive having a first partition including an operating system (OS) and a master boot record (MBR) with initial settings indicating the first partition as an active bootable partition. The system also includes a non-transitory computer storage medium. The non-transitory computer storage medium stores computer-executable instructions, and when these instructions are executed by the processor of the computer, these instructions cause the processor to: (a) load computer-executable instructions from the non-transitory computer storage medium and execute a hypervisor that has a privileged domain and an unprivileged domain, (b) initiate a virtual service processor (VSP) in the privileged domain, and the VSP is configured to manage at least one health, operation, or performance related aspect of the computer system, (c) configure the unprivileged domain to allow the operating system to run directly on the computer system, and (d) load and execute the OS in the unprivileged domain.

In certain embodiments, the computer-executable instructions stored in the non-transitory computer storage medium also cause the processor to: (a) initiate a virtual drive having (i) a virtual partition that includes a reference to the OS stored in the physical drive in the unprivileged domain, and (ii) a virtual MBR that indicates the virtual partition as an active bootable partition, (b) instruct a virtue CPU of the hypervisor, in accordance with the virtual MBR, to load an OS from the virtual partition and execute that OS of the virtual partition in the unprivileged domain, (c) load the OS from the first partition of the physical drive, and (d) executing the hypervisor to provide the loaded OS to the virtual CPU.

In certain embodiments, the computer-executable instructions stored in the non-transitory computer storage medium further cause the processor to: (a) configure the virtual MBR to have same settings as the initial settings of the MBR of the physical drive, (b) configure the unprivileged domain to emulate hardware configurations of the computer system, (c) create a second partition in the physical drive, (d) copy a virtual SP environment file including a hypervisor file and a virtual SP file from the non-transitory computer storage medium to the second partition of the physical drive, where the virtual SP environment file is a bootable file instructing the processor to initiate the hypervisor and to initiate the VSP in the privileged domain of the hypervisor, and (e) modify a partition table of the MBR of the physical drive to have settings indicating that the second partition of the physical drive is an active bootable partition.

In certain embodiments, the computer-executable instructions stored in the non-transitory computer storage medium also cause the processor to: (a) store configurations of the virtual MBR in a configuration space of the physical drive for the unprivileged domain, such that in a next booting process the hypervisor initiates the virtual MBR to have the initial settings of the MBR of the physical drive and to indicate that the virtual partition having a reference to the OS in the physical drive is an active bootable partition, and (b) store configurations of the unprivileged domain in a configuration space of the physical drive for the unprivileged domain, such that in a next booting process the hypervisor initiates the unprivileged domain to emulate hardware configurations of the computer system.

DETAILED DESCRIPTION

As used herein, the term “memory” generally refers to the physical devices used to store programs (sequences of instructions) or data (e.g. program state information) on a temporary or permanent basis for use in a computer or other digital electronic device. The terms “non-volatile memory” or “nonvolatile memory” refer to computer memory that can retain the stored information even when not powered, and the term “volatile memory” refers to computer memory that requires power to maintain the stored information.

As used herein, the term “virtual machine” or its abbreviation “VM” generally refers to a software implementation or virtualized simulation of a machine (i.e. a computer) that executes programs like a physical machine. A VM may be based on specifications of a hypothetical computer or emulate the architecture and functioning of a real world computer.

As used herein, the term “guest operating system” or its abbreviation “guest OS” generally refers to the operating system being installed and run in a virtual machine. To run an operating system as the guest OS on a VM, the VM must be configured in the same way that a computer is configured to run the OS.

As used herein, the term “hypervisor” generally refers to a piece of computer software, firmware or hardware that creates and runs virtual machines. The hypervisor is sometimes referred to as a virtual machine manager (VMM).

As used herein, the term “communication” generally refers to communication through physical or non-physical connections between computer components or devices with or without intermediate communicating devices, links, interface or other intercommunicating media. Communication can be generally performed by, but not limited to, non-physical signals such as electronic, magnetic, optical or other types of signals.

The term “interface”, as used herein, generally refers to a communication tool or means at a point of interaction between components for performing data communication between the components. Generally, an interface may be applicable at the level of both hardware and software, and may be uni-directional or bi-directional interface. Examples of physical hardware interface may include electrical connectors, buses, ports, cables, terminals, and other I/O devices or components. The components in communication with the interface may be, for example, multiple components or peripheral devices of a computer system.

The terms “chip” or “computer chip”, as used herein, generally refer to a hardware electronic component, and may refer to or include a small electronic circuit unit, also known as an integrated circuit (IC), or a combination of electronic circuits or ICs.

The invention described herein relates to computer systems. As depicted in the drawings, computer components may include physical hardware components, which are shown as solid line blocks, and virtual software components, which are shown as dashed line blocks. One of ordinary skill in the art would appreciate that, unless otherwise indicated, these computer components may be implemented in, but not limited to, the forms of software, firmware or hardware components, or a combination thereof.

FIG. 1Aschematically depicts a computer system having an existing OS according to one embodiment of the present disclosure. As shown inFIG. 1A, a computer system100is provided as a stand-alone, general purpose computer system. One of ordinary skill in the art would appreciate that the computer system100discussed throughout the present disclosure can be of various types, such as desktop computers, laptop computers, tablet computers, hand-held computers, server computers, blade servers, industrial computers, embedded computers, appliances controllers, electronics equipment controllers, etc. The computer system100can be a special purpose computer system or a system that incorporates more than one interconnected system, such as a client-server network.

The computer system100ofFIG. 1Aonly represents an exemplary embodiment of the present disclosure, and therefore should not be considered to limit the disclosure in any manner. In some embodiments, the computer system100may include other physical or virtual components not shown inFIG. 1for purposes not mentioned in the disclosure.

In the computer system100, a chassis110is provided to enclose various components or devices of the computer system100. Although not explicitly shown inFIG. 1A, a baseboard is provided in the chassis110, which is a printed circuit board to which a plurality of components or devices may be disposed thereon and be interconnected. The layout of the components on the baseboard and the manner of the interconnection between the components on the baseboard is herein referred to as the “configuration” of the baseboard. One of ordinary skill in the art would appreciate that the configuration of the baseboard may be adjusted or changed according to the necessary design or manufacturing requirements.

In one embodiment, the components in the chassis110include, but not limited to, a central processing unit (CPU)120, a memory121, a Basic Input/Output System (BIOS) chip130, a hard drive140, an interface150, and other required memory and Input/Output modules (not shown). Further, a detachable bootable data storage medium160is provided outside the chassis110, and the detachable bootable data storage medium160is connected to the computer system100through the interface150. In certain embodiments, the interface between the components may be physical hardware interface such as electrical connectors, buses, ports, cables, terminals, or other I/O devices. The CPU120is a host processor which is configured to control operation of the computer system100. In some embodiments, one of ordinary skill in the art would appreciate that the computer system100may run on or more than one CPU as the host processor, such as two CPUs, four CPUs, eight CPUs, or any suitable number of CPUs.

The BIOS chip130is one of the most crucial components of the computer system100. The BIOS chip130is in communication to the CPU120, and is configured to store the BIOS software (hereinafter BIOS)132for performing the booting functions as described above. Generally, the BIOS chip130is a non-volatile chip, such as a flash memory chip, an EEPROM chip. The BIOS132is in communication with a complementary metal oxide semiconductor (CMOS) memory. Initial settings and configurations of the BIOS may be stored in the CMOS memory. Settings in the BIOS chip130may specify a set of storage devices (designated as “bootable data storage devices” or a “bootable devices”) that the computer system100is allowed to boot from. When the computer system100starts up, the first job for the BIOS132is the power-on self-test, which initializes and identifies the system hardware devices, such as the CPU120, memory and storage devices, display card, keyboard and mouse, and other hardware devices. The BIOS132then attempts to boot the computer system100, i.e., instructs the CPU to read and execute an OS from the devices as specified in the BIOS132. Typically the BIOS132attempts to load, i.e., instruct the CPU to read and execute, the boot loader software from a specified device. The boot loader software then loads an OS from that bootable device. An OS is a collection of software managing computer hardware resources and software programs. Thus, the CPU120can execute the OS and run an instance of the OS. Accordingly, the control of the computer system100is given to the OS. This process is known as booting, or booting up, which is short for bootstrapping.

In certain embodiments, the BIOS chip130can also be a bootable data storage medium, and the computer system100may be bootable from the BIOS chip130if necessary booting software is provided in the BIOS chip130.

The hard drive140is a block-based bootable data storage medium. Specifically, the hard drive140may be logically divided into a plurality of logical storage units, which are referred to as “partitions”.FIG. 1Bschematically depicts configuration of the hard drive of the computer system ofFIG. 1Aaccording to one embodiment of the present disclosure. As shown inFIG. 1B, the hard drive140includes a first partition147storing the existing OS142. The first partition147can be an active bootable partition of the hard drive140. The existing OS142has been configured to be run directly on the computer system100. In other words, during a booting process, the BIOS132loads the existing OS142. Then, the running instance of the existing OS142can be the only operating system that manages the resources of the computer system100. Further, the hard drive140also includes a master boot record (MBR)144having a partition table146. In certain embodiments, the hard drive140may include a second partition148or more partitions. The partition table146indicates, among other things, which one of the partitions of the hard drive140is the active bootable partition. As shown inFIG. 1B, the first partition147storing the existing OS142is a bootable partition. The MBR144and the partition table146indicate that the first partition147is the active bootable partition. Thus, when the computer system100boots from the hard drive140, the existing OS142stored in the first partition147of the hard drive140will be launched and executed.

Referring back toFIG. 1A, the interface150is a physical input/output hardware provided on the chassis110for connecting the detachable bootable data storage medium160to connect to the computer system100. In certain embodiments, the interface150may be electrical connectors, buses, ports, cables, terminals, or other I/O devices corresponding to the detachable bootable data storage medium160.

The detachable bootable data storage medium160is a physical data storage device detachably connected to the computer system100through the interface150. In certain embodiments, the detachable bootable data storage medium160may be any portable and bootable data storage device such as a memory card, a USB drive, a soft disk drive, a portable hard drive, an optical disk drive, a data cartridge, a network storage device, or any other type of portable and detachable data storage devices. To simplify the description, the USB drive will be used as an example of the detachable bootable data storage medium160, and in this case, the corresponding interface150will be a USB port.

As described above, when the computer system100starts up, the BIOS132performs the booting process for booting the existing OS142from the hard drive140. The computer system100then operates under the management of the existing OS142. Since the existing OS142runs directly on the computer system100, there is no virtualization.

FIG. 2schematically depicts the execution of the existing OS on the computer system when the VSP environment is installed according to one embodiment of the present disclosure. There are computer systems or servers with no space available for a physical SP or BMC on the server hardware due to high number of systems packed within a small chassis. For example, some computer systems have packed hardware with all existing hardware elements embedded therein, and modification of the existing hardware elements is difficult and may be destructive to the computer system. In some instances, a VSP environment can provide a suitable solution. The VSP environment typically includes a hypervisor and a VSP running in the privileged domain of the hypervisor. The VSP can virtualize a complete SP or BMC hardware and the functionality while no physical SP or BMC hardware is present on the system. Running on the in-band space on the processor of a server, the VSP can offer a comprehensive manageability which is consistent across all other traditional server management solutions. Generally, a hypervisor implements hardware virtualization techniques and allows one or more OS to run concurrently as guests of one or more virtual machines on a host computer.

As shown inFIG. 2, in order to install the VSP environment in such a computer system100without modifying the hardware configuration of the computer system100or changing the existing OS142in a destructive way, a hypervisor200must be provided to run on the computer system100. The hypervisor200can be of various types and designs, such as XEN, MICROSOFT HYPER-V, VMWARE ESX, or other types of hypervisor. The hypervisor200can emulate a plurality of domains, including a privileged domain210, and an unprivileged domain220(i.e. the virtual machine). Thus, the VSP module230runs in the privileged domain210, and the existing OS142runs in the unprivileged domain (the virtual machine)220instead of running directly on the physical machine of the computer system100directly.

The VSP module230, when running in the privileged domain210, functions similarly to a physical system-on-a-chip BMC installed in the computer system100. For example, the computer system100can include different types of sensors, the VSP module230may be capable of obtaining data from these sensors to obtain parameters and health, operating and performance-related aspects associated with the computer system100, such as, but not limited to, the temperature of one or more components of the computer system100, speed of rotational components (e.g., spindle motor, CPU Fan, etc.) within the computer system100, the voltage across or applied to one or more components within the computer system100, and the available or used capacity of memory devices within the computer system100. For example, if a temperature sensor is disposed near the CPU120, the VSP module230may receive data from the temperature sensor and determine whether the CPU120exceeds a prescribed temperature. When the VSP module230determines that the temperature of CPU120exceeds prescribed temperature, the VSP module230may issue an instruction to the CPU fan to cool down the CPU120. In certain embodiments, the VSP module230may include various applications and software for, among other things, implementing different baseboard management functions. In certain embodiments, the VSP module230can provide advanced monitoring features and more detailed hardware information (such as temperatures in different thermal zones).

In certain embodiments, the VSP module230adheres to the Intelligent Platform Management Interface (IPMI) industry standard for system monitoring and event recovery. The IPMI standard is well-known to those of ordinary skill in the industry, and therefore not described in detail herein. Rather, revision 1.1 of the IPMI Specification, version 1.5, release date Feb. 20, 2002, is incorporated herein by reference.

FIGS. 3A to 3Cschematically depict installation of a VSP environment to the computer system according to one embodiment of the present disclosure. In the description below, a USB drive160and a USB interface150may be used as examples of a detachable bootable data storage medium160and the corresponding interface150. One skilled in the art would appreciate that other types of detachable bootable data storage medium can be similarly used in place of the USB drive.

To install the VSP environment to the computer system, initially the BIOS132and the CMOS memory of the computer system100are changed, when necessary, to specify that a USB drive is the first in order of the devices from which the computer system100is allowed to boot. The VSP environment is stored in the USB drive160as a bootable file. Thus, when the computer system100is powered on, the BIOS132of the computer system100, in accordance with the configuration of the CMOS, can instruct the CPU120to attempt to boot from the attached USB drive160. The VSP environment includes a hypervisor200and a VSP module230configured to run within the privileged domain210of the hypervisor200. As shown inFIG. 3A, the USB drive160storing the VSP environment can be inserted to the USB interface150of the computer system100. Then, the BIOS132instructs the CPU120to boot the computer system100from the USB drive160. Under the instruction of a boot loader in the VSP environment, the CPU120loads the hypervisor300into the memory121and executes the hypervisor300. As discussed above, the existing MBR144has a partition table146indicating the active bootable partition of the hard drive140. Referring back toFIG. 2, the hypervisor200can communicate with the BIOS132for managing the hardware and can detect the hardware configuration of the computer system100including the CPU120, the memory121, the disks, I/O devices, and network devices. The hypervisor200also installs necessary device drivers for managing those devices. Then the hypervisor200initiates the VSP module230in the privileged domain210. The hypervisor200creates a virtual machine (unprivileged domain)220having a virtual hardware configuration as the actual physical hardware configuration. In other words, a guest running in the virtual machine would perceive that it actually runs on a physical machine having those hardware configurations. Further, in the process of setting up a virtual machine220, the hypervisor200can read the existing MBR144of the hard drive140and use it as the virtual MBR for that virtual machine220. More specifically, during initialization of the virtual machine220, a virtual BIOS264of the virtual machine220starts a booting process of the virtual machine220. The virtual BIOS264determines, e.g. based on the configuration of a virtual CMOS, from which device it should load an operating system. The settings of virtual CMOS, which is the same as or similar to the original settings of the CMOS of the computer system100, indicates that the virtual hard drive242is the device from which an operating system should be loaded by the virtual BIOS264. The hypervisor200has set up the virtual hard drive242to have a mirroring or corresponding configuration of the original physical hard drive140. In other words, the virtual hard drive242has a virtual MBR246that indicates that a first partition250including an operating system254is the active bootable partition. The first partition250of the virtual hard drive242has a reference to the first partition147of the physical hard drive140. Thus, the virtual BIOS264(instructing the virtual CPU202) reads the virtual MBR246and finds that it should load the OS254from the first partition250of the virtual hard drive242. The hypervisor200operates the virtual CPU202and the virtual hard drive242for the virtual machine220, and translates the requests directed to the virtual hard drive242to requests directed to the physical hard drive140. In this example, the hypervisor200loads the existing OS142stored in the first partition147of the physical hard drive140and provides the existing OS142to the virtual BIOS264as an OS254stored in the first partition250of the virtual hard drive242. The virtual BIOS264instructs the virtual CPU202to load the boot loader of the existing OS254, which then instructs the virtual CPU202to load the rest of the existing OS254. In this way, the virtual machine220runs an instance262of the existing OS254.

Referring toFIG. 3A, in certain embodiments, the VSP module instance230running in the privileged domain210of the hypervisor200can create a second partition148in the physical hard drive140and copy the VSP file330and the hypervisor file300from the detachable bootable data storage medium160to the second partition148as shown inFIG. 3B. The running VSP instance230modifies the partition table (not shown) of the MBR144of the hard drive140to indicate that the second partition148storing the VSP environment file330is the active bootable partition. The running VSP instance230copies the original MBR144of the hard drive140into the configuration space338of the virtual machine220such that the configuration space338stores a MBR configuration340that is the same as the original MBR140. During initialization of the virtual machine220, the hypervisor200, in accordance with the MBR configuration340stored in the configuration space338, configures the virtual hard drive242to have a MBR246having the same settings as those of the original MBR140.

Once the VSP environment file300has been copied to the second partition148of the physical hard drive140and that the settings of the original MBR has been copied to the configuration space338of the virtual machine220, in the next booting process, the computer system100can boot the VSP environment even if the USB drive160has been removed from the computer system100. More specifically, initially the BIOS132determines that the hard drive140is the device from which an OS should be loaded by the BIOS132. Then, the BIOS132reads the modified MBR144of the hard drive140. The modified MBR144of the hard drive140now indicates that the second partition148storing the VSP environment file300as the active bootable partition. Accordingly, the BIOS132instructs the CPU120to read the boot loader from the second partition148. Subsequently, the boot loader instructs the CPU120to load the hypervisor300from the second partition148such that a hypervisor instance200is running. The hypervisor instance200creates a privileged domain210and initiates a VSP instance230in that domain210. Further, the hypervisor instance200also creates an unprivileged domain220(the virtual machine), which has been configured to emulates the original settings of the computer system100. The MBR246of the virtual hard drive has the same configuration as the original MBR340of the physical hard drive140, indicating that the first partition250of the virtual hard drive242having the existing OS254as the active bootable partition. The virtual BIOS264accordingly instructs the virtual CPU202to load the operating system254stored in the first partition250of the virtual hard drive242. As discussed above, the hypervisor200loads the existing OS142stored in the first partition147of the physical hard drive140in the virtual machine220. In certain embodiments, during the installation process, system modifications, other than modifying the BIOS132in order to boot from the USB drive160, may not be necessary in order to install the VSP environment. There is no destructive change to the existing OS142stored in the hard drive140. In other words, the installation of the VSP to the computer system100is non-destructive.