How can I create Linode with 100% allocated disk space?

Hey @nitesh_sakhiya - this is a really interesting case, and the question has come up before internally. I looked into it, and I'm sorry to say that at this point in time, there's no option to deploy an Image with 100% disk allocation.

Right now, when an Image is deployed the only disk allocation is for that of the Image size itself. For example (as you stated), if your Image size is 4GB, your new deployment will only have 4GB of disk allocated until you shut down the server and reallocate the disk space manually. That means that the behavior you're seeing is expected.

In the interest of full transparency, our team discussed this recently, and it was decided that the option to choose the amount of disk allocation prior to deploying an Image would not be implemented. That doesn't mean it will never happen, but it's not currently on our roadmap.

Based on your use case, it certainly sounds like this would be a pain to get around. Another one of my colleagues offered a potential solution for that revolves around writing a script using the Linode API (disclaimer: I haven't tried this myself). Here's what the script would need to include:

• Use the Linode API to deploy your Image without booting
• Also using the API, reallocate the disk space while the new Linode is powered down
• Boot the Linode

I've included a link above to our API documentation that includes commands and syntax on how to achieve everything that you would normally be able to do in the Cloud Manager. If you haven't used the API before, here's a guide with some good first steps:

Getting Started with the Linode API

I hope this helps a bit! Let us know how it goes if you end up going this route. :)

Hi @jdutton

This is really disappointing not to get 100% allocated disk space when creating a Linode from an image. This might lead us to setbacks from using the Linode cloud. I am surprised that the solution to the issue is not your roadmap.
Also, I had checked out the API documentation. But the thing is scaling up a new Linode server with fully allocated disk space would take at least 5-6 minutes which might not be acceptable for our production workloads.
Another workaround I can think of is if we create a larger size image by adding some junk data in the image and then deleting this junk using shell script or something when the server is created. Can we increase the image size? In the Linode account, I see that the maximum size of image I can create is 4 GB.

Hi @jdutton

I tried creating a Linode server by using the solution you offered. The following are the step if anyone needs to implement the same.

Step 1: Create a Linode server from an image without booting up.

curl -H "Content-Type: application/json" -H "Authorization: Bearer $TOKEN" \
-X POST -d '{
"backups_enabled": false,
"image": "private/imageid",
"root_pass": "somecomplexstring",
"label": "server-name",
"type": "g6-dedicated-4",
"region": "ap-west",
"booted": false
}' \
https://api.linode.com/v4/linode/instances

Step 2: List disks to get the disk id. Use the LinodeID you get in the response of step 1.

curl -H "Authorization: Bearer $TOKEN" \
https://api.linode.com/v4/linode/instances/{LinodeID}/disks

Step 3: Resize the disk.
This API might throw an error if the server is in a provisioning state. Please retry after a few seconds in that case. Use the DiskID received in response of step 2.

curl -H "Content-Type: application/json" \
-H "Authorization: Bearer $TOKEN" \
-X POST -d '{
"size": 160000
}' \
https://api.linode.com/v4/linode/instances/{LinodeID}/disks/{DiskID}/resize

Step 4: Start the Linode server. You might have to implement a retry mechanism in this step as well because resizing disk would take a few seconds.

curl -H "Content-Type: application/json" \
-H "Authorization: Bearer $TOKEN" \
-X POST \
https://api.linode.com/v4/linode/instances/{LinodeID}/boot

Hello @jdutton and others,
In reading over this post, I think there's no reason a new Linode deployed from an image, shouldn't have full disk space allocated to it, perhaps optionally. After all, when you deploy a distribution, this occurs, but I doubt the distributions take up the full size of the space required for a Linode disk. This seems to be simple to achieve, but needlessly complicated for the user to implement at the moment. I would highly recommend you put this on your road map, as I, too, have found it bothersome to create a Linode from an image, shut it down, resize the disk, then boot it back up again. Scripting from the API would be one easier way around it, but only if you're a more advanced user. If you aren't, the cloud manager's way of doing it takes more time than needed.

As an alternative, perhaps you'd consider making the Linode booting after a deployment optional in the cloud manager. It's optional in the linode-cli and API, after all, so why not there, also? That way, the disk could be resized before it's even booted. That would be easier than the cloud manager's way of doing things is currently.

Blake

I totally agree with @tech10.

I created a script to do this.

https://gist.github.com/ryansch/1adefefa50e70b8221025d597263837e

It prompts for inputs and provisions a linode from the selected image, then resizes the primary disk before booting.

I agree that this behaviour is unintuitive, and that the decision not allow for allocating 100% of the space on creation should be revisited.

Thank you to the script-authors above. The scripts have helped me work around this shortcoming in the API.

Not getting the 100% disk allocated is bullshit. No other cloud provider that I know does it this way and I feel like it's simply a way to save disk space (costs) and at the same time not offer the customer what he pays for. This behaviour should definitely be changed as it causes problems for our deployment procedure that we do not face with other providers.