[ovirt-users] iSCSI storage domain and multipath when adding node

[Gianluca Cecchi]

On Mon, Apr 10, 2017 at 2:44 PM, Ondrej Svoboda <osvoboda at redhat.com> wrote:

> Yes, this is what struck me about your situation. Will you be able to find
> relevant logs regarding multipath configuration, in which we would see when
> (or even why) the third connection was created on the first node, and only
> one connection on the second?
>
> On Mon, Apr 10, 2017 at 2:17 PM, Gianluca Cecchi <
> gianluca.cecchi at gmail.com> wrote:
>
>> On Mon, Apr 10, 2017 at 2:12 PM, Ondrej Svoboda <osvoboda at redhat.com>
>> wrote:
>>
>>> Gianluca,
>>>
>>> I can see that the workaround you describe here (to complete multipath
>>> configuration in CLI) fixes an inconsistency in observed iSCSI sessions. I
>>> think it is a shortcoming in oVirt that you had to resort to manual
>>> configuration. Could you file a bug about this? Ideally, following the bug
>>> template presented to you by Bugzilla, i.e. "Expected: two iSCSI sessions",
>>> "Got: one the first node ... one the second node".
>>>
>>> Edy, Martin, do you think you could help out here?
>>>
>>> Thanks,
>>> Ondra
>>>
>>
>> Ok, this evening I'm going to open a bugzilla for that.
>> Please keep in mind that on the already configured node (where before
>> node addition there were two connections in place with multipath), actually
>> the node addition generates a third connection, added to the existing two,
>> using "default" as iSCSI interface (clearly seen if I run "iscsiadm -m
>> session -P1") ....
>>
>> Gianluca
>>
>>
>
>
vdsm log of the already configured host is here for that day:
https://drive.google.com/file/d/0BwoPbcrMv8mvQzdCUmtIT1NOT2c/view?usp=sharing

Installation / configuration of the second node happened between 11:30 AM
and 01:30 PM of 6th of April.

Aound 12:29 you will find:

2017-04-06 12:29:05,832+0200 INFO  (jsonrpc/7) [dispatcher] Run and
protect: getVGInfo, Return response: {'info': {'state': 'OK', 'vgsize':
'1099108974592', 'name': '5ed04196-87f1-480e-9fee-9dd450a3b53b', 'vgfree':
'182536110080', 'vgUUID': 'rIENae-3NLj-o4t8-GVuJ-ZKKb-ksTk-qBkMrE',
'pvlist': [{'vendorID': 'EQLOGIC', 'capacity': '1099108974592', 'fwrev':
'0000', 'pe_alloc_count': '6829', 'vgUUID':
'rIENae-3NLj-o4t8-GVuJ-ZKKb-ksTk-qBkMrE', 'pathlist': [{'connection':
'10.10.100.9', 'iqn':
'iqn.2001-05.com.equallogic:4-771816-e5d0dfb59-1c9b240297958d53-ovsd3910',
'portal': '1', 'port': '3260', 'initiatorname': 'p1p1.100'}, {'connection':
'10.10.100.9', 'iqn':
'iqn.2001-05.com.equallogic:4-771816-e5d0dfb59-1c9b240297958d53-ovsd3910',
'portal': '1', 'port': '3260', 'initiatorname': 'p1p2'}, {'connection':
'10.10.100.9', 'iqn':
'iqn.2001-05.com.equallogic:4-771816-e5d0dfb59-1c9b240297958d53-ovsd3910',
'portal': '1', 'port': '3260', 'initiatorname': 'default'}], 'pe_count':
'8189', 'discard_max_bytes': 15728640, 'pathstatus': [{'type': 'iSCSI',
'physdev': 'sde', 'capacity': '1099526307840', 'state': 'active', 'lun':
'0'}, {'type': 'iSCSI', 'physdev': 'sdf', 'capacity': '1099526307840',
'state': 'active', 'lun': '0'}, {'type': 'iSCSI', 'physdev': 'sdg',
'capacity': '1099526307840', 'state': 'active', 'lun': '0'}], 'devtype':
'iSCSI', 'discard_zeroes_data': 1, 'pvUUID':
'g9pjI0-oifQ-kz2O-0Afy-xdnx-THYD-eTWgqB', 'serial':
'SEQLOGIC_100E-00_64817197B5DFD0E5538D959702249B1C', 'GUID':
'364817197b5dfd0e5538d959702249b1c', 'devcapacity': '1099526307840',
'productID': '100E-00'}], 'type': 3, 'attr': {'allocation': 'n', 'partial':
'-', 'exported': '-', 'permission': 'w', 'clustered': '-', 'resizeable':
'z'}}} (logUtils:54)

and around 12:39 you will find

2017-04-06 12:39:11,003+0200 ERROR (check/loop) [storage.Monitor] Error
checking path /dev/5ed04196-87f1-480e-9fee-9dd450a3b53b/metadata
(monitor:485)
Traceback (most recent call last):
  File "/usr/share/vdsm/storage/monitor.py", line 483, in _pathChecked
    delay = result.delay()
  File "/usr/lib/python2.7/site-packages/vdsm/storage/check.py", line 368,
in delay
    raise exception.MiscFileReadException(self.path, self.rc, self.err)
MiscFileReadException: Internal file read failure:
('/dev/5ed04196-87f1-480e-9fee-9dd450a3b53b/metadata', 1,
bytearray(b"/usr/bin/dd: error reading
\'/dev/5ed04196-87f1-480e-9fee-9dd450a3b53b/metadata\': Input/output
error\n0+0 records in\n0+0 records out\n0 bytes (0 B) copied, 0.000234164
s, 0.0 kB/s\n"))
2017-04-06 12:39:11,020+0200 INFO  (check/loop) [storage.Monitor] Domain
5ed04196-87f1-480e-9fee-9dd450a3b53b became INVALID (monitor:456)

that I think corresponds to the moment when I executed "iscsiadm -m session
-u" and had the automaic remediation of the correctly defined paths

Gianluca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20170410/c5d9c953/attachment.html>