Abstract: Exemplary embodiments described herein relate to a destination path for use with multiple different types of VMs, and techniques for using the destination path to convert, copy, or move data objects stored in one type of VM to another type of VM. The destination path represents a standardized (canonical) way to refer to VM objects from a proprietary VM. A destination location may be specified using the canonical destination path, and the location may be converted into a hypervisor-specific destination location. A source data object may be copied or moved to the destination location using a hypervisor-agnostic path.

Abstract: Exemplary embodiments described herein relate to a destination path for use with multiple different types of VMs, and techniques for using the destination path to convert, copy, or move data objects stored in one type of VM to another type of VM. The destination path represents a standardized (canonical) way to refer to VM objects from a proprietary VM. A destination location may be specified using the canonical destination path, and the location may be converted into a hypervisor-specific destination location. A source data object may be copied or moved to the destination location using a hypervisor-agnostic path.

Abstract: Exemplary embodiments described herein relate to a destination path for use with multiple different types of VMs, and techniques for using the destination path to convert, copy, or move data objects stored in one type of VM to another type of VM. The destination path represents a standardized (canonical) way to refer to VM objects from a proprietary VM. A destination location may be specified using the canonical destination path, and the location may be converted into a hypervisor-specific destination location. A source data object may be copied or moved to the destination location using a hypervisor-agnostic path.

Abstract: A virtual disk conversion system determines location ranges for data on a storage device that are found in files representing a virtual disk in a source format. An intermediate virtual disk data structure containing the location ranges for the data is generated, and the intermediate virtual disk data structure is used to associate data at the location ranges with a new file on the storage device that represents a virtual disk in a destination format.

Abstract: A virtual disk conversion system determines location ranges for data on a storage device that are found in files representing a virtual disk in a source format. An intermediate virtual disk data structure containing the location ranges for the data is generated, and the intermediate virtual disk data structure is used to associate data at the location ranges with a new file on the storage device that represents a virtual disk in a destination format.

Abstract: Exemplary embodiments provide techniques for managing VM migrations that use relatively simple and uncomplicated commands or APIs that can be executed through scripts or applications. Configuration and preparation for the conversion may be addressed by one set of command-lets or APIs, while the conversion itself is handled by a separate set of command-lets or APIs, which allows the conversion command-lets to be uncomplex and to require little input. Moreover, the architecture-specific commands can be largely abstracted away, so that the configuration and conversion processes can be carried out through straightforward general commands, which automatically cause an interface (e.g., at the conversion server) to call upon any necessary architecture-specific functionality.

Abstract: Exemplary embodiments provide techniques for managing VM migrations that use relatively simple and uncomplicated commands or APIs that can be executed through scripts or applications. Configuration and preparation for the conversion may be addressed by one set of command-lets or APIs, while the conversion itself is handled by a separate set of command-lets or APIs, which allows the conversion command-lets to be uncomplex and to require little input. Moreover, the architecture-specific commands can be largely abstracted away, so that the configuration and conversion processes can be carried out through straightforward general commands, which automatically cause an interface (e.g., at the conversion server) to call upon any necessary architecture-specific functionality.

Abstract: The present application provides exemplary methods, mediums, and systems for converting a virtual machine from management by one type of hypervisor to management by a second, different type of hypervisor. The exemplary method involves: (1) discovering information about the source VM; (2) making a backup copy of the source VM data (3) storing the information in the source VM; (4) copying the source VM data using cloning; (5) starting the destination VM with the cloned data by attaching the copied disks to the destination VM; (6) restoring the source VM to its original state; and (7) starting the destination VM and applying the saved system configuration to a destination guest OS. In some embodiments, the first type of hypervisor (the source hypervisor) may be a Hyper-V hypervisor, and the second type to hypervisor (the destination hypervisor) may be a VMware hypervisor.

Abstract: Exemplary embodiments described herein relate to a destination path for use with multiple different types of VMs, and techniques for using the destination path to convert, copy, or move data objects stored in one type of VM to another type of VM. The destination path represents a standardized (canonical) way to refer to VM objects from a proprietary VM. A destination location may be specified using the canonical destination path, and the location may be converted into a hypervisor-specific destination location. A source data object may be copied or moved to the destination location using a hypervisor-agnostic path.

Abstract: Techniques to dynamically generate real time frequently asked questions from forum data are described. In one embodiment, for example, an apparatus may comprise a preprocessor, a validator, a data module, and a list regenerator. The preprocessor may be operative to receive a user entry to a forum and to generate a processed entry. The validator may be operative to receive the processed entry, to receive an accuracy rating for the processed entry from a data module, and to forward the processed entry for inclusion in an existing frequently-asked-questions (FAQ) list based on the accuracy rating and rules. The data module may be operative to receive the processed entry and to determine the accuracy rating of the processed entry. The list regenerator may be operative to receive the processed entry and to regenerate the existing FAQ list into an updated FAQ list including the processed entry. Other embodiments are described and claimed.