US20160210199A1 - Virtualizing multiple networked machines using a predetermined network recovery policy - Google Patents
Virtualizing multiple networked machines using a predetermined network recovery policy Download PDFInfo
- Publication number
- US20160210199A1 US20160210199A1 US14/717,133 US201514717133A US2016210199A1 US 20160210199 A1 US20160210199 A1 US 20160210199A1 US 201514717133 A US201514717133 A US 201514717133A US 2016210199 A1 US2016210199 A1 US 2016210199A1
- Authority
- US
- United States
- Prior art keywords
- machines
- multiple networked
- recovery policy
- network
- virtual machines
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
- G06F11/1464—Management of the backup or restore process for networked environments
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1417—Boot up procedures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1448—Management of the data involved in backup or backup restore
- G06F11/1451—Management of the data involved in backup or backup restore by selection of backup contents
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
- G06F11/1469—Backup restoration techniques
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1479—Generic software techniques for error detection or fault masking
- G06F11/1482—Generic software techniques for error detection or fault masking by means of middleware or OS functionality
- G06F11/1484—Generic software techniques for error detection or fault masking by means of middleware or OS functionality involving virtual machines
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
- G06F9/4416—Network booting; Remote initial program loading [RIPL]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1456—Hardware arrangements for backup
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45595—Network integration; Enabling network access in virtual machine instances
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/805—Real-time
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/815—Virtual
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/84—Using snapshots, i.e. a logical point-in-time copy of the data
Definitions
- the embodiments disclosed herein relate to virtualizing multiple networked machines using a predetermined network recovery policy.
- a storage is computer-readable media capable of storing data.
- a backup of the data in a storage may be created at a particular point in time to enable the restoration of the data at some future time. Such a restoration may become desirable, for example, if the storage experiences corruption of its stored data, if the storage becomes unavailable, or if a user wishes to create a second identical storage.
- the restoration to storages on new physical machines can involve a number of challenges, including taking an unacceptable amount of time.
- a user may restore the backups to virtual storages on virtual machines.
- a virtual machine is a software-based emulation of a physical machine in a process generally known as virtualization.
- a virtual machine generally operates based on the computer architecture and functions of a physical machine.
- a hypervisor is computer software, computer firmware, or computer hardware that creates and runs virtual machines.
- a computer on which a hypervisor is running one or more virtual machines is generally referred to as a host machine, while each virtual machine running on the hypervisor is generally referred to as a guest virtual machine.
- a hypervisor generally creates a guest virtual machine by accessing a virtual machine file, which may be a backup of a storage of a physical machine, that contains or references data that is used to create the guest virtual machine.
- the hypervisor also generally presents the guest virtual machines with a virtual operating platform and manages the execution of operating systems and network settings of the guest virtual machines.
- One common problem encountered by a user when utilizing a hypervisor to restore storages of multiple networked physical machines from backups to virtual storages on virtual machines is the time and effort involved for the user to manually boot the virtual machines and manually configure the network settings during the virtualization.
- the user may be stressed and consequently find it very difficult to clearly think through the manual booting of the virtual machines and the manual configuring of network settings during the virtualization.
- slow user performance and user errors during a restoration in a disaster scenario are commonplace.
- Slow user performance and user errors during the manual booting of virtual machines and manual configuring of network settings during virtualization can increase downtime, thereby further exacerbating the detrimental effects of the disaster.
- example embodiments described herein relate to virtualizing multiple networked machines using a predetermined network recovery policy.
- the example methods disclosed herein may be employed to allow a hypervisor to restore storages of multiple networked physical machines from backups to virtual storages on networked virtual machines using a predetermined network recovery policy.
- the use of the predetermined network recovery policy may allow advance testing of the virtualization and may avoid a user needing to manually boot the virtual machines and manually configure network settings during the virtualization, thus avoiding slow user performance and user errors and decreasing downtime during the virtualization.
- a method for virtualizing multiple networked machines using a predetermined network recovery policy may include identifying multiple image backups of the multiple networked machines, determining an order for booting the multiple networked machines as multiple networked virtual machines, determining network settings for the multiple networked machines when booted as the multiple networked virtual machines, storing the order and the network settings in the predetermined network recovery policy prior to booting the multiple networked machines as the multiple networked virtual machines, booting the multiple networked machines as the multiple networked virtual machines from the multiple image backups in the order stored in the predetermined network recovery policy and with the network settings stored in the predetermined network recovery policy subsequent to the storing and in response to receiving a command to implement the predetermined network recovery policy.
- FIG. 1 is a schematic block diagram illustrating an example physical networked backup system
- FIG. 2 is a schematic block diagram illustrating an example virtual networked restoration system
- FIG. 3 is a schematic block diagram illustrating an example network recovery policy
- FIG. 4 is a schematic flowchart diagram of an example method for virtualizing multiple networked machines using a predetermined network recovery policy.
- FIG. 1 is a schematic block diagram illustrating an example physical networked backup system 100 .
- the example system 100 may include physical machines 102 a - 102 c and a destination system 104 .
- the physical machines 102 a - 102 c may include physical storages 106 a - 106 c , respectively, and the destination system 104 may include a destination storage 108 .
- the physical machines 102 a - 102 c and the destination system 104 may be networked together over network 110 .
- the destination storage 108 may store image backups 116 a - 116 c of the physical storages 106 a - 106 c , respectively.
- the destination storage 108 may further store a network recovery policy 300 .
- the network recovery policy 300 may include boot settings and network settings for restoring the physical machines 102 a - 102 c as virtual machines.
- the destination system 104 may further include a backup disaster recovery (BDR) module 112 and a hypervisor 114 .
- BDR backup disaster recovery
- Each of the machines 102 a - 102 c and the system 104 may be any computing device capable of supporting a storage and communicating with other systems including, for example, file servers, web servers, other servers, personal computers, desktop computers, laptop computers, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, smartphones, digital cameras, hard disk drives, and flash memory drives.
- the network 110 may be any wired or wireless communication network including, for example, a Local Area Network (LAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN), a Wireless Application Protocol (WAP) network, a Bluetooth network, an Internet Protocol (IP) network such as the internet, or some combination thereof.
- LAN Local Area Network
- MAN Metropolitan Area Network
- WAN Wide Area Network
- WAP Wireless Application Protocol
- Bluetooth an Internet Protocol (IP) network such as the internet, or some combination thereof.
- IP Internet Protocol
- the image backups 116 a - 116 c stored in the destination storage 108 may be created by the BDR module 112 .
- the BDR module 112 may be configured to execute computer instructions to perform image backup operations of creating full and/or incremental or decremental image backups of the physical storages 106 a - 106 c .
- Each of the image backups 116 a - 116 c may actually be a chain of full/incremental image backups, full/decremental image backups, or full/incremental/decremental image backups. It is noted that the image backups 116 a - 116 c may initially be created on the physical machines 102 a - 102 c and then copied to the destination system 104 .
- the image backups 116 a - 116 c may be stored on the destination system 104 , which may be in a different physical location (such as a different city) from the physical machines 102 a - 102 c , to enable a restoration of the networked physical machines 102 a - 102 c in the event that the networked physical machines 102 a - 102 c become unavailable due to, for example, a disaster such as a fire or an earthquake. This restoration may be accomplished virtually using the hypervisor 114 .
- FIG. 2 is a schematic block diagram illustrating an example virtual networked restoration system 200 .
- the example system 200 may include virtual machines 202 a - 202 c that are created and run by the hypervisor 114 of the system 100 of FIG. 1 .
- the hypervisor 114 may create the virtual machines 202 a - 202 c from the image backups 116 a - 116 c , respectively, by restoring the image backups 116 a - 116 c to the virtual storages 206 a - 206 c , respectively, and then booting each of the virtual storages 206 a - 206 c .
- the hypervisor 114 may create the virtual network 210 by configuring the network settings of the virtual machines 202 a - 202 c and the virtual network 210 according to the network settings in the network recovery policy 300 of FIG. 1 .
- the hypervisor 114 may be computer software, computer firmware, computer hardware, or some combination thereof, of the destination system 104 of FIG. 1 , which acts as a host machine.
- the hypervisor 114 is configured to create, run, and manage one or more of the virtual machines 202 a - 202 c , which each acts as a guest virtual machine.
- the virtual machines 202 a - 202 c are software-based emulations of the physical machines 102 a - 102 c of FIG. 1 that are configured to execute programs in a manner similar to the physical machines 102 a - 102 c.
- the hypervisor 114 may be a VMware® vSphere® hypervisor, and the image backups 116 a - 116 c of FIG. 1 may be StorageCraft® ShadowProtect® Full (SPF) backup image files.
- the VMware® vSphere® hypervisor may create the virtual machines 202 a - 202 c using the SPF backup image files.
- each of these machines or system may instead include two or more storages.
- the destination storage 108 is disclosed in FIG. 1 as being local to the hypervisor 114 , it is understood that the destination storage 108 may be remote from the hypervisor 114 .
- one or more of the image backups 116 a - 116 c may be stored remotely from the hypervisor 114 .
- the BDR module 112 is the only module and the hypervisor 114 is the only hypervisor disclosed in the example system 100 of FIG.
- the functionality of the BDR module 112 and/or of the hypervisor 114 may be replaced or augmented by one or more similar modules and/or hypervisors on the destination system 104 or on another machine or system that is local to or remote from the destination system 104 .
- FIGS. 1 and 2 Having described one specific environment with respect to FIGS. 1 and 2 , it is understood that the specific environment of FIGS. 1 and 2 is only one of countless environments in which the example methods disclosed herein may be employed. The scope of the example embodiments is not intended to be limited to any particular environment.
- FIG. 3 is a schematic block diagram illustrating the example network recovery policy 300 of FIG. 1 .
- the network recovery policy 300 may be determined prior to a catastrophic event such as an earthquake, fire, or other disaster, in order to allow the network physical machines 102 a - 102 c of FIG. 1 to be restored as networked virtual machines 202 a - 202 c of FIG. 2 using the hypervisor 114 of FIGS. 1 and 2 .
- the use of the predetermined network recovery policy 300 may allow advance testing of the virtualization and may avoid a user needing to manually boot the virtual machines 202 a - 202 c of FIG. 2 and manually configure the network settings of the virtual network 210 of FIG. 2 during the virtualization, thus avoiding slow user performance and user errors and decreasing downtime during the virtualization.
- the network recovery policy 300 may include a boot order for the physical machines 102 a - 102 c .
- This boot order may be designated by the user in terms of a set numerical order (e.g., 1, 2, and 3) or in terms of dependencies (e.g., the physical machine 102 b depends on physical machines 102 ), or both.
- the network recovery policy 300 may also include a boot timing for the physical machines 102 a - 102 c .
- This boot timing may be designated by the user in terms of a specific amount of time to wait before booting the next machine (e.g. waiting 300 seconds after beginning the boot of the physical machine 102 a to begin booting the next machine) or in terms of a yes/no flag that specifies that the boot timing should be determined in real-time based on the ready state of the machine being booted (e.g. waiting to boot the physical machine 102 b until it is determined that the physical machine 102 a has finished booting and is in a ready state), or both.
- the network recovery policy 300 may also include network settings such as network role assignments, static Internet Protocol (IP) addresses, port blocking rules, and port forwarding rules for the networked physical machines 102 a - 102 c .
- the network role assignments may include assigned roles of domain controller, Dynamic Host Configuration Protocol (DHCP) Server, exchange server, another network role assignment, or some combination thereof.
- Other network settings that may be included in the network recovery policy 300 are Virtual Private Network (VPN) configuration, firewall rules, or some combination thereof for the networked physical machines 102 a - 102 c
- VPN Virtual Private Network
- the information stored in the network recovery policy 300 may apply equally to the virtual machines 202 a - 202 c of FIG. 2 that correspond to the physical machines 102 a - 102 c of FIG. 1 , respectively. Therefore, when the physical machines 102 a - 102 c of FIG. 1 are virtualized by the hypervisor 114 as the virtual machines 202 a - 202 c of FIG. 2 , the information stored in the network recovery policy 300 can be employed by the hypervisor 114 to create the example virtual networked restoration system 200 of FIG. 2 .
- FIG. 4 is a schematic flowchart diagram of an example method 400 for virtualizing multiple networked machines using a predetermined network recovery policy.
- the method 400 may be implemented, in at least some embodiments, by the BDR module 112 of FIG. 1 and the hypervisor 114 of FIGS. 1 and 2 .
- the BDR module 112 and the hypervisor 114 may be configured as one or more programs stored on one or more non-transitory computer-readable media that are configured, when executed, to cause one or more processors to perform operations of virtualizing the multiple networked physical machines 102 a - 102 c of FIG. 1 using the predetermined network recovery policy 300 of FIGS. 1 and 3 , as represented by one or more of steps 402 - 410 of the method 400 .
- steps 402 - 410 of the method 400 may be illustrated as discrete steps, various steps may be divided into additional steps, combined into fewer steps, or eliminated, depending on the desired implementation.
- the method 400 will now be discussed with reference to FIGS. 1-4 .
- the method 400 may include a step 402 of identifying multiple image backups of multiple networked machines.
- the BDR module 112 may, at step 402 , identify the image backups 116 a - 116 c of the networked physical machines 102 a - 102 c , which are stored in the destination storage 108 of the destination system 104 of FIG. 1 .
- step 402 may be performed based on a designation of the multiple image backups of the multiple networked machines received from a user.
- the BDR module 112 may, at step 402 , identify the image backups 116 a - 116 c based on a designation of the image backups 116 a - 116 c received from a user.
- step 402 may be performed based on the multiple image backups of the multiple networked machines belonging to a single backup job.
- the BDR module 112 may, at step 402 , identify the image backups 116 a - 116 c based on the image backups 116 a - 116 c belonging to a single backup job. Belonging to a single backup job may entail the image backups 116 a - 116 c representing the states of the physical machines 102 a - 102 c at a single point in time.
- the method 400 may include a step 404 of determining an order for booting the multiple networked machines as multiple networked virtual machines.
- the BDR module 112 may, at step 404 , determine an order for booting the networked machines 102 a - 102 c of FIG. 1 as the networked virtual machines 202 a - 202 c of FIG. 2 .
- step 404 may be based on a designation of the order received from a user.
- the BDR module 112 may, at step 404 , determine an order for booting the networked virtual machines 202 a - 202 c of FIG. 2 based on a designation of the boot order received from a user.
- step 404 may be performed based on a designation of dependencies between the multiple networked machines received from a user.
- the BDR module 112 may, at step 404 , determine an order for booting the networked virtual machines 202 a - 202 c of FIG. 2 based on a designation of dependencies between the networked machines 102 a - 102 c of FIG. 1 received from a user, as disclosed in FIG. 3 .
- This designation may be received from the user, for example, via a GUI associated with the BDR module 112 that is configured to allow the user to visually input dependencies using graphical elements beyond text including, but not limited to, lines in a hierarchical graph, rows in a chart, and arrows.
- step 404 may include determining a timing for booting the multiple networked machines as the multiple networked virtual machines.
- the BDR module 112 may, at step 404 , determine a timing for booting the networked machines 102 a - 102 c of FIG. 1 as the networked virtual machines 202 a - 202 c of FIG. 2 .
- the timing may be a specific wait time between the booting of each of the multiple networked machines as multiple networked virtual machines.
- the timing for the virtual machine 202 a corresponding to the physical machine 102 a may be a wait time of 300 seconds before booting the virtual machine 202 b corresponding to the physical machine 102 b , as disclosed in FIG. 3 .
- the timing may be determined in real-time during the booting of the multiple networked machines as the multiple networked virtual machines based on the timing of each of the multiple networked virtual machines achieving a ready state.
- the timing for booting the virtual machine 202 b may be determined in real-time during the booting of the virtual machine 202 a based on the virtual machine 202 b being dependent on the virtual machine 202 a , as designated in the network recovery policy of FIG. 3 , and based on a real-time determination that the virtual machine 202 a has achieved a ready state.
- the method 400 may include a step 406 of determining network settings for the multiple networked virtual machines.
- the BDR module 112 may, at step 406 , determine network settings for the networked machines 102 a - 102 c of FIG. 1 when booted as the networked virtual machines 202 a - 202 c of FIG. 2 .
- the network settings determined at step 406 may include network role assignments, static Internet Protocol (IP) addresses, port blocking rules, port forwarding rules, or some combination thereof, for the networked virtual machines 202 a - 202 c of FIG. 2 , as disclosed in FIG. 3 .
- IP Internet Protocol
- the network settings determined at step 406 may include Virtual Private Network (VPN) configuration, firewall rules, or some combination thereof, for the networked virtual machines 202 a - 202 c of FIG. 2 .
- the network role assignments for the networked virtual machines 202 a - 202 c of FIG. 2 may include assigned roles of domain controller, Dynamic Host Configuration Protocol (DHCP) Server, exchange server, or some combination thereof.
- step 406 may be based on a designation of the network settings received from a user.
- the BDR module 112 may, at step 406 , determine network settings for the networked virtual machines 202 a - 202 c of FIG.
- This designation may be received from the user, for example, via a GUI associated with the BDR module 112 that is configured to allow the user to visually specify the network settings for the networked virtual machines 202 a - 202 c of FIG. 2 .
- the method 400 may include a step 408 of storing the order and the network settings in a predetermined network recovery policy.
- the BDR module 112 may, at step 408 , store the order and the network settings in the predetermined network recovery policy 300 in the destination storage 108 of the destination system 104 of FIG. 1 .
- Step 408 may be performed prior to booting the networked machines 102 a - 102 c of FIG. 1 as the networked virtual machines 202 a - 202 c of FIG. 2 .
- the method 400 may include a step 410 of booting the multiple networked virtual machines from the multiple image backups in the order stored in the predetermined network recovery policy and with the network settings stored in the predetermined network recovery policy.
- the hypervisor 114 may, at step 410 , boot the networked machines 102 a - 102 c of FIG. 1 as the networked virtual machines 202 a - 202 c of FIG. 2 from the image backups 116 a - 116 c of FIG. 1 , in the order stored in the network recovery policy 300 of FIGS. 1 and 3 , and with the network settings stored in the network recovery policy 300 of FIGS. 1 and 3 .
- Step 410 may be performed subsequent to step 408 and may be performed in response to receiving a command to implement the network recovery policy 300 of FIGS. 1 and 3 . Additionally or alternatively, step 410 may include booting the multiple networked machines as the multiple networked virtual machines from the multiple image backups with the timing stored in the predetermined network recovery policy.
- the hypervisor 114 may, at step 410 , boot the networked virtual machines 202 a - 202 c of FIG. 2 from the image backups 116 a - 116 c with the timing stored in the network recovery policy 300 of FIGS. 1 and 3 .
- the booting at step 410 may be automatic. For example, where the command to implement the network recovery policy 300 of FIGS.
- the booting may be automatic.
- the command may be automatically generated in response to only a single action by a user, such as a single click of a single “Virtualize” button, or other button or link, by the user, to implement the network recovery policy 300 .
- This single action by the user such as a single click of a button, may be performed on a device with a display having a relatively small form factor, such as a mobile phone or tablet.
- the virtual machines 202 a - 202 c will have been virtualized and networked together over the virtual network 210 .
- the use of the predetermined network recovery policy 300 may allow advance testing of the virtualization and may avoid a user needing to manually boot the virtual machines 202 a - 202 c and manually configure network settings of the virtual network 210 during the virtualization, thus avoiding slow user performance and user errors and decreasing downtime during the virtualization.
- inventions described herein may include the use of a special-purpose or general-purpose computer, including various computer hardware or software modules, as discussed in greater detail below.
- Embodiments described herein may be implemented using non-transitory computer-readable media for carrying or having computer-executable instructions or data structures stored thereon.
- Such computer-readable media may be any available media that may be accessed by a general-purpose or special-purpose computer.
- Such computer-readable media may include non-transitory computer-readable storage media including RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other storage medium which may be used to carry or store one or more desired programs having program code in the form of computer-executable instructions or data structures and which may be accessed and executed by a general-purpose computer, special-purpose computer, or virtual computer such as a virtual machine. Combinations of the above may also be included within the scope of computer-readable media.
- Computer-executable instructions comprise, for example, instructions and data which, when executed by one or more processors, cause a general-purpose computer, special-purpose computer, or virtual computer such as a virtual machine to perform a certain method, function, or group of methods or functions.
- module may refer to software objects or routines that execute on a computing system.
- the different modules described herein may be implemented as objects or processes that execute on a computing system (e.g., as separate threads). While the system and methods described herein are preferably implemented in software, implementations in hardware or a combination of software and hardware are also possible and contemplated.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Quality & Reliability (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Stored Programmes (AREA)
- Hardware Redundancy (AREA)
Abstract
Description
- This application is a continuation of U.S. patent application Ser. No. 14/599,273, filed Jan. 16, 2015, and titled “VIRTUALIZING MULTIPLE NETWORKED MACHINES USING A PREDETERMINED NETWORK RECOVERY POLICY,” which is incorporated herein by reference in its entirety.
- The embodiments disclosed herein relate to virtualizing multiple networked machines using a predetermined network recovery policy.
- Individual physical computers, also known as physical machines, are often configured to exchange data with one another over a computer network, also known as being networked together. In order for networked physical machines to communicate over the network, various network settings may need to be configured. These network settings may designate various roles performed by the physical machines, addresses of the physical machines, and port rules for the physical machines, among other things.
- Physical machines face a myriad of threats to their smooth and continuous operation, including threats to the data stored in storages of the physical machines. A storage is computer-readable media capable of storing data. In order to mitigate these threats, a backup of the data in a storage may be created at a particular point in time to enable the restoration of the data at some future time. Such a restoration may become desirable, for example, if the storage experiences corruption of its stored data, if the storage becomes unavailable, or if a user wishes to create a second identical storage.
- When a user desires to restore the storages of multiple networked physical machines from backups, the restoration to storages on new physical machines can involve a number of challenges, including taking an unacceptable amount of time. In order to shorten the amount of time it takes to restore the storages of multiple networked physical machines from backups, a user may restore the backups to virtual storages on virtual machines.
- A virtual machine is a software-based emulation of a physical machine in a process generally known as virtualization. A virtual machine generally operates based on the computer architecture and functions of a physical machine. A hypervisor is computer software, computer firmware, or computer hardware that creates and runs virtual machines. A computer on which a hypervisor is running one or more virtual machines is generally referred to as a host machine, while each virtual machine running on the hypervisor is generally referred to as a guest virtual machine. A hypervisor generally creates a guest virtual machine by accessing a virtual machine file, which may be a backup of a storage of a physical machine, that contains or references data that is used to create the guest virtual machine. The hypervisor also generally presents the guest virtual machines with a virtual operating platform and manages the execution of operating systems and network settings of the guest virtual machines.
- One common problem encountered by a user when utilizing a hypervisor to restore storages of multiple networked physical machines from backups to virtual storages on virtual machines is the time and effort involved for the user to manually boot the virtual machines and manually configure the network settings during the virtualization. For example, in a disaster scenario where multiple networked physical machines have become unavailable due to an earthquake, fire, or other disaster, the user may be stressed and consequently find it very difficult to clearly think through the manual booting of the virtual machines and the manual configuring of network settings during the virtualization. As a result, slow user performance and user errors during a restoration in a disaster scenario are commonplace. Slow user performance and user errors during the manual booting of virtual machines and manual configuring of network settings during virtualization can increase downtime, thereby further exacerbating the detrimental effects of the disaster.
- The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as those described above. Rather, this background is only provided to illustrate one example technology area where some embodiments described herein may be practiced.
- In general, example embodiments described herein relate to virtualizing multiple networked machines using a predetermined network recovery policy. The example methods disclosed herein may be employed to allow a hypervisor to restore storages of multiple networked physical machines from backups to virtual storages on networked virtual machines using a predetermined network recovery policy. The use of the predetermined network recovery policy may allow advance testing of the virtualization and may avoid a user needing to manually boot the virtual machines and manually configure network settings during the virtualization, thus avoiding slow user performance and user errors and decreasing downtime during the virtualization.
- In one example embodiment, a method for virtualizing multiple networked machines using a predetermined network recovery policy may include identifying multiple image backups of the multiple networked machines, determining an order for booting the multiple networked machines as multiple networked virtual machines, determining network settings for the multiple networked machines when booted as the multiple networked virtual machines, storing the order and the network settings in the predetermined network recovery policy prior to booting the multiple networked machines as the multiple networked virtual machines, booting the multiple networked machines as the multiple networked virtual machines from the multiple image backups in the order stored in the predetermined network recovery policy and with the network settings stored in the predetermined network recovery policy subsequent to the storing and in response to receiving a command to implement the predetermined network recovery policy.
- It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are not restrictive of the invention, as claimed.
- Example embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:
-
FIG. 1 is a schematic block diagram illustrating an example physical networked backup system; -
FIG. 2 is a schematic block diagram illustrating an example virtual networked restoration system; -
FIG. 3 is a schematic block diagram illustrating an example network recovery policy; and -
FIG. 4 is a schematic flowchart diagram of an example method for virtualizing multiple networked machines using a predetermined network recovery policy. -
FIG. 1 is a schematic block diagram illustrating an example physical networkedbackup system 100. As disclosed inFIG. 1 , theexample system 100 may include physical machines 102 a-102 c and adestination system 104. The physical machines 102 a-102 c may include physical storages 106 a-106 c, respectively, and thedestination system 104 may include adestination storage 108. The physical machines 102 a-102 c and thedestination system 104 may be networked together overnetwork 110. Thedestination storage 108 may store image backups 116 a-116 c of the physical storages 106 a-106 c, respectively. Thedestination storage 108 may further store anetwork recovery policy 300. As discussed in greater detail below, thenetwork recovery policy 300 may include boot settings and network settings for restoring the physical machines 102 a-102 c as virtual machines. Thedestination system 104 may further include a backup disaster recovery (BDR)module 112 and ahypervisor 114. - Each of the machines 102 a-102 c and the
system 104 may be any computing device capable of supporting a storage and communicating with other systems including, for example, file servers, web servers, other servers, personal computers, desktop computers, laptop computers, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, smartphones, digital cameras, hard disk drives, and flash memory drives. Thenetwork 110 may be any wired or wireless communication network including, for example, a Local Area Network (LAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN), a Wireless Application Protocol (WAP) network, a Bluetooth network, an Internet Protocol (IP) network such as the internet, or some combination thereof. - The image backups 116 a-116 c stored in the
destination storage 108 may be created by theBDR module 112. For example, theBDR module 112 may be configured to execute computer instructions to perform image backup operations of creating full and/or incremental or decremental image backups of the physical storages 106 a-106 c. Each of the image backups 116 a-116 c may actually be a chain of full/incremental image backups, full/decremental image backups, or full/incremental/decremental image backups. It is noted that the image backups 116 a-116 c may initially be created on the physical machines 102 a-102 c and then copied to thedestination system 104. The image backups 116 a-116 c may be stored on thedestination system 104, which may be in a different physical location (such as a different city) from the physical machines 102 a-102 c, to enable a restoration of the networked physical machines 102 a-102 c in the event that the networked physical machines 102 a-102 c become unavailable due to, for example, a disaster such as a fire or an earthquake. This restoration may be accomplished virtually using thehypervisor 114. -
FIG. 2 is a schematic block diagram illustrating an example virtual networkedrestoration system 200. As disclosed inFIG. 2 , theexample system 200 may include virtual machines 202 a-202 c that are created and run by thehypervisor 114 of thesystem 100 ofFIG. 1 . Thehypervisor 114 may create the virtual machines 202 a-202 c from the image backups 116 a-116 c, respectively, by restoring the image backups 116 a-116 c to the virtual storages 206 a-206 c, respectively, and then booting each of the virtual storages 206 a-206 c. Further, thehypervisor 114 may create thevirtual network 210 by configuring the network settings of the virtual machines 202 a-202 c and thevirtual network 210 according to the network settings in thenetwork recovery policy 300 ofFIG. 1 . - The
hypervisor 114 may be computer software, computer firmware, computer hardware, or some combination thereof, of thedestination system 104 ofFIG. 1 , which acts as a host machine. Thehypervisor 114 is configured to create, run, and manage one or more of the virtual machines 202 a-202 c, which each acts as a guest virtual machine. The virtual machines 202 a-202 c are software-based emulations of the physical machines 102 a-102 c ofFIG. 1 that are configured to execute programs in a manner similar to the physical machines 102 a-102 c. - In one example embodiment, the
hypervisor 114 may be a VMware® vSphere® hypervisor, and the image backups 116 a-116 c ofFIG. 1 may be StorageCraft® ShadowProtect® Full (SPF) backup image files. Using the example methods disclosed herein, the VMware® vSphere® hypervisor may create the virtual machines 202 a-202 c using the SPF backup image files. - Although only a single storage is disclosed in each of the physical machines 102 a-102 c of
FIG. 1 , the virtual machines 202 a-202 c ofFIG. 2 , and thedestination system 104 ofFIG. 1 , it is understood that each of these machines or system may instead include two or more storages. Further, although thedestination storage 108 is disclosed inFIG. 1 as being local to thehypervisor 114, it is understood that thedestination storage 108 may be remote from thehypervisor 114. Further, one or more of the image backups 116 a-116 c may be stored remotely from thehypervisor 114. Further, although theBDR module 112 is the only module and thehypervisor 114 is the only hypervisor disclosed in theexample system 100 ofFIG. 1 , it is understood that the functionality of theBDR module 112 and/or of thehypervisor 114 may be replaced or augmented by one or more similar modules and/or hypervisors on thedestination system 104 or on another machine or system that is local to or remote from thedestination system 104. - Having described one specific environment with respect to
FIGS. 1 and 2 , it is understood that the specific environment ofFIGS. 1 and 2 is only one of countless environments in which the example methods disclosed herein may be employed. The scope of the example embodiments is not intended to be limited to any particular environment. -
FIG. 3 is a schematic block diagram illustrating the examplenetwork recovery policy 300 ofFIG. 1 . As disclosed inFIG. 3 , thenetwork recovery policy 300 may be determined prior to a catastrophic event such as an earthquake, fire, or other disaster, in order to allow the network physical machines 102 a-102 c ofFIG. 1 to be restored as networked virtual machines 202 a-202 c ofFIG. 2 using thehypervisor 114 ofFIGS. 1 and 2 . The use of the predeterminednetwork recovery policy 300 may allow advance testing of the virtualization and may avoid a user needing to manually boot the virtual machines 202 a-202 c ofFIG. 2 and manually configure the network settings of thevirtual network 210 ofFIG. 2 during the virtualization, thus avoiding slow user performance and user errors and decreasing downtime during the virtualization. - As disclosed in
FIG. 3 , thenetwork recovery policy 300 may include a boot order for the physical machines 102 a-102 c. This boot order may be designated by the user in terms of a set numerical order (e.g., 1, 2, and 3) or in terms of dependencies (e.g., thephysical machine 102 b depends on physical machines 102), or both. - As disclosed in
FIG. 3 , thenetwork recovery policy 300 may also include a boot timing for the physical machines 102 a-102 c. This boot timing may be designated by the user in terms of a specific amount of time to wait before booting the next machine (e.g. waiting 300 seconds after beginning the boot of thephysical machine 102 a to begin booting the next machine) or in terms of a yes/no flag that specifies that the boot timing should be determined in real-time based on the ready state of the machine being booted (e.g. waiting to boot thephysical machine 102 b until it is determined that thephysical machine 102 a has finished booting and is in a ready state), or both. - As disclosed in
FIG. 3 , thenetwork recovery policy 300 may also include network settings such as network role assignments, static Internet Protocol (IP) addresses, port blocking rules, and port forwarding rules for the networked physical machines 102 a-102 c. The network role assignments may include assigned roles of domain controller, Dynamic Host Configuration Protocol (DHCP) Server, exchange server, another network role assignment, or some combination thereof. Other network settings that may be included in thenetwork recovery policy 300 are Virtual Private Network (VPN) configuration, firewall rules, or some combination thereof for the networked physical machines 102 a-102 c - It is understood that the information stored in the
network recovery policy 300 may apply equally to the virtual machines 202 a-202 c ofFIG. 2 that correspond to the physical machines 102 a-102 c ofFIG. 1 , respectively. Therefore, when the physical machines 102 a-102 c ofFIG. 1 are virtualized by thehypervisor 114 as the virtual machines 202 a-202 c ofFIG. 2 , the information stored in thenetwork recovery policy 300 can be employed by thehypervisor 114 to create the example virtualnetworked restoration system 200 ofFIG. 2 . -
FIG. 4 is a schematic flowchart diagram of anexample method 400 for virtualizing multiple networked machines using a predetermined network recovery policy. Themethod 400 may be implemented, in at least some embodiments, by theBDR module 112 ofFIG. 1 and thehypervisor 114 ofFIGS. 1 and 2 . For example, theBDR module 112 and thehypervisor 114 may be configured as one or more programs stored on one or more non-transitory computer-readable media that are configured, when executed, to cause one or more processors to perform operations of virtualizing the multiple networked physical machines 102 a-102 c ofFIG. 1 using the predeterminednetwork recovery policy 300 ofFIGS. 1 and 3 , as represented by one or more of steps 402-410 of themethod 400. Although illustrated as discrete steps, various steps may be divided into additional steps, combined into fewer steps, or eliminated, depending on the desired implementation. Themethod 400 will now be discussed with reference toFIGS. 1-4 . - The
method 400 may include astep 402 of identifying multiple image backups of multiple networked machines. For example, theBDR module 112 may, atstep 402, identify the image backups 116 a-116 c of the networked physical machines 102 a-102 c, which are stored in thedestination storage 108 of thedestination system 104 ofFIG. 1 . Additionally or alternatively, step 402 may be performed based on a designation of the multiple image backups of the multiple networked machines received from a user. For example, theBDR module 112 may, atstep 402, identify the image backups 116 a-116 c based on a designation of the image backups 116 a-116 c received from a user. This designation may be received from the user, for example, via a graphical user interface (GUI) associated with theBDR module 112 that is configured to allow the user to visually select the image backups 116 a-116 c. Additionally or alternatively, step 402 may be performed based on the multiple image backups of the multiple networked machines belonging to a single backup job. For example, theBDR module 112 may, atstep 402, identify the image backups 116 a-116 c based on the image backups 116 a-116 c belonging to a single backup job. Belonging to a single backup job may entail the image backups 116 a-116 c representing the states of the physical machines 102 a-102 c at a single point in time. - The
method 400 may include astep 404 of determining an order for booting the multiple networked machines as multiple networked virtual machines. For example, theBDR module 112 may, atstep 404, determine an order for booting the networked machines 102 a-102 c ofFIG. 1 as the networked virtual machines 202 a-202 c ofFIG. 2 . Additionally or alternatively, step 404 may be based on a designation of the order received from a user. For example, theBDR module 112 may, atstep 404, determine an order for booting the networked virtual machines 202 a-202 c ofFIG. 2 based on a designation of the boot order received from a user. This designation may be received from the user, for example, via a GUI associated with theBDR module 112 that is configured to allow the user to visually specify a numerical boot order for the networked virtual machines 202 a-202 c, as disclosed inFIG. 3 . Additionally or alternatively, step 404 may be performed based on a designation of dependencies between the multiple networked machines received from a user. For example, theBDR module 112 may, atstep 404, determine an order for booting the networked virtual machines 202 a-202 c ofFIG. 2 based on a designation of dependencies between the networked machines 102 a-102 c ofFIG. 1 received from a user, as disclosed inFIG. 3 . This designation may be received from the user, for example, via a GUI associated with theBDR module 112 that is configured to allow the user to visually input dependencies using graphical elements beyond text including, but not limited to, lines in a hierarchical graph, rows in a chart, and arrows. - Additionally or alternatively, step 404 may include determining a timing for booting the multiple networked machines as the multiple networked virtual machines. For example, the
BDR module 112 may, atstep 404, determine a timing for booting the networked machines 102 a-102 c ofFIG. 1 as the networked virtual machines 202 a-202 c ofFIG. 2 . Additionally or alternatively, the timing may be a specific wait time between the booting of each of the multiple networked machines as multiple networked virtual machines. For example, the timing for thevirtual machine 202 a corresponding to thephysical machine 102 a may be a wait time of 300 seconds before booting thevirtual machine 202 b corresponding to thephysical machine 102 b, as disclosed inFIG. 3 . Additionally or alternatively, the timing may be determined in real-time during the booting of the multiple networked machines as the multiple networked virtual machines based on the timing of each of the multiple networked virtual machines achieving a ready state. For example, the timing for booting thevirtual machine 202 b may be determined in real-time during the booting of thevirtual machine 202 a based on thevirtual machine 202 b being dependent on thevirtual machine 202 a, as designated in the network recovery policy ofFIG. 3 , and based on a real-time determination that thevirtual machine 202 a has achieved a ready state. - The
method 400 may include astep 406 of determining network settings for the multiple networked virtual machines. For example, theBDR module 112 may, atstep 406, determine network settings for the networked machines 102 a-102 c ofFIG. 1 when booted as the networked virtual machines 202 a-202 c ofFIG. 2 . The network settings determined atstep 406 may include network role assignments, static Internet Protocol (IP) addresses, port blocking rules, port forwarding rules, or some combination thereof, for the networked virtual machines 202 a-202 c ofFIG. 2 , as disclosed inFIG. 3 . Additionally or alternatively, the network settings determined atstep 406 may include Virtual Private Network (VPN) configuration, firewall rules, or some combination thereof, for the networked virtual machines 202 a-202 c ofFIG. 2 . The network role assignments for the networked virtual machines 202 a-202 c ofFIG. 2 may include assigned roles of domain controller, Dynamic Host Configuration Protocol (DHCP) Server, exchange server, or some combination thereof. Additionally or alternatively, step 406 may be based on a designation of the network settings received from a user. For example, theBDR module 112 may, atstep 406, determine network settings for the networked virtual machines 202 a-202 c ofFIG. 2 based on a designation of the network settings received from a user. This designation may be received from the user, for example, via a GUI associated with theBDR module 112 that is configured to allow the user to visually specify the network settings for the networked virtual machines 202 a-202 c ofFIG. 2 . - The
method 400 may include astep 408 of storing the order and the network settings in a predetermined network recovery policy. For example, theBDR module 112 may, atstep 408, store the order and the network settings in the predeterminednetwork recovery policy 300 in thedestination storage 108 of thedestination system 104 ofFIG. 1 . Step 408 may be performed prior to booting the networked machines 102 a-102 c ofFIG. 1 as the networked virtual machines 202 a-202 c ofFIG. 2 . - The
method 400 may include astep 410 of booting the multiple networked virtual machines from the multiple image backups in the order stored in the predetermined network recovery policy and with the network settings stored in the predetermined network recovery policy. For example, thehypervisor 114 may, atstep 410, boot the networked machines 102 a-102 c ofFIG. 1 as the networked virtual machines 202 a-202 c ofFIG. 2 from the image backups 116 a-116 c ofFIG. 1 , in the order stored in thenetwork recovery policy 300 ofFIGS. 1 and 3 , and with the network settings stored in thenetwork recovery policy 300 ofFIGS. 1 and 3 . Step 410 may be performed subsequent to step 408 and may be performed in response to receiving a command to implement thenetwork recovery policy 300 ofFIGS. 1 and 3 . Additionally or alternatively, step 410 may include booting the multiple networked machines as the multiple networked virtual machines from the multiple image backups with the timing stored in the predetermined network recovery policy. For example, thehypervisor 114 may, atstep 410, boot the networked virtual machines 202 a-202 c ofFIG. 2 from the image backups 116 a-116 c with the timing stored in thenetwork recovery policy 300 ofFIGS. 1 and 3 . The booting atstep 410 may be automatic. For example, where the command to implement thenetwork recovery policy 300 ofFIGS. 1 and 3 is automatically generated, the booting may be automatic. In one example, the command may be automatically generated in response to only a single action by a user, such as a single click of a single “Virtualize” button, or other button or link, by the user, to implement thenetwork recovery policy 300. This single action by the user, such as a single click of a button, may be performed on a device with a display having a relatively small form factor, such as a mobile phone or tablet. - By the conclusion of
step 410, the virtual machines 202 a-202 c will have been virtualized and networked together over thevirtual network 210. The use of the predeterminednetwork recovery policy 300 may allow advance testing of the virtualization and may avoid a user needing to manually boot the virtual machines 202 a-202 c and manually configure network settings of thevirtual network 210 during the virtualization, thus avoiding slow user performance and user errors and decreasing downtime during the virtualization. - The embodiments described herein may include the use of a special-purpose or general-purpose computer, including various computer hardware or software modules, as discussed in greater detail below.
- Embodiments described herein may be implemented using non-transitory computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media may be any available media that may be accessed by a general-purpose or special-purpose computer. By way of example, and not limitation, such computer-readable media may include non-transitory computer-readable storage media including RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other storage medium which may be used to carry or store one or more desired programs having program code in the form of computer-executable instructions or data structures and which may be accessed and executed by a general-purpose computer, special-purpose computer, or virtual computer such as a virtual machine. Combinations of the above may also be included within the scope of computer-readable media.
- Computer-executable instructions comprise, for example, instructions and data which, when executed by one or more processors, cause a general-purpose computer, special-purpose computer, or virtual computer such as a virtual machine to perform a certain method, function, or group of methods or functions. Although the subject matter has been described in language specific to structural features and/or methodological steps, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or steps described above. Rather, the specific features and steps described above are disclosed as example forms of implementing the claims.
- As used herein, the term “module” may refer to software objects or routines that execute on a computing system. The different modules described herein may be implemented as objects or processes that execute on a computing system (e.g., as separate threads). While the system and methods described herein are preferably implemented in software, implementations in hardware or a combination of software and hardware are also possible and contemplated.
- All examples and conditional language recited herein are intended for pedagogical objects to aid the reader in understanding the example embodiments and the concepts contributed by the inventor to furthering the art, and are to be construed as being without limitation to such specifically-recited examples and conditions.
Claims (6)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/717,133 US20160210199A1 (en) | 2015-01-16 | 2015-05-20 | Virtualizing multiple networked machines using a predetermined network recovery policy |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/599,273 US9087001B1 (en) | 2015-01-16 | 2015-01-16 | Virtualizing multiple networked machines using a predetermined network recovery policy |
US14/717,133 US20160210199A1 (en) | 2015-01-16 | 2015-05-20 | Virtualizing multiple networked machines using a predetermined network recovery policy |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/599,273 Continuation US9087001B1 (en) | 2015-01-16 | 2015-01-16 | Virtualizing multiple networked machines using a predetermined network recovery policy |
Publications (1)
Publication Number | Publication Date |
---|---|
US20160210199A1 true US20160210199A1 (en) | 2016-07-21 |
Family
ID=53540138
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/599,273 Active US9087001B1 (en) | 2015-01-16 | 2015-01-16 | Virtualizing multiple networked machines using a predetermined network recovery policy |
US14/717,133 Abandoned US20160210199A1 (en) | 2015-01-16 | 2015-05-20 | Virtualizing multiple networked machines using a predetermined network recovery policy |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/599,273 Active US9087001B1 (en) | 2015-01-16 | 2015-01-16 | Virtualizing multiple networked machines using a predetermined network recovery policy |
Country Status (4)
Country | Link |
---|---|
US (2) | US9087001B1 (en) |
EP (1) | EP3048531A1 (en) |
JP (1) | JP6122159B2 (en) |
AU (1) | AU2016200242B1 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20230273862A1 (en) * | 2022-02-25 | 2023-08-31 | Netapp, Inc. | Using ephemeral storage as backing storage for journaling by a virtual storage system |
US11775907B1 (en) * | 2021-08-23 | 2023-10-03 | Datto, Inc. | Method facilitating business continuity of enterprise computer network and system associated therewith |
Families Citing this family (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9990222B2 (en) | 2016-03-18 | 2018-06-05 | Airwatch Llc | Enforcing compliance rules against hypervisor and virtual machine using host management component |
JP6586237B2 (en) * | 2016-08-09 | 2019-10-02 | 日本電信電話株式会社 | Resource allocation device and resource allocation method |
US20180063088A1 (en) * | 2016-09-01 | 2018-03-01 | Airwatch Llc | Hypervisor network profiles to facilitate vpn tunnel |
US11108858B2 (en) | 2017-03-28 | 2021-08-31 | Commvault Systems, Inc. | Archiving mail servers via a simple mail transfer protocol (SMTP) server |
US11074138B2 (en) * | 2017-03-29 | 2021-07-27 | Commvault Systems, Inc. | Multi-streaming backup operations for mailboxes |
US10999376B2 (en) * | 2018-01-24 | 2021-05-04 | Walmart Apollo, Llc | Simulating parallel mock rest services with single server |
US11323552B2 (en) * | 2019-04-19 | 2022-05-03 | EMC IP Holding Company LLC | Automatic security configurations in disaster recovery |
CN111541480B (en) * | 2020-04-15 | 2021-03-19 | 燕山大学 | Low-energy-consumption free space optical network restoration method based on reflection characteristics |
US11782623B2 (en) * | 2020-12-15 | 2023-10-10 | International Business Machines Corporation | Transferring an operating image into a multi-tenant environment |
CN114307569B (en) * | 2021-12-17 | 2022-09-16 | 山东国舜建设集团有限公司 | Intelligent operation optimization control system and method for flue gas treatment |
Citations (27)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030126242A1 (en) * | 2001-12-28 | 2003-07-03 | Chang Albert H. | Network boot system and method using remotely-stored, client-specific boot images created from shared, base snapshot image |
US20050278583A1 (en) * | 2004-06-14 | 2005-12-15 | Lennert Joseph F | Restoration of network element through employment of bootable image |
US20070006225A1 (en) * | 2005-06-23 | 2007-01-04 | Microsoft Corporation | System and method for converting a target computing device to a virtual machine |
US20070083655A1 (en) * | 2005-10-07 | 2007-04-12 | Pedersen Bradley J | Methods for selecting between a predetermined number of execution methods for an application program |
US20070136447A1 (en) * | 2005-12-12 | 2007-06-14 | Takao Nakajima | Controlling method, computer system, and processing program of booting up a computer |
US20070186212A1 (en) * | 2006-01-24 | 2007-08-09 | Citrix Systems, Inc. | Methods and systems for providing access to a computing environment |
US20070192466A1 (en) * | 2004-08-02 | 2007-08-16 | Storage Networking Technologies Ltd. | Storage area network boot server and method |
US20070268917A1 (en) * | 2006-05-16 | 2007-11-22 | Oracle International Corporation | Methods and systems for enabling remote booting of remote boot clients in a switched network defining a plurality of virtual local area networks (VLANS) |
US20080183812A1 (en) * | 2001-04-27 | 2008-07-31 | International Business Machines Corporation | Method and System for Fault-Tolerant Remote Boot in the Presence of Boot Server Overload/Failure with Self-Throttling Boot Servers |
US20090276771A1 (en) * | 2005-09-15 | 2009-11-05 | 3Tera, Inc. | Globally Distributed Utility Computing Cloud |
US7761540B2 (en) * | 2006-10-17 | 2010-07-20 | Dell Products L.P. | System and method for automated remote booting in a serial attached SCSI environment |
US8019837B2 (en) * | 2009-01-14 | 2011-09-13 | International Business Machines Corporation | Providing network identity for virtual machines |
US20110238969A1 (en) * | 2010-03-25 | 2011-09-29 | Microsoft Corporation | Intelligent boot device selection and recovery |
US20120011394A1 (en) * | 2009-09-29 | 2012-01-12 | Hitachi, Ltd. | Management method and system for managing replication by taking into account cluster |
US20120150815A1 (en) * | 2010-12-09 | 2012-06-14 | Ibm Corporation | Efficient backup and restore of virtual input/output server (vios) cluster |
US20120204173A1 (en) * | 2007-12-28 | 2012-08-09 | Huan Liu | Virtual machine configuration system |
US20130024726A1 (en) * | 2011-07-20 | 2013-01-24 | Dell Products L.P. | System and method for removable network attached storage enabling system recovery from backup |
US20130054950A1 (en) * | 2011-08-31 | 2013-02-28 | Michael S. Tsirkin | User-controllable boot order through a hypervisor |
US20130185715A1 (en) * | 2012-01-12 | 2013-07-18 | Red Hat Inc. | Management of inter-dependent configurations of virtual machines in a cloud |
US20130212437A1 (en) * | 2009-10-12 | 2013-08-15 | Veeam Software International Ltd. | Item-Level Restoration and Verification of Image Level Backups |
US20130326260A1 (en) * | 2012-06-04 | 2013-12-05 | Falconstor, Inc. | Automated Disaster Recovery System and Method |
US20140195848A1 (en) * | 2013-01-08 | 2014-07-10 | Symantec, Inc. | Methods and systems for instant restore of system volume |
US20140331309A1 (en) * | 2011-04-18 | 2014-11-06 | Bank Of America Corporation | Secure Network Cloud Architecture |
US20140337493A1 (en) * | 2013-05-09 | 2014-11-13 | Wistron Corporation | Client/server network environment setup method and system |
US20140372744A1 (en) * | 2013-06-14 | 2014-12-18 | Futurewei Technologies, Inc. | Bootstrapping From A Remote Disk Image Via A Network |
US20150074659A1 (en) * | 2013-09-06 | 2015-03-12 | Vmware, Inc. | Methods and Apparatus to Perform Web-Based Installations and/or Upgrade Architectures for Enterprise Software |
US20160210161A1 (en) * | 2015-01-21 | 2016-07-21 | Cisco Technology, Inc. | Dynamic, automated monitoring and controlling of boot operations in computers |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4515314B2 (en) * | 2005-04-08 | 2010-07-28 | 株式会社日立製作所 | Computer system configuration reproduction method |
US8819673B1 (en) * | 2007-05-24 | 2014-08-26 | United Services Automobile Association (Usaa) | Systems and methods for java virtual machine management |
JP2010026829A (en) * | 2008-07-22 | 2010-02-04 | Hitachi Ltd | Server having automatic start-up function of logical partition |
JP5530759B2 (en) * | 2010-03-05 | 2014-06-25 | 株式会社エヌ・ティ・ティ・データ | Resource linkage system and resource linkage method |
US8954544B2 (en) * | 2010-09-30 | 2015-02-10 | Axcient, Inc. | Cloud-based virtual machines and offices |
CN103294494B (en) * | 2012-02-29 | 2018-07-03 | 中兴通讯股份有限公司 | A kind of method and system of virtual system automatically dispose |
US9183097B2 (en) * | 2013-06-05 | 2015-11-10 | Sungard Availability Services, Lp | Virtual infrastructure recovery configurator |
-
2015
- 2015-01-16 US US14/599,273 patent/US9087001B1/en active Active
- 2015-05-20 US US14/717,133 patent/US20160210199A1/en not_active Abandoned
-
2016
- 2016-01-15 EP EP16151602.6A patent/EP3048531A1/en not_active Withdrawn
- 2016-01-15 AU AU2016200242A patent/AU2016200242B1/en active Active
- 2016-01-15 JP JP2016006206A patent/JP6122159B2/en active Active
Patent Citations (32)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080183812A1 (en) * | 2001-04-27 | 2008-07-31 | International Business Machines Corporation | Method and System for Fault-Tolerant Remote Boot in the Presence of Boot Server Overload/Failure with Self-Throttling Boot Servers |
US20030126242A1 (en) * | 2001-12-28 | 2003-07-03 | Chang Albert H. | Network boot system and method using remotely-stored, client-specific boot images created from shared, base snapshot image |
US20050278583A1 (en) * | 2004-06-14 | 2005-12-15 | Lennert Joseph F | Restoration of network element through employment of bootable image |
US20070192466A1 (en) * | 2004-08-02 | 2007-08-16 | Storage Networking Technologies Ltd. | Storage area network boot server and method |
US20070006225A1 (en) * | 2005-06-23 | 2007-01-04 | Microsoft Corporation | System and method for converting a target computing device to a virtual machine |
US20090276771A1 (en) * | 2005-09-15 | 2009-11-05 | 3Tera, Inc. | Globally Distributed Utility Computing Cloud |
US8429630B2 (en) * | 2005-09-15 | 2013-04-23 | Ca, Inc. | Globally distributed utility computing cloud |
US20070083655A1 (en) * | 2005-10-07 | 2007-04-12 | Pedersen Bradley J | Methods for selecting between a predetermined number of execution methods for an application program |
US20070136447A1 (en) * | 2005-12-12 | 2007-06-14 | Takao Nakajima | Controlling method, computer system, and processing program of booting up a computer |
US20070186212A1 (en) * | 2006-01-24 | 2007-08-09 | Citrix Systems, Inc. | Methods and systems for providing access to a computing environment |
US20070198656A1 (en) * | 2006-01-24 | 2007-08-23 | Citrix Systems, Inc. | Methods and servers for establishing a connection between a client system and a virtual machine executing in a terminal services session and hosting a requested computing environment |
US20070268917A1 (en) * | 2006-05-16 | 2007-11-22 | Oracle International Corporation | Methods and systems for enabling remote booting of remote boot clients in a switched network defining a plurality of virtual local area networks (VLANS) |
US7761540B2 (en) * | 2006-10-17 | 2010-07-20 | Dell Products L.P. | System and method for automated remote booting in a serial attached SCSI environment |
US20120204173A1 (en) * | 2007-12-28 | 2012-08-09 | Huan Liu | Virtual machine configuration system |
US8019837B2 (en) * | 2009-01-14 | 2011-09-13 | International Business Machines Corporation | Providing network identity for virtual machines |
US20120011394A1 (en) * | 2009-09-29 | 2012-01-12 | Hitachi, Ltd. | Management method and system for managing replication by taking into account cluster |
US20130212437A1 (en) * | 2009-10-12 | 2013-08-15 | Veeam Software International Ltd. | Item-Level Restoration and Verification of Image Level Backups |
US8775781B2 (en) * | 2010-03-25 | 2014-07-08 | Microsoft Corporation | Intelligent boot device selection and recovery |
US20110238969A1 (en) * | 2010-03-25 | 2011-09-29 | Microsoft Corporation | Intelligent boot device selection and recovery |
US20140325202A1 (en) * | 2010-03-25 | 2014-10-30 | Microsoft Corporation | Intelligent boot device selection and recovery |
US20120150815A1 (en) * | 2010-12-09 | 2012-06-14 | Ibm Corporation | Efficient backup and restore of virtual input/output server (vios) cluster |
US20140331309A1 (en) * | 2011-04-18 | 2014-11-06 | Bank Of America Corporation | Secure Network Cloud Architecture |
US20130024726A1 (en) * | 2011-07-20 | 2013-01-24 | Dell Products L.P. | System and method for removable network attached storage enabling system recovery from backup |
US20130054950A1 (en) * | 2011-08-31 | 2013-02-28 | Michael S. Tsirkin | User-controllable boot order through a hypervisor |
US8806186B2 (en) * | 2011-08-31 | 2014-08-12 | Red Hat Israel, Ltd. | User-controllable boot order through a hypervisor |
US20130185715A1 (en) * | 2012-01-12 | 2013-07-18 | Red Hat Inc. | Management of inter-dependent configurations of virtual machines in a cloud |
US20130326260A1 (en) * | 2012-06-04 | 2013-12-05 | Falconstor, Inc. | Automated Disaster Recovery System and Method |
US20140195848A1 (en) * | 2013-01-08 | 2014-07-10 | Symantec, Inc. | Methods and systems for instant restore of system volume |
US20140337493A1 (en) * | 2013-05-09 | 2014-11-13 | Wistron Corporation | Client/server network environment setup method and system |
US20140372744A1 (en) * | 2013-06-14 | 2014-12-18 | Futurewei Technologies, Inc. | Bootstrapping From A Remote Disk Image Via A Network |
US20150074659A1 (en) * | 2013-09-06 | 2015-03-12 | Vmware, Inc. | Methods and Apparatus to Perform Web-Based Installations and/or Upgrade Architectures for Enterprise Software |
US20160210161A1 (en) * | 2015-01-21 | 2016-07-21 | Cisco Technology, Inc. | Dynamic, automated monitoring and controlling of boot operations in computers |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11775907B1 (en) * | 2021-08-23 | 2023-10-03 | Datto, Inc. | Method facilitating business continuity of enterprise computer network and system associated therewith |
US20230273862A1 (en) * | 2022-02-25 | 2023-08-31 | Netapp, Inc. | Using ephemeral storage as backing storage for journaling by a virtual storage system |
US11748204B1 (en) * | 2022-02-25 | 2023-09-05 | Netapp, Inc. | Using ephemeral storage as backing storage for journaling by a virtual storage system |
Also Published As
Publication number | Publication date |
---|---|
JP6122159B2 (en) | 2017-04-26 |
AU2016200242B1 (en) | 2016-06-02 |
EP3048531A1 (en) | 2016-07-27 |
US9087001B1 (en) | 2015-07-21 |
JP2016136384A (en) | 2016-07-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9087001B1 (en) | Virtualizing multiple networked machines using a predetermined network recovery policy | |
US10929244B2 (en) | Optimized backup of clusters with multiple proxy servers | |
US11416342B2 (en) | Automatically configuring boot sequence of container systems for disaster recovery | |
US9600323B2 (en) | Storing and resuming application runtime state | |
US9870288B2 (en) | Container-based processing method, apparatus, and system | |
US11086662B2 (en) | Method and system of migrating applications to a cloud-computing environment | |
US11567757B2 (en) | Container based application reification | |
US8776058B2 (en) | Dynamic generation of VM instance at time of invocation | |
US20150205542A1 (en) | Virtual machine migration in shared storage environment | |
AU2014204468B2 (en) | Virtual machine deployment and management engine | |
US8924969B2 (en) | Virtual machine image write leasing | |
CN107632937B (en) | Method and device for testing virtual machine cluster and readable storage medium | |
US9547514B2 (en) | Maintaining virtual hardware device ID in a virtual machine | |
CN110347483B (en) | Method and device for migrating physical machine to virtual machine and storage medium | |
JP6366726B2 (en) | Method and apparatus for provisioning a template-based platform and infrastructure | |
US20200150950A1 (en) | Upgrade managers for differential upgrade of distributed computing systems | |
CN110268378A (en) | The method for creating the data backup of virtual automation solution, the computer program of implementation method and the virtual server run by method | |
US11157309B2 (en) | Operating cluster computer system with coupling facility | |
JP6075882B2 (en) | Distributed processing system and distributed processing method | |
US10162667B2 (en) | Multi-virtual-machine snapshot using guest hypervisor | |
US11223537B1 (en) | Executing custom scripts from the host during disaster recovery |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: STORAGECRAFT TECHNOLOGY CORPORATION, UTAH Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:CHRISTENSEN, THOMAS FRANK;DERRICK, CHRISTOPHER GLADE;MCCONKIE, DAVID MERRILL, JR.;REEL/FRAME:035678/0690 Effective date: 20150116 |
|
AS | Assignment |
Owner name: SILICON VALLEY BANK, AS ADMINISTRATIVE AGENT, VIRG Free format text: SECURITY AGREEMENT;ASSIGNOR:STORAGECRAFT TECHNOLOGY CORPORATION;REEL/FRAME:038449/0943 Effective date: 20160415 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: STORAGECRAFT TECHNOLOGY CORPORATION, MINNESOTA Free format text: TERMINATION AND RELEASE OF PATENT SECURITY AGREEMENT;ASSIGNOR:SILICON VALLEY BANK, AS ADMINISTRATIVE AGENT;REEL/FRAME:055614/0607 Effective date: 20210316 |