Inherited product activation for virtual machines

Inherited product launch for virtual machines

This disclosure is about the launch of a successor product for virtual machines.

Virtualization allows the creation of fully configured computers entirely from software. For example, when a client computer system is emulated on a host computer system, the client computer system is called a "virtual machine" because the client computer system exists on the host computer as a software representation for operating a specific hardware architecture In the computer system. In the virtual machine, the operating system can be installed as the operating system on the physical hardware.

The virtual machine can use the software application of the application activation mechanism. For example, some applications can apply an authorization mechanism that allows users to use applications that comply with certain terms and conditions on one or more virtual machines. In this context, "product activation" describes actions that meet the requirements of the authorization mechanism, thereby allowing the use of the software. In the context of virtual machines, there are unique challenges for the activation mechanism of application software products.

Software anti-piracy solutions often operate by linking software licenses to individual computer hardware. The link is performed by creating a hardware-based ID or fingerprint for the computer. Since the hardware is virtualized, virtualization makes these solutions unreliable. The fingerprint can be edited or copied, so the fingerprint can be used to skip the product activation and copy or steal the software. In addition, typical server virtualization scenarios move virtual machines from one host to another as needed. This legal use can interrupt the software licensing solution linked to the hardware fingerprint.

This article reveals a method and system for inheriting the startup mechanism to open a secure communication path from the host operating system (OS) to the guest OS. The license status of the software on the host is transmitted through this channel, and the software installed in the guest uses this information to notify the software of its own product activation process. When the license requirements of the host are met, the virtualized software can be subsequently activated without any external communication.

The above is an overview, and therefore the above must contain simplifications, generalizations, and omissions of details. Those familiar with the technology will understand that this summary is only illustrative and not intended to be limiting in any way.

<b>Overall computing environment</b>

Certain specific details are set forth in the following description and figures to provide a thorough understanding of various embodiments of the present invention. In the following disclosure, certain well-known details generally associated with computing and software technology are not described in order to avoid unnecessarily obscuring the various embodiments of the present invention. In addition, those skilled in the art should understand that those skilled in the art can practice other embodiments of the present invention without one or more of the details described below. Finally, although the various methods are described with reference to the steps and sequence in the following disclosure, the description thus provides a clear implementation of the embodiments of the present invention, and it should not be considered that the steps and the sequence of the steps must be performed in order to practice this invention.

It should be understood that the various technologies described herein can be implemented in combination with hardware or software, or a combination of hardware and software under appropriate circumstances. Therefore, the method and device of the present invention or certain aspects or parts of the present invention may take the form of program codes (that is, instructions) implemented in tangible media, such as floppy disks, CD-ROMs, and hard disks. A drive machine or any other machine readable storage medium, wherein when the program code is loaded into a machine such as a computer and executed by the machine, the machine becomes a device for practicing the present invention. When the code is executed on a programmable computer, the computing device usually includes a processor, a storage medium that can be read by the processor (including volatile memory and non-volatile memory and/or storage elements), and at least one input Device and at least one output device. For example, through the use of an application programming interface (API), reusable controls, or the like, one or more programs can implement or utilize the processes related to the present invention. These programs are better implemented in high-level programming languages or object-oriented programming languages to communicate with computer systems. However, the program can be implemented in assembly language or machine language when needed. In any case, the language can be a compiled language or an interpreted language, and the language can be combined with hardware implementations.

The remote desktop system is a computer system that maintains application programs, which can be remotely executed by the client computer system. The input is entered at the client computer system, and the input is via the network (for example, using a protocol based on the International Telecommunications Union (ITU) T.120 protocol family, such as the Remote Desktop Protocol (RDP) ) To the application on the terminal server. The application processes the input as if it were entered at the terminal server. The application generates output in response to the received input, and the output is sent to the client via the network.

The embodiments can be executed on one or more computers. Figures 1 and 2 and the following discussion are intended to provide a brief general description of a suitable computing environment in which the present disclosure can be implemented. Those familiar with this technology can understand that the computer systems 200 and 300 may have some or all of the components described with respect to the computer 100 in FIG. 1 and FIG. 2.

The term "circuit system" used throughout this disclosure may include hardware components, such as hardware interrupt controllers, hard drives, network adapters, graphics processors, and hardware-based video/audio codecs And the firmware/software used to operate this hardware. The term "circuitry" may also include microprocessors that are configured to be configured by firmware or by a switch or one or more logical processors (eg, multi-core general-purpose processing One or more cores) to perform functions. The logic processor in this example can be configured by software instructions that implement logic that can operate to perform functions, and load these functions from memory (for example, RAM, ROM, firmware, and/or virtual memory) . In an exemplary embodiment where the circuit system includes a combination of hardware and software, the implementer can write the source code for the implementation logic, which is then compiled into machine-readable code, and the machine-readable code can be used by the logic processor To execute. As those who are familiar with this technology can understand that the current best technology has developed to a situation where there is almost no difference between hardware, software, or a combination of hardware/software, so the hardware-to-software selection for the realization of the function is only For the design choice. Therefore, since those familiar with the technology can understand that software processing can be transformed into an equivalent hardware structure, and the hardware structure itself can be transformed into an equivalent software processing, the hardware implementation is not important for the choice of software implementation. Leave it to the implementer.

Figure 1 illustrates an example of a computing system configured to have the aspect of the present disclosure. The computing system may include a computer 20 or the like of the computer 20. The computer 20 includes a processing unit 21, a system memory 22, and a system bus 23. The system bus 23 couples various system components including the system memory to the processing unit 21 . The system bus 23 can be any one of several types of bus structures. The several types of bus structures include a memory bus or a memory controller, a peripheral bus, and any of various bus architectures. A regional bus with a bus architecture. The system memory includes read only memory (ROM) 24 and random access memory (RAM) 25. The basic input/output system 26 (BIOS) contains basic routines such as helping to transfer information between components in the computer 20 during startup. The BIOS is stored in the ROM 24. The computer 20 may further include a hard disk drive 27, which is used for reading and writing hard disks from a hard disk (not shown); and the magnetic disk drive 28, which is used for reading from a self-removable disk 29 Fetch or write a removable disk 29; and an optical disk drive 30, which is used to read or write a removable optical disk 31 from the removable optical disk 31, such as a CD ROM or other optical media. In some exemplary embodiments, computer-executable instructions that implement aspects of the present disclosure may be stored in ROM 24, hard disk (not shown), RAM 25, removable disk 29, optical disk 31, and/or processing unit 21 in the cache. The hard disk drive 27, the disk drive 28, and the optical disk drive 30 are connected to the system bus 23 through the hard disk drive interface 32, the disk drive interface 33, and the optical drive interface 34, respectively. The drivers and the computer-readable media associated with the drivers provide computer 20 with computer non-volatile storage. The non-volatile storage stores readable commands, data structures, program modules, and other data. Although the environment described in this article uses hard disks, removable disks 29, and removable optical disks 31, those familiar with the technology should understand that other types of computer-readable media (such as, Cassette tapes, flash memory cards, digital video discs, Bernoulli cartridges, random access memory (RAMs), read-only memory (ROMs), etc.) can also be used in operating environments.

