openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #22118
Re: Libvirt iSCSI client: duplicit connection_info data
On Wed, Mar 20, 2013 at 5:06 PM, Vishvananda Ishaya
<vishvananda@xxxxxxxxx> wrote:
>> 2) Wipeout connection_info after disconnect. At least for Netapp
>> provider it makes no sense to retain the info which is no longer valid
>> anyway.
>
> This seems reasonable. In fact, the whole block_device_mapping item
> can be deleted after disconnect.
You cannot delete the whole bdm entry when you stop an instance. Volume
is disconnected but you still need that info for next start-instance to reattach
the volume.
You could nullify 'connection_info' value in bdm.. but I have never
seen bdm with
connection_info blank. No idea how many things that would break..
> I need a little more context to
> understand if this will actually help the issue that you are seeing
If there is no information in bdm that this volume *had* LUN id 5, then there
is no way somebody will send it down to disconnect_volume. And no way
for me to delete a wrong device which happens to be using LUN id 5 now.
> though. The double disconnects are usually very close together, so
> there shouldn't be a new lun assigned in between two of them anyway.
> Have you identified a case where a second disconnect is called much
> later?
Yes.
The first disconnect is when you stop an instance with attached volume.
The second one is when you terminate that stopped instance.
https://github.com/openstack/nova/blob/stable/essex/nova/virt/libvirt/connection.py#L470
In-between those two disconnects, the volume is in state
'available/detached' and there
is a (non-deleted) bdm entry with connection_info regarding the last attachment.
Regards,
Brano Zarnovican
Follow ups
References