OVH Community

Welcome to your community space. Ask questions, search for information, post content, and interact with other OVH Community members.

Detach a boot volume


This post was flagged by the community and is temporarily hidden.

Instance downgrade (eg: B2 => S1-4)
Instance downgrade (eg: B2 => S1-4)

Replying myself, I got it running using openstack command-line client:
openstack server remove volume foo-server foo-data --os-compute-api-version 2.20

That --os-compute-api-version 2.20 is key here!
I think OVH should update Horizon to take that into account.


Errata. This does work for common volume.
It fails for boot volumes.

Can't detach root device volume (HTTP 403) (Request-ID: req-xxx)


This post was flagged by the community and is temporarily hidden.


When it is a root volume it is not possible to detach it. Simple principle here is parent and child scenario. The instance cannot operate without a disk so for this simple reason it won’t allow you to detach the root device.

The only trick here is to delete the instance and then the disk automatically gets detached. You can then resize the disk and create a new instance with the additional volume as the root device. This does mean that you will lose the IP address.

However, you also have a trick for the IP. You just simply buy a Failover IP and any time you recreate the instance, just attach the IP to it.

Don’t want to hassle with the IP? Got an even more simple solution. Buy at least a block of 4 failover IPs and route the IP block into the vRack. You will have 1 IP that will be usable but you can use it on any server that is inside your vRack. Just like in this guide:

Furthermore, we also have on the roadmap L3 networking which can help with the IP situation also: which is already in alpha on some regions:


I’m happy we can reach to the core-problem: If an instance is stopped, or according to OpenStack documentation, shelved (or shutoff ?), then detaching the boot volume must be possible (The stopped instance does not need it)

This would drop the need to delete the instance (loosing the IP addresses and all the related workarounds).

Note: When I initially posted about this limitation last year, it wasn’t for the purpose of scaling-up/down the instance but about quickly resizing of the root volume. Anyway both (common) use-cases need a simple way to detach/resize the root-volume.

Since that’s where (according to OS itself), lays the underlying limitation, that really the kind of cases where I would love to see OVH making the difference and seeing OVH contributing the feature upstream and support it in prime-time at ovh[.]com. That would be so great!


I agree the current methods can cause issues for specific scenarios (especially licensing). However, looking at the discussions, I think there hasn’t really been a research (backed by facts) as to what negative effects could be when detaching the root device from an instance even in shut off state (if there is any). I think the community is stuck in this phase for this feature request.

At OVHcloud we mainly contribute to the upstream in Neutron ( I cannot say that we would be working on implementing new features such as this (not my call). At the moment we are working on expanding the existing features that are on OpenStack but not at OVHcloud yet. Such as LBaaS, FSaaS, Ironic, routers and floating IPs and many other features. You can see our roadmap here with the feature requests we are working on or committed to:

Keep in mind, you can also submit feature requests to us on the above link which will be reviewed by the product developers if we can add it to our back log. So feel free to submit product bug or improvements.

At the moment, the only solution I am able to offer is the previous post I have made.


Do you know why my posts/topics about feature requests where hidden/delisted (supposedly automatically by a SPAM filter)?
Is it related to this thread? Why would a moderator hide such posts?