Several program modules can be stored on the hard disk, floppy disk 29, optical disk 31, ROM 24 or RAM 25. The program modules include operating system 35, one or more application programs 36, other program modules 37 and Program data 38. The user can input commands and information into the computer 20 via input devices (such as the keyboard 40 and the pointing device 42). Other input devices (not shown) may include microphones, joysticks, game pads, satellite dishes, scanners, or the like. These and other input devices are often connected to the processing unit 21 via the serial port interface 46, which is coupled to the system bus, but these and other input devices can be connected by other interfaces, such as parallel ports, game ports Or universal serial bus (universal serial bus; USB). The display 47 or other types of display devices can also be connected to the system bus 23 via an interface such as a video adapter 48. In addition to the display 47, the computer usually includes other peripheral output devices (not shown), such as speakers and printers. The system in FIG. 1 also includes a host adapter 55, a Small Computer System Interface (SCSI) bus 56 and an external storage device 62 connected to the SCSI bus 56.

The computer 20 can operate in a network environment using logical connections with one or more remote computers (such as the remote computer 49). Although only the memory storage device 50 is shown in Figure 1, the remote computer 49 can be another computer, server, router, network PC, peer device or other shared network node, virtual machine, and The remote computer 49 may generally include many or all of the elements described above with respect to the computer 20. The logical connection shown in Figure 1 may include a local area network (LAN) 51 and a wide area network (WAN) 52. Such network environments are commonly found in offices, enterprise-wide computer networks, intranets, and the Internet.

When the computer 20 is used in a LAN network environment, the computer 20 can be connected to the LAN 51 via a network interface or adapter 53. When the computer 20 is used in a WAN network environment, the computer 20 may generally include a modem 54 or other components for establishing communication via a wide area network 52 (such as the Internet). The modem 54 can be internal or external, and the modem 54 can be connected to the system bus 23 via the serial port interface 46. In a network environment, the computer 20 or the program modules shown in the computer 20 can be stored in a remote memory storage device. It should be understood that the network connections shown are examples, and other components that establish communication links between computers may be used. In addition, although it is envisaged that many embodiments of the present disclosure are particularly applicable to computer systems, nothing in this document is intended to limit the present disclosure to these embodiments.

Referring now to Figure 2, another embodiment of an exemplary computing system 100 is shown. The computer system 100 may include a logical processor 102, for example, an execution core. Although one logical processor 102 is shown, in other embodiments, the computer system 100 may have multiple logical processors, for example, each processor substrate may have multiple execution cores and/or may each have multiple execution cores. Multiple processor substrates. As shown in the figure, various computer-readable storage media 110 can be interconnected by one or more system buses that couple various system components to the logical processor 102. The system bus can be any one of several types of bus structures. The several types of bus structures include memory buses or memory controllers, peripheral buses, and use any of various bus structures The regional bus of the bus structure. In an exemplary embodiment, the computer-readable storage medium 110 may include, for example, a random access memory (RAM) 104, a storage device 106 (for example, an electromechanical hard drive, a solid state hard drive, etc.), and firmware 108 (For example, FLASH RAM or ROM) and a removable storage device 118 (such as CD-ROM, floppy disk, DVD, flash drive, external storage device, etc.). Those familiar with this technology should understand that other types of computer-readable storage media can be used, such as cassettes, flash memory cards, digital video discs, and Bernoulli cartridges.

The computer-readable storage medium provides non-volatile storage for the computer 100. The non-volatile storage is for storing processor executable instructions 122, data structures, program modules, and other data. The basic input/output system (BIOS) 120 contains basic routines such as helping to transfer information between components in the computer system 100 during startup. The BIOS can be stored in the firmware 108. Several programs can be stored on the firmware 108, the storage device 106, the RAM 104, and/or the removable storage device 118, and these programs can be executed by the logical processor 102, which includes an operating system and/or application programs.

Commands and information can be received by the computer 100 via the input device 116, and the input device 116 can include (but is not limited to) a keyboard and a pointing device. Other input devices may include microphones, joysticks, game pads, scanners, or the like. These and other input devices are often connected to the logic processor 102 via a serial port interface that is coupled to the system bus, but these and other input devices can be connected to other interfaces, such as parallel ports, game ports Or Universal Serial Bus (USB). A display or other type of display device can also be connected to the system bus via an interface such as a video adapter, which can be part of the graphics processor 112 or connected to the graphics processor 112. In addition to the display, computers usually include other peripheral output devices (not shown), such as speakers and printers. The exemplary system of Figure 1 may also include a host adapter, a small computer system interface (SCSI) bus, and an external storage device connected to the SCSI bus.

The computer system 100 can operate in a network environment using logical connections with one or more remote computers (such as remote computers). The remote computer can be another computer, a server, a router, a network PC, a peer device, or other shared network nodes, and the remote computer can usually include many or more of the components described above with respect to the computer system 100 All components.

When the computer system 100 is used in a LAN or WAN network environment, the computer system 100 can be connected to the LAN or WAN via the network interface card 114. The NIC 114 can be an internal or external network interface card, and the NIC 114 can be connected to a system bus. In a network environment, the illustrated program modules related to the computer system 100 or part of the computer system 100 can be stored in a remote memory storage device. It should be understood that the network connection described here is exemplary, and other components that establish a communication link between computers may be used. In addition, although it is envisaged that the numerous embodiments of the present disclosure are particularly suitable for computerized systems, nothing in this document is intended to limit the present disclosure to these embodiments.

The remote desktop system is a computer system that maintains application programs, which can be remotely executed by the client computer system. The input is entered at the client computer system, and the input is sent to the terminal server via the network (for example, using a protocol based on the International Telecommunication Union (ITU) T.120 protocol family, such as the remote desktop protocol (RDP)) Application. The application processes the input as if it were entered at the terminal server. The application program generates output in response to the received input, and the output is sent to the client computer system via the network. The client computer system presents the output data. Therefore, input is received and output is presented at the client computer system, while the processing actually takes place at the terminal server. The communication period may include a window frame (shell) and a user interface such as a desktop, a subsystem that tracks mouse movement in the desktop, a subsystem that converts a mouse click icon into a command that implements an instance of the program, and so on. In another exemplary embodiment, the communication period may include an application program. In this example, although the application is presented, the desktop environment may still be generated and hidden from the user. It should be understood that the above discussion is exemplary, and the subject matter disclosed herein can be implemented in various client/server environments, and is not limited to a specific terminal service product.

