Bug Report

Description

Creation of a new backing image for a running VM fails.

Steps to Reproduce

1. Start experiment
2. Create new backing image for a VM
3. Cry, yell, and scream when it fails with a useless error message

Expected Behavior

A new backing image is created and I don't break anything in a rage of fury.

Actual Behavior

An unhelpful error is displayed, no backing image is created, and I break my keyboard. Oh, and the target image still exists, which is just a copy of the original VM image.

Screenshots

Environment

• Operating System: Arch Linux baby!
• Browser: Firefox of course!
• Version: Of what?

Additional Context

The issue is caused by the snapshot image that minimega creates using a relative path to its backing image, which is the intermediate snapshot that phenix creates for injects. When phenix creates a new backing image, it copies the minimega snapshot (e.g., /tmp/minimega/{id}/disk-0.qc2) to something like /phenix/images/{exp_name}/tmp/{vm_name}.qc2. Since this snapshot is using a relative path to the intermediate snapshot as its backing image (e.g., ../../../phenix/images/node-foo_{exp_name}_{vm_name}-snapshot), this relative path is no longer accurate and an error gets logged about no such file or directory.

The solution is to add a step into the process for creating a new backing image that updates the copy of the minimega snapshot to have its backing image point to the absolute path of the intermediate snapshot, which we will always know the location of.

I plan on creating a PR for this once I can find time to code it up and test it.

Checklist

• I have included no proprietary/sensitive information in my issue.