Created attachment 944274 [details] vdsm and setup logs Description of problem: Executed hosted-engine deployment using iSCSI storage. The execution failed because I had an engine VM already running from a previous deployment. As part of rolling back the deployment, the host doesn't disconnect from the iSCSI storage server, it remains connected to the target. Version-Release number of selected component (if applicable): vdsm-4.16.5-2.el7.x86_64 ovirt-hosted-engine-setup-1.2.0-1.el7.noarch How reproducible: Always Steps to Reproduce: 1. Run hosted-engine --deploy while having a VM still running on the host [ INFO ] Stage: Programs detection [ INFO ] Stage: Environment setup [ ERROR ] The following VMs has been found: 5d832ee1-e066-4087-bc30-a18faffde6ec [ ERROR ] Failed to execute stage 'Environment setup': Cannot setup Hosted Engine with other VMs running [ INFO ] Stage: Clean up [ INFO ] Generating answer file '/etc/ovirt-hosted-engine/answers.conf' [ INFO ] Answer file '/etc/ovirt-hosted-engine/answers.conf' has been updated [ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination Actual results: Host doesn't disconnect its open iSCSI session with the storage server after the deploy failure [root@green-vdsb ~]# iscsiadm -m session tcp: [2] 10.35.146.129:3260,1 iqn.2008-05.com.xtremio:001e675b8ee0 (non-flash) Expected results: Host should clean its session with the iSCSI target after a deploy failure Additional info: vdsm and setup logs
This happens also on NFS, storage is not disconnected on failure for allowing further investigation. It may be worth to add a question about closing storage connection on failure.
Maybe this should be an RFE for adding such question.
Disconnecting during cleanup may be harmful in some scenarios as you may have running VMs. The way to handle it will be to add a flag to the answer file which allows killing the storage connection.
I see no value in disconnecting, except that you might have connected to the wrong storage / LUN / ... I'd close-wontfix until we hear of a real life scenario where this is required.
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions
Agree with comment #4. Closing.