Ynt: Virtual Image Lifecycle

[seanobrien]

I'm creating custom windows virtual images.  But unsure on how to handle the lifecycle of the windows template image.  

FYI all this would be done via the API as i intend to automate this process.  

If i was to create a new windows template, i'd create the virtual image and then upload the the template as an image file

POST: https://{serverURL}/api/virtual-images
POST: https://{serverURL}/api/virtual-images/{virtualImageId}/upload?filename=NEWFILE

After the image is mapped to the node, this works perfect.  I'm able to provision instances of the virtual image.

The question i have is , if i want to update the windows template.  How should I approach this in morpheus ?  It doesn't seem like you should recreate the virtual image as there can be instances associated with the original virtual image. 

I thought since there is an image file, i could just replace it with new template.  

DELETE: https://{serverURL}/api/virtual-images/{virtualImageId}/files?filename=OLDFILE

POST: https://{serverURL}/api/virtual-images/{virtualImageId}/upload?filename=NEWFILE

However, when i then attempt to provision an instance i get the following error
Error: Failed to create server volumes: Failed to clone volume: qemu-img: Could not open '/mnt/6a611573-f3ea-46e6-aeee-7081a1eb3700/WindowServer2019_199-disk-0-e9540bf': Could not open '/mnt/6a611573-f3ea-46e6-aeee-7081a1eb3700/WindowServer2019_199-disk-0-e9540bf': No such file or directory

One thing i did notice is that when getting the virtual image to get the filename. I get this
>>> response.json()["virtualImage"]["config"]["diskIds"]
[{'name': 'windows_server_2019.qcow2', 'path': 'morpheus-virtual-images/305/output/windows_server_2019.qcow2', 'uniqueId': 'a861967b-a831-412b-800b-5d70ece11275'}]

I then use the path as the filename of the delete request.  Which returns success.  If i run again, it then returns 'file not found', which would suggest it deleted.  However if i then get the virutal image, the filepath is still there. So not sure if that's a bug. 

Any guidance would be appreciated. 

[duru19]

Hello,

Based on the behavior you are seeing, I would avoid treating the Virtual Image file as something that can be safely replaced in-place under the same Virtual Image ID.

A Virtual Image in Morpheus is not only the uploaded file. It also has metadata such as disk IDs, paths, unique IDs, and image location/cache references on the target cloud or HVM cluster. For uploaded/local images, Morpheus may copy the image to the target during the first provision, and subsequent provisions can continue to use the target-side copy if it is still present.

In this case, deleting the old file appears to remove the backing file, but the Virtual Image metadata still references the previous disk/path. That would explain why qemu-img is later trying to clone from a path that no longer exists.

For image lifecycle management, I would recommend using an immutable/versioned image model instead:

Create a new Virtual Image for each updated Windows template.
Upload the new QCOW2/VMDK file to the new Virtual Image.
Validate provisioning from the new image.
Update the Node Type / Layout / Catalog Item / automation to reference the new Virtual Image ID.
Keep the old Virtual Image until no active workflows depend on it, then remove it cleanly, including the target image locations if required.

If the old Virtual Image still shows the deleted disk path in config.diskIds after the file removal, I would treat that as stale metadata or an unsupported update path and open a support case with HPE/Morpheus to confirm whether the file replacement workflow is expected to be supported.

[duru19]

The following link may be helpful for you; I kindly request that you review it.

https://hpevm-docs.morpheusdata.com/en/8.0.6-vme/provisioning/requirements.html

[seanobrien]

Thank you for the information.  Yes this seems to be the case, i just wasn't sure if this was expected behaviour when working with the image file as there is an API to both add and remove the image files.  And it offered the easier workflow as you don't have to recreate, delete and remap the virtual image to the nodes etc. 

I will follow your suggested workflow.  I had concerns as there did appear to be an instance association with the virtual image.  But i tested deleting the virtual image which had a running instance and it's fine.  It appears to be just cosmetic. 

Thanks again.  

[duru19]

Hello Seanobrien,

I am glad to hear that your issue has been resolved. Please keep us informed of any further updates.

If you are satisfied with the responses, please click the “Accept as Solution” button on the most helpful answer so that it can benefit all community members.

Please also consider giving a “Kudo” by clicking the “Thumbs Up/Kudo” icon.