220-1201 Practice Question: A company uses a Type 1 hypervisor for production…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Snapshot the VM and restore on the new host

  Why it's wrong here

  Snapshots capture a point-in-time state of a virtual machine, including its memory, disk, and configuration files. While useful for backups or testing, restoring a snapshot, especially to a new host, necessitates powering off the original VM, transferring potentially large data files, and then powering on the restored VM. This entire process inherently introduces significant service interruption and downtime, making it unsuitable for a production environment requiring continuous operation.

• ✗

  Use virtual machine cloning

  Why it's wrong here

  Virtual machine cloning creates an exact, independent copy of a VM's virtual disks and configuration, essentially duplicating the entire machine. This method is primarily used for creating templates or deploying multiple identical VMs. However, to prevent conflicts such as duplicate IP addresses, MAC addresses, or Security Identifiers (SIDs) on the network, the original VM typically must be powered off or undergo a system preparation (sysprep) process before the clone can be brought online. This directly results in downtime for the original production service.

• ✓

  Perform a live migration using the hypervisor's built-in feature

  Why this is correct

  Live migration is a sophisticated feature built into type 1 hypervisors that allows a running virtual machine to be moved from one physical host to another without any interruption to the services it provides. The process involves iteratively copying the VM's active memory and CPU state to the destination host while the VM continues to execute on the source, with a final cutover taking only milliseconds. This ensures zero downtime and continuous availability, making it the ideal solution for relocating production VMs.

• ✗

  Export the VM as an OVF and import on the new host

  Why it's wrong here

  Exporting a virtual machine to an Open Virtualization Format (OVF) or Open Virtual Appliance (OVA) package creates a standardized, portable file set containing the VM's virtual disks and configuration. This is highly beneficial for archiving, sharing, or deploying VMs across different hypervisor platforms. However, the fundamental requirement for an export operation is that the source VM must be powered off. Consequently, the VM remains offline until it is successfully imported and powered on at the new destination host, leading to unavoidable service downtime.

Go deeper

Related to this question