The subject technology relates in general to virtual disk images, driver injection or streaming, and more particularly to apparatus and method for network driver injection into a target image.
In one aspect, operating system (OS) streaming is a technology to boot a computer (or a virtual machine) from an image file stored on a network. The actual operating system may be centrally located on a server and may stream to a client device on demand. In one aspect, such an image file may be sometimes referred to as a “virtual disk.”
Typically, a virtual disk created from a specific device can be streamed to multiple devices if they bear the same hardware characteristics. More specifically, the motherboard, the network adapter and the video card must be the same in this typical scenario. Be able to use a single virtual disk to boot multiple devices greatly simplifies information technology (IT) department's maintenance effort and cost. For example, to perform Windows updates, a system administrator only needs to apply the changes on the centrally located common virtual disk once. All client devices booted from this virtual disk will receive the changes.
In one aspect of the disclosure, a machine-readable storage medium may be encoded with instructions that may be executable by a processing system to perform a method for providing network driver injection into a target image. In one aspect, the method may transform the target image to be compatible with one or more source machines. In one aspect, the method may facilitate operating system streaming over a network.
The instructions may comprise code for some or all of the following: facilitating access to a source system registry file of a source machine; facilitating access to a target system registry file of the target image, without copying the target image; determining whether one or more source network interface cards of the source machine are compatible with the target image; and if the one or more source network interface cards are not compatible with the target image, performing network interface driver injection. The target image may comprise an operating system.
The operation of performing network interface driver injection may comprise some or all of the following: determining one or more source network components associated with the one or more source network interface cards; determining source network configuration of the one or more source network components; determining target network configuration of one or more target network components of the target image; determining whether the source network configuration conflicts with the target network configuration; if the source network configuration conflicts with the target network configuration, adjusting the source network configuration so that the source network configuration does not conflict with the target network configuration; and injecting, to the target system registry file, the source network configuration of the one or more source network components.
The operation of performing network interface driver injection may further comprise facilitating copying of one or more files associated with the one or more source network components of the source machine onto the target image.
In a further aspect of the disclosure, a method may provide network driver injection into a target image. In one aspect, the method may transform the target image to be compatible with one or more source machines. In one aspect, the method may facilitate operating system streaming over a network.
The method may comprise some or all of the following: facilitating access to a source system registry file of a source machine; facilitating access to a target system registry file of the target image, without copying the target image; determining, by the source machine, whether one or more source network interface cards of the source machine are compatible with the target image; and if the one or more source network interface cards are not compatible with the target image, performing, by the source machine, network interface driver injection. The target image may comprise an operating system.
The operation of performing network interface driver injection may comprise some or all of the following: determining one or more source network components associated with the one or more source network interface cards; determining source network configuration of the one or more source network components; determining target network configuration of one or more target network components of the target image; determining whether the source network configuration conflicts with the target network configuration; if the source network configuration conflicts with the target network configuration, adjusting the source network configuration so that the source network configuration does not conflict with the target network configuration; and injecting, to the target system registry file, the source network configuration of the one or more source network components.
In yet a further aspect of the disclosure, an apparatus may comprise some or all of the following: a processing system; and a machine-readable storage medium encoded with instructions executable by the processing system.
The instructions may comprise code for some or all of the following: facilitating access to a source system registry file of a source machine; facilitating access to a target system registry file of a target image, without copying a target image, determining whether one or more source network interface cards of the apparatus are compatible with the target image; and if the one or more source network interface cards are not compatible with the target image, performing network interface driver injection. The target image may comprise an operating system.
The operation of performing network interface driver injection may comprise some or all of the following: determining one or more source network components associated with the one or more source network interface cards; determining source network configuration of the one or more source network components; determining target network configuration of one or more target network components of the target image; determining whether the source network configuration conflicts with the target network configuration; if the source network configuration conflicts with the target network configuration, adjusting the source network configuration so that the source network configuration does not conflict with the target network configuration; and injecting, to the target system registry file, the source network configuration of the one or more source network components.
In one aspect, the above instructions may be executable by the processing system to perform a method for providing network driver injection from one or more source machines into a target image. In one aspect, the method may transform the target image to be compatible with the one or more source machines. In one aspect, the method may facilitate operating system streaming over a network.
In yet a further aspect of the disclosure, an apparatus may comprise some or all of the following: means for facilitating access to a source system registry file of a source machine; means for facilitating access to a target system registry file of a target image, without copying the target image, wherein the target image comprises an operating system; means for determining whether one or more source network interface cards of the apparatus are compatible with the target image; and means for, if the one or more source network interface cards are not compatible with the target image, performing network interface driver injection. The apparatus may comprise a source system registry file. The target image may comprise an operating system.
The means for performing network interface driver injection may comprise some or all of the following: means for determining one or more source network components associated with the one or more source network interface cards; means for determining source network configuration of the one or more source network components; means for determining target network configuration of one or more target network components of the target image; means for determining whether the source network configuration conflicts with the target network configuration; means for, if the source network configuration conflicts with the target network configuration, adjusting the source network configuration so that the source network configuration does not conflict with the target network configuration; and means for injecting, to the target system registry file, the source network configuration of the one or more source network components.
In one aspect, the apparatus may provide network driver injection from one or more source machines into a target image. In one aspect, this may transform the target image to be compatible with the one or more source machines. In one aspect, the apparatus may facilitate operating system streaming over a network.
In yet a further aspect of the disclosure, a method may build a computer program for providing network driver injection into a target image. In one aspect, this may transform the target image to be compatible with one or more computing machines. In one aspect, the method may facilitate operating system streaming over a network.
The method may comprise some or all of the following: selecting a first computing machine and a second computing machine, wherein the first computing machine comprises a first network interface card, the second computing machine comprises a second network interface card, wherein configuration of the second network interface card is different from configuration of the first network interface card; building a first virtual disk image of the first computing machine; building a second virtual disk image that is compatible with the first computing machine and the second computing machine; booting the first computing machine using the first virtual disk image; extracting first system registry information of the first computing machine after booting the first computing machine using the first virtual disk image, the first system registry information comprising configuration values for the first network interface card based on the first virtual disk image; booting the first computing machine using the second virtual disk image; extracting second system registry information of the first computing machine after booting the first computing machine using the second virtual disk image, the second system registry information comprising configuration values for the first network interface card and the second network interface card based on the second virtual disk image; determining network driver injection components based on differences between the first system registry information and the second system registry information and based on registries that do not affect network functionalities; injecting the network driver injection components into the first virtual disk image; and producing the computer program based on the network driver injection components.
It is understood that other configurations of the subject technology will become readily apparent to those skilled in the art from the following detailed description, wherein various configurations of the subject technology are shown and described by way of illustration. As will be realized, the subject technology is capable of other and different configurations and its several details are capable of modification in various other respects, all without departing from the scope of the subject technology. Accordingly, the drawings and detailed description are to be regarded as illustrative in nature and not as restrictive.
The detailed description set forth below is intended as a description of various configurations of the subject technology and is not intended to represent the only configurations in which the subject technology may be practiced. The appended drawings are incorporated herein and constitute a part of the detailed description. The detailed description includes specific details for the purpose of providing a thorough understanding of the subject technology. However, it will be apparent to those skilled in the art that the subject technology may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form in order to avoid obscuring the concepts of the subject technology. Like components are labeled with identical element numbers for ease of understanding.
Overview
An aspect of the disclosure provides using driver injection to enhance an existing virtual disk image to support multiple heterogeneous platforms for streaming.
Since it is very rare that there is only one type of platform in any OS streaming deployment, it is desirable to have a single virtual disk image streamable to multiple client platforms bearing different hardware characteristics. In one aspect, such a virtual disk image may be sometimes referred to as a “golden” image.
In one aspect, the subject technology enables a user to inject OS streaming related drivers and configurations into an existing virtual disk image to support multiple heterogeneous platforms for OS streaming. The resulting virtual disk image becomes a “golden” image.
The importance of a golden image may be exemplified in the scenario described below:
On an OS streaming deployment, a customer may have 100 client devices scattered in nine branch offices. The 100 devices are purchased from 10 different manufacturers/models. If a golden image is not available, the customer needs to create 10 different virtual disk images, each supporting a unique hardware platform. A typical VDisk image is 10 GB in size.
To deploy OS streaming on all branch offices, the customer needs to distribute all 10 VDisk images from the headquarters to all nine branch offices. That is 10*10 GB*9=900 GB of data traveling on wire, which is typically low-bandwidth channels. To keep the images up to date with latest OS patches, each of the 10 VDisk images needs to be updated from the headquarters. The changes applied on all 10 images would then need to be pushed to each branch office, again on low-bandwidth channels.
If a golden image is available, the customer only needs to create a single virtual disk image supporting all 10 platforms (and 100 client devices). To deploy OS streaming on all branch offices, the customer would need to distribute only one VDisk image from the headquarters to the nine branch offices. That is 10 GB*9=90 GB of data traveling on wire, which is ten times less than without a golden image. To keep the image up to date with latest OS patches, the changes need to be applied on only the single golden image and distributed to the branch offices subsequently.
Obviously, the capability to create a golden image supporting multiple heterogeneous platforms greatly improves the usability of OS streaming, and truly achieves scalability on an enterprise level.
Illustration of Various Approaches
A first approach enables a user to create a golden virtual disk image to support multiple heterogeneous platforms for OS streaming. This approach, however, requires installation of a common network interface card (e.g., a network adapter) on each source platforms during the virtual disk creation process. It involves opening up each source platform and finding a spare bus interface slot to accommodate the new network interface card. It is challenging to common users and often not feasible on platforms where a spare bus slot is not available, which is the case on most laptops. It is also not desirable because opening up a computer chassis may void the manufacturer's warranty. This approach also requires all source platforms to have OS installation that uses the same hardware abstraction layer (HAL).
An aspect of the subject technology overcomes the drawbacks of the foregoing approach. For example, an aspect of the subject technology does not require a common network interface card among different source platforms, does not require a user to open up each source platform, and does not require a spare bus slot to insert a new network interface card. In addition, an aspect of the subject technology does not require all source platforms to have the same HAL.
A second approach enables a user to create a golden virtual disk image to support multiple heterogeneous platforms for OS streaming. This approach helps a user to prepare an OS installation on a physical hard disk, which contains all drivers for all source platforms before capturing a snapshot of the hard disk installation into a virtual disk image. The process involves backing up a hard disk OS installation of one platform to a file (e.g., a wup file), restoring the file from the first source platform to a non-active partition of a second source platform. The process also involves booting the second source platform from the “restored” partition and installing drivers for the second source platform. The resulting hard disk OS installation, which resides on the “restored” partition, contains all drivers from both the first and the second source platforms. Such backup and restore process needs to be repeated on all source platforms.
The repeated backup and restore process is long and tedious. It often may take hours to create a golden image for three to four platforms. It also requires each source platform, except the first, to have at least two hard disk partitions, one for boot up and another for restore (e.g., a wup file). If source platforms have an operating system pre-installed on a single partition, a user needs to remove the existing installation, re-partition the hard disk and re-install the OS first. This approach also requires all source platforms to have OS installation on a hard disk that uses the same hardware abstraction layer (HAL).
An aspect of the subject technology overcomes the drawbacks of the foregoing second approach. For example, an aspect of the subject technology does not require multiple hard disk partitions on any source platforms, does not require copying of an entire hard disk image onto a source platform, and does not require copying of an entire operating system image onto a source platform. In addition, an aspect of the subject technology does not require all source platforms to have the same HAL. In accordance with one aspect of the disclosure, while the foregoing features are not required, the subject technology can also function in the presence of the foregoing drawbacks.
A third approach utilizes a process to create a common virtual disk image between a physical device and a virtual machine. This method can create a common virtual disk for only a single platform and a virtual machine. It does not achieve the goal of creating a single virtual disk for any number of heterogeneous hardware platforms.
An aspect of the subject technology overcomes the drawbacks of the foregoing third approach. For example, an aspect of the subject technology can create a golden virtual disk image for any number of heterogeneous hardware platforms.
A fourth approach uses a method of preinstalling plug-and-play (PnP) drivers into an offline Windows OS image to be deployed to new hardware. An original equipment manufacturer (OEM) or corporate IT staff may utilize this method. This method can be utilized on a Windows image targeted to boot a hard disk physically attached to a target device only. It, however, cannot be used on a virtual disk image, which resides on the network, since a virtual disk image residing on a network needs a network interface card bound to an OS streaming driver designed specifically to support OS streaming. This fourth approach does not inject the binding relationship between the network interface card and the OS streaming driver, and hence cannot be used on a virtual disk image. Furthermore, this approach supports only a plug-and-play driver.
Illustration of Various Advantages
An aspect of the subject technology overcomes the drawbacks of the foregoing fourth approach. For example, an aspect of the subject technology can support injecting a network interface card driver and corresponding network components onto plug-and-play interfaces as well as non plug-and-play interfaces.
In accordance with one aspect of the disclosure, the subject technology can provide, among others, the following advantages.
Illustration of Code/Pseudo Code Representation
Shown below is an aspect of the subject technology written in C++ programming language, but the subject technology is not limited to C++ and can be written in other programming languages. Some examples of subroutines, functions, data structures and defines are shown below, and some of these are referred to later in this disclosure.
Illustration of Terminology
In accordance with one aspect of the subject technology, some of the terms are described below with examples.
Streaming component: In one aspect, a streaming component may include, for example, a software package to be installed on a machine such as a client device to enable the machine to communicate with an OS streaming server over a network, so that the machine can be booted from a virtual disk image that resides on the network. An example of a streaming component is the WSM Client software, which is a streaming manager product of Wyse. Another example is Citrix's provisioning server product, called the Master Target Device software.
Compatible: In one aspect, the term compatible may be used to describe a relationship between multiple entities, such as between a virtual disk image and a client device. Two entities may be considered compatible if, for example, one entity can be booted using the other entity. A virtual disk image and a client device may be considered to be compatible if, for example, the client device can be booted from the virtual disk image through OS streaming. Two entities may be considered incompatible if, for example, one entity cannot be booted using the other entity. A virtual disk image and a client device may be considered to be incompatible if, for example, the client device cannot be properly booted from the virtual disk image through OS streaming.
Source Platform (or Source): In one aspect, a Source Platform, Source, source platform, or source may be a device or a machine, and in one aspect, it can be a physical device or machine, or a virtual device or machine. For example, it may be a computing machine or a computer, which a user would like to make a virtual disk image be compatible with. In one example, it may be referred to as a client device or a client. In one aspect, a Source Platform may be referred to as a source machine. Sometimes the terms platform, device and machine are used interchangeably in this disclosure.
Target Platform: In one aspect, a Target Platform may be a device or a machine. For example, it may be a server on which a Target VDisk resides or a server from which a Target VDisk is streamed to a Source Platform(s). In one aspect, a Target Platform may be referred to as a target machine. In one aspect, a Target VDisk does not necessarily reside in a Target Platform. For example, a Target VDisk can appear as a file residing in a Source Platform or on a Development Machine. Thus, a Target VDisk may reside on a Target Platform (e.g., 304 in
Target VDisk (or Target): In one aspect, a Target VDisk, Target, Target Vdisk, VDisk, target VDisk, or target vdisk may describe a virtual disk or a virtual disk image. A virtual disk image may be, for example, a software image into which support for a Source Platform is to be added so that the virtual disk image can become compatible with the Source Platform. In one aspect, a Target VDisk may be referred to as a target image. In one example, a Target VDisk may be an image file stored on a network. In one aspect, a Target VDisk may be used for driver injection and/or streaming.
Development Machine: In one aspect, a Development Machine or a development machine is a physical or virtual device or machine. For example, a Development Machine may be utilized to perform driver injection (e.g., the driver injection stage 101B of
NIC: In one aspect, a NIC may refer to a network interface card. In one aspect, a NIC can be a physical hardware, or a virtual hardware when a Source Platform is a virtual machine.
Network component: In one aspect, a network component may be a component relating to a network(s). A network component may be, for example, a network driver interface specification (NDIS) miniport driver 1110A (e.g., an NIC driver), an NDIS intermediate driver 1110B, an NDIS protocol driver 1110C, an NDIS protocol driver 1110C, or a network service 1160, as shown in
System registry file: In one aspect, a System registry file or system registry file may be system information. For example, a system registry file may contain configuration information, setup information or system registry information. In one aspect, a system registry file may be editable. In one aspect, a system registry file may contain at least some of network configuration. In one aspect, a system registry file for a source machine may be referred to as a source system registry file. In one aspect, a system registry file for a target image may be referred to as a target system registry file.
Network configuration: In one aspect, network configuration may include configuration information associated with network component(s). An example of a description about network configuration is provided below with reference to operation 1020 in
Driver Injection: In one aspect, the term Driver Injection or driver injection may refer to a process of injecting one or more network components (e.g., one or more drivers or one or more driver components). In one example, after applying this process from the Source Platform onto a Target VDisk, the resulting Target VDisk may become compatible with the Source Platform. The process may involve injecting information of selected network components present in a Source Platform into a Target VDisk. The selected network components may be referred to as “to-be-injected” components.
NetNode structure: In one aspect, each selected network component of the Source Platform and Target VDisk may be described by an instance of this data structure referred to as NetNode (or sometimes referred to as NETNODE or netnode). This structure may have fields that may describe the characteristics and binding relationship of its network component with other network component(s). For example, this structure may include a display name, the type of interface bus, a global unique identifier assigned by the operating system to the component, the installation file used to install the driver for this component, the registry key paths under which various information of this component can be found, a pointer to another NetNode structure which this component is bound to in the operating system's network stack. An example of a NetNode structure is shown above in C++ code within the structure named “typedef struct _NETNODE { . . . }”.
System volume: In one aspect, a System volume (or a system volume) may be the disk volume where an operating system's system files and system information reside. For example, in Windows OS, this is where the kernel binaries and the system registry hive file are located.
HKLM: In one aspect, the term HKLM may refer to HKEY_LOCAL_MACHINE (see item 210 in
Below describes examples of some of the major functions of the CInject class.
InjectDriver: In one aspect, the InjectDriver function may be the top most function in CInject class. The InjectDriver function can check compatibility between multiple entities such as a Source Platform and a Target VDisk. If the two entities are not compatible, this function may perform the Driver Injection process to make the two entities compatible.
CheckNICCompatibility: In one aspect, the function CheckNICCompatibility may check compatibility of NIC between multiple entities such as a Source Platform and a Target VDisk.
InjectWSMNIC: In one aspect, this function InjectWSMNIC may inject OS streaming and NIC related registries from a Source to a Target. This function can also copy a NIC driver binary file and a NIC driver installation file from a Source to a Target.
Below describes examples of some of the helper functions for the functions described above:
EnumWSMNIC: In one aspect, this function EnumWSMNIC may enumerate the registry csSysKey to get a list of NICs whose drivers are currently bound to a network component such as the OS streaming driver. It constructs a NETNODE for each NIC found and adds it to “nList”.
BuildNetNode: In one aspect, this function BuildNetNode may create a NETNODE, fills in the content according to values under classKey registry.
FindEnumEntry: In one aspect, this function FindEnumEntry may find an entry under the “Enum” registry key where a network component described by pNode belongs. This function enumerates all keys under <csSysKey>\Enum, reads the “Driver” registry values under each subkey, and tries to find a match on “<Net Device class >\<pNode->csOldNetClassSubKey>”
FindUpper: In one aspect, this function FindUpper may find the upper node of a target network component. The upper node is the network component currently bound to a target network component from the upper edge in the operating system's network stack. This function looks into the Net Device class key and locates a subkey which “RootDevice” contains target node's GUID.
FindDeviceClassEntry: In one aspect, this function FindDeviceClassEntry may find the Device Class registry entry for a target network component. This function looks into the NDIS LAN class key and locates a subkey value that matches a target node's GUID. The parent key of the above subkey is the Device Class entry.
FindLastSubKey: In one aspect, this function FindLastSubKey may find the last subkey index under regKey. This function may take one input parameter:
AssignNewNetClassSubKey: In one aspect, a function AssignNewNet ClassSubKey may recursively assign the next NetClass subkey number to a to-be-injected network component and its upper nodes.
AssignNewBusSpecificID: In one aspect, this function AssignNewBusSpecificID may recursively assign newBusSpecificID to a to-be-injected network component and its upper nodes.
AssignNewDeviceClassKey: In one aspect, this function AssignNewDeviceClassKey may recursively assign the csNewDeviceClassKey value to a to-be-injected network component and its upper nodes.
TallyNetworkDescriptionInstances: In one aspect, this function TallyNetwork DescriptionInstances tallies the number of Driver Description instances that will appear in a Target VDisk after injecting a network component and its upper nodes. This function stores the information in a string to pointer mapping list, m_NetworkInstanceList.
AssignNewInfPath: In one aspect, this function AssignNewInfPath may set the csNewInfPath field of a to-be-injected net node. This is the path where the OS would find the installation file for a target component after it is moved to the Target.
CopyInfFile: In one aspect, this function CopyInfFile may copy a driver installation file for a to-be-injected network component from a Source to a Target unless an inf file already exists in the Target. The inf file name at the Source is recorded in the csOldInfPath of a NETNODE structure. The inf file name to be used after copying to the Target is recorded in the csNewInfPath of a NETNODE structure.
CopyDriverFile: In one aspect, this function CopyDriverFile may copy a driver binary file for a to-be-injected network component from a Source to a Target unless the driver file already exists in the Target.
MergeNetClassSubKeys: In one aspect, this function MergeNetClassSubKeys may merge the “csSrcSysKey\Class\<Net Device class >” subkeys of the to-be-injected network component (and its uppers) to Target.
MergeDeviceClassSubKeys: In one aspect, this function MergeDeviceClassSubKeys may merge the NDIS LAN class subkeys of the to-be-injected network component (and its uppers) from a Source to a Target.
MergeEnumSubKey: In one aspect, this function MergeEnumSubKey may merge the Enumsubkeys of the to-be-injected network component (and its uppers) from a Source to a Target.
AddLinkage: In one aspect, this function AddLinkage may enumerate all “services” registry keys at a Target. If a subkey's existing “linkage\bind”, “linkage\Route” and “linkage\Export” values contain csRefGUID, this function constructs a similar string by replacing csRefGUID to csGUID of the to-be-injected network component, then adds a new string into the “linkage\bind”, “linkage\Route” and “linkage\Export” registry values. This is to bind the new NIC and/or network component to those services.
AddSvcInterfaces: In one aspect, this function AddSvcInterfaces may enumerate subkeys under “services” registry keys at a Target. If the key name matches the csRefGUID value, this function constructs a similar key name for a target NIC by replacing csRefGUID to target NIC's GUID. This function then looks for this key from a Source. If found, the function copies the whole key from the Source to the Target
AddRemoteAccessInterfaces: In one aspect, this function AddRemoteAccess Interfaces may add an interface to a Target's Remote Access service registry key to represent the new NIC. This function may perform the following:
Organization of Illustrations
Now referring to
Illustration of Process for Building Software Program for Driver Injection
In one aspect of the disclosure, a Driver Injection process involves injecting information of selected network components present in a Source Platform into a Target VDisk. By doing this, the operating system in the Target VDisk, when boots up on the Source Platform, will recognize the network component(s) present in the Source Platform, knows where to find the driver binary for such component(s) and how to bind such component(s) into its network stack. The result is a functional chain of network drivers (network stack) capable of performing normal network activities as well as OS streaming.
An example of building a software program for performing these features is outlined below.
4. Produce a computer program to perform the injection. Based on some or all of the foregoing operations 1-3, produce a computer program 162 (or a software application). This computer program may be based on the network driver injection components 142. It may further be based on the registry injection pattern 145 described above. The computer program can then be encoded onto a machine-readable storage medium.
Illustration of Systems for Driver Injection
A computer network system 300 may include one ore more remote Source Platforms 302 in communication with a Target Platform 304 via a network 306. In one aspect, the Target Platform 304 is configured to allow remote sessions (e.g., remote desktop sessions) wherein users can access applications and files on the Target Platform 304 by logging onto the Target Platform 304 from a Source Platform 302. Such a connection may be established using any of several well-known techniques such as the Remote Desktop Protocol (RDP) on a Windows-based server.
By way of illustration and not limitation, a Source Platform 302 can represent a computer, a mobile phone, a laptop computer, a thin Source Platform, a personal digital assistant (PDA), a portable computing device, a virtual machine, or a suitable device with a processor. In one example, a Source Platform 302 is a smartphone (e.g., iPhone, Android phone, Blackberry, etc.). In certain configurations, a Source Platform 302 can represent an audio player, a game console, a camera, a camcorder, an audio device, a video device, a multimedia device, or a device capable of supporting a connection to a remote Target Platform. In one example, a Source Platform 302 can be mobile. In another example, a Source Platform 302 can be stationary. In one example, a Source Platform 302 may be a device having at least a processor and memory, where the total amount of memory of the Source Platform 302 could be less than the total amount of memory in a Target Platform 304. In one example, a Source Platform 302 does not have a hard disk. In one aspect, a Source Platform 302 has a display smaller than a display supported by a Target Platform 304. In one aspect, a Source Platform may include one or more Source Platforms. In one aspect, each of the Source Platforms 302 may be the same (e.g., the same system configurations and the same network component configurations) or different (e.g., different system configurations or different network component configuration).
In one aspect, a Target Platform 304 may represent a computer, a laptop computer, a computing device, a virtual machine (e.g., VMware® Virtual Machine), a desktop session (e.g., Microsoft Terminal Server), a published application (e.g., Microsoft Terminal Server) or a suitable device with a processor. In one aspect, a Target Platform 304 can be stationary. In another aspect, a Target Platform 304 can be mobile. In certain configurations, a Target Platform 304 may be any device that can represent a Source Platform. In one aspect, a Target Platform 304 may include one or more Target Platforms.
In one example, a first device is remote to a second device when the first device is not directly connected to the second device. In one example, a first remote device may be connected to a second device over a communication network such as a Local Area Network (LAN), a Wide Area Network (WAN), and/or other network.
When a Source Platform 302 and a Target Platform 304 are remote with respect to each other, a Source Platform 302 may connect to a Target Platform 304 over a network 306, for example, via a modem connection, a LAN connection including the Ethernet or a broadband WAN connection including DSL, Cable, T1, T3, Fiber Optics, Wi-Fi, or a mobile network connection including GSM, GPRS, 3G, WiMax or other network connection. A network 306 can be a LAN network, a WAN network, a wireless network, the Internet, an intranet or other network. A network 306 may include one or more routers for routing data between Source Platforms and/or Target Platforms. A remote device (e.g., Source Platform, Target Platform) on a network may be addressed by a corresponding network address, such as, but not limited to, an Internet protocol (IP) address, an Internet name, a Windows Internet name service (WINS) name, a domain name or other system name. These illustrate some examples as to how one device may be remote to another device. However, the subject technology is not limited to these examples.
In one aspect of the disclosure, a “Source Platform” may be sometimes referred to as a source platform, a source machine, a source, a client, a client device or vice versa. Similarly, a “Target Platform” may be sometimes referred to as a target platform, a target machine, a server or vice versa.
In one aspect, the terms “local” and “remote” are relative terms, and a Source Platform may be referred to as a local Source Platform or a remote Source Platform, depending on whether a Source Platform is described from the Source Platform side or from the Target Platform side, respectively. Similarly, a Target Platform may be referred to as a local Target Platform or a remote Target Platform, depending on whether the Target Platform is described from the Target Platform side or from a Source Platform side, respectively.
In one aspect, devices placed on a Source Platform side (e.g., devices connected directly to a Source Platform(s) or to one another using wires or wirelessly) may be referred to as local devices with respect to a Source Platform and remote devices with respect to a Target Platform. Similarly, devices placed on a Target Platform side (e.g., devices connected directly to a Target Platform(s) or to one another using wires or wirelessly) may be referred to as local devices with respect to a Target Platform and remote devices with respect to a Source Platform.
A machine 400 may be, for example, a Source Platform, a Target Platform, a Development Machine, a source platform, a target platform, a source machine, a target machine, a development machine, a computing machine, a computing device, a client device, a device, or a computer. The machine 400 may include a processing system 402. The processing system 402 is capable of communication with a receiver 406 and a transmitter 409 through a bus 404 or other structures or devices. It should be understood that communication means other than busses could be utilized with the disclosed configurations. The processing system 402 can generate audio, video, multimedia, and/or other types of data to be provided to the transmitter 409 for communication. In addition, audio, video, multimedia, and/or other types of data can be received at the receiver 406, and processed by the processing system 402.
The processing system 402 may include a general-purpose processor or a specific-purpose processor for executing instructions and may further include a machine-readable medium 419, such as a volatile or non-volatile memory, for storing data and/or instructions for software programs. The instructions, which may be stored in a machine-readable medium 410 and/or 419, may be executed by the processing system 402 to control and manage access to the various networks, as well as provide other communication and processing functions. The instructions may also include instructions executed by the processing system 402 for various user interface devices, such as a display 412 and a keypad 414. The processing system 402 may include an input port 422 and an output port 424. Each of the input port 422 and the output port 424 may include one or more ports. The input port 422 and the output port 424 may be the same port (e.g., a bi-directional port) or may be different ports.
The processing system 402 may be implemented using software, hardware, or a combination of both. By way of example, the processing system 102 may be implemented with one or more processors. A processor may be a general-purpose microprocessor, a microcontroller, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Programmable Logic Device (PLD), a controller, a state machine, gated logic, discrete hardware components, or any other suitable device that can perform calculations or other manipulations of information.
A machine-readable medium can be one or more machine-readable media. Software shall be construed broadly to mean instructions, data, or any combination thereof, whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. Instructions may include code (e.g., in source code format, binary code format, executable code format, or any other suitable format of code).
Machine-readable media (e.g., 419) may include storage integrated into a processing system, such as might be the case with an ASIC. Machine-readable media (e.g., 410) may also include storage external to a processing system, such as a Random Access Memory (RAM), a flash memory, a Read Only Memory (ROM), a Programmable Read-Only Memory (PROM), an Erasable PROM (EPROM), registers, a hard disk, a removable disk, a CD-ROM, a DVD, or any other suitable storage device. In addition, machine-readable media may include a transmission line or a carrier wave that encodes a data signal. Those skilled in the art will recognize how best to implement the described functionality for the processing system 402. According to one aspect of the disclosure, a machine-readable medium is a computer-readable medium encoded or stored with instructions and is a computing element, which defines structural and functional interrelationships between the instructions and the rest of the system, which permit the instructions' functionality to be realized. In one aspect, a machine-readable medium is a machine-readable storage medium. Instructions may be executable, for example, by a machine (e.g., Source Platform or Target Platform) or by a processing system of a Source Platform or Target Platform. Instructions can be, for example, a computer program including code.
Interfaces or interface cards 416 may be any type of interface and may reside between any of the components shown in
Illustration of Method for Driver Injection
An example of a method for performing driver injection from one or more Source Platforms into a Target VDisk is illustrated below. In one aspect, the method may be performed by a computer program generated by the operation 4 described under the subheading “Illustration of Process for Building Software Program for Driver Injection” (e.g., a computer program called VDiskImageCreation.exe written in C++ programming language). In this example, the method utilizes Windows XP. However, the subject technology is not limited to programs written in C++ or the Windows OS. In one aspect, the subject technology may be practiced utilizing other tools, programming languages or operating systems.
Referring to
Illustration of Checking NIC Compatibility
An example of a method for determining whether the network interface card(s) (NIC(s)) of the Source Platform are compatible with the Target VDisk is illustrated below. An operation 910 for checking the NIC compatibility is shown in
The foregoing operations 1 and 2 select NIC(s) from a Source Platform to inject them into a Target VDisk by detecting the NIC(s) that are currently bound to the OS streaming driver at the Source Platform. There are, however, other methods of selecting NIC(s). For example, (i) prompt a user to select one or more NIC(s) present in the Source Platform, (ii) select the NIC(s) of specific characteristics (e.g., all Ethernet NICs), or (iii) select all NIC(s) in the Source Platform regardless of their characteristics. After injecting the selected NICs' driver/configuration from the Source Platform to the Target VDisk using the methods described in this disclosure, add an OS Streaming driver to bind to the newly injected NIC(s) at the Target VDisk. This can produce a Target VDisk that is compatible and streamable to a Source Platform.
In one aspect, the driver injection stage 101B can perform properly without having a streaming driver in a Source Platform, Target VDisk or a Development Machine. If a Target VDisk does not have a streaming driver, then a streaming driver can be added to (or copied onto) the Target VDisk and be made to bind to appropriate network component(s) on the Target VDisk before streaming the Target VDisk to a Source Platform (e.g., before the streaming operation 670 in
Illustration of Performing Network Interface Driver Injection
An example of a method for performing network interface driver injection is illustrated below. An operation 1000 for performing network interface driver injection if the network interface card(s) are not compatible with the Target VDisk is shown in
Detailed Illustration of Performing Network Interface Driver Injection
A detailed example of a method for performing network interface driver injection, when the network interface card(s) are not compatible with the Target VDisk, is illustrated below with reference to
In one aspect of the disclosure, the method described with reference to
In this example, the method provides a more detailed description of the InjectWSMNIC function (see, e.g., 1310 in
Illustration of Machine-Readable Medium for Driver Injection and Streaming (Described as Clauses)
The subject technology is illustrated, for example, according to various aspects described below. Various examples of aspects of the subject technology are described as numbered clauses for convenience. These are provided as examples, and do not limit the subject technology. The instructions and code for the first clause below are presented, for example, with reference to
1. A machine-readable storage medium (e.g., 1800 in
facilitating access to a source system registry file of a source machine (e.g., 1805 in
facilitating access to a target system registry file of the target image, without copying the target image (e.g., 1810 in
determining whether one or more source network interface cards of the source machine are compatible with the target image (e.g., 1820 in
if the one or more source network interface cards are not compatible with the target image, performing network interface driver injection (e.g., 1830 in
determining one or more source network components associated with the one or more source network interface cards (e.g., 1830-A in
determining source network configuration of the one or more source network components (e.g., 1830-B in
determining target network configuration of one or more target network components of the target image (e.g., 1830-C in
determining whether the source network configuration conflicts with the target network configuration (e.g., 1830-D in
if the source network configuration conflicts with the target network configuration, adjusting the source network configuration so that the source network configuration does not conflict with the target network configuration (e.g., 1830-E in
injecting, to the target system registry file, the source network configuration of the one or more source network components (e.g., 1830-F in
2. The machine-readable storage medium of clause 1,
wherein the instructions further comprise code for:
wherein the method is for facilitating operating system streaming over a network (e.g., 306 in
wherein the operation of facilitating access to a target system registry file of the target image, without copying the target image, comprises:
wherein the operation of facilitating access to a source system registry file of a source machine, the operation of facilitating access to a target system registry file of the target image, the operation of determining, and the operation of performing network interface driver injection are to be performed by the development machine.
3. The machine-readable storage medium of clause 1, wherein the instructions further comprise code for:
selecting at least one of the one or more target network components as a reference network component;
determining a binding relationship between the reference network component and one or more network services for the target image; and
establishing a binding relationship between at least one of the one or more source network components and the one or more network services.
4. The machine-readable storage medium of clause 1, wherein the instructions further comprise code for:
determining whether an operating system of the source machine is compatible with an operating system of the target image; and
determining whether a hardware abstraction layer for the target image is lower than, or the same as, a hardware abstraction layer of the source machine; and
if the operating system of the source machine is compatible with the operating system of the target image and if the hardware abstraction layer for the target image is lower than, or the same as, the hardware abstraction layer of the source machine, performing the following operations:
5. The machine-readable storage medium of clause 1,
wherein the operation of performing network interface driver injection, further comprises:
wherein the operation of determining one or more source network components associated with the one or more source network interface cards is to be performed, by a development machine, based solely on the source system registry file of the source machine,
wherein the operation of determining source network configuration of the one or more source network components is to be performed, by the development machine, based on the source system registry file of the source machine and based on the one or more files associated with the one or more network components of the source machine, and
wherein the operation of determining target network configuration of one or more target network components of the target image is to be performed, by the development machine, based on the target system registry file of the target image and based on one or more files associated with the one or more target network components of the target image.
6. The machine-readable storage medium of clause 1,
wherein the operation of facilitating access to a target system registry file of the target image, without copying the target image, comprises:
wherein the instructions further comprise code for:
7. The machine-readable storage medium of clause 1, wherein the instructions further comprise code for:
facilitating streaming of the target image from a target machine to the source machine over a network.
8. The machine-readable storage medium of clause 1,
wherein the operation of facilitating access to a target system registry file of the target image, without copying the target image, comprises:
wherein the instructions further comprise code for:
9. The machine-readable storage medium of clause 1, wherein the target image resides on a target machine, and the source machine is located remotely from the target machine over a network,
wherein the one or more source network components comprises at least a network interface card driver and an operating system streaming driver, and
wherein the target image is a virtual disk image.
10. The machine-readable storage medium of clause 1,
wherein the operation of determining whether one or more source network interface cards of the source machine are compatible with the target image, comprises:
wherein the operation of determining whether the one or more source network interface cards of the source machine are the same as the one or more target network interface cards for the target image, comprises:
11. The machine-readable storage medium of clause 1,
wherein the operation of determining one or more source network components associated with the one or more source network interface cards, comprises:
wherein the one or more source network components comprise the instance of the source network interface card driver, the instance of the first source intermediate network driver, and the instance of the second source intermediate network driver,
wherein the operation of determining source network configuration of the one or more source network components, comprises:
wherein the operation of, if the source network configuration conflicts with the target network configuration, adjusting the source network configuration, comprises:
12. The machine-readable storage medium of clause 1,
wherein the operation of performing network interface driver injection, further comprises:
wherein the operation of facilitating copying of one or more files, comprises:
wherein the operation of injecting, to the target system registry file, the source network configuration of the one or more source network components, comprises:
13. The machine-readable storage medium of clause 2, wherein the development machine is the source machine.
14. The machine-readable storage medium of clause 2, wherein the operation of facilitating access to one or more files associated with the one or more source network components of the source machine, comprises:
facilitating access to the one or more files associated with the one or more source network components of the source machine, without copying the one or more files onto the development machine.
15. The machine-readable storage medium of clause 1,
wherein the operation of determining whether one or more source network interface cards of the source machine are compatible with the target image, comprises:
wherein the operation of determining whether the one or more source network interface cards of the source machine are the same as the one or more target network interface cards for the target image, comprises:
Illustration of Method for Driver Injection and Streaming (Described as Clauses)
The subject technology is illustrated, for example, according to various aspects described below. Various examples of aspects of the subject technology are described as numbered clauses for convenience. These are provided as examples, and do not limit the subject technology. The operations of the method for the first clause below are presented, for example, with reference to
1. A method (e.g., 1900) for providing network driver injection into a target image (e.g., 324 in
facilitating access to a source system registry file of a source machine (e.g., 1905 in
facilitating access to a target system registry file of the target image, without copying the target image (e.g., 1910 in
determining whether one or more source network interface cards of the source machine are compatible with the target image (e.g., 1920 in
if the one or more source network interface cards are not compatible with the target image, performing network interface driver injection (e.g., 1930 in
2. The method of clause 1,
wherein the method further comprises:
wherein the method is for facilitating operating system streaming over a network (e.g., 306 in
wherein the operation of facilitating access to a target system registry file of the target image, without copying the target image, comprises:
wherein the operation of facilitating access to a source system registry file of a source machine, the operation of facilitating access to a target system registry file of the target image, the operation of determining, and the operation of performing network interface driver injection are performed by the development machine.
3. The method of clause 1, further comprising:
selecting at least one of the one or more target network components as a reference network component;
determining a binding relationship between the reference network component and one or more network services for the target image; and
establishing a binding relationship between at least one of the one or more source network components and the one or more network services.
4. The method of clause 1, further comprising:
determining whether an operating system of the source machine is compatible with an operating system of the target image; and
determining whether a hardware abstraction layer for the target image is lower than, or the same as, a hardware abstraction layer of the source machine; and
if the operating system of the source machine is compatible with the operating system of the target image and if the hardware abstraction layer for the target image is lower than, or the same as, the hardware abstraction layer of the source machine, performing the following operations:
5. The method of clause 1,
wherein the operation of performing network interface driver injection, further comprises:
wherein the operation of determining one or more source network components associated with the one or more source network interface cards is performed, by a development machine, based solely on the source system registry file of the source machine,
wherein the operation of determining source network configuration of the one or more source network components is performed, by the development machine, based on the source system registry file of the source machine and based on the one or more files associated with the one or more network components of the source machine, and
wherein the operation of determining target network configuration of one or more target network components of the target image is performed, by the development machine, based on the target system registry file of the target image and based on one or more files associated with the one or more target network components of the target image.
6. The method of clause 1,
wherein the operation of facilitating access to a target system registry file of the target image, without copying the target image, comprises:
wherein method further comprises:
7. The method of clause 1, further comprising:
facilitating streaming of the target image from a target machine to the source machine over a network, after the operation of performing network interface driver injection.
8. The method of clause 1,
wherein the operation of facilitating access to a target system registry file of the target image, without copying the target image, comprises:
wherein the method further comprises:
9. The method of clause 1, wherein the target image resides on a target machine, and the source machine is located remotely from the target machine over a network,
wherein the one or more source network components comprises at least a network interface card driver and an operating system streaming driver, and
wherein the target image is a virtual disk image.
10. The method of clause 1,
wherein the operation of determining whether one or more source network interface cards of the source machine are compatible with the target image, comprises:
wherein the operation of determining whether the one or more source network interface cards of the source machine are the same as the one or more target network interface cards for the target image, comprises:
11. The method of clause 1,
wherein the operation of determining one or more source network components associated with the one or more source network interface cards, comprises:
wherein the one or more source network components comprise the instance of the source network interface card driver, the instance of the first source intermediate network driver, and the instance of the second source intermediate network driver,
wherein the operation of determining source network configuration of the one or more source network components, comprises:
1 determining, based on the source system registry file, a driver installation file name and location, a driver binary file name and location, a windows services name, and a global unique identifier, for each of the one or more source network components,
wherein the operation of, if the source network configuration conflicts with the target network configuration, adjusting the source network configuration, comprises:
12. The method of clause 1,
wherein the operation of performing network interface driver injection, further comprises:
wherein the operation of facilitating copying of one or more files, comprises:
wherein the operation of injecting, to the target system registry file, the source network configuration of the one or more source network components, comprises:
updating registry values of the target system registry file.
13. The method of clause 2, wherein the development machine is the source machine.
14. The method of clause 2, wherein the operation of facilitating access to one or more files associated with the one or more source network components of the source machine, comprises:
facilitating access to the one or more files associated with the one or more source network components of the source machine, without copying the one or more files onto the development machine.
15. The method of clause 1,
wherein the operation of determining whether one or more source network interface cards of the source machine are compatible with the target image, comprises:
wherein the operation of determining whether the one or more source network interface cards of the source machine are the same as the one or more target network interface cards for the target image, comprises:
In one aspect, all of the operations described under the above subheading “Illustration of Method for Driver Injection and Streaming (described as Clauses)” are performed by the development machine (or the processing system of the development machine). In another aspect, at least some of the operations described under the above subheading are performed by the development machine (or the processing system of the development machine). A development machine may be a source machine or another machine.
Illustration of Apparatus for Driver Injection and Streaming (Described as Clauses)
The subject technology is illustrated, for example, according to various aspects described below. Various examples of aspects of the subject technology are described as numbered clauses for convenience. These are provided as examples, and do not limit the subject technology. The instructions and code for the first clause below are presented, for example, with reference to
1. An apparatus (e.g., 2090 in
facilitating access to a source system registry file of a source machine (e.g., 2005 in
facilitating access to a target system registry file of a target image, without copying the target image (e.g., 2010 in
determining whether one or more source network interface cards of the source machine are compatible with the target image (e.g., 2020 in
if the one or more source network interface cards are not compatible with the target image, performing network interface driver injection (e.g., 2030 in
2. The apparatus of clause 1,
wherein the instructions further comprise code for:
wherein the apparatus is for providing network driver injection into the target image to transform the target image to be compatible with one or more source machines, for facilitating operating system streaming over a network (e.g., 306 in
wherein the operation of facilitating access to a target system registry file of the target image, without copying the target image, comprises:
wherein the operation of facilitating access to a source system registry file of a source machine, the operation of facilitating access to a target system registry file of the target image, the operation of determining, and the operation of performing network interface driver injection are to be performed by the development machine, and
wherein the development machine is the apparatus.
3. The apparatus of clause 1, wherein the instructions further comprise code for:
selecting at least one of the one or more target network components as a reference network component;
determining a binding relationship between the reference network component and one or more network services for the target image; and
establishing a binding relationship between at least one of the one or more source network components and the one or more network services.
4. The apparatus of clause 1, wherein the instructions further comprise code for:
determining whether an operating system of the source machine is compatible with an operating system of the target image; and
determining whether a hardware abstraction layer for the target image is lower than, or the same as, a hardware abstraction layer of the source machine; and
if the operating system of the source machine is compatible with the operating system of the target image and if the hardware abstraction layer for the target image is lower than, or the same as, the hardware abstraction layer of the source machine, performing the following operations:
5. The apparatus of clause 1,
wherein the operation of performing network interface driver injection, further comprises:
wherein the operation of determining one or more source network components associated with the one or more source network interface cards is to be performed, by a development machine, based solely on the source system registry file of the source machine,
wherein the operation of determining source network configuration of the one or more source network components is to be performed, by the development machine, based on the source system registry file of the source machine and based on the one or more files associated with the one or more network components of the source machine,
wherein the operation of determining target network configuration of one or more target network components of the target image is to be performed, by the development machine, based on the target system registry file of the target image and based on one or more files associated with the one or more target network components of the target image, and
wherein the development machine is the apparatus.
6. The apparatus of clause 1,
wherein the operation of facilitating access to a target system registry file of a target image, without copying the target image, comprises:
wherein the instructions further comprise code for:
wherein the development machine is the apparatus.
7. The apparatus of clause 1, wherein the instructions further comprise code for:
facilitating streaming of the target image from a target machine to a source machine over a network.
8. The apparatus of clause 1,
wherein the operation of facilitating access to a target system registry file of a target image, without copying the target image, comprises:
wherein the instructions further comprise code for:
wherein the development machine is the apparatus.
9. The apparatus of clause 1, wherein the target image resides on a target machine, and the source machine is located remotely from the target machine over a network,
wherein the one or more source network components comprises at least a network interface card driver and an operating system streaming driver,
wherein the target image is a virtual disk image, and
wherein the apparatus comprises a display, a transmitter, and a receiver.
10. The apparatus of clause 1,
wherein the operation of determining whether one or more source network interface cards of the source machine are compatible with the target image, comprises:
wherein the operation of determining whether the one or more source network interface cards of the source machine are the same as the one or more target network interface cards for the target image, comprises:
11. The apparatus of clause 1,
wherein the operation of determining one or more source network components associated with the one or more source network interface cards, comprises:
wherein the one or more source network components comprise the instance of the source network interface card driver, the instance of the first source intermediate network driver, and the instance of the second source intermediate network driver,
wherein the operation of determining source network configuration of the one or more source network components, comprises:
wherein the operation of, if the source network configuration conflicts with the target network configuration, adjusting the source network configuration, comprises:
12. The apparatus of clause 1,
wherein the operation of performing network interface driver injection, further comprises:
wherein the operation of facilitating copying of one or more files, comprises:
wherein the operation of injecting, to the target system registry file, the source network configuration of the one or more source network components, comprises:
13. The apparatus of clause 2, wherein the development machine is the source machine.
14. The apparatus of clause 2, wherein the operation of facilitating access to one or more files associated with the one or more source network components of the source machine, comprises:
facilitating access to the one or more files associated with the one or more source network components of the source machine, without copying the one or more files onto the development machine.
15. The apparatus of clause 1,
wherein the operation of determining whether one or more source network interface cards of the source machine are compatible with the target image, comprises:
wherein the operation of determining whether the one or more source network interface cards of the source machine are the same as the one or more target network interface cards for the target image, comprises:
Illustration of Means for Driver Injection and Streaming (Described as Clauses)
The subject technology is illustrated, for example, according to various aspects described below. Various examples of aspects of the subject technology are described as numbered clauses for convenience. These are provided as examples, and do not limit the subject technology. The first clause below is presented, for example, with reference to
The “means” described below may be implemented, for example, as modules as shown in
1. An apparatus (e.g., 2100 in
means for facilitating access to a source system registry file of a source machine (e.g., 2105 in
means for facilitating access to a target system registry file of a target image, without copying the target image (e.g., 2110 in
means for determining whether one or more source network interface cards of the source machine are compatible with the target image (e.g., 2120 in
means for, if the one or more source network interface cards are not compatible with the target image, performing network interface driver injection (e.g., 2130 in
means for determining one or more source network components associated with the one or more source network interface cards (e.g., 2130-A in
means for determining source network configuration of the one or more source network components (e.g., 2130-B in
means for determining target network configuration of one or more target network components of the target image (e.g., 2130-C in
means for determining whether the source network configuration conflicts with the target network configuration (e.g., 2130-D in
means for, if the source network configuration conflicts with the target network configuration, adjusting the source network configuration so that the source network configuration does not conflict with the target network configuration (e.g., 2130-E in
means for injecting, to the target system registry file, the source network configuration of the one or more source network components (e.g., 2130-F in
2. The apparatus of clause 1,
wherein the apparatus further comprises:
wherein the apparatus is for providing network driver injection into the target image to transform the target image to be compatible with one or more source machines, for facilitating operating system streaming over a network (e.g., 306 in
wherein the means for facilitating access to a target system registry file of the target image, without copying the target image, comprises:
wherein the means for facilitating access to a source system registry file of a source machine, the means for facilitating access to a target system registry file of the target image, the means for determining, and the means for performing network interface driver injection are to be performed by the development machine, and
wherein the development machine is the apparatus.
3. The apparatus of clause 1, further comprising:
means for selecting at least one of the one or more target network components as a reference network component;
means for determining a binding relationship between the reference network component and one or more network services for the target image; and
means for establishing a binding relationship between at least one of the one or more source network components and the one or more network services.
4. The apparatus of clause 1, further comprising:
means for determining whether an operating system of the source machine is compatible with an operating system of the target image; and
means for determining whether a hardware abstraction layer for the target image is lower than, or the same as, a hardware abstraction layer of the source machine; and
means for, if the operating system of the source machine is compatible with the operating system of the target image and if the hardware abstraction layer for the target image is lower than, or the same as, the hardware abstraction layer of the source machine, allowing the following means to perform:
5. The apparatus of clause 1,
wherein the means for performing network interface driver injection, further comprises:
wherein the means for determining one or more source network components associated with the one or more source network interface cards comprises: means for determining the one or more source network components associated with the one or more source network interface cards based solely on the source system registry file of the source machine,
wherein the means for determining source network configuration of the one or more source network components comprises: means for determining the source network configuration of the one or more source network components based on the source system registry file of the source machine and based on the one or more files associated with the one or more network components of the source machine, and
wherein the means for determining target network configuration of one or more target network components of the target image comprises: means for determining the target network configuration of the one or more target network components of the target image based on the target system registry file of the target image and based on one or more files associated with the one or more target network components of the target image, and
wherein the development machine is the apparatus.
6. The apparatus of clause 1,
wherein the means for facilitating access to a target system registry file of a target image, without copying the target image, comprises:
wherein the apparatus further comprises:
wherein the development machine is the apparatus.
7. The apparatus of clause 1, further comprising:
means for facilitating streaming of the target image from a target machine to a source machine over a network.
8. The apparatus of clause 1,
wherein the means for facilitating access to a target system registry file of a target image, without copying the target image, comprises:
wherein the apparatus further comprises:
wherein the development machine is the apparatus.
9. The apparatus of clause 1, wherein the target image resides on a target machine, and the source machine is located remotely from the target machine over a network,
wherein the one or more source network components comprises at least a network interface card driver and an operating system streaming driver, and
wherein the target image is a virtual disk image.
10. The apparatus of clause 1,
wherein the means for determining whether one or more source network interface cards of the source machine are compatible with the target image, comprises:
wherein the means for determining whether one or more source network interface cards of the source machine are compatible with the target image comprises: means for determining whether the one or more source network interface cards of the source machine are compatible with the target image based on the source system registry file and the target system registry file, and
wherein the means for determining whether the one or more source network interface cards of the source machine are the same as the one or more target network interface cards for the target image, comprises:
11. The apparatus of clause 1,
wherein the means for determining one or more source network components associated with the one or more source network interface cards, comprises:
wherein the one or more source network components comprise the instance of the source network interface card driver, the instance of the first source intermediate network driver, and the instance of the second source intermediate network driver,
wherein the means for determining source network configuration of the one or more source network components, comprises:
wherein the means for, if the source network configuration conflicts with the target network configuration, adjusting the source network configuration, comprises:
12. The apparatus of clause 1,
wherein the means for performing network interface driver injection, further comprises:
wherein the means for facilitating copying of one or more files, comprises:
wherein the means for injecting, to the target system registry file, the source network configuration of the one or more source network components, comprises:
13. The apparatus of clause 2, wherein the development machine is the source machine.
14. The apparatus of clause 2, wherein the means for facilitating access to one or more files associated with the one or more source network components of the source machine, comprises:
means for facilitating access to the one or more files associated with the one or more source network components of the source machine, without copying the one or more files onto the development machine.
15. The apparatus of clause 1,
wherein the means for determining whether one or more source network interface cards of the source machine are compatible with the target image, comprises:
wherein the means for determining whether one or more source network interface cards of the source machine are compatible with the target image comprises: means for determining whether the one or more source network interface cards of the source machine are compatible with the target image based on the source system registry file and the target system registry file, and
wherein the means for determining whether the one or more source network interface cards of the source machine are the same as the one or more target network interface cards for the target image, comprises:
Illustration of Method of Building a Computer Program (Described as Clauses)
The subject technology is illustrated, for example, according to various aspects described below. Various examples of aspects of the subject technology are described as numbered clauses for convenience. These are provided as examples, and do not limit the subject technology. The operations of the method for the first clause below are presented, for example, with reference to
1. A method (e.g., 2200 in
selecting a first computing machine and a second computing machine (e.g., 2210 in
building a first virtual disk image of the first computing machine (e.g., 2220 in
building a second virtual disk image that is compatible with the first computing machine and the second computing machine (e.g., 2230 in
booting the first computing machine using the first virtual disk image (e.g., 2240 in
extracting first system registry information of the first computing machine after booting the first computing machine using the first virtual disk image, the first system registry information comprising configuration values for the first network interface card based on the first virtual disk image (e.g., 2250 in
booting the first computing machine using the second virtual disk image (e.g., 2260 in
extracting second system registry information of the first computing machine after booting the first computing machine using the second virtual disk image, the second system registry information comprising configuration values for the first network interface card and the second network interface card based on the second virtual disk image; (e.g., 2270 in
determining network driver injection components based on differences between the first system registry information and the second system registry information and based on registries that do not affect network functionalities (e.g., 2280 in
injecting the network driver injection components into the first virtual disk image (e.g., 2290 in
producing the computer program based on the network driver injection components (e.g., 2295 in
2. The method of clause 1, further comprising:
determining a registry injection pattern applicable to one or more other computing machines, before the operation of producing the computer program; and
encoding the computer program onto a machine-readable storage medium,
wherein the operation of producing the computer program based on the network driver injection components is based further on the registry injection pattern.
3. The method of clause 1,
wherein the network driver injection components comprise registries and one or more files associated with network components of the second computing machine,
wherein the operation of injecting network driver injection components into the first virtual disk image, comprises:
wherein the operation of injecting the one or more files, comprises:
4. The method of clause 1, wherein the configurations of the first and second network interface cards are different in at least one of the following attributes: a network interface card manufacturer, a network interface card model, a network interface card revision, or a bus slot for a network interface card.
5. The method of clause 1,
wherein the operation of determining network driver injection components, comprises:
wherein the network driver injection components comprise the second set of registries,
wherein the operation of determining a second set of registries, comprises:
wherein the method further comprises:
Appendix: Illustration of Driver Injection for One Example of Scenario
The disclosure provided under this subheading is simply one exemplary scenario and does not limit the subject technology.
In one approach, a single virtual disk image may be streamed to multiple client devices as long as the devices have similar hardware characteristics. In this example, the mother board, the Preboot eXecution Environment (PXE) capable network card and the video card need to be the same.
According to another approach, a technique can facilitate creation of a “golden” virtual disk image to support multiple heterogeneous client platforms in which the mother board, network card or video card is different. The process involves first creating a hard disk OS installation containing all drivers for all source platforms, then installing a streaming component such as the WSM Client software, and finally capturing a snapshot of the OS installation to a virtual disk image.
In accordance with an aspect of the subject technology, the driver injection feature of the subject technology greatly shortens the time and procedures involved in creating a golden image. The disclosure in this subheading describes how to use driver injection to create a golden image to support client devices (e.g., Source Platforms) with heterogeneous hardware characteristics for one exemplary scenario.
In one aspect, the driver injection to prepare a golden virtual disk for streaming may involve some or all of the following steps:
VDisk by merging a cache file for the second source platform into the VDisk.
Since many of the steps are standard operations, the disclosure under this subheading is focused on discussing the steps that are specific to the driver injection feature.
The driver injection process starts with a VDisk for the first platform. In one aspect, the first platform needs to bear the lowest HAL among all source platforms. For example, if the native HAL for three source platforms are:
This “base” VDisk can be a new disk created from the first platform, or any existing VDisk streamable to the first platform.
Although it is suggested to start with a base VDisk that has latest WSM Client, this is not a requirement. One can use a VDisk created from older streaming manager releases.
The base VDisk may contain any number of partitions.
During the driver injection process, the base VDisk may be configured to private, persistent or volatile cache mode. However, using different cache modes has different implications:
In one aspect, to inject an NIC driver of a device to a VDisk, the following exemplary steps may be utilized:
Driver into Existing Image” If one desires to extend the VDisk size at the same time, fill in the VDisk Size field. Otherwise, leave this field blank. In one aspect, the VDisk needs to be in private mode for VDisk size adjustment to work. See
Now the VDisk is ready to stream to the source platform.
Once the source platform successfully boots from the “new” VDisk, Windows's hardware discovery wizard will prompt to install drivers for hardware found in the source platform. The drivers and corresponding .inf files can usually be found in the local hard disk.
Occasionally, the local hard disk volume is not assigned a driver letter. If this is the case, go to My Computer→Manage→Disk Manager, right click on local hard disk, select Change driver letter and Path, then Add a drive letter.
One can point the hardware installation wizard to the local disk drive (<local disk>:{windows\inf), which contains all the driver inf files. Driver binaries are usually under <local disk>:\windows\system32\\drivers, <local disk>:\windows\system32, or <local disk>:\windows folders.
It is found that on some platforms, installing video and audio drivers from binaries found in local disk causes the display or audio hardware to malfunction. It is recommended that one install these drivers from complete driver installation packages provided by the hardware vendor if possible.
In order to install drivers for newly discovered hardware, one may need to use a keyboard and/or a mouse to select some menus from the hardware discovery wizard. If the Universal Serial Bus (USB) controller driver is not already installed on the VDisk, one will not be able to use the USB keyboard and mouse. Hence, it is recommended that a PS2 keyboard and mouse be attached to the platform when it first boots from the new VDisk. Once the USB controller driver is installed, the USB keyboard mouse can be used in subsequent boots. For a platform that does not have a PS2 keyboard/mouse interface, one may not be able to proceed with drivers installations.
In one aspect, it is recommend that a user does not try to upgrade the driver for the PXE enabled Ethernet network adapter. Doing so can cause a VDisk to hang. A driver upgrade for the PXE enabled Ethernet network adapter needs to be done before driver injection when the platform is booted from a hard disk.
Installing some wireless network drivers may cause network stack re-bind, which in turn may cause a VDisk to hang. If this is the case, one may need to roll back the driver injection changes by deleting the cache file for the target device, re-injecting the NIC driver to the VDisk, and disabling the wireless network adapter from the new VDisk. If wireless network adapter functionality is needed, one may need to use a traditional tool to create a golden VDisk.
Once all drivers are installed, reboot the device once to the new VDisk to confirm proper operation.
In one aspect, if the VDisk is in persistent or volatile cache mode, once the VDisk is confirmed to work properly on the source platform, the changes made on the cache file may need to be committed to the VDisk itself. This can be done by merging the cache file for the source platform into the VDisk file.
When a VDisk is created through a normal image capturing process, it can be streamed to multiple devices bearing the same hardware characteristics as the original device from where the VDisk was captured. However, in some cases, even if a device looks the same (e.g., the same model from the same manufacturer) as the original device, streaming may fail. This is because the network card between the two devices may have slightly different revision number, or may be located on a different PCI slot. These subtle differences between the network cards can cause the VDisk to fail in booting. When attempting to stream a device from an incompatible VDisk, a device typically hangs at Windows boot up progress bar.
In the past, a user did not realize the incompatibility until actually streaming the VDisk to a target device. WSM 3.5 introduces a tool to detect compatibility between an existing VDisk and a device. This tool may be especially useful in large streaming deployment where thousands of client devices from the same manufacturing model are used. It is often impractical to find out that a VDisk is not compatible with some client devices at branch offices after the VDisk has been qualified and deployed from the headquarters.
This tool can be run on a device without installing the streaming software WSM Client. It may take one input parameter: a path to the system hive file of the VDisk. It generates a log file showing the compatibility check result. Below describes some typical steps to use this tool in a large scale streaming deployment scenario:
In one aspect, at the headquarters, perform the following:
In one aspect, at the branch offices, perform the following on each client device:
Below are last few lines from some sample log file:
In one aspect, at the Headquarters, the following may be performed:
Although OSMCheckCompat.exe can be run on a system without installing WSM Client, it can also be run on a system after installing WSM Client. In one aspect, use the following steps:
Closing Subheading
Those of skill in the art would appreciate that the various illustrative blocks, modules, elements, components, methods, and algorithms described herein may be implemented as electronic hardware, computer software, or combinations of both. To illustrate this interchangeability of hardware and software, various illustrative blocks, modules, elements, components, methods, and algorithms have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application. Various components and blocks may be arranged differently (e.g., arranged in a different order, or partitioned in a different way) all without departing from the scope of the subject technology. For example, the specific orders of operations may be rearranged, and some or all of the components may be partitioned in a different way.
It is understood that the specific order or hierarchy of steps in the processes disclosed is an illustration of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged. Some of the steps may be performed simultaneously. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented.
The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. The previous description provides various examples of the subject technology, and the subject technology is not limited to these examples. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more.” For example, a file may include one or more files. Unless specifically stated otherwise, the term “some” refers to one or more. Pronouns in the masculine (e.g., his) include the feminine and neuter gender (e.g., her and its) and vice versa. Headings and subheadings, if any, are used for convenience only and do not limit the invention.
A phrase such as an “aspect” does not imply that such aspect is essential to the subject technology or that such aspect applies to all configurations of the subject technology. A disclosure relating to an aspect may apply to all configurations, or one or more configurations. An aspect may provide one or more examples. A phrase such as an aspect may refer to one or more aspects and vice versa. A phrase such as an “embodiment” does not imply that such embodiment is essential to the subject technology or that such embodiment applies to all configurations of the subject technology. A disclosure relating to an embodiment may apply to all embodiments, or one or more embodiments. An embodiment may provide one or more examples. A phrase such an embodiment may refer to one or more embodiments and vice versa. A phrase such as a “configuration” does not imply that such configuration is essential to the subject technology or that such configuration applies to all configurations of the subject technology. A disclosure relating to a configuration may apply to all configurations, or one or more configurations. A configuration may provide one or more examples. A phrase such a configuration may refer to one or more configurations and vice versa.
The word “exemplary” is used herein to mean “serving as an example or illustration.” Any aspect or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs.
All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. No claim element is to be construed under the provisions of 35 U.S.C. §112, sixth paragraph, unless the element is expressly recited using the phrase “means for” or, in the case of a method claim, the element is recited using the phrase “step for.” Furthermore, to the extent that the term “include,” “have,” or the like is used in the description or the claims, such term is intended to be inclusive in a manner similar to the term “comprise” as “comprise” is interpreted when employed as a transitional word in a claim.