nova volume-detach falha silenciosamente, compute log mostra libvirtError: argumento inválido: no target device vdb

Question

Usando o Openstack Havana, estou tentando separar um volume de cinza de uma nova instância.

Nova lista de volumes mostra como em uso:

| 34b0ea26-f85c-4b62-8ebd-884b0e63e2d5 | in-use | filestore | 256  | None| 4d05ffe4-d30a-4c93-b710-c9ec80dad1c2 |

O volume está conectado via iscsi:

# iscsiadm -m session
tcp: [5] 10.3.40.10:3260,1 iqn.2010-10.org.openstack:volume-34b0ea26-f85c-4b62-8ebd-884b0e63e2d5 (non-flash)

É visível como / dev / vdb dentro da instância e é montável e lido / gravável.

No entanto, depois de desmontá-lo na instância e emitir

# nova volume-detach 4d05ffe4-d30a-4c93-b710-c9ec80dad1c2 34b0ea26-f85c-4b62-8ebd-884b0e63e2d5

não se destaca. O volume fica rotulado "em uso". Eu recebo este erro no compute.log:

libvirtError: invalid argument: no target device vdb

Quando executo "virsh edit 4" no nó de cálculo, o dispositivo de disco para vdb está de fato ausente. No entanto, quando eu executo "virsh dumpxml 4" ainda está lá!

Como posso desemaranhar isso?

Virsh dumpxml vs. link

Compute.log do erro: link

    

Answer 1

Consegui sincronizar a configuração do libvirt copiando o XML do xml dump para o seu próprio arquivo e, em seguida, atualizando-o de volta para a configuração atual via

virsh attach-device 4 filestore.xml --config

Depois disso, reran nova volume-detach. Conseguiu limpar o nó de cálculo, a sessão iscsi está agora inativa. No entanto, agora o volume estava preso no status "desanexando". Nenhum erro em lugar algum, nenhuma ideia de por que ele não voltou para "disponível". O tgt-admin permitiu que eu o colocasse off-line e de volta ao estado pronto, então eu retornei ao status disponível com o estado de reset do cinder.