In most (if not all) remote desktop environments, the input data (input at the client computer system) usually includes mouse and keyboard data that provide commands to the application, and (at the terminal server by the application The generated output data usually includes video data displayed on a video output device. Many remote desktop environments also include functionality that extends to send other types of data.

The communication channel can be used to extend the RDP protocol by allowing plug-ins to send data via the RDP connection. There are many such extensions. Features such as printer redirection, clip board redirection, communication port redirection, etc. use communication channel technology. Therefore, in addition to input data and output data, there may be many communication channels that need to transmit data. Therefore, there may be occasional requests for sending output data and one or more channel requests for sending other data competing for available network bandwidth.

Turning to Figure 3, an exemplary virtual machine server is shown, which can be used to generate virtual machines. In this embodiment, the hypervisor microkernel 302 can be configured to control and arbitrate access to the hardware of the computer system 300. The hypervisor microcore 302 can isolate processing in one partition from accessing resources in another partition. For example, the hypervisor microcore 302 can generate an execution environment called a partition (such as sub-partition 1 to sub-partition N (where N is an integer greater than 1)). In this embodiment, the sub-partition is the basic unit of isolation supported by the hypervisor micro-core 302. Each sub-partition can be mapped to a collection of hardware resources under the control of the hypervisor micro-core 302, such as memory, devices, logical processor cycles, and so on. In an embodiment, the hypervisor micro-core 302 can be an independent software product, a part of an operating system, an embedded firmware on a motherboard, a dedicated integrated circuit, or a combination of the above.

The hypervisor micro-core 302 can perform partitioning by restricting the memory window of the guest operating system to the physical computer system. When the hypervisor microcore 302 instantiates a virtual machine, the hypervisor microcore 302 can store pages of system physical memory (system physical memory; SPM) (for example, a memory with a start address and an end address). The fixed length blocks (fixed length blocks) are allocated to the virtual machine as guest physical memory (GPM) of the client. In this embodiment, the restricted window of the system memory of the client is controlled by the hypervisor microcore 302. The term "client's physical memory" is an abbreviated expression method for describing the pages of memory from the perspective of a virtual machine, and the term "system physical memory" is an abbreviated expression method for describing the pages of memory from the perspective of a physical system. Therefore, the page allocated to the memory of the virtual machine will have the physical address of the client (the address used by the virtual machine) and the physical address of the system (the actual address of the page).

The guest operating system can virtualize the physical memory of the client. Virtual memory is a management technology that allows the operating system to over commit memory and provides applications with exclusive access to continuous working memory. In a virtualized environment, the guest operating system can use one or more page tables to convert virtual locations, as we know, to convert virtual client addresses into client physical addresses. In this example, the memory address may have a client virtual address, a client physical address, and a system physical address.

In the example shown, the parent partition component can also be considered similar to the domain 0 of Xen's open source management program, and the parent partition component can include the host 304. The host 304 can be an operating system (or a collection of configuration utilities), and the host 304 can be configured to provide resources to guest operating systems that use virtualization service providers in the sub-partition 1-N (virtualization service providers; VSPs) 328 to execute. VPS 328 is usually called a back-end driver in the open source community. VPS 328 can be used by virtualized service clients (VSCs) (usually called in open source communities or paravirtualized devices). For the front-end driver), the interface is multiplexed to hardware resources. As shown in the figure, the virtualized service client executes in the context of the guest operating system. However, these drivers are different from other drivers in the client. The difference is that these drivers can have a management program instead of a client. In an exemplary embodiment, the path used to communicate with the virtualization service client 316 and 318 through the virtualization service provider 328 can be considered a virtualization path.

As shown in the figure, an emulator 334 (eg, a virtualized IDE device, a virtualized video adapter, a virtualized NIC, etc.) can be configured to operate within the host 304, and the emulator 334 is attached to which is available to the guest Resources of operating systems 330 and 322. For example, when the guest OS touches the memory location, the register mapped to the memory location to the device will be mapped to the device or the memory mapped to the location of the device. The micro core management program 302 can intercept the request and transfer the client The value you try to write is passed to the associated emulator. The resource in this example can be considered as the location of the virtual device. Using the simulator in this way can be regarded as a simulation path. The simulation path is less efficient than the virtualization path because the simulation path requires more CPU resources to simulate the device than the CPU resources required by the simulation path to transfer messages between the VSP and the VSC. For example, the hundreds of actions that need to map the memory to the register can be simplified into a single message. The single message is transferred from the VSC to the VSP in the virtualization path, and the memory needs to be mapped to the register. The purpose is to write the value to the disk via the emulation path.

Each sub-partition can include one or more virtual processors (320 and 322), and the guest operating system (320 and 322) can manage and schedule the threads to be executed on the one or more virtual processors. Generally, virtual processors are executable instructions and associated state information, and these executable instructions and associated state information provide a representation of a physical processor with a specific architecture. For example, one virtual machine may have a virtual processor with the characteristics of an Intel x86 processor, and another virtual processor may have the characteristics of a PowerPC processor. The virtual processor in this example can be mapped to the logical processor of the computer system, so that the instructions for realizing the virtual processor will be sent back by the logical processor. Therefore, in an embodiment including multiple logical processors, the virtual processors can be executed by the logical processors at the same time (for example, when other logical processors execute hypervisor instructions). The combination of virtual processor and memory in the partition can be regarded as a virtual machine.

The guest operating system (320 and 322) can be any operating system, such as from Microsoft<img file="TW201218081A_D0001.tif" />, Apple<img file="TW201218081A_D0002.tif" />, Open source community, etc. operating system. The guest operating system may include a user/core mode of operation, and the guest operating system may have a core that may include a scheduler, a memory manager, and so on. Generally speaking, the core mode may include an execution mode in a logical processor, and the execution mode of the logical processor allows access to at least privileged processor instructions. Each client operating system may have associated file systems, and the associated file systems may have applications (such as terminal servers, e-commerce servers, email servers, etc.) and client programs stored on the file systems. The operating system itself. The guest operating system can schedule threads to be executed on the virtual processor, and instances of these applications can be implemented.

Now refer to Figure 4, which shows a virtual machine server based on an alternative architecture. Figure 4 illustrates components similar to those in Figure 3; however, in this exemplary embodiment, the hypervisor 402 may include micro-core components and components similar to those in the host 304 in Figure 3, which Similar components are the virtualization service provider 328 and the device driver 324, and the management operating system 404 may include, for example, a configuration utility program for configuring the management program 402. In this architecture, the hypervisor 402 can perform the same or similar functions as the hypervisor microcore 302 in Figure 3; however, in this architecture, the hypervisor 404 can be configured to provide resources to clients executing in the sub-partitions. System. The management program 402 in FIG. 4 can be an independent software product, a part of the operating system, the embedded firmware of the motherboard, or a part of the management program 402 can be implemented by a dedicated integrated circuit.

Turning now to Figure 5, a high-level block diagram of the virtual desktop server 500 is shown. In an embodiment, the virtual desktop server 500 may be configured to deploy a virtual desktop session (VDS) to the client, for example, a mobile device such as a smart phone, which has components similar to those shown in Figure 1. Computer systems with similar components, etc. In short, virtual desktop technology allows users to remotely interact with guest operating systems running in virtual machines. Different from the remote desktop communication period, in the virtual desktop communication period, only one user logs into the guest operating system, and only one user can fully control the guest operating system. For example, the user can run as an administrator and can The client has full rights. In the example shown, the virtual desktop server 500 may have similar components to the computer system 300 in FIG. 3 or the computer system 400 in FIG. 4. In the example shown, the virtualization platform 502 is a logical abstraction of the virtualization infrastructure components described in Figures 3 and 4 above. The functionality described in the following sections as "inner" virtualization platform 502 can be implemented in one or more of the elements shown in Figure 3 or Figure 4. For example, the virtual desktop manager 530 can be implemented in the host 304 in FIG. 3. More specifically, the virtual desktop manager 530 may be implemented in a host operating system executed in the parent partition.

At the beginning of the virtual desktop communication period, the guest operating system needs to be instantiated in the virtual machine. In an exemplary embodiment, the virtual desktop manager 530 (eg, a module of processor-executable instructions) can activate the virtual machine 514 (and the guest operating system 528) in response to the request. The virtual desktop manager 530 may execute on a logical processor and instruct the virtualization platform 502 (for example, the micro-core hypervisor 202) to allocate memory for partitions. The virtualization platform 502 can be executed in the virtual machine 514, and the virtualization platform 502 can set the virtual device in the virtual machine 514, and the virtualization platform 502 can load the boot loader program into the virtual machine memory. The boot loader program can be executed on the virtual processor, and the boot loader program can be loaded into the guest operating system 528. For example, the communication period manager 508 may be loaded, which may instantiate the environment subsystem, such as the execution time subsystem 526, which may include core mode components, such as the operating system core 510. For example, the environmental subsystem in an embodiment can be configured to expose a subset of services to applications, and the environmental subsystem can provide core 520 with an access point. When the guest operating system 528 is loaded, the boot loader program can exit and transfer control of the virtual machine to the guest operating system 528. The guest operating system 528 can execute various modules shown in FIG. 5, and the guest operating system 528 configures itself to host the virtual desktop communication period. For example, the guest operating system 528 may include login values that enable the remote display engine 506 and/or the configuration service 534 to start after being started.

The virtual desktop communication period may start when the guest operating system 528 receives a connection request from the client via the network. The connection request can be processed by the remote display engine 506 first. The remote display engine 506 can be configured to listen to connection messages and forward the connection messages to the communication period manager 508. As shown in FIG. 3, when a communication period is generated, the remote display engine 506 can execute the protocol stack instance of the communication period. Generally, the protocol stack instance can be configured to route user interface output to the associated client and route user input received from the associated client to the operating system core 510. In short, the operating system core 510 can be configured to manage screen output; collect input from the keyboard, mouse, and other devices.

The user identification code (for example, the user name/passcode combination) can be received by the remote display engine 506 and transmitted to the communication period manager 508. The communication period manager 508 may pass the identity code to the login program, which may route the identity code to the authentication engine 524 for verification. The authentication engine 524 can generate a system token, and the system token can be used as long as the user tries to execute a process to determine whether the user has a security ID to execute the process or thread. For example, when a process or thread attempts to gain access (for example, open, close, delete, and/or modify an object (for example, a file, setting, or application)), the thread or thread can be authenticated by the security subsystem 522 . The security subsystem 522 can check the system token according to the access control list associated with the object and determine whether the thread has permission based on the comparison of the system token and the information in the access control list. If the security subsystem 522 determines that the thread is authorized, the thread can be allowed to access the object.

Continuing to describe FIG. 5, in an embodiment, the operating system core 510 may include a graphics display interface (GDI) 516 and an input subsystem 512. The input subsystem 512 in the exemplary embodiment may be configured to receive user input from the client via the protocol stack instance of the virtual desktop communication period and send the input to the operating system core 510. The user input may include signals indicating absolute and/or relative mouse movement commands, mouse coordinates, mouse clicks, keyboard signals, joystick movement signals, etc. in some embodiments. User input (e.g., a mouse double click on an icon) can be received by the operating system core 510, and the input subsystem 512 can be configured to determine that the icon is located at the coordinates associated with the double click. The input subsystem 512 can then be configured to send a notification to the execution time subsystem 526, which can execute the itinerary of the application associated with the icon.

Drawing commands can be received from applications and/or desktops, and these drawing commands can be processed by GDI 516. The GDI 516 can generally include a stroke that can generate a drawing command for the graphic object. The GDI 516 in this exemplary embodiment can be configured to pass commands to the remote display subsystem 518, and the remote display subsystem 518 can instantiate the display driver during the communication period. In an exemplary embodiment, the remote display subsystem 518 may be configured to include virtual display drivers, which may be configured to receive drawing commands and send the drawing commands to the client.

The configuration service 534 is also shown in Figure 5. In an exemplary embodiment, the configuration service 534 can be used to configure the guest operating system 528 to execute a virtual desktop communication period before being connected by the client. For example, the configuration service 534 may be executed within the guest operating system 528, and the configuration service 534 may be executed when the guest operating system 528 is started. Since certain configuration settings require administrative privileges, the configuration service 534 can be configured to execute as a process with system-wide privileges. Some of the exemplary actions that the configuration service 534 can take include (but are not limited to) the following actions: adding the users account identifier to the list of managed users of the guest operating system 528; adding to the list of authorized virtual desktop users Account identifier; set the login value; open the guest operating system firewall; and open the port on which the remote display engine 506 waits for (listen) connection. The configuration service 534 is described in more detail in the following paragraphs.

In an exemplary embodiment, a communication channel may be established between the virtualization platform 502 and the guest operating system 528 to configure and control the guest operating system 528. Since the remote user can fully control the virtual machine 514, appropriate security is required to ensure that any channel used to configure and control the guest operating system 528 cannot be used to attack the virtualization platform 502 or other connections to the internal network computer system. Traditionally, the network communication channel is used to configure and control the guest operating system 528. However, when the guest operating system 528 is not in the same network domain as the virtualization platform 502, the network channel is difficult to deploy, and the virtualization platform 502 is configured to reject incoming connection requests from outside the network domain.

In an exemplary embodiment, the inter-partition communication channel 504 can be used to communicate with the configuration server 534 to configure and/or manage the virtual desktop communication period. The partitioned communication channel 504 can be configured to be implicitly trusted by the virtual machine 514 rather than by the virtualization platform 502. In this example, information (eg, data and/or commands) can be easily routed to the guest operating system 528 without any verification of the information. On the other hand, the data received from the virtual machine 514 can be verified and authenticated before the virtualization platform 502 takes action. In addition, because the inter-partition communication channel 504 does not use a network connection, the guest operating system 528 may not be close to the internal network.

Because only the virtualization platform 502 can generate the inter-partition communication channel 504, the inter-partition communication channel 504 can be implicitly trusted by the virtual machine 514, that is, the information received through the channel is inherently authenticated/verified. For example, in an embodiment, the inter-partition communication channel 504 may be implemented at least in part as an area of memory shared between the virtual machine 514 and the virtualization platform 502. The virtualization platform 502 can create a data structure indicating a ring buffer or the like of a ring buffer in an area of shared memory, which can be used as a full duplex between the virtualization platform 502 and the virtual machine 514 Communication channel. In an exemplary embodiment, the inter-partition communication channel may include the features described in US Patent No. 7,689,800 entitled "Partition bus", the contents of which are fully incorporated herein by reference.

The virtualization platform 502 can write information into the inter-partition communication channel 504, and the information can be read by the virtual machine 514. In an exemplary embodiment, the inter-partition communication channel 504 may be based on information. That is, the virtualization platform 502 and the virtual machine 514 can be configured to write data packets into the inter-partition communication channel 504. In the same or another exemplary embodiment, the inter-partition communication channel 504 may be event-driven. In this configuration, when information is written to the channel, the receiver can be instructed to read the information from the inter-partition communication channel 504 by the management program 302 in FIG. 3, for example.

Turning now to Figure 6, a high-level block diagram of a data center is shown. The data center includes a virtual desktop server 500, a virtual desktop server 602, an authorization server 604, an intermediary server 608, a gateway 612, and a client 614. The data center can be configured to deploy the virtual desktop communication period to the client. In the example shown, the virtualization platform 502, the virtual desktop server 602, the authorization server 604, the intermediary server 608, and the gateway 612 may be part of the intranet, and the user ID code used to log in to these computers It can be a member of the same domain, that is, the infrastructure domain 520. The infrastructure domain 520 is illustrated with dotted lines, which divide the virtual desktop server 500 into two halves to illustrate that in an exemplary embodiment, the virtual machine 514 may be part of a different domain or not part of any domain .

The data center may include an internal network, the internal network is coupled to a plurality of virtual desktop servers (602 and 500), the plurality of virtual desktop servers may include components and intermediaries shown in Figure 3 or Figure 4 The server 608 and the authorization server 604 are similar components. As those familiar with this technology can understand, although two virtual desktop servers are shown in the figure, the data center can have more virtual desktop servers. Also, although the virtual desktop server 500 is shown as executing one virtual machine (514), each virtual desktop server can simultaneously host many virtual machines. Or in other words, the data center can have M (where M is an integer greater than 1) virtual desktop servers, and each of the M virtualized hosts can host N (where N is also an integer greater than 1) Virtual machine.

The intermediary server 608 can serve as an interface with the internal network of the client 614. In short, the intermediary server 608 may include components similar to those described in relation to FIG. 2. The intermediary server 608 may have a network adapter and another network adapter. The network adapter connects the intermediary server 608 to a public network (such as the Internet). The other network The router adapter connects the interface of the intermediary server 608 to the internal network (that is, the corporate internal network). In this example, the intermediary server 608 can act as a gateway to the internal network, thereby allowing the virtual desktop server and the authorization server 604 to not be close to the public network.

When the user of the client 614 needs the virtual desktop communication period, the user can click the icon, and the client 614 can send one or more information packets to the intermediary server 608. The intermediary server 608 may include a module of software instructions. After the module of software instructions is executed, the logical processor selects a suitable virtualization host, and a sample virtual machine is used to host the virtual desktop communication period. User ID codes (for example, a combination of user name and passcode) can be collected, and the intermediary server 608 can check the communication period database 610 to determine whether the data center includes any disconnected user ID codes (such as, The user name/passcode combination) is associated with the virtual desktop communication period. If the communication period database 610 includes a disconnected virtual desktop communication period associated with the user ID, the intermediary server 608 may send a signal to the virtualization host, which has a disconnected communication period and instructs the disconnection The virtual machine is executed during the open communication period. If the communication period database 610 does not have information indicating the user's disconnected communication period, the intermediary server 608 can select a suitable virtual desktop server, for example, a virtual desktop server that can be used for sample virtual machines to host virtual desktop communications The virtual desktop server for the resources of the period.

The virtualization platform 502 can instantiate the virtual machine 514 and execute the guest operating system 528 on the virtual processor. Referring back to Figure 5, the guest operating system 528 can execute the remote display engine 506; return the Internet protocol (IP) address of the virtual NIC 616 to the intermediary server 608; and wait for a request from the client 614 connect. The intermediary server 608 can return the IP address of the virtual NIC 616 to the client 614 in the form of an information packet, which causes the logical processor of the client 614 to redirect the client to the IP address of the virtual machine 514. The gateway 612 can receive the connection request and forward the connection request to the virtual NIC 616.

In at least one exemplary embodiment, the communication period manager 508 may be configured to check whether the client 614 is associated with a valid license before starting the virtual desktop communication period. The remote display engine 506 may receive the license (or information associated with the license) from the client 614 and send the information to the virtualization platform 502, and the virtualization platform 502 may associate the license (or associate it with the license). Information) sent to the authorization server 604. The authorization server 604 may include a license verification engine 606, which may be configured to determine whether the license associated with the client 614 is valid. If the license is valid, the license verification engine 606 can send a signal back to the virtual desktop server 500, and the virtual desktop communication period can start. At this time, the remote display engine 506 can stream one or more information packets indicating the graphical user interface of the guest operating system 528 to the client 614, and the remote display engine 506 can receive instructions from the user of the client 614 One or more information packets entered.

