The basic idea is that it doesn't create a second VM, so it can't leak. However, it's dependent on a bunch of outstanding work, and needs more testing. It also needs to handle upgrades. I think it's the ultimate solution to this problem, though.
I reviewed Andrew's patch above. I think it's robust and it would be correct (although I haven't actually run it, yet). However, I'm concerned about the performance impact. It adds a call to get_vm_ref_from_name on every destroy(). This is an ugly call, and called here on a rescue image, it would almost always result in an additional call to vim_utils.get_objects(). This is an unfortunate function which traverses every object on the vsphere server to find what it's looking for.
I'll have a look at this in a bit more detail tomorrow. Hopefully I can come up with a slightly cheaper fix until we can do this properly.
Couple of things. Firstly, I wrote a discussion patch to change the way the vmware driver does rescue images here:
https:/ /review. openstack. org/#/c/ 106078/
The basic idea is that it doesn't create a second VM, so it can't leak. However, it's dependent on a bunch of outstanding work, and needs more testing. It also needs to handle upgrades. I think it's the ultimate solution to this problem, though.
I reviewed Andrew's patch above. I think it's robust and it would be correct (although I haven't actually run it, yet). However, I'm concerned about the performance impact. It adds a call to get_vm_ ref_from_ name on every destroy(). This is an ugly call, and called here on a rescue image, it would almost always result in an additional call to vim_utils. get_objects( ). This is an unfortunate function which traverses every object on the vsphere server to find what it's looking for.
I'll have a look at this in a bit more detail tomorrow. Hopefully I can come up with a slightly cheaper fix until we can do this properly.