Disk validation failed for AWS Import/Export task

Question

I have been trying to convert a Docker image into a VMDK file for creating an AWS AMI using AWS's Import/Export. For that:

1. I have used this guide for creating the .img file from my DockerFile.

2. Now, I am using this command: VBoxManage convertfromraw --format VMDK disk.img disk.vmdk to convert my .img file to a .vmdk file, as IMG format, is unsupported by the AWS service.

However, when I run the Import/Export service, it gives me this error:

"StatusMessage": "ClientError: Disk validation failed [Unsupported VMDK File Format]"

Is there anything which I did wrong in my conversion process?

Answer 1

This may be helpful, not sure exactly why you're getting the issue but others with the problem have been directed here.

http://docs.aws.amazon.com/vm-import/latest/userguide/vmimport-image-import.html

Error importing vmdk files using ec2 developer tools

Answer 2

I have contacted the AWS Support folks regarding the same problem. Their response is as follows:

Unfortunately, importing a Docker image is not supported by VMIE. Since a Docker image is not a fully-virtualized OS, you would not be able to boot into this image even if the import was successful.

---

There is a much simpler solution by running user-data. As far as the code running inside a container is concerned, there isn't a difference between containers or VM's. The code thinks its running on a regular OS. So instead of creating the docker container with the Dockerfile, you can use a user-data script to do the same things on an instance. For example, with ADD in a Dockerfile, it takes files and writes them to the container. We can pull this file from, say S3, and copy it wherever on the instance is needs to go. It will go in the same place that it lives in the container. The RUN directives in a docker file will map 1-to-1 with a user-data script, since these are simply commands. For the CMD directive, we can simply run that process via user-data. Docker volumes are irrelevant, since we have access to the full storage of the instance, so you can ignore the creation of volumes and simply write wherever any files need to go. In summary, your user-data script will replace the Dockerfile for bootstrapping your instance and running your application. Instead of Dockerfile syntax, you will use Bash syntax. Look below for an example script that mimics your Dockerfile.

#! /bin/bash 
pip install --upgrade --user awscli 
sudo aws s3 cp s3://example-bucket/hello / 
sudo chmod +x /hello /hello 

Here is a breakdown of what the script is doing:

1. Makes sure the aws cli is installed

2. Pulls the file "hello" from an S3 bucket, and writes it to '/'

3. Makes sure the file "hello" is executable

4. Executes hello This is essentially what a Dockerfile does in a container, however instead of pulling from S3, it pulls it from the location of the Dockerfile. After adding your file to S3, you can easily pull it in a user-data script. Running this, you won't even need to create a custom AMI, as the bootstrapping is done on instance after bootup. To select the appropriate OS, you can launch a QuickStart Ubuntu AMI and add this user-data script. Additionally, you can continue testing with Docker without issue, you just need to make sure the file "hello" is in sync between your Docker location and the S3 bucket. You can use the S3 Sync command to accomplish this.

Answer 3

I was getting an error like: Disk validation failed [We do not have access to the specified resource. 403 Forbidden]

I knew the role was fine because I've uploaded plenty of images in the past. Sometimes I would use ova format, sometime vmdk, it always worked, until it stopped working.

As mentioned above, the error 'disk validation failed' is helpful. The message 'unable to access the resource' AND the '403 forbidden' had me looking at permission for 2 days. Ultimately, I heeded the warning and looked at the disk validation, not the permission. Sure enough, though my ova had no spaces in the file name, the vmdk inside it had a space in the file name, an the resource couldn't be found. Make sure you extract your ova (or verify with tar tvfz) and verify the disk file name has no spaces in the file name.