In an exemplary embodiment, when the virtualization platform 502 receives a request for a sample virtual machine from the intermediary server 608, the virtual desktop manager 530 can execute the command and/or information and communicate the command and/or information through the partitions. The channel 504 is sent to the virtual machine 514 so that the guest operating system 528 is configured to execute the virtual desktop communication session. The configuration service 534 can receive the commands and/or information and configure the guest operating system 528 accordingly. For example, the virtual desktop manager 530 can send the identification of the user trying to connect, the required settings of the firewall that protects the guest operating system 528, the registry value, the list of applications that the user is allowed to operate, and the command to enable the virtual desktop communication period. And add the user's identification command to the list of authorized virtual desktop users, and so on. The configuration service 534 can be executed on the virtual processor and change the appropriate settings.

Once the virtual desktop communication period is executed, the virtual desktop manager 530 can manage the running virtual desktop communication period via the inter-partition communication channel 504. For example, the virtual desktop manager 530 may issue commands to the virtual machine 514, such as a command to cause the guest operating system 528 to shut down, a command to disconnect the user, a command to reset the guest operating system 528, and so on. In the same or another embodiment, the virtual desktop manager 530 can manage the virtual desktop communication period to receive the status information of the virtual machine 514, the status information from the remote display engine 506, and/or the virtual desktop manager 530 can control the The command of the virtual desktop communication period is sent to the configuration service 534. For example, the virtual desktop manager 530 can receive the status information of the virtual machine 514, the status information indicates whether the virtual machine 514 is running, paused, ready, or started, and the virtual desktop manager 530 can receive a list of IP addresses. The list of IP addresses can be sent to the client. In addition, the virtual desktop manager 530 can receive status information of the guest operating system 528 (such as the identification of the user used to log in the virtual desktop communication period), and the virtual desktop manager 530 can communicate some or all of this information to Intermediary server 608.

