The problem persists despite me trying to manually change LUN ID on the
target (scsi-target-utils installed on centos 6.3) .. does anyone know how
to make ovirt (or vdsm?) based on iqn + lun id ? I'd think it'd resolve the
issue I'm having.
Anyone ?
Thanks,
Alex
On 28 February 2013 16:30, Alex Leonhardt <alex.tuxx(a)gmail.com> wrote:
FWIW, restarting the HV "resolves" the issue and brings the
storage domain
back up; but I dont know whether that is because that's where the target
(and iscsi initiator) runs or whether vdsmd then clears its cache / routes
to a/the target(s) ?
Alex
On 28 February 2013 16:25, Alex Leonhardt <alex.tuxx(a)gmail.com> wrote:
> another screenshot of how confused it can get
>
> alex
>
>
> On 28 February 2013 15:36, Alex Leonhardt <alex.tuxx(a)gmail.com> wrote:
>
>> Hi there,
>>
>> I was doing some testing around ovirt and iscsi and found an issue where
>> as when you use "dd" to create "backing-stores" for iscsi and
you point
>> ovirt to it to discover & login, it thinks the LUN ID is the same although
>> the target is different and adds additional paths to the config
>> (automagically?) bringing down the iSCSI storage domain.
>>
>> See attached screenshot of what I got when trying to a "new iscsi san
>> storage domain" to ovirt. The Storage Domain is now down and I cannot get
>> rid of the config (???) how do I force it to logout of the targets ??
>>
>> Also, anyone know how to deal with the duplicate LUN ID issue ?
>>
>> Thanks
>> Alex
>>
>> --
>>
>> | RHCE | Senior Systems Engineer |
www.vcore.co |
www.vsearchcloud.com|
>>
>
>
>
> --
>
> | RHCE | Senior Systems Engineer |
www.vcore.co |
www.vsearchcloud.com |
>
--
| RHCE | Senior Systems Engineer |
www.vcore.co |
www.vsearchcloud.com |
--
| RHCE | Senior Systems Engineer |
www.vcore.co |
www.vsearchcloud.com |