Comment 9 for bug 1396965

I second the issue here. There are several use cases where having the ability is crucial for operation. Changing a MAC / IP address can be prohibitive in some environment. Consider setups where security is relevant and any changes need to go through a manual review process or when you are using provider nets with interconnects to real existing devices (like RSA token server, etc.) where you just can't have systems change their mac and/or ip addresses.

You need the ability in such cases.

Here's a manual workaround (read: hack) to make it work. I am actually in the process of codifying this into our tooling as this is something we need and cannot wait another year until someone re-enables this.

I write this down here in the hope that it may help others stuck here. Note that perhaps not all these steps are necessary for you. They are for us as we're booting from volumes generated from snapshotted images (on ceph) ie: on nova show serverId I have "Attempt to boot from volume - no image supplied" in the image columns.

- Detaching:
 first ensure VM is stopped
 cinder reset-state --state available oldVolumeId
 mysql cinder 'delete from volume_attachment where volume_id = oldVolumeId';
 mysql cinder 'update volumes set attachment_status="detached" where id = oldVolumeId';
 mysql nova 'delete from block_device_mapping where not deleted and volume_id = oldVolumeId';
 nova volume-attach serverId newVolumeId
 cinder delete oldVolumeId
 mysql nova 'update block_device_mapping set device_name = "/dev/vda" where instance_uuid = serverId';

Now very important, you need to execute this to regenerate the libvirt xml file (it would have bad disk references and would not start otherwise):

nova reboot --hard serverId

Now you should have the new volume mounted, the old deleted (obviously omit that step if you need to keep it) and the vm booting with the new one.

Things that I noticed. Prior to this process, nova volume-detach server volume failes with the known root volume cannot be removed message. Afterwards this procedure it works. For some reason nova thinks the volume is vdb (ie second volume). You see this if you do a volume-detach then volume-attach where it will always be displayed as vdb and you will always need to do the update device mapping to vda and nova reboot --hard to make it start. If anyone knows where to kick nova so that it will accept this new volume as root / vda, I'll happily amend the procedure.

I hope this is useful information until this bug results in working volume-attach / detach for root volumes again.