Copying an environment with running VMs

For production systems and other VMs that you can’t shut down, Skytap supports copying an environment with running VMs (live clone). With just a few clicks, you can quickly copy an entire complex environment, including the VMs, networks, and environment settings. You can also save an environment with running VMs to a template without suspending or shutting down the environment or any of the VMs in it.

After you’ve copied an environment, changes to the copied environment won’t affect the source environment. The source and copy are unlinked, separate resources.

Contents

You can create a copy of an environment with running VMs only in the same region as the source environment. To copy an environment to a different Skytap region, see Copying an environment to another region.

We recommend that you reduce application activity—particularly database activity—to a minimum for all running VMs before you copy the environment. For more information, see quiescing VM activity.

Copying an environment in the same region

  1. Navigate to the Environment page.

    Environment Details page

  2. Click Copy in the top toolbar.

    Environment details top menu - copy

  3. The Copy Environment window displays. The current region is selected as the Destination Region. To copy to another region, see Copying an environment to another region.

    Copy Environment Window

  4. Edit the Environment name or accept the default.
  5. Select Copy VMs while they’re running.

  6. Optionally select a Project for the new environment. For more information about projects, see Sharing resources with projects.

  7. Click Copy. The detail page for the new environment displays, but you can’t interact with it until the process is complete.

    If you leave the copy page or sign out of Skytap, the copy process continues automatically. Skytap sends you an email when the copy process is complete.

Changes to an environment during the copy process

Generally, a copied environment is a duplicate of the original. Almost all of the environment settings (notes, labels, etc.), VM settings (MAC addresses, hostnames, CPUs, storage, etc.), and network settings (network subnet, gateway IP address, etc.) remain the same.

There are only a few places where the copy differs from the original.

Setting

Change to copied environment

Published services

Skytap creates a new published service that maps the same internal port to a new external port address. For example:

Port 80 open at services-uscentral.skytap.com:12345

changes to:

Port 80 open at services-uscentral.skytap.com:78901

Sharing portals

Skytap creates sharing portals for the new environment with the same settings and new, unique access links.

Public IPs

  • Static public IPs: The VM in the new environment has the same public IP address attached to it. When the same static public IP address is attached to multiple VMs, only one of these VMs can run at a time.
  • Dynamic public IPs with DNS: Skytap automatically generates a new, unique domain name for the VM in the new environment. When the VM is run, Skytap automatically deploys an available public IP address.

Connections to networks in other environments (ICNR)

The network in the new environment isn’t connected to other networks. To connect it, see Networking between environments.

Schedules

The new environment does not have any schedules. To create one, see Automating actions with schedules.

Auto-shutdown

The new environment inherits the account-wide auto-shutdown setting.

Power state

If the VMs in the source environment were running, they are suspended or powered off during the copy operation.

Canceling a copy operation

To cancel the copy operation, click Delete on the right side of the progress bar.

Sharing portals

If an environment has sharing portals, they will also be copied.

When an environment with sharing portals is copied to a new environment, Skytap creates new sharing portals with the same access settings, but with new, unique access URLs. Expiration date and times are automatically adjusted, as described below.

Sharing portal expiration date settings

The expiration date and time is saved with the sharing portal. When the copied environment is started, the expiration date for the new sharing portal is adjusted so that the new sharing portal has the same amount of remaining time available as the original sharing portal.

For example:

  • A sharing portal that expires on January 20 at 12PM is copied to a new environment on January 10 at 10AM. The sharing portal has 10 days and 2 hours remaining.
  • When the new environment is started on February 1 at 12 PM, the new sharing portal expires at February 11 at 2 PM. The new sharing portal also has 10 days and 2 hours remaining.