Why does libvirt go through and update all targets on iSCSI host each time I connect only one target?

Asked by Laz Peterson on 2017-12-18

Hello everyone, I'm a little confused about the behavior of libvirt in Ubuntu 16.04.3. Maybe someone can enlighten me.

We have up to 140 iSCSI targets on a single storage host, and all of these are made available to our VM hosts. If I stop one of the iSCSI pools through virsh and start it back up again while running libvirt in debug, I see that it runs a discovery and proceeds to go through and update every single target available on that host -- even targets that we do not use.

This turns a <1 second process into a minimum of 30 seconds, and I just ran it with the stopwatch and clocked it at 64 seconds. So if we are doing maintenance on these hosts and go for a reboot, it takes 90-120+ minutes to finish auto starting all of the iSCSI pools. And of course, during this period of time, the server is completely worthless as a VM host. Libvirt is just stuck until it finishes connecting everything. Manually connecting to the targets using iscsiadm without doing all the same hubbub that libvirt is doing connects these targets immediately, as I would expect from libvirt.

And for each of the 140 iSCSI targets, it goes through and runs an iscsiadm sendtargets and then updates every single target before finally connecting the respective pool.

How can we simply connect to the target without all the extra time wasted?

We also noticed that libvirt in Ubuntu 17.10 does not have this behavior. Well maybe it does, but it connects the iSCSI targets immediately. It is a much different process than Ubuntu 16.04.3.

Any help would be greatly appreciated. Thank you so much.

Question information

English Edit question
Ubuntu libvirt Edit question
No assignee Edit question
Solved by:
Manfred Hampl
Last query:
Last reply:
Best Manfred Hampl (m-hampl) said : #1

I suggest that you create a bug report.

Laz Peterson (laz-v) said : #2

Thanks Manfed. Bug report created.

Laz Peterson (laz-v) said : #3

Thanks Manfred Hampl, that solved my question.