Bug 839307 - RHEVM - Backend: Wrong parameters sent to VDSM when creating a POSIX domain
Summary: RHEVM - Backend: Wrong parameters sent to VDSM when creating a POSIX domain
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.1.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 3.1.0
Assignee: Maor
QA Contact: vvyazmin@redhat.com
URL:
Whiteboard: storage
Depends On: 845831
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-07-11 13:56 UTC by Daniel Paikov
Modified: 2016-02-10 16:42 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
oVirt Team: Storage
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
engine.log (26.96 KB, application/x-compressed-tar)
2012-07-11 13:56 UTC, Daniel Paikov
no flags Details

Description Daniel Paikov 2012-07-11 13:56:44 UTC
Created attachment 597584 [details]
engine.log

* Create a POSIX domain (vfs type=glusterfs).
* Backend sends validateStorageServerConnection with the correct vfs_type, then sends connectStorageServer with the wrong vfs_type (posixfs, which doesn't exist). This causes all new glusterfs domain creation to fail.

Thread-378110::INFO::2012-07-06 09:07:50,107::logUtils::37::dispatcher::(wrapper) Run and protect: validateStorageServerConnection(domType=6, spUUID='00000000-0000-0000-0000-000000000000', conList=[{'port': '', 'connection': '10.35.97.44:/rep1', 'iqn': '', 'portal': '', 'user': '', 'vfs_type': 'glusterfs', 'password': '******', 'id': '00000000-0000-0000-0000-000000000000'}], options=None)

[...]

Thread-378111::INFO::2012-07-06 09:07:50,160::logUtils::37::dispatcher::(wrapper) Run and protect: connectStorageServer(domType=6, spUUID='00000000-0000-0000-0000-000000000000', conList=[{'port': '', 'connection': '10.35.97.44:/rep1', 'iqn': '', 'portal': '', 'user': '', 'vfs_type': 'posixfs', 'password': '******', 'id': '38b65427-1bfe-4069-9503-f9f6b10a7d6d'}], options=None)

Comment 2 Itamar Heim 2012-07-12 15:25:58 UTC
laszlo - another duplicate of the posixfs/glusterfs issue in vdsm?

Comment 3 Laszlo Hornyak 2012-07-12 15:36:02 UTC
afaik 'posixfs' is accepted by vdsm (and used as a synonim of sharedfs), but then it is returned as 'sharedfs' at the moment, this is when things go wrong. 

It could be a duplicate.

Comment 4 Itamar Heim 2012-07-15 07:57:39 UTC
i misread the bug - this isn't about a wrong type of storage domain, rather a wrong type of the vds_type sent inside (sending storage domain type instead of vfs_type somewhere)

Comment 5 Maor 2012-08-02 18:04:52 UTC
Does not reproduce, I try to find the spcific commit number but still no luck

Thread-7414::INFO::2012-08-02 21:26:42,480::logUtils::37::dispatcher::(wrapper) Run and protect: validateStorageServerConnection(domType=6, spUUID='00000000-0000-0000-0000-000000000000', conList=[{'port': '', 'con
nection': '10.35.97.44:/vol2', 'mnt_options': '/tmp/tmp1', 'portal': '', 'user': '', 'iqn': '', 'vfs_type': 'glusterfs', 'password': '******', 'id': '00000000-0000-0000-0000-000000000000'}], options=None)
Thread-7414::INFO::2012-08-02 21:26:42,480::logUtils::39::dispatcher::(wrapper) Run and protect: validateStorageServerConnection, Return response: {'statuslist': [{'status': 0, 'id': '00000000-0000-0000-0000-00000
0000000'}]}

......
Thread-7422::INFO::2012-08-02 21:26:56,199::logUtils::37::dispatcher::(wrapper) Run and protect: connectStorageServer(domType=6, spUUID='00000000-0000-0000-0000-000000000000', conList=[{'port': '', 'connection': '
10.35.97.44:/vol2', 'iqn': '', 'portal': '', 'user': '', 'vfs_type': 'glusterfs', 'password': '******', 'id': 'a84deb23-6ec9-4cb1-b7cd-5cad37d435dc'}], options=None)

Comment 6 Maor 2012-08-05 08:54:08 UTC
latest verify was from commit hash d5227631e4231eb21186ff22172e67d2d68c8060

Comment 7 Daniel Paikov 2012-08-05 13:26:43 UTC
This functionality is now even more broken (as seen in bug #845831). Unable to verify until this bug is fixed.

Comment 8 Daniel Paikov 2012-08-05 14:04:37 UTC
Checked on si13.1.


Note You need to log in before you can comment on or make changes to this bug.