Modern computing continues to have areas where improvement is desired. The continuing evolution of how computers are designed and programmed at both the intra-machine and inter-machine level leads to new issues of performance, security, reliability, power consumption, efficiency, and so forth. Increasing complexity can make it difficult to identify bugs or critical aspects of machines or software. It has been known to analyze groups of static computers (e.g., static files of dormant machines) to learn about individual machines as well as groups of machines. Physical computers (physical machines) have been automatically analyzed to identify features in common among failing or well-performing machines, programmatic bugs, machines that are performing poorly or are experiencing errors, and so forth. However, to date, such analysis has been limited to the static state of physical machines, log files, disk images, and the like. It has not been possible to analyze, as a body, large groups of running computers.
Recently, however, in some environments such as compute clouds, data centers, etc., operating systems and software thereon are sometimes run on virtual machines (VMs), which are described in detail below. With virtual machine technology, it is possible to capture and store a snapshot of a running “machine”, including hardware state of the machine, software state, operating system state, file system state, memory state, and so forth. This captured state of a machine “in motion” holds information that has not previously been considered as a collective set of data that may be subject to analysis.
Techniques related to analysis of sets virtual machine snapshots are discussed below.
The following summary is included only to introduce some concepts discussed in the Detailed Description below. This summary is not comprehensive and is not intended to delineate the scope of the claimed subject matter, which is set forth by the claims presented at the end.
Described are techniques for capturing and analyzing snapshots of virtual machines. One or more computers may automatically obtain snapshots of virtual machines as they are executing to form a pool of virtual machine snapshots. The virtual machine snapshots are then read to obtain a set of features properties of the virtual machine snapshots, including information about a running guest operating system, software installed on the virtual machine, metadata about the virtual machine itself, and others. The features or properties are analyzed, in one embodiment using a machine learning algorithm, to automatically compute and store information about the virtual machines.
Many of the attendant features will be explained below with reference to the following detailed description considered in connection with the accompanying drawings.
The present description will be better understood from the following detailed description read in light of the accompanying drawings, wherein like reference numerals are used to designate like parts in the accompanying description.
Machine Virtualization
The virtualization layer 100 may be of any variety of known or future implementations, such as Hyper-V Server™, VMWare ESX Server™, Xen, Oracle VM™, etc. The architecture of the virtualization layer may a hosted type, with a virtual machine monitor (VMM) running on a host operating system, or a bare-metal type with a hypervisor or the like running directly on the hardware 104 of the computer 102. As used herein, the term “virtual machine” refers to a system-type virtual machine that simulates any specific hardware architecture (e.g., x86) able to run native code for that hardware architecture; to the guest, the virtual machine may be nearly indistinguishable from a hardware machine. Virtual machines discussed herein are not abstract or process-type virtual machines such as Java Virtual Machines.
The virtualization layer 100 performs the basic function of managing the virtual machines 114 and sharing of the hardware 104 by both itself and the virtual machines 114. Any of a variety of techniques may be used to isolate the virtual machines 114 from the hardware 104. In one embodiment, the virtualization layer may provide different isolated environments (i.e., partitions or domains) which correspond to virtual machines 114. Some of the virtualization layer 100 such as shared virtual device drivers, inter virtual machine communication facilities, and virtual machine management APIs (application programming interfaces), may run in a special privileged partition or domain, allowing for a compact and efficient hypervisor. In other embodiments, functionality for virtual machine management and coherent sharing of the hardware 104 may reside in a monolithic on-the-metal hypervisor.
The virtualization layer 100 manages execution of the virtual machine 114, handling certain calls to the guest's kernel, hypercalls, etc., and coordinating the virtual machine 114′s access to the underlying hardware 104. As the guest and its software run, the virtualization layer 100 may maintain state of the guest on the virtual disk image 140; when the guest, or an application run by the guest, writes data to “disk”, the virtualization layer 100 translates the data to the format of the virtual disk image 140 and writes to the image.
The virtualization layer 100 may perform a process 144 for shutting down the virtual machine 114. When an instruction is received to stop the virtual machine 114, the state of the virtual machine 114 and its guest is saved to the virtual disk image 140, and the executing virtual machine 114 process (or partition) is deleted. A specification of the virtual machine 114 may remain for a later restart of the virtual machine 114.
Virtual Machine Shapshotting
Capturing a snapshot 188 may be performed with known techniques or with existing implementations of virtualization technology. Notably, snapshot 188 may include any information available in an equivalent running physical machine. For example, snapshot 188 may include a copy of the memory of the virtual machine 113, which may include executing processes 190, kernel data structures 192, or any information in the virtualized physical memory of the virtual machine 113. In addition, the snapshot 188 may include information captured from physical or virtual devices used by the virtual machine 113, including register values, buffer contents, etc. In some implementations, the snapshotting process 186 may also capture information about the virtual physical environment of the virtual machine 113, such as virtual CPU information (number of virtual cores or CPUs), amounts of memory and storage, virtual devices, virtual network interface cards, BIOS, virtual mother board, device drivers, and others. Some virtualization implementations may link a snapshot to the virtual machine's disk image, and the snapshot may comprise storage blocks of the executing virtual machine that differ from the virtual machine's disk image. In sum, snapshot 188 is a persistent object such as a file that contains the captured working state of a virtual machine. Most virtualization implementations allow a snapshot to be loaded and executed; the virtual machine executing the snapshot (possible a virtual machine other than the original from which the snapshot was captured) begins executing as though the original virtual machine at the time the snapshot was taken. In other words, the state of an executing virtual machine may be captured and later resumed in the same or a new virtual machine.
The snapshot manager 212 may be part of a virtual machine management system that manages virtual machines across a network. In one embodiment, snapshots 188 are repeatedly taken over time for any given virtual machine, possibly forming a chain of sequential snapshots for a virtual machine. For example, in
Virtual Machine Snapshot Analysis
The snapshots are read by a feature extractor 250. A subset of the stored virtual machine snapshots may be selected or queried for according to a particular purpose of the analysis, the selection of analysis algorithm, and so forth. The feature extractor 250 accesses a virtual machine snapshot, mounts/reads the file system therein, reads the stored memory content, reads configuration (e.g., registry) settings, and/or reads metadata about the virtual machine included with the snapshot, to identify a set of pre-defined features of the snapshot. Any type of feature may be subject to extraction for analysis. The feature extractor 250 may have a template or definition file that defines the features to be sought and extracted, for example a set of files, a set of attributes of the virtual machine itself, a set of software packages to be checked for, etc. Feature extraction and example features are discussed in greater detail with reference to
Returning to
The analysis tool 254 receives the feature pool 252 and performs analysis on the feature pool 252. The analysis can take a wide range of forms. The analysis tool 254, running as software on one or more computers, may be programmed with custom logic such as a decision tree or a set of rules (obtained from a rule database) that are specific to a particular analysis to be performed (e.g., security, or performance, or a particular software bug). The analysis tool 254 may instead perform analysis using statistical modeling or machine learning techniques described below, where analytical conclusions are not from hard-coded logic but rather the meaning of features depends on training data and/or the feature pool 252 as a whole.
The analysis tool 254 outputs analysis output 256, which also may take a variety of forms. The purpose of automated snapshot analysis is to identify or estimate properties or traits of virtual machines that correspond to the snapshots being analyzed. As such, analysis output 256 may be a ranking of snapshots according to likelihood of a virtual machine having a defined condition (e.g., infected with a computer virus), or having a particular trait (e.g., will experience a failure in the next 8 days), or belongs to a particular category (e.g., underperforming machines) etc. Analysis output 256 may also, rather than analyzing snapshots relative to predefined semantic meaning, identify statistical traits of virtual machines, clusters of machines grouped by similarities, and others.
Feature pool 252C is a set of feature vectors 270. Each feature vector is a set of values arranged in a predefined order, with each value at a position corresponding to a feature variable in a vector of feature variables 272. In some embodiments where machine learning is used, there is no need to explicitly define the feature variables. Again, the features in a feature vector are simply values derived from a snapshot, including its semantic content and/or metadata. For example, it is possible to read the stored copy of working memory in a snapshot and parse for objects such as names of open files, programmatic objects, or other objects that can be seen as having been active when the virtual machine was snapshotted.
As noted earlier, many forms of machine learning may be used. Any type of linear classifier may be used. Semi-supervised learning algorithms may be used. As used herein “machine learning” will refer to any known or future artificial intelligence algorithms for automated learning, including, categorically: supervised learning algorithms (e.g., neural networks, Bayesian statistics, decision trees, learning automata, regression analysis, Gaussian process regression, inductive logic programming, etc); statistical classification algorithms (e.g., linear classifiers, k-nearest neighbor, boosting, Bayesian networks, hidden Markov models, etc.); unsupervised learning algorithms (e.g., data clustering, expectation-maximization, radial basis function network, etc.); associative learning (e.g., a-priori algorithms and FP-growth algorithms); hierarchical clustering algorithms; partial clustering algorithms; and/or others.
Because snapshots are taken from live running virtual machines, run-time state may be taken into account. In particular, features of a guest operating system may be used, including features related to memory, processes, threads, boot state, and other features that are not found in dormant physical computers (or images thereof), or information found in static files, log files, etc.
Conclusion
Embodiments and features discussed above can be realized in the form of information stored in volatile or non-volatile computer or device readable media. This is deemed to include at least media such as optical storage (e.g., compact-disk read-only memory (CD-ROM)), magnetic media, flash read-only memory (ROM), or any current or future means of storing digital information. The stored information can be in the form of machine executable instructions (e.g., compiled executable binary code), source code, bytecode, or any other information that can be used to enable or configure computing devices to perform the various embodiments discussed above. This is also deemed to include at least volatile memory such as random-access memory (RAM) and/or virtual memory storing information such as central processing unit (CPU) instructions during execution of a program carrying out an embodiment, as well as non-volatile media storing information that allows a program or executable to be loaded and executed. The embodiments and features can be performed on any type of computing device, including portable devices, workstations, servers, mobile wireless devices, and so on.
Number | Name | Date | Kind |
---|---|---|---|
7542959 | Barnhill et al. | Jun 2009 | B2 |
8095662 | Lappas et al. | Jan 2012 | B1 |
8135994 | Keromytis et al. | Mar 2012 | B2 |
8296759 | Hutchins et al. | Oct 2012 | B1 |
20020087290 | Wegerich et al. | Jul 2002 | A1 |
20060085784 | Traut et al. | Apr 2006 | A1 |
20070074208 | Ling et al. | Mar 2007 | A1 |
20070180439 | Sundararajan et al. | Aug 2007 | A1 |
20070244938 | Michael | Oct 2007 | A1 |
20070283192 | Shevchenko | Dec 2007 | A1 |
20080016572 | Burkhardt et al. | Jan 2008 | A1 |
20080022032 | Nicholas et al. | Jan 2008 | A1 |
20080155169 | Hiltgen et al. | Jun 2008 | A1 |
20080256533 | Ben-Yehuda et al. | Oct 2008 | A1 |
20080262991 | Kapoor et al. | Oct 2008 | A1 |
20090007100 | Field | Jan 2009 | A1 |
20090043812 | Rigdon | Feb 2009 | A1 |
20090070771 | Yuyitung et al. | Mar 2009 | A1 |
20090089078 | Bursey | Apr 2009 | A1 |
20090276771 | Nickolov et al. | Nov 2009 | A1 |
20090300076 | Friedman et al. | Dec 2009 | A1 |
20090320010 | Chow et al. | Dec 2009 | A1 |
20100049930 | Pershin et al. | Feb 2010 | A1 |
20100070725 | Prahlad et al. | Mar 2010 | A1 |
20100107158 | Chen | Apr 2010 | A1 |
20100180092 | Rajaa | Jul 2010 | A1 |
20100251004 | Schuba | Sep 2010 | A1 |
20100293144 | Bonnet | Nov 2010 | A1 |
20100299309 | Maki et al. | Nov 2010 | A1 |
20110022812 | van der Linden et al. | Jan 2011 | A1 |
20110047545 | Ellison et al. | Feb 2011 | A1 |
20110113206 | Heim | May 2011 | A1 |
20110138366 | Wintergerst et al. | Jun 2011 | A1 |
20110265182 | Peinado et al. | Oct 2011 | A1 |
20110269111 | Elesseily et al. | Nov 2011 | A1 |
20120054554 | Dagan | Mar 2012 | A1 |
20120072968 | Wysopal et al. | Mar 2012 | A1 |
20120084262 | Dwarampudi et al. | Apr 2012 | A1 |
20120096158 | Astete et al. | Apr 2012 | A1 |
20120131480 | Kalmbach et al. | May 2012 | A1 |
20120137367 | Dupont et al. | May 2012 | A1 |
20120167094 | Suit | Jun 2012 | A1 |
20120233331 | Voccio et al. | Sep 2012 | A1 |
20120233610 | Mandre | Sep 2012 | A1 |
20120324236 | Srivastava et al. | Dec 2012 | A1 |
20130014259 | Gribble et al. | Jan 2013 | A1 |
20130311824 | Ji et al. | Nov 2013 | A1 |
20140075440 | Prahlad et al. | Mar 2014 | A1 |
Number | Date | Country |
---|---|---|
200925995 | Jun 2009 | TW |
201027431 | Jul 2010 | TW |
2013003005 | Jan 2013 | WO |
Entry |
---|
Virtual Machine Snapshots with Hyper-V Author: Robert Larson Date Published: Apr. 26, 2008. |
Using vmrun to Control Virtual Machines Date Published: Dec. 7, 2010. |
“Search Report Received for European Patent Application No. 12800885.1”, Mailed Date : Oct. 22, 2014, 7 Pages. |
Zhang, et al., “Learning-Aided Predictor Integration for System Performance Prediction”, In Cluster Computing, vol. 10, Issue 4, Oct. 2, 2007, pp. 425-442. |
“International Search Report”, Mailed Date: Jan. 31, 2013, Application No. PCT/US2012/040958, Filed Date: Jun. 5, 2012, Pages 8. |
“Office Action and Search Report Issued in Taiwan Patent Application No. 101113805”, Mailed Date: Nov. 11, 2015, 9 Pages. |
Number | Date | Country | |
---|---|---|---|
20120323853 A1 | Dec 2012 | US |