A computer implemented method for processing virtualization of physical computers that are part of a group into virtual computers is provided. The method includes obtaining relationship data from the physical computers, where the relationship data identifies parameters used to communicate within the group. Then, the method analyzes utilization parameters for each of the physical computers of the group. A visual model for proposed virtualization of the group of physical computers is then generated. The visual model identifies hosting machines designated to define a virtual computer for each of the physical computers, where the visual model provides a graphical illustration of the group of physical computers once converted to virtual computers. The method enables adjustment of the proposed virtualization of the group of physical computers. Then, an execution sequence of virtualization operations to be carried out is generated, if execution of the proposed virtualization is triggered, and the execution sequence is saved to storage and accessed upon execution.
|
1. A method comprising:
receiving a request to virtualize a plurality of physical computers into virtual computers;
accessing a script that defines an execution sequence of virtualization operations to be executed in order to virtualize each of the plurality of physical computers into the virtual computers at a point in time, the sequence of operations being based on: a) relationship data for the plurality of physical computers, the relationship data identifying parameters that define communication information needed to communicate between the plurality of physical computers and maintain interrelationships that existed between the plurality of physical computers when virtualizing the physical computers into the virtual computers, and b) each hosting machine designated to define the virtual computers for each of the plurality of physical computers; and
virtualizing the plurality of physical computers into the virtual computers at the point in time by executing the execution sequence of virtualization.
8. A system comprising:
a plurality of physical computers;
a memory; and
a processor programmed to:
receive a request to virtualize the plurality of physical computers into virtual computers;
access a script from the memory, the script defining an execution sequence of virtualization operations to be executed in order to virtualize each of the plurality of physical computers into the virtual computers at a point in time, the sequence of operations being based on: a) relationship data for the plurality of physical computers, the relationship data identifying parameters that define communication information needed to communicate between the plurality of physical computers and maintain interrelationships that existed between the plurality of physical computers when virtualizing the physical computers into the virtual computers, and b) each hosting machine designated to define the virtual computers for each of the plurality of physical computers; and
virtualize the plurality of physical computers into the virtual computers at the point in time by executing the execution sequence of virtualization operations.
15. A non-transitory computer readable medium comprising computer-executable instructions that, when executed by a processor, cause the processor to:
receive a request to virtualize the plurality of physical computers into virtual computers;
access a script from the memory, the script defining an execution sequence of virtualization operations to be executed in order to virtualize each of the plurality of physical computers into the virtual computers at a point in time, the sequence of operations being based on: a) relationship data for the plurality of physical computers, the relationship data identifying parameters that define communication information needed to communicate between the plurality of physical computers and maintain interrelationships that existed between the plurality of physical computers when virtualizing the physical computers into the virtual computers, and b) each hosting machine designated to define the virtual computers for each of the plurality of physical computers; and
virtualize the plurality of physical computers into the virtual computers at the point in time by executing the execution sequence of virtualization operations.
2. The method of
3. The method of
receiving, from a user, additional virtualization operations to be executed;
modifying the execution sequence of virtualization operations based on the additional virtualization operations; and
virtualizing the plurality of physical computers into the virtual computers by executing the modified execution sequence of virtualization operations.
4. The method of
5. The method of
comparing the relationship data for the plurality of physical computers with relationship data for the virtualized plurality of the physical computers; and
adjusting parameters of the virtualized plurality of the physical computers based on the comparing.
6. The method of
accessing a second script that defines a second execution sequence of virtualization operations to be executed in order to virtualize a second plurality of physical computers into a second set of virtual computers, the sequence of operations being based on: a) relationship data for the second plurality of physical computers, the relationship data identifying parameters that define communication information needed to communicate between the plurality of physical computers and the second plurality of physical computers, and b) each hosting machine designated to define the second set of virtual computers for each of the second plurality of physical computers; and
virtualizing the second plurality of physical computers into the second set of virtual computers by executing the second execution sequence of virtualization operations.
7. The method of
determining which of the script and the second script is executed first based on relationship data between the plurality of physical computers and the second plurality of physical computers; and
virtualizing the plurality of physical computers and the second plurality of physical computers based on the determining.
9. The system of
10. The system of
receive, from a user, additional virtualization operations to be executed;
modify the execution sequence of virtualization operations based on the additional virtualization operations; and
virtualize the plurality of physical computers into the virtual computers by executing the modified execution sequence of virtualization operations.
11. The system of
12. The system of
compare the relationship data for the plurality of physical computers with relationship data for the virtualized plurality of the physical computers; and
adjust parameters of the virtualized plurality of the physical computers based on the comparing.
13. The system of
access a second script from the memory, the second script defining a second execution sequence of virtualization operations to be executed in order to virtualize the second plurality of physical computers into a second set of virtual computers, the sequence of operations being based on: a) relationship data for the second plurality of the physical computers, the relationship data identifying parameters that define communication information needed to communicate between the plurality of physical computers and the second plurality of physical computers, and b) each hosting machine designated to define the second set of virtual computers for each of the second plurality of physical computers; and
virtualize the second plurality of physical computers into the second set of virtual computers by executing the second execution sequence of virtualization operations.
14. The system of
determining which of the script and the second script is executed first based on relationship data between the plurality of physical computers and the second plurality of physical computers; and
virtualizing the plurality of physical computers and the second plurality of physical computers based on the determining.
16. The non-transitory computer-readable medium of
17. The non-transitory computer-readable medium of
receive, from a user, additional virtualization operations to be executed;
modify the execution sequence of virtualization operations based on the additional virtualization operations; and
virtualize the plurality of physical computers into the virtual computers by executing the modified execution sequence of virtualization operations.
18. The non-transitory computer-readable medium of
19. The non-transitory computer-readable medium of
compare the relationship data for the plurality of physical computers with relationship data for the virtualized plurality of the physical computers; and
adjust parameters of the virtualized plurality of the physical computers based on the comparing.
20. The non-transitory computer-readable medium of
access a second script from the memory, the second script defining a second execution sequence of virtualization operations to be executed in order to virtualize a second plurality of physical computers into a second set of virtual computers, the sequence of operations being based on: a) relationship data for the second plurality of physical computers, the relationship data identifying parameters that define communication information needed to communicate between the plurality of physical computers and the second plurality of physical computers, and b) each hosting machine designated to define the second set of virtual computers for each of the second plurality of physical computers; and
virtualize the second plurality of physical computers into the second set of virtual computers by executing the second execution sequence of virtualization operations.
|
|||||||||||||||||||||||||||
This application is a continuation of U.S. application Ser. No. 12/256,198, filed Oct. 22, 2008, which is incorporated by reference herein.
The computing industry has seen many advances in recent years, and such advances have produced a multitude of products and services. Computing systems have also seen many changes, including their virtualization. Virtualization of computer resources generally connotes the abstraction of computer hardware, which essentially separates operating systems and applications from direct correlation to specific hardware. Hardware is therefore abstracted to enable multiple operating systems and applications to access parts of the hardware, defining a seamless virtual machine. The result of virtualization is that hardware is more efficiently utilized and leveraged.
The advent of virtualization has sparked a number of technologies, which allow companies to optimize the utilization of their systems. As a company's enterprise systems are usually installed at various geographic locations, networking protocols are used to interconnect the various systems, which can then be virtualized into one or more virtual servers.
With the recent proliferation of virtual systems and servers, proper deployment practices have become increasingly important. Although vitalizing individual systems has become increasingly simplified with the use of special software programs and tools, this simplification has introduced laborious complexities set-up and configuration of grouped computer systems, enterprise systems, and the like. These complexities arise primarily based on the need to keep system interrelationships intact after virtualization of tens, hundreds or thousands of computers. As managed group systems depend on the processes and/or data produced or generated by other systems of the group, conventional virtualization schemes that virtualize one computer system at a time tends to be time consuming, and prone to errors. Although it is envisioned that care can be taken to account for the interrelationships between the managed systems of a group, these relationships sometimes are dependent on multiple conditions. Unfortunately, the conventional manner of virtualization currently requires virtualization of one computer at a time.
In view of the foregoing, there is a need for methods, systems and computer implemented processes that enable automated virtualization processes for groups of computers, while ensuring that existing interrelationships are maintained or updated.
In one embodiment, a computer implemented method for processing virtualization of physical computers that are part of a group into virtual computers is provided. The method includes obtaining relationship data from the physical computers, where the relationship data identifies parameters used to communicate within the group. Then, the method analyzes utilization parameters for each of the physical computers of the group. A visual model for proposed virtualization of the group of physical computers is then generated. The visual model identifies hosting machines designated to define a virtual computer for each of the physical computers, where the visual model provides a graphical illustration of the group of physical computers once converted to virtual computers. The method enables adjustment of the proposed virtualization of the group of physical computers. Then, an execution sequence of virtualization operations to be carried out is generated, if execution of the proposed virtualization plan is triggered, and the execution sequence is saved to storage and accessed upon execution.
In another embodiment, a computer implemented method for visualizing a model of a virtualized data center is provided. The data center has a group of physical computers designated for virtualization. The method includes obtaining relationship data from the physical computers, where the relationship data defines parameters used to enable communication among the group of physical computers of the data center. The method then builds a visual model for display on a screen, where the visual model is for a proposed virtualization of the group of physical computers of the data center. The visual model identifies hosting machines designated to host a virtual computer for a particular one of the physical computers. The visual model is graphically interactive to enable modification of the proposed virtualization. The method further generates an execution sequence of virtualization operations to be carried out if execution of the proposed virtualization is triggered, where the execution sequence is saved to memory and accessed upon execution.
The invention may best be understood by reference to the following description taken in conjunction with the accompanying drawings.
In this example, each of the computer systems are part of a physical computer system environment, where actual computers or servers are processing instructions and acting in cooperation with other computers that have been assigned other tasks. For example, arrows illustrate a plurality of communication interfaces that define relationships 102a-102h. Each of the relationships 102 can include a number of parameters that define the communication information required to interactively communicate, share data, update application states, etc. In one embodiment, each computer could have a specific IP address assigned to that particular computer in the multi-tiered application environment. The IP address can either be static or dynamically assigned using Dynamic Host Configuration Protocol (DHCP).
Other communication information can include software credentials needed to access the various computers or communication between the various computers that require either passwords, codes, or keys. For instance, some computers may implement firewalls, log-on procedures, and other security configurations designed to safeguard the information being processed by the multi-tiered application 100. Any one or more of this information can be broadly construed as relationships 102, which are part of a computer or shared between the various physical hardware machines that make up the multi-tiered application 100.
These relationships in turn, are defined by specific parameters that must be programmed into each of the computers, or devices communicating with particular computers and databases. For completeness, that multi-tiered application 100 and its various physical computers will now be described, to illustrate the physical relationships as well as the logical relationships between the computers that define the multi-tiered application 100. In this example, a load balancer is provided that communicates with front end application server (FA1), as well as the front end application server (FA2). As illustrated, the front end application servers FA1 and FA2 each communicate with a database server (FD). The front end application server FA1 in turn, communicates with the back end application server (BA2).
In a similar manner, the front end application server FA2 communicates with the back end application server (BA1). Back end application server BA1, as well as back end application server BA2, communicate with database server (DB), by way of relationships 102g and 102h. In this multi-tiered application 100, the load balancer is designed to communicate with redundant front end and back end servers, so as to enhance the operation and capacity of the system, as well as to provide fail-over.
The multi-tiered application 100 of
Virtualization of physical hardware is a desired conversion for a multitude of reasons. Virtualization of hardware enables for simplified deployment of new virtual systems, as well as simplicity in management and utilization of hardware resources. As a result, multi-tiered applications 100 and their associated hardware are commonly being virtualized using virtualization tools. These virtualization tools will act upon a single piece of hardware at a time in order to convert and create a virtual machine from a defined physical machine. As mentioned above, virtualization of machines has become simpler as tools are provided to enable users to examine and convert the physical systems into virtual systems. The noted drawback is that physical systems are generally converted to virtual systems one at a time. Consequently, the relationships between other physical computers in a system are ignored or are not considered important when virtualization of a particular physical computer is performed. The result is that each of the physical computers are virtualized to create virtual machines that are assigned to host computer machines. The host computer machines act as a server machine, and the server machine can host one or more virtual machine that result from specific virtualizations of specific physical computers.
The resulting (one-by-one) virtualization will therefore lose the relationships 102 created when the multi-tiered application 100 was created. Thus, substantial time and effort is required to then reconfigure each of the virtual machines that are created from the various physical machines that were individually virtualized. Although the illustration of
In one embodiment, the process will include information gathering that entails a process for obtaining relationships, configuration parameters, credential information, and interdependencies from the physical systems that are to be virtualized. At this point, the gathering of information can be done in an automated manner by querying the physical systems for information regarding their relationships, credentials, and other information.
In one embodiment, automated requests can be made to the physical systems if the physical systems have the software capable of returning information regarding their relationships, parameters and credentials. In one embodiment, an automated technique we use a common information model (CIM) request that is processed by the physical systems and then gathered in an automated manner. Broadly, a CIM architectures includes clients and servers.
A server can respond to CIM requests from a client. This request can be used to obtain all of the information about the physical system, its relationships with other systems of a group and all associated parameters. Thus, CIM clients communicate with managed systems (e.g., CIM servers), which operate with a common information model object manager (CIMOM). A CIMOM includes a repository for storing schemas that are defined by one more classes. The CIM Schema supplies a set of classes with properties and associations that provide a framework within which it is possible to organize the available information about the managed environment. The CIM Schema is therefore a combination of the Core and Common Models. CIM management information has a specific format to enable the exchange information. The CIM Specification defines a language based on the Interface Definition Language (IDL) called Managed Object Format (MOF). The MOF syntax is a way to describe object definitions in textual form, and it establishes the syntax for writing definitions.
The CIM is a hierarchical, object oriented architecture that makes it easy to track and depict the often complex interdependencies and associations among different managed objects. Such interdependencies may include those between logical network connections and underlying physical devices, or those of an e-commerce transaction and the web and database servers on which it depends. The CIM is therefore an information model of a conceptual view of the managed environment, that attempts to unify and extend the existing instrumentation and management standards (SNMP, DMI, CMIP, etc.) using object-oriented constructs and design. The CIMOM is responsible for responding to client requests over the network, and either responding to them directly (typically for class level operations) or forwarding the request to one or more Providers.
Information gathering can also include a query sent to a system administrator to identify information that was not possible to obtain in an automated request, or information that the system administrator would like to preserve, change or modify during the information gathering operation. It is envisioned that the system administrator can be provided with a graphical user interface that identifies each of the various physical computers and the various parameters. The various parameters of the various computers are then provided to the system administrator in a GUI, table, graph, folder, file system, or other representation to enable the system administrator to easily and accurately confirm, modify, or adjust the various pieces of information gathered at the initial stage.
Once the information has been gathered, an analysis operation is performed on the gathered information. The analysis will include identification of utilization requirements for each of the physical computers that will be virtualized and then assigned to a host machine. In one embodiment, the host machine can be an ESX host machine, which is available from VMware, Inc., of Palo Alto, Calif. As each host machine is only capable of servicing a particular number of virtual machines that result from the physical machines, it is important to identify the utilization requirements of each of the physical machines before they are assigned to the various host machines (ESX servers).
In one embodiment, the utilization can be performed using a capacity planner program that identifies the capacity required for the various applications running on the resulting virtual machines. In still another embodiment, the utilization can be obtained from historical data of use or operations performed by the programs running on the physical machines. The historical data can then be used to plan and assess which virtual machines will be assigned to particular ESX servers.
Now that the information gathering and the analysis operations are performed, a modeling operation will be performed automatically by the process in accordance with one embodiment of the present invention. In one embodiment, a visual model is provided and presented to a system administrator or user in response to completing the information and analysis steps. In the model, a proposed virtualization configuration is presented which will fit the capabilities of the physical servers. For example, if the physical server has two network interface cards (NICs), the corresponding virtual machine (VM) will have two virtual NICs. Accordingly, each of the virtualized machines will be constructed so as to mirror the capabilities of the physical machines that were virtualized in order for the model to maintain the relationships that existed between the physical machines.
The virtual model 110 also enables the user to select different virtual machines that are assigned to the hosting machines and drag and drop them to the various hosting machines, make new hosting machines, etc., depending on the desired resulting virtualization. Although the proposed virtualization has been constructed based on the gathered information and the utilization analysis, the user or system administrator may know that a different configuration or assignment of a virtual machine to a given hosting machine is preferred over a proposed configuration. As a result, the ability to drag, drop, move and re-set the visual model 110 provides additional flexibility to the user to achieve the desired virtualization while maintaining the set relationships.
In the illustrated visual model 110, ESX1 is shown hosting FA1 and BA1. ESX2 is shown hosting FA2 and BA2. ESX3 is shown hosting LB, FD, and BD. The moving of LB 108 is shown using a drag and drop operation that allows LB to be moved from ESX3 to ESX1. If LB is moved to ESX1, the visual model 110 will also be adjusted so that the relationships are maintained, updated, and the utilization parameters are re-adjusted. If utilization parameters indicate that the drag and drop operation exceeds a threshold load for a given ESX, a warning would be given through the visual model user interface.
For example, FA1 & FA2 may have been grouped on same ESX server but the system admin may wants them on separate servers to plan for any possible ESX Server/Hardware failure. Also, proposed VM capabilities can be adjusted in the model, e.g., number of vNICs, number of CPUs, CPU capacity, memory, etc.
Additional suggestions or recommendations may also be provided to the user in response to an inappropriate or non-recommended drag and drop of the particular virtual machine from one hosting machine to another, or other change. Still further, the visual model can also allow user to add additional hosting machines if the load requirements are anticipated to increase or change, as known by the system administrator or user that is viewing the virtual model, before the virtualization occurs.
Based on the defined plan, operation 152 shows a proposal for script 1 that will, among other things, collect configuration information, prepare the computers for virtualization (e.g., shutdown certain critical applications, take the computers out of the load balancer, etc.) and trigger virtualization of BA1 followed by the virtualization of FA1. Referring to
The method would then move to operation 154 where a proposed script 2 would enable the virtualization of BA2 and then FA2, followed by the virtualization of BD, FD, and LB. During the virtualization of the databases, it may not be possible to continue un-interrupted operations of the multi-tiered application 100 if the databases are required or critical to the servicing of those process applications or services. If the databases are not required during the virtualization of FA2 and BA2 in operation 154, then it is possible to continue with un-interrupted operation of the multi-tiered application 100.
The defined plan 150, however, is only a proposed virtualization sequence. The proposed virtualization sequence is also displayed to the user through a graphical user interface to illustrate the operations that will be performed during the virtualization. It is possible that the user or system administrator will know of or require an additional step, script, or modification to the defined plan. If such modification is desired, the operations move from 158 to 160 where changes in the scripts are made to modify the plan. Although scripts are specifically identified, it is possible to have other process operations that are not scripts (e.g., algorithms, flows, methods, etc.), which can be modified in accordance with the user's requirements. Once the plan has been defined, the user can save the plan in operation 162. The plan is preferably save to memory, and can be recalled when the virtualization operations take place.
In one embodiment, the user can use a mouse clicker or pointer 204 to click on the virtual machines in the virtual model itself. When the user clicks on FA1 using pointer 204, section 206 of the graphical user interface 200 will illustrate the properties of the selected virtual machine FA1. If other VMs are clicked, section 206 will change accordingly. In this example, FA1 is the front end application server, which has a plurality of properties. For ease of illustration, only a few sample properties are shown, but pointer 204 may be used to move a slider in the graphical user interface window that shows the additional properties of the particular virtual machine. Thus, the host in this example is ESX1, representing the hosting machine for FA1. The host name will be a virtual FA1 (vFA1). The network address will be assigned by DHCP. The original settings are also provided under the notation “old.”
As mentioned above, the properties 206 of FA1 are only presented for example, and other information will also be provided, such as hardware configuration information of the original physical machine, and the resulting configuration for the new machine. Certain physical configurations may include the media access controller (MAC), that define the machine number assigned to the physical machine. The MAC number is also referred to as the MAC address, and each computer system is universally assigned a particular number that is unique. As a result, the new MAC address for the virtual machine cannot be identical to the original machine. However, the new MAC address that is assigned can be correlated to properly be referenced by other virtual machines that may be referencing that virtual machine (if the MAC address was used for identification or a relationship).
If the host name is changed for one of the virtual machines, the virtual machines that were referencing that new virtual machine will also be updated so that each of the machines can properly continue to use their original relationships, or the relationships that were defined by the visual model, in accordance with one embodiment of the present invention. Still shown in section 206 of the graphical user interface 200 is the ability of a user, such as a system administrator to assign new MAC addresses to specific virtual machines, based on the relationships that should be maintained between virtual machines, that are part of the visual model. In one embodiment, a new MAC address is automatically obtained from the virtual Network Interface Card (vNIC) of the virtual machine.
Once the relationships, parameters, and properties of the specific virtual machines have been identified and their old and new configurations are saved by selecting button 208, the information is saved to memory, storage, or a file. This information, once saved, can be used in conjunction with the visual model 110 to define the proposed execution sequence.
Section 210 of the graphical user interface shows an example interface provided to the user. As discussed above, there are two scripts that would be run in operations 152 and 154 of
Once the model is finalized, virtualization will not need any manual intervention assuming that either ESX servers can be deployed automatically or physical hosts are shipped with ESXi.
Apart from various benefits of virtualization, one embodiment is to make virtualization transparent to the application users i.e., all the configuration and group semantics should be unchanged. In other embodiments, the user or system admin can change one or more configuration and/or group semantics, or can override recommendations. For one example, a process may be as follows:
If no configurations changes are made, all servers will retain IP addresses (or DHCP configuration) and hostnames—hence, making virtualization transparent to the users. Then, users can still connect to same IP address or hostname, to consume services offered by the application.
In still another embodiment, partial virtualization can be performed. In case the system admin may not be comfortable with virtualizing all the servers, and can select a subset of servers during the modeling step. As shown in
Still further, system down time can be managed. For instance, in some cases, where physical systems are deployed with redundancy & load-balancing, application downtime can be made zero or close to zero, by using proper sequence and scripts as mentioned above.
In operation 304, the identified computers from the group or data center are examined to obtain the defined relationships between the computers, databases, and other computing and storage infrastructure in order to obtain and define the relationships, as well as access credentials to the various computers of the group. Once these relationships and parameters, as well as any access credentials are obtained in operation 304, the method moves to operation 306 where utilization or anticipated utilization of the group of computers and the processes performed on those computers is analyzed. If certain computers or processes are charged with high throughput or high bandwidth operations, higher utilization will be required, and ultimate virtualization to host machines needs to be based on the workload assigned hosting machine (e.g., ESX).
In operation 308, a visual model for the proposed virtualization of the group of computers is generated automatically. This visual model will generate a listing of recommended hosting machines and the virtual machines that are to be installed on the hosting machines to satisfy the virtualization of the physical machines that are part of the group of machines or data center.
In operation 310, a sequence of virtualization operations are presented to the user to achieve the execution of the proposed virtualization of the group of machines. The sequence of virtualization operations represent the steps performed and the order in which the steps are going to be performed in order to meet the virtualization, while still preserving the relationships between the various computers that are part of the virtualization group.
In one embodiment, both the sequence of virtualization operations as well as the visual model, may be presented to the user in a graphical user interface, a tabular form, or a listing that allows the user to interface with the information and make modifications if desired. Although the visual model and the sequence of virtualization operation are defined, based on the original physical machines, relationships, and utilization factors, the system administrator or user may propose alternatives, based on plan changes to the system, or known desires for a different configuration.
Thus, operation 312 provides editable adjustability to the visual model and the sequence of virtualized operations to allow modifications, if desired. Once the modifications have been made, if any, the sequence of virtualization operations are executed in operation 314. If any non-software relationship data of hardware is not updated during the virtualization operation, the method can proceed to operation 316 where the hardware configuration data can be modified to make adjustments to the resulting virtualized systems. In one or more embodiments, an audit trail is maintained for the sequence of virtualization operations for a future reporting and/or troubleshooting purpose.
In one embodiment, it is desired to keep a record of the virtualization operations that were performed, as well as the virtual visual model of the virtualized system. If any troubleshooting is desired to be performed on the resulting virtualized system, it is possible to quickly refer back to the visual model 110 and identify each of the virtual machines and the hosting machines, as well as identify their relationships.
As shown in
Although virtualization operations can take on many forms, several concepts are important to ensure that physical constructs of physical machines are properly transferred to virtual machines. With this in mind, and by way of reference, more information on virtual system and methods can be found in U.S. patents owned by the assignee of the present application, VMware, Inc. Thus, U.S. Pat. Nos. 6,397,242, 6,496,847, 7,069,413, 7,356,679, and US Published Application 2008/0244028 A1, are each incorporated by reference for all purposes.
For completeness, reference is made to an example server system, that is referred to by the trademark “ESX™”, which is provided by VMware, of Palo Alto, Calif. However, the methods, systems and embodiments are not limited to any one brand of server or virtualization servers. The example ESX(x) server is a hypervisor that partitions physical servers in multiple virtual machines. Each virtual machine may represent a complete system, with processors, memory, networking, storage and BIOS. VMware ESX enables multiple virtual machines to: (a) share physical resources, (b) run unmodified operating systems and applications, and (c) run the most resource-intensive applications side by side on the same server. Other servers made by other suppliers can have similar functionality or more or less functionality, depending on their target product. Accordingly, the systems, methods and computer readable media can be practiced using any product, software, or hardware configuration.
It will be obvious, however, to one skilled in the art, that the present invention may be practiced without some or all of these specific details. In other instances, well known process operations have not been described in detail in order not to unnecessarily obscure the present invention.
Embodiments of the present invention may be practiced with various computer system configurations including hand-held devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers and the like. The invention can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a wire-based or wireless network.
With the above embodiments in mind, it should be understood that one or more embodiments of the invention may employ various computer-implemented operations involving data stored in computer systems. These operations are those requiring physical manipulation of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. Further, the manipulations performed are often referred to in terms, such as producing, identifying, determining, or comparing.
Any of the operations described herein that form part of one or more embodiments of the invention are useful machine operations. One or more embodiments of the invention also relates to a device or an apparatus for performing these operations. The apparatus may be specially constructed for the required purposes, such as the carrier network discussed above, or it may be a general purpose computer selectively activated or configured by a computer program stored in the computer. In particular, various general purpose machines may be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required operations.
The programming modules and software subsystems described herein can be implemented using programming languages such as Flash, JAVA™, C++, C, C#, Visual Basic, JavaScript, PHP, XML, HTML etc., or a combination of programming languages. Commonly available protocols such as SOAP/HTTP may be used in implementing interfaces between programming modules. As would be known to those skilled in the art the components and functionality described above and elsewhere herein may be implemented on any desktop operating system such as different versions of Microsoft Windows, Apple Mac, Unix/X-Windows, Linux, etc., executing in a virtualized or non-virtualized environment, using any programming language suitable for desktop software development.
The programming modules and ancillary software components, including configuration file or files, along with setup files required for providing the method and apparatus for troubleshooting subscribers on a telecommunications network and related functionality as described herein may be stored on a computer readable medium. Any computer medium such as a flash drive, a CD-ROM disk, an optical disk, a floppy disk, a hard drive, a shared drive, and storage suitable for providing downloads from connected computers, could be used for storing the programming modules and ancillary software components. It would be known to a person skilled in the art that any storage medium could be used for storing these software components so long as the storage medium can be read by a computer system.
One or more embodiments of the invention may be practiced with other computer system configurations including hand-held devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers and the like. The invention may also be practiced in distributing computing environments where tasks are performed by remote processing devices that are linked through a network.
One or more embodiments of the invention can also be embodied as computer readable code on a computer readable medium. The computer readable medium is any data storage device that can store data, which can thereafter be read by a computer system. Examples of the computer readable medium include hard drives, network attached storage (NAS), read-only memory, random-access memory, CD-ROMs, CD-Rs, CD-RWs, DVDs, Flash, magnetic tapes, and other optical and non-optical data storage devices. The computer readable medium can also be distributed over a network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.
While one or more embodiments of the present invention have been described, it will be appreciated that those skilled in the art upon reading the specification and studying the drawings will realize various alterations, additions, permutations and equivalents thereof. It is therefore intended that embodiments of the present invention include all such alterations, additions, permutations, and equivalents as fall within the true spirit and scope of the invention as defined in the following claims. Thus, the scope of the invention should be defined by the claims, including the full scope of equivalents thereof.
| Patent | Priority | Assignee | Title |
| 10795712, | Oct 22 2008 | VMware LLC | Methods and systems for converting a related group of physical machines to virtual machines |
| 11868797, | Oct 22 2008 | VMware LLC | Methods and systems for converting a related group of physical machines to virtual machines |
| 9965314, | Oct 22 2008 | VMware LLC | Methods and systems for converting a related group of physical machines to virtual machines |
| Patent | Priority | Assignee | Title |
| 5966540, | Feb 06 1997 | International Business Machines Corp. | Hosted machine code installation |
| 7640292, | Apr 29 2005 | NetApp, Inc | Physical server to virtual server migration |
| 7912955, | Apr 24 2007 | Hewlett Packard Enterprise Development LP | Model-based provisioning of resources |
| 7913009, | Jun 20 2007 | Microsoft Technology Licensing, LLC | Monitored notification facility for reducing inter-process/inter-partition interrupts |
| 8108855, | Jan 02 2007 | International Business Machines Corporation | Method and apparatus for deploying a set of virtual software resource templates to a set of nodes |
| 20060010176, | |||
| 20060080425, | |||
| 20060173912, | |||
| 20060294516, | |||
| 20070006225, | |||
| 20070204266, | |||
| 20070260831, | |||
| 20070271560, | |||
| 20070300223, | |||
| 20080052719, | |||
| 20080184225, | |||
| 20080222638, | |||
| 20090113423, | |||
| 20090217267, |
| Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
| Oct 09 2013 | VMware, Inc. | (assignment on the face of the patent) | / | |||
| Nov 21 2023 | VMWARE, INC | VMware LLC | CHANGE OF NAME SEE DOCUMENT FOR DETAILS | 067102 | /0395 |
| Date | Maintenance Fee Events |
| Sep 27 2019 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
| Sep 27 2023 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
| Date | Maintenance Schedule |
| Apr 12 2019 | 4 years fee payment window open |
| Oct 12 2019 | 6 months grace period start (w surcharge) |
| Apr 12 2020 | patent expiry (for year 4) |
| Apr 12 2022 | 2 years to revive unintentionally abandoned end. (for year 4) |
| Apr 12 2023 | 8 years fee payment window open |
| Oct 12 2023 | 6 months grace period start (w surcharge) |
| Apr 12 2024 | patent expiry (for year 8) |
| Apr 12 2026 | 2 years to revive unintentionally abandoned end. (for year 8) |
| Apr 12 2027 | 12 years fee payment window open |
| Oct 12 2027 | 6 months grace period start (w surcharge) |
| Apr 12 2028 | patent expiry (for year 12) |
| Apr 12 2030 | 2 years to revive unintentionally abandoned end. (for year 12) |