Patent Application
20190065213
A computing system can include an operating system (OS) executing on a hardware platform, which includes processor(s), memory, storage, input/output (TO) devices, and the like. When the OS executes directly on the hardware platform, the OS is referred to herein as a “host OS.” Computer virtualization is a technique that involves encapsulating the hardware platform of the computing system into virtual hardware platforms on which virtual machine(s) execute under control of virtualization software. A virtual machine (VM) provides virtual hardware abstractions for processor, memory, storage, and the like to a guest operating system (OS) and guest application(s) that run on the guest OS. The virtualization software provides virtual hardware platforms and virtual execution environments for the virtual machine(s).
In some virtualized environments, the hosts have different hardware architectures, such as central processing units (CPUs) having different instruction set architectures (ISAs). However, care must be taken to deploy virtual machine images to hardware with matching ISAs. For example, if a data center includes both x86-based and ARM-based services, the system administrator must build and maintain twice as many virtual machine images (e.g., a VM image for each ISA). Also, moving a VM image between platforms having different ISAs becomes impossible, as an x86-based VM image is not compatible with a hardware platform having an ARM ISA and vice versa.
One or more embodiments relate to a method of provisioning a virtual appliance to a virtualized computing system, comprising: deploying the virtual appliance to the virtualized computing system, the virtual appliance including a system partition, one or more disk images, and configuration data, the configuration data defining a virtual machine executable on each of a plurality of processor architectures, the system partition configured to boot on any one of the plurality of processor architectures; and booting the virtual appliance from the system partition.
Further embodiments include a non-transitory computer-readable storage medium comprising instructions that cause a computer system to carry out the above method, as well as a computer system configured to carry out the above method.
To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures. It is contemplated that elements disclosed in one embodiment may be beneficially utilized on other embodiments without specific recitation.
In an embodiment, hosts 102 have hardware platforms that include processors having different instruction set architectures (ISAs). For example, host 102-1 can include a hardware platform with an x86 processor and host 102-2 can include a hardware platform with an ARM-based processor. In general, the ISA of the processor in host 102-1 is different than the ISA of the processor in host 102-2. An application binary compiled for the ISA used by host 102-1 cannot execute on the host 102-2 and vice versa. Thus, a virtual appliance built specifically for the ISA used by host 102-1 cannot be provisioned to host 102-2 and vice-versa. Virtual appliance provider 108 provides FatVMs 110. A FatVM 110 is a virtual appliance that can be seamlessly provisioned for either host 102-1 or host 102-2 regardless of ISA. In general, a FatVM 110 includes a number of disk images and associated configuration and metadata distributed in a known format, such as the Open Virtualization Format (OVF). FatVMs 110 can be various virtual appliances, such as virus scanners, network services, virtualization management servers, and the like.
System registers 304 include registers for use by code to configure and control core 302. Instruction decoder 318 supports an instruction set of core 302. Instruction decoder 318 decodes input instructions and controls functional units of core 302 to perform the input instructions. The instruction set of core 302 can include branch instructions, exception generating instructions, system instructions, data processing instructions, load and store instructions, and the like. As noted above, the instruction set for one host can be different from the instruction set for another host in the same data center (e.g., a data center can include x86-based hosts and ARM-based hosts). MMU 312 implements memory management in the form of paging of memory 208. MMU 312 controls address translation and access permissions for memory accesses made by core 302.
Returning to
Each VM 220 supported by hypervisor 218 includes guest software that runs on the virtualized resources supported by hardware platform 202. In the example shown, the guest software of each VM 220 includes a guest OS 222. Guest OS 222 can be any commodity operating system known in the art, such as such as Linux®, Microsoft Windows®, Mac OS®, or the like. VM 220 can also include various applications (not shown) that execute therein in with support of guest OS 222. As noted above, a VM 220 can be provisioned as a virtual appliance, such as a FatVM 110 described further herein.
Hypervisor 218 includes, among other components, a kernel 224 and virtual machine monitors (VMMs) 2261 . . . 226M (collectively VMMs 226). Kernel 224 provides operating system functionality (e.g., process creation and control, file system, process threads, etc.), as well as CPU scheduling and memory scheduling. VMMs 226 are processes scheduled by kernel 224 to implement the virtual system support for VMs 220. Each VMM 226 manages a corresponding virtual hardware platform. The virtual hardware platform includes virtual CPUs (vCPUs), guest physical memory, virtual 10 devices, and the like. At power-on of computing system 200, firmware 216 performs initialization of hardware platform 202. Firmware 216 hands of execution to a bootloader of hypervisor 218. The bootloader performs various initialization tasks.
After the correct kernel is booted with its initrd image and before pivoting to the real root filesystem and executing the init process to setup the user environment, the appropriate filesystem with the correct binaries must be used depending on the architecture. There are various embodiments discussed below for providing multiple architecture support in FatVM 110.
In one embodiment, binaries, libraries, kernel modules, and the like are compiled into a universal binary format, such as FatELF. FatELF is a file format that embeds multiple ELF binaries for different architectures into one file. FatELF is actually a container format that adds some accounting information at the start of the file and then appends all the ELF binaries afterwards. FatELF can be used for both executable files and shared libraries. In an embodiment, FatVM 110 has a single disk image 404 that includes binaries, libraries, kernel modules, and the like in a universal binary format, such as FatELF or the like. The advantages of this embodiment is that only a single disk image 404 is needed to serve as the root filesystem that can be booted on multiple architectures. The universal binary format eliminates the need for scripts and special configurations for picking the correct binaries to load when booting on different architectures. Non-binary files, such as configuration files, images, video files, etc. can be shared and managed transparently on different architectures. There is no need for replication and conversion. However, the support for universal binary format requires that the OS support the executables. Thus, at step 606, the virtual appliance can create a filesystem from a single disk image and at step 608 the virtual appliance can execute binaries having a universal binary format.
In another embodiment, FatVM 110 includes multiple disk images 404. For example, FatVM 110 can include a disk image 404 for each supported architecture. All binaries used by FatVM 110 are packaged inside architecture-specific disk images and replicated across platforms.
In another embodiment, FatVM 110 merges the support for different architectures in the same filesystem, avoiding the duplication of the common files or the manipulation of several file systems. At step 606, all binaries and libraries are moved to different directories, which have the corresponding architecture name appended (e.g., /bin_$(arch), /lib_$(arch)). During the boot process, a script running from initrd creates the required symlinks to present the correct binaries and libraries to the system. Shared configuration, content, and state do not need additional treatment. However, similar to a multiple disk image approach, this technique adds complexity when upgrading or installing new software. The package manager needs to install architecture specific files in their corresponding directories.
In another embodiment, FatVM 110 includes a kernel image that includes a FatVM filesystem filter. At step 606, the directory names for binaries and libraries are re-mapped on-the-fly by the kernel into architecture-specific directories. Directories for the other architectures not being used are hidden. This technique avoids boot-time symlinking and makes the filesystem appear as standard as possible. However, the package manager needs the capability to see architecture specific directories during software installation and upgrade.
In an embodiment, at step 704, the virtual appliance creates symbolic links to merge the disk images. In another embodiment, at step 706, the virtual appliance merges layers of a union-based filesystem, such as OverlayFS and AUFS. For example, with OverlayFS, the architecture-specific disk image containing the binaries can serve as the bottom layer and the shared disk image with common files can serve as the top layer. The layers are merged to form a unified view of the filesystem. The advantage of using architecture-specific disk images is that no modification of the kernel and toolchain are necessary. However, this simplicity results in some added complexity for handing disk updates and maintaining multiple disk images.
In another embodiment, a synthetic block device can be used to achieve similar results as using multiple disk images. Hypervisor 218 can be configured for synthetic block device support, which allows for media (e.g., hard disk, CD/DVD, USB, floppy, etc.) to be efficiently mastered on the fly with contents as described by a recipe. Using a different recipe per architecture, a FatVM 110 can support multiple architectures for hypervisors that support such a synthetic block device.
The various embodiments described herein may employ various computer-implemented operations involving data stored in computer systems. For example, these operations may require physical manipulation of physical quantities—usually, though not necessarily, these quantities may take the form of electrical or magnetic signals, where they or representations of them are capable of being stored, transferred, combined, compared, or otherwise manipulated. Further, such manipulations are often referred to in terms, such as producing, identifying, determining, or comparing. Any operations described herein that form part of one or more embodiments of the invention may be useful machine operations. In addition, one or more embodiments of the invention also relate to a device or an apparatus for performing these operations. The apparatus may be specially constructed for specific required purposes, or it may be a general purpose computer selectively activated or configured by a computer program stored in the computer. In particular, various general purpose machines may be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required operations.
The various embodiments described herein may be practiced with other computer system configurations including hand-held devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like.
One or more embodiments of the present invention may be implemented as one or more computer programs or as one or more computer program modules embodied in one or more computer readable media. The term computer readable medium refers to any data storage device that can store data which can thereafter be input to a computer system—computer readable media may be based on any existing or subsequently developed technology for embodying computer programs in a manner that enables them to be read by a computer. Examples of a computer readable medium include a hard drive, network attached storage (NAS), read-only memory, random-access memory (e.g., a flash memory device), a CD (Compact Discs)—CD-ROM, a CD-R, or a CD-RW, a DVD (Digital Versatile Disc), a magnetic tape, and other optical and non-optical data storage devices. The computer readable medium can also be distributed over a network coupled computer system so that the computer readable code is stored and executed in a distributed fashion.
Although one or more embodiments of the present invention have been described in some detail for clarity of understanding, it will be apparent that certain changes and modifications may be made within the scope of the claims. Accordingly, the described embodiments are to be considered as illustrative and not restrictive, and the scope of the claims is not to be limited to details given herein, but may be modified within the scope and equivalents of the claims. In the claims, elements and/or steps do not imply any particular order of operation, unless explicitly stated in the claims.
Virtualization systems in accordance with the various embodiments may be implemented as hosted embodiments, non-hosted embodiments or as embodiments that tend to blur distinctions between the two, are all envisioned. Furthermore, various virtualization operations may be wholly or partially implemented in hardware. For example, a hardware implementation may employ a look-up table for modification of storage access requests to secure non-disk data.
Certain embodiments as described above involve a hardware abstraction layer on top of a host computer. The hardware abstraction layer allows multiple contexts to share the hardware resource. In one embodiment, these contexts are isolated from each other, each having at least a user application running therein. The hardware abstraction layer thus provides benefits of resource isolation and allocation among the contexts. In the foregoing embodiments, virtual machines are used as an example for the contexts and hypervisors as an example for the hardware abstraction layer. As described above, each virtual machine includes a guest operating system in which at least one application runs. It should be noted that these embodiments may also apply to other examples of contexts, such as containers not including a guest operating system, referred to herein as “OS-less containers” (see, e.g., www.docker.com). OS-less containers implement operating system-level virtualization, wherein an abstraction layer is provided on top of the kernel of an operating system on a host computer. The abstraction layer supports multiple OS-less containers each including an application and its dependencies. Each OS-less container runs as an isolated process in userspace on the host operating system and shares the kernel with other containers. The OS-less container relies on the kernel's functionality to make use of resource isolation (CPU, memory, block I/O, network, etc.) and separate namespaces and to completely isolate the application's view of the operating environments. By using OS-less containers, resources can be isolated, services restricted, and processes provisioned to have a private view of the operating system with their own process ID space, file system structure, and network interfaces. Multiple containers can share the same kernel, but each container can be constrained to only use a defined amount of resources such as CPU, memory and I/O. The term “virtualized computing instance” as used herein is meant to encompass both VMs and OS-less containers.
Many variations, modifications, additions, and improvements are possible, regardless the degree of virtualization. The virtualization software can therefore include components of a host, console, or guest operating system that performs virtualization functions. Plural instances may be provided for components, operations or structures described herein as a single instance. Boundaries between various components, operations and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within the scope of the invention(s). In general, structures and functionality presented as separate components in exemplary configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements may fall within the scope of the appended claim(s).
This application claims priority to U.S. Provisional Patent Application Ser. No. 62/549,690, filed Aug. 24, 2017, 6which is incorporated herein by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 62549690 | Aug 2017 | US |