Figure 7 illustrates an exemplary system in which the client has a work area, the work area includes remote communication periods, and the remote communication periods have a plurality of servers.

The computer shown in Figure 7 can be similar to the computer shown in Figure 1. In Figure 7, the client 702 communicates with the deployment 700. The deployment 700 includes an authentication server 704, a connection broker 708, a gateway 708, and a remote application server group 714 (the remote application server group 714 also includes two Two homogenously configured servers, namely remote application servers 716a and 716b) and a VM server group 710 (the VM server group 710 also includes two homogenously configured VMs, namely VMs 712a and 712b).

The client 702 has a work area, and the work area includes a plurality of remote resources, and the plurality of remote resources are provided by one or more remote application servers 716 and VM 712. The client 702 can log in to the work area of the client 702 via the authentication server 704. Once the client's request to connect to the client's work area is authenticated, the request is transmitted from the authentication server 704 to the connection broker 706. The connection broker 706 is configured to act as a connection broker between the client 702 and the application server 716 and VM 712. The application server 716 and VM 712 will provide remote resources to the client 702, and for this purpose The connection broker 706 is configured to communicate with the application server 716 and the VM 712 to determine which resources the application server 716 and the VM 712 currently provide (including the disconnected remote resources of the user of the client 702).

The client 702 may have a work area that includes a plurality of remote resources--including remote resources of a remote application from the remote application server 716a, and remote resources of a VM from the VM 712a. As shown, the client 702 does not have remote resources with a remote application server 716b or VM 712b. The remote application server 716 and the VM 712 can each provide different applications or desktops, application versions or other arrangements. For example, the remote application server 716a can provide a remote word processor application to the client 702, and the VM 712 can provide a remote desktop to the client 702.

