Upload/Download Virtual Disks

If I am using the APIs to create new VMs or clone existing ones, and I want to update the virtual disk image or download a virtual disk image for an existing VM is the NFS mount the correct/preferred way to do this or is there another API to do this through the image service? I see APIs in the old REST API for images, but it is not clear how to determine the upload/download URLs.

Also, is it possible to access the same image conversion functionality that the image service provides from the Prism UI so images can be uploaded in a compressed format?

Thanks
Bob

icon

Best answer by ckousoulis22 September 2016, 17:41

Both of the options you discussed go through the Image Service, so you can transfer a qcow2 either way and let the Image Service unpack it.

The only difference is in the requirement from the API client. Transfering a disk to the Image Service from a URL accessible to the cluster is as easy as one POST with the appropriate URL parameter in the body. Transferring a disk to the Image Service from a local file (that you aren't serving in any way) is a POST (to create the image metadata) followed by a PUT at /upload URL to stream the bytes (in this case the API client participates in the image transfer). As an example, the Prism UI sets a DOM File object as the 'data' in the body of the PUT and specifies a 'contentType' of 'application/octet-stream'. The browser handle the rest, but we can help you author a non-browser app that has this behavior. I'll try and locate some sample code.

7 replies

if they want to download a disk attached to a VM they would have to do it through NFS. For uploading, they could go through image service in the UI and then attach the disk to the VM. If they want to use the REST API to do the upload they can do PUT /images//upload. the body of that REST API should just be the raw image itself.

Prism UI has an Image Configuration popup that is accessible from the Settings Gear icon in the top-right. That UI allows you to create an Image from a local file or a URL (to the disk file on a file server that is accessible to the cluster), and both paths go through the Image Service conversion functionality. Once uploaded to the Image Service, the disk can be attached to any AHV VM through the Disks section in the Create/Update VM popup. Note: a (thin) clone of the image is attached as a disk to the VM. Images are read-only.

For workflows where you have a disk image (or ISO) that you want multiple VMs to use or you want to update the disk image independently of the VM, the Image Service is the way to go. Prism has all the UI to upload disks and attach them to VMs. There is no UI to export an Image or VM to an external format. If you require that we can point you to a KB which describes that manual procedure.

You can also mount ADSF via NFS, transfer a disk file, then use the Create/Update VM popup in the Prism to attach that file as a disk to the VM. This path does not go through the Image Service, so it's up to you to do any kind of conversion required on the disk file. Personally, I think the Image Service UI will suit you better, as its intention is to provide a repository of disk images that one/many VMs can use. The "export" feature will be added to the product, eventually.

For uploading images via REST API, in my opinion it is easier to provide a URL to the file in the POST request. For example, if you have an ISO on your laptop that you want to upload to the Image Service via API, run python -m SimpleHTTPServer in the directory containing the image, and then use the public IP address of your laptop to create a URL that can be passed in the body of the /images POST. We can provide more precise details, if this is what Bob wants to do.

If we upload through this mechanism /images/{imageid}/upload or by providing a local URL as ckousoulis suggests and let Acropolis pull the image, does either mechanism go through the image service and therefore provide the conversion from a more compressed format (i.e. qcow2) to a raw image format, or must that conversion be done before hand.

From the documentation of the Image Service UI, it seems that whatever API it is using does conversion on upload so less bandwidth is used.

What I'm working on is an integration with AHV, so the UI is not an option, but I was hoping to leverage the conversion capabilites of the image service to reduce the amount I need to upload.

I do have the NFS model of file transfer working from our product, but from there I clearly need to copy the raw image and not a compressed one.

Both of the options you discussed go through the Image Service, so you can transfer a qcow2 either way and let the Image Service unpack it.

The only difference is in the requirement from the API client. Transfering a disk to the Image Service from a URL accessible to the cluster is as easy as one POST with the appropriate URL parameter in the body. Transferring a disk to the Image Service from a local file (that you aren't serving in any way) is a POST (to create the image metadata) followed by a PUT at /upload URL to stream the bytes (in this case the API client participates in the image transfer). As an example, the Prism UI sets a DOM File object as the 'data' in the body of the PUT and specifies a 'contentType' of 'application/octet-stream'. The browser handle the rest, but we can help you author a non-browser app that has this behavior. I'll try and locate some sample code.

Thanks. That answers my question. I'll probably go with using the PUT /upload API as that more closely fits with similar things we have done in other areas. It should not be a problem wrinting the non-browser code as we have similar code that uploads files to other places using similar means. However, I'll take any samples if you have them.

Here's an example with cURL. Note the "X-Nutanix-Destination-Container" header which needs to be provided for the /upload to tell Prism on which storage container in ADSF you want the image data to be stored.

Cookie policy

Cookie settings

We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.