I have a volume which is shown as attached to a destroyed machine. This prevents me from destroying the volume or attaching it to another machine.
Interestingly the error message I get when trying to destroy the volume tells me it is attached to a different machine to the one shown through fly volumes show. Both of the machines have been destroyed.
This all came about when I tried to use the machines API to unmount a volume from one machine and mount it on another.
> fly volume list
ID STATE NAME SIZE REGION ZONE ENCRYPTED ATTACHED VM CREATED AT
vol_5podq4q1q2nvg8w1 created shared 50GB lhr 81b8 true 1781113a9d40d8 5 days ago
> fly volume destroy vol_5podq4q1q2nvg8w1
Error failed destroying volume: volume is currently bound to machine: 3d8d5d2b276d89
> fly machine list
No machines are available on this app ...
Would you mind trying again? We’ve deployed a fix that checks for the machine state if a volume is still showing as claimed. The underlying issue looks to be where a machine config has a volume and then a machine update occurs without declaring a volume and leaves the claim around.
The volume is still showing as attached to a machine but destroying it worked this time.
The machine update you described was one I intentionally performed through the API in an attempt to unmount the volume. I take it that this is not supported.
I missed this in the original post and looking at the machine config for 1781113a9d40d8 makes me think there was another issue that occurred at some point which we’ll look into.
It should be supported so we’ll have another follow-up change soon to address this.
@JP_Phillips Hi there, I seem to have encountered the same issue.
It’s with vol vol_jlgz1vpdm92v78m3 and machine 73d8d34df4d989.
The VM seems destroyed, fly vol list says the volume is attached and when I run a new machine with the volume, the CLI errors:
@sh4rk I’ve resolved the issue so you should be able to use the volume again with a new machine. There’s an edge case where once a machine is created, you cannot later add a volume because there’s no guarantee (right now) that the volume and machine will be on the same underlying host. We’ll likely get a fix in soon to prevent updating a machine with a volume if the initial version did not define one (or defined a different one).