As can be seen from this description, when a user wants to reconnect to the users workspace, the user may want to reconnect to the remote application server 716a and VM 712a via a command instead of a command executed three times The remote resource of the two. The user can perform this reconnection operation from the client 702 or from another client computer (such as the user's computer when the client 702 is at work, and the user wishes to reconnect from the computer at home on the weekend).

Figure 8 illustrates an exemplary communication flow for the client to reconnect to the remote resource in the workspace.

Figure 8 illustrates an exemplary communication process in the system, in which the client reconnects to the work area, which includes the remote communication period, and the remote communication period has a plurality of servers. This communication process can be implemented in a system (such as the computer system shown in Figure 7). That is, the remote deployment 800, the client 802, the authentication server 804, the connection broker 806, the gateway 808, the VM group 810, and the VM 812a in Fig. 8 can be compared with the remote deployment 200 and the client 202 in Fig. 7 respectively. , Authentication server 204, connection broker 206, gateway 208, VM group 210 and VM212a are similar.

The user of the client 802 has previously had a work area of the remote server group 800, which involves accessing remote resources from the VM 812a, and is now disconnected from this work area. Even before the client 802 attempts to reconnect to the deployment 800, the authentication server 804 publishes the document (via communication (1)) to the client 802. The client 802 recognizes information about the deployment 800, and the client 802 can use this information to Access the remote resources of the deployment 800. The client 802 then reconnects by sending the communication (2) to the authentication server 804. The authentication server 804 verifies the user's and/or client's identity code (such as login and passcode). When the identity code is verified, the authentication server 804 communicates with the connection broker 806 to determine which remote resources the client 802 should reconnect to when the client 802 reconnects to the client 802s work area (here, VM 812a). The authentication server 804 makes this decision by the following operations: sending communication (3) to the connection agent 806, and in response, receiving back the list of server group (here, VM group 810) in communication (4), It is used when the user terminal 802 reconnects. The information indicated in the communication (4) is transmitted by the authentication server 804 to the client 802 in the communication (5).

When the client 802 has a list of servers that have been reconnected from the authentication server 804, the client 802 re-establishes communication with each server group in their server group. As shown in Figure 8, the server group is a VM group 810. The client 802 communicates with the gateway 808 (6) to access the remote resources of these server groups. The gateway 808 handles the communication (6) and communicates with the connection agent 806 (7) to send similar information. The connecting agent 806 identifies the server group from the communication (7), and from the communication (7), the connecting agent 806 identifies the machine (VM 812a) in the group 810 that has disconnected remote resources. The connection broker 806 sends the communication (8) to the VM 812a, thereby instructing the VM 812a to reconnect the remote resource to the client 802. The VM 812a reconnects with the client 802 by the following operations: the communication (9) indicating the same information is sent to the gateway 808, and the gateway 808 sends the communication (10) indicating the same information to the client 802.

It may be understood that this figure is a simplified diagram emphasizing the present invention, and that more or fewer server groups may exist and/or be reconnected, and may be more related to the transmitted communication (for example, the result display, the communication (9) and communication (10) establish a reconnection between the VM 812a and the client 802, which may also involve the communication sent from the client 802 to the VM 812a via the gateway 808).

All these changes for implementing the virtual machines mentioned above are only exemplary implementations, and nothing in this document should be construed as limiting the present disclosure to any specific virtualization aspect.

<b>Succession product launch</b>

Software anti-piracy solutions usually operate by linking software licenses to individual computer hardware. The link is performed by creating a hardware ID or fingerprint for the computer. Since the hardware is virtualized, virtualization makes these solutions unreliable. The fingerprint can be edited or copied, so the fingerprint can be used to copy or steal software. For example, snapshots of hardware configuration files used to launch software applications can be copied and used to illegally authorize additional copies. In addition, typical server virtualization scenarios move virtual machines from one host to another as needed. This can interrupt the software licensing solution linked to the hardware fingerprint.

This article discloses a method and system in which the inherited activation mechanism can be used to open a secure communication path from the host operating system (OS) to the guest OS. The license status of the software on the host can be transmitted through this channel, and the software installed in the client can use this information to notify the software of its own product activation process. When the license requirements of the host are met, the virtualized (client) software can be subsequently activated without any external communication. This mechanism can be used to exchange startup information in a trusted manner between endpoints in a virtualized environment.

In general, activation can represent a technology that changes the functionality of software based on proof of purchase or some other event or action. In an embodiment, the inherited activation mechanism can open a secure communication path from the host OS to one or more virtual machines. The license information includes the SKU, license status, and other data of the software installed on the host. The license information can be transmitted through this channel, and the client can use this data to notify the client of its own product activation process. For example, when the OS installed in the client is permitted by the installed license, the OS can be started without any external communication or user interaction when it receives the proof that the host OS has been started. In addition, by inheriting the activation state of the host OS, as long as the host system is properly activated, the guest OS can remain activated even when moving between hosts.

Such inheritance activation mechanism can provide benefits to hosting providers and cloud computing providers, for example. Using the inherited activation mechanism, the physical host computer can use any regional infrastructure or other methods for product activation. Virtual clients running on these hosts can inherit the activation data, but these virtual clients will not need any visibility or access to the activation infrastructure used by these hosts. Sensitive information (such as product keys) does not need to be shared, and customer assets can be protected.

In one embodiment, the host OS can be configured to support the inherited activation mechanism. The host OS can collect or maintain license data for the OS itself and for any solution aware software. This data can be protected by the host OS, and this data can be used to execute the client environment via the virtualization engine. This communication can be implemented as a query from the client and a response from the host. However, the inheritance activation mechanism is not limited to this communication model. The inheritance activation mechanism can also support license data. The license data is pushed (without request) from the host to the client. The data is displayed as readable for wireless communication (ad hoc) access and other communication models. Get the table or other data storage. The host can also use the inherited activation communication channel to transmit policy information to the virtual machine.

The inherited activation mechanism is not limited to the activation of software applications in virtual machines. This mechanism can usually be used to start a virtual instance of a software application, regardless of whether the application is running in the context of a client virtual machine partition. For example, the web server can host the virtualized communication period of the application X. Application X can also be installed locally and properly activated. When the virtualized instance of the application X is generated by inheriting the license status of the application X on the host, the virtualized instance of the application X will remain activated.

When the data being communicated can be protected to become trustworthy, the inheritance activation mechanism does not require specific authentication or encryption methods. Although a secure method (such as PKI or one-way hash) can be used for the communication path for exchanging activation information, any mechanism can be used as long as the activation information is sufficiently trustworthy for the needs of the software publisher. In some embodiments, if the application publisher does not need a security mechanism, the communication path may not use a security mechanism. The security of the communication path can be a design decision based on the needs of the application and the application publisher.

As described above, the virtualization engine is software on the host OS, and the virtual environment is executed in the host OS. In one embodiment, the virtual engine can provide a secure channel for communication between the host OS and any execution client environment. Within the client environment, the guest OS can be configured to support the inherited startup functionality of the virtualization engine. This guest OS can be configured to support any software that supports inherited activation, allowing access to activation information via the virtualization engine. The software that supports inherited activation can include the OS itself and other applications.

For software (including OS and other applications) that support inherited activation on the host, specific data about the license can be collected. The publisher of the software can decide what data to collect, how to store and protect the data, and how to receive and evaluate the data on the client.

Examples of data that can be collected may include:

Software identifier (model or SKU ID, application ID, etc.)

serial number

Version label

License status

Value from the host license (such as policies, restrictions, licenses, etc.)

Data from active clients can be collected, such as

Installed software information (SKU information, license status, etc.)

Number of clients

The stock-keeping unit (SKU) is a unique identifier used for any different products or services that can be tracked.

In a typical software activation scenario, the information can be collected and compared with the rule set embedded in the XrML license or other trusted documents. These rule sets establish conditions that prove whether the software is properly licensed. Traditionally, these conditions may include (but are not limited to) product keys, connection with trusted hosts, ownership of secret information, physical connection with cryptographic devices, and so on. By introducing the system to execute in a virtual machine (client) and there are requirements to meet specific conditions of authorization requirements, the inheritance activation mechanism can be added to the scope of these rules. When these conditions are met, the software can be started.

Events such as software start, system startup, login event, or timer can all start the process. To prevent theft, the startup can be updated frequently. The frequency, duration and trigger used for any activation or restart can be determined by the software publisher.

In one embodiment, the activation information may include the storage period of the inherited activation. For example, the information may include a time and date stamp that establishes the expiration for activation. By using this expiration, due to time-limited activation, unauthorized copies of activation information will have restricted utilities. A virtual machine activated with a trusted inheritance can continue to receive updated storage period information through a secure channel. Therefore, as long as the virtual machine is authorized to continue to use the activation software, the virtual machine can continue to use the activation software.

In an embodiment, the host can use asset management exchange information. For example, the host can collect SKU data from a virtual machine, and the host uses the information to track the number of users of an application or service. This information can be used to manage and limit the total number of activations.

In an illustrative example of the inherited activation mechanism shown in FIG. 9, the virtual machine host 900 can implement a virtual service provider (VSP) 925 and a worker schedule 935 for each virtual machine client instance. The VSP 925 can use the VMBus infrastructure 920 to provide a connection with the virtual machine client after it is started. The VMBus infrastructure 920 may expose API settings to allow communication between the root partition and the virtual machine client. The host VSP 925 can wait for the virtual machine client 910 to connect, and after the connection, the host VSP 925 can use the VMbus pipe/handle 920 to write data to the virtual machine client 910 and read from the virtual machine client 910 material. The VSP 925 does not interpret the security data read from the virtual machine client 910, but the VSP 925 relays this data to the authorized application 940 running on the host. Based on the information read from the virtual machine client 910 and the authorization status on the host machine, the host authorization service creates a secure authorization status packet returned to the VSP 925. The VSP 925 writes this data back to the virtual machine client 910 via the VMBus pipeline 920.

The client virtual component that inherits the activation mechanism can be managed in the instance of the authorized application on the virtual machine client. The client component uses the VMBus infrastructure to enumerate connections with a host that matches a certain standard. This standard allows the VMBus infrastructure to find and open the connection with the host VSP. This connection is exposed to the application in the client virtual machine as a composite device. By using the API, data can be read from and written to the host via the synthetic device to exchange information related to authorization. The license application running on the client virtual machine uses the authorization status packet to determine whether the client virtual machine is properly authorized, and the license application indirectly obtains the authorization status packet through the host VSP.

In one embodiment, the inherited activation mechanism can be nested within the virtual machine architecture. For example, the host virtual machine can send inherited activation information to the client virtual machine. The client virtual machine can generate one or more additional virtual machines, each of the one or more additional virtual machines can inherit the startup information, and so on. In other embodiments, the inherited activation mechanism can be configured to operate with only one host, so as not to allow activation of the nest of information.

The principles disclosed herein are not limited to the above-described embodiments. The inherited startup need not be limited to the client virtual machine. The inherited startup can be used to start the second virtualized instance of the startup product.

FIG. 10 illustrates an exemplary operating procedure for starting a software product in a virtualized computing environment. The exemplary operating procedure includes operations 1000, 1002, 1004, and 1006. Referring to Figure 10, operation 1000 starts the operating procedure, and operation 1002 illustrates a first example of starting a software product on a first parent partition in a virtualized computing environment, wherein the starting step is based at least in part on the first parent partition The information exported on the configuration. Operation 1004 icon to retrieve the information. Operation 1006 icon uses the information to activate the second instance of the software product.

Figure 11 illustrates an exemplary system and operating procedures for launching software products in a virtualized computing environment. Referring to FIG. 11, the system 1100 includes a process 1111 and a memory 1120. The memory 1120 further includes computer instructions that are configured to launch software products in a virtualized computing environment. Block 1122 illustrates the first instance of activating the software product on the host virtual machine. The block 1124 icon generates information indicating that the software product has been activated on the host virtual machine. Block 1126 illustrates the use of this information to activate the second instance of the software product.

Any of the above-mentioned aspects can be implemented in a method, a system, a computer readable medium, or any type of manufacturing. For example, a computer-readable storage medium can store computer-executable instructions on the storage medium, and the computer-executable instructions are used to launch software products in a virtualized computing environment. These media may include: a first subset of instructions for launching a first software product on a first parent partition in a virtualized computing environment, wherein the launching is based at least in part on the first parent partition in the virtualized computing environment The information derived from the configuration of a parent partition; the second subset of the command, the second subset of the command is used to retrieve the information; and the third subset of the command, the third subset of the command is used to use the Information to activate the second software product in the child partition of the first parent partition. Those familiar with the art will understand that the additional set of commands can be used to capture various other aspects disclosed in this document, and the subset of commands currently disclosed according to the present disclosure may differ in detail.

The foregoing detailed description has illustrated various embodiments of the system and/or process with examples and/or operation diagrams. In the case where these block diagrams and/or examples contain one or more functions and/or operations, those familiar with the art will understand that each function and/or operation in these block diagrams or examples can be implemented by various hardware , Software, firmware or actually any combination of hardware, software, and firmware to be implemented individually and/or collectively.

It should be understood that the various technologies described herein can be implemented in combination with hardware or software, or a combination of hardware and software under appropriate circumstances. Therefore, the method and equipment of the present disclosure or certain aspects or parts of the present disclosure may take the form of code (ie, instructions) implemented in tangible media, such as floppy disks and CD-ROMs. , A hard drive or any other machine-readable storage medium, wherein when the program code is loaded into a machine such as a computer and executed by the machine, the machine becomes a device for practicing the present disclosure. When the code is executed on a programmable computer, the computing device usually includes a processor, a storage medium that can be read by the processor (including volatile memory and non-volatile memory and/or storage elements), and at least one input Device and at least one output device. For example, through the use of an application programming interface (API), reusable controls, or the like, one or more programs can implement or utilize the process described in conjunction with this disclosure. These programs are better implemented in high-level programming languages or object-oriented programming languages to communicate with computer systems. However, the program can be implemented in assembly language or machine language when needed. In any case, the language can be a compiled language or an interpreted language, and the language can be combined with hardware implementations.

Although the present invention has been described with reference to the specific illustrations of the preferred embodiments of the present invention, those skilled in the art will understand that various operations can be carried out without departing from the scope of the present invention set forth in the scope of the following patent applications. Changes in form and details. In addition, although the elements of the present invention may be described or claimed in the singular form, unless the restriction on the singular form is clearly stated, a plural form is contemplated.

<p>20. . . computer</p><p>twenty one. . . Processing unit</p><p>twenty two. . . System memory</p><p>twenty three. . . System bus</p><p>twenty four. . . Read-only memory</p><p>25. . . Random access memory</p><p>26. . . Basic Input/Output System</p><p>27. . . Hard drive</p><p>28. . . Disk Drive/Floppy Drive</p><p>29. . . Removable Disk/Removable Storage</p><p>30. . . Optical disc drive</p><p>31. . . Removable disc</p><p>32. . . Hard Disk Drive Interface</p><p>33. . . Drive interface</p><p>34. . . Optical driver interface</p><p>35. . . System</p><p>36. . . application</p><p>37. . . Other program modules</p><p>38. . . Program data</p><p>40. . . keyboard</p><p>42. . . Pointing device/mouse</p><p>46. . . Serial port interface</p><p>47. . . monitor</p><p>48. . . Video adapter</p><p>49. . . Remote computer</p><p>50. . . Memory storage device/floppy drive</p><p>51. . . Local area network</p><p>52. . . Wide area network</p><p>53. . . Network interface/adapter</p><p>54. . . Modem</p><p>55. . . Host adapter</p><p>56. . . Small computer system interface bus</p><p>62. . . Storage device</p><p>100. . . Computing System/Computer System/Computer</p><p>102. . . Logical processor</p><p>104. . . Random access memory</p><p>106. . . Storage device</p><p>108. . . firmware</p><p>110. . . Computer readable storage media</p><p>112. . . Graphics processor</p><p>114. . . Network interface card</p><p>116. . . Input device</p><p>118. . . Removable storage device</p><p>120. . . Basic Input/Output System</p><p>122. . . Processor executable instructions</p><p>300. . . computer system</p><p>302. . . Hypervisor microkernel</p><p>304. . . Host</p><p>316. . . Virtualization service client</p><p>318. . . Virtualization service client</p><p>320. . . Guest operating system</p><p>322. . . Guest operating system</p><p>324. . . Device driver</p><p>328. . . Virtualization service provider</p><p>330. . . Virtual processor</p><p>332. . . Virtual processor</p><p>334. . . Emulator</p><p>400. . . computer system</p><p>402. . . Management procedures</p><p>404. . . Management operating system/management program</p><p>500. . . Virtual desktop server</p><p>502. . . Virtualization platform</p><p>504. . . Inter-zone communication channel</p><p>506. . . Remote display engine</p><p>508. . . Communication period manager</p><p>510. . . Operating system core</p><p>512. . . Input subsystem</p><p>514. . . Virtual machine</p><p>516. . . Graphical display interface</p><p>518. . . Remote display subsystem</p><p>520. . . Core/Infrastructure Field</p><p>522. . . Security subsystem</p><p>524. . . Authentication engine</p><p>526. . . Execution time subsystem</p><p>528. . . Guest operating system</p><p>530. . . Virtual Desktop Manager</p><p>534. . . Configuration service</p><p>602. . . Virtual desktop server</p><p>604. . . License server</p><p>606. . . License verification engine</p><p>608. . . Intermediary server</p><p>610. . . Correspondence database</p><p>612. . . Gateway</p><p>614. . . user terminal</p><p>616. . . Virtual NIC</p><p>700. . . deploy</p><p>702. . . user terminal</p><p>704. . . Authentication server</p><p>706. . . Connection broker</p><p>708. . . Gateway</p><p>710. . . VM server group</p><p>712a. . . VM</p><p>712b. . . VM</p><p>714. . . Remote application server group</p><p>716a. . . Remote application server</p><p>716b. . . Remote application server</p><p>800. . . Remote deployment</p><p>802. . . user terminal</p><p>804. . . Authentication server</p><p>806. . . Connection broker</p><p>808. . . Gateway</p><p>810. . . VM group</p><p>812a. . . VM</p><p>900. . . Virtual machine host</p><p>910. . . Virtual machine client</p><p>920. . . VMbus pipeline/processing/VMBus infrastructure</p><p>925. . . Virtual service provider</p><p>935. . . Worker itinerary (process)</p><p>940. . . Authorized application</p><p>1000. . . operate</p><p>1002. . . operate</p><p>1004. . . operate</p><p>1006. . . operate</p><p>1100. . . system</p><p>1110. . . processor</p><p>1120. . . Memory</p><p>1122. . . Cube</p><p>1124. . . Cube</p><p>1126. . . Cube</p>

Figures 1 and 2 illustrate exemplary computer systems in which aspects of the present disclosure can be implemented.

Figure 3 illustrates a working environment for practicing the aspect of this disclosure.

Figure 4 illustrates a working environment for practicing the aspect of this disclosure.

Figure 5 illustrates a computer system, which includes a circuit system for implementing remote desktop services.

Figure 6 illustrates a working environment for practicing the aspect of this disclosure.

Figure 7 illustrates a working environment for practicing the aspect of this disclosure.

Figure 8 illustrates a working environment for practicing the aspect of this disclosure.

Figure 9 illustrates an exemplary operating procedure for practicing the aspect of the present disclosure.

Figure 10 illustrates an exemplary operating procedure for practicing the aspect of the present disclosure.

Figure 11 illustrates an exemplary system and operating procedure used to practice the aspect of the present disclosure.