Response on skipping login issue, "iSCSI sessions can be handled better. This is something we'll consider for a future release."

I didn't lose the session client side on a HA fault either. I put a disk offline to create HA failure.

Even a force remove target doesn't remove the session from the client.

Understood but trying to figure out when the session is no longer reported with "iscsiadm -m session". I've already tried a ban and disconnect in StarWind and adding CHAP permissions without updating client config: neither remove the session from the client. As long as the client thinks it...

Here's a scenario that just happened. 1. Took down a StarWind node using service shutdown 2. When the StarWind node was restored it had to do a full sync. 3. When the full sync finished Xen restored the path with no admin action. Does StarWind logout sessions from the out-sync instance(s) upon HA fa...

No update from Xen developers. I am setting up a test instance with a licensed XenServer 7.4 so I can report to XenServer support too.

I created the following perl script which uses PBD metadata / isciadm command to monitor iSCSI sessions and login to down targets. This has to be deployed to each XenServer pool member as a frequently run cron job or similar. Use at your own risk. #!/usr/bin/env perl use Getopt::Long; use strict; us...

Actually, the XenServer multpath recovery works fine as long as there is no need to login to StarWind so the reason for failure does matter.

Well I see it got assigned to a team but yeah no idea how responsive they'll be. Given their track record I'm not holding my breath. I'm going to try to reproduce this on a testing instance then contact XenServer support. Anything you guys can do given you've gone through the certification process a...

I also created https://bugs.xenserver.org/browse/XSO-850.

To be clear, the difference in behavior had nothing to do with how it failed: what mattered is if all paths were up before the event. Here's the worst case scenario: 1. Target 1 goes down 2. Target 1 fixed but not reconnected automatically by XenServer nor even when doing SR repair / xe pbd-plug. 3....

The issue is XenServer doesn't login to down iSCSI targets when the PDB status is attached. I created a XenServer bug on the open source tracker: https://bugs.xenserver.org/browse/XSO-848. You can get more info about my configuration there but nothing further needed from the StarWind side.

Also, XenServer support has been worthless as always with trying to resolve this.

Hello, I'm using XenServer 7.0 configured per https://www.starwindsoftware.com/technical_papers/StarWind-Virtual-SAN-Providing-HA-storage-repositories-for-XenServer-Pool.pdf with a StarWind HA cluster of 2 running 8.0.11456. I plan to update to XenServer 7.2; however, I've checked and the sm package...