Created attachment 1161742 [details] screenshot of rhevm 4.0 storage page Description of problem: When adding local disk domain in RHEV-M 4.0 storage page, there is default path /data/images/rhev which can not changed, but there is no such dir in RHEV-H ng, so it will report error when click ok. RHEV-H should prebuild path /data/images/rhev for adding local disk domain. Version-Release number of selected component (if applicable): rhev-hypervisor7-ng-3.6-20160518.0 imgbased-0.6-0.1.el7ev.noarch vdsm-4.17.28-0.el7ev.noarch How reproducible: 100% Steps to Reproduce: 1. Install node ng 2. Add RHEV-H ng to RHEV-M 4.0 with 3.6 cluster. 3. In RHEV-M 4.0 storage page, add new domain with local storage type 4. Check the path "/data/images/rhev" in RHEV-H Actual results: 1. After step3, the default path is "/data/images/rhev" and can not be changed, click OK, it reports error(Please refer to attachment). 2. After step4, there is no path "/data/images/rhev" in RHEV-H. Expected results: 1. RHEV-H should prebuild path /data/images/rhev for adding local disk domain Additional info: 1. After step2, mkdir /data/images/rhev in RHEV-H and chmod the path, in step3, will add local disk domain successful
Created attachment 1161745 [details] sosreport and /var/log in rhev-h ng
Looks like this path should be created by vdsm.
(In reply to Fabian Deutsch from comment #2) > Looks like this path should be created by vdsm. I disagree. The path we are discussing (/data/images/rhev) is a storage endpoint. Vdsm consumes storage. It does not provision it. If we want that location to be reserved for local storage on RHEV-H, the RHEV-H installer should create that directory.
Right. That's a valid point. But maybe it does make sense if vdsm was owning this path anyway. The path itself is pre-defined in Engine. To make it consumable by vdsm, there need to be certain permissions on this path to make it consumable. The easiest way to ensure that the path (and all of it's components) do have the right permissions, is if vdsm was creating it. Does this sound reasonable? I do however agree that this specific path is a Node only thing, and thus we could also do it from the Node side.
How hard is it to do in Node? I thought you would just need to add a line in a config file to have the path created in the image. I really believe it's more correct to do this in Node so unless it's prohibitively more complex or ugly, let's try to do it there.
Creating the dir is not complex, but what user/group and access bits shall be set?
group 36 user 36 mode 0644 should be all you need.
Here we go, that is the knowledge which vdsm has but Node does not have. We can now take these informations passed to us via bugzilla. Whenever one of these pieces changes, Node will need to run after this change and get it fixed. To me this is not the right solution, but the right is probably to not hard-code the path in Engine. For now I'm hacking this right in Node.
(In reply to Fabian Deutsch from comment #8) > Here we go, that is the knowledge which vdsm has but Node does not have. Unfortunately, this is knowledge you also need to have when setting up an NFS export. Since you're setting up a LocalFS "export" you need to know it too :) > We can now take these informations passed to us via bugzilla. Whenever one > of these pieces changes, Node will need to run after this change and get it > fixed. Don't worry about changes. In order to change the userid/group (36:36 == qemu:kvm) we would need to change a lot of other things about the system. It's not going to happen. > To me this is not the right solution, but the right is probably to not > hard-code the path in Engine. > > For now I'm hacking this right in Node. Sounds good.
(In reply to Adam Litke from comment #7) > group 36 user 36 mode 0644 should be all you need. Do we really need mode 0644 on a dir? This doesn't sound right, since the execute bit is needed for a lot of operations
(In reply to Ryan Barry from comment #10) > (In reply to Adam Litke from comment #7) > > group 36 user 36 mode 0644 should be all you need. > > Do we really need mode 0644 on a dir? This doesn't sound right, since the > execute bit is needed for a lot of operations Oops, you're right. It should be 0755.
This bug is fixed both in ovirt-node-ng-installer-ovirt-3.6 and ovirt-node-ng-installer-ovirt-4.0 builds. Test version: ovirt-node-ng-installer-ovirt-3.6-2016062004.iso ovirt-node-ng-installer-ovirt-4.0-2016062004.iso Red Hat Enterprise Virtualization Manager Version: 4.0.0.2-0.1.el7ev Test steps: 1. Install ovirt-node-ng 2. Add RHEV-H ng to RHEV-M 4.0 with 3.6 cluster(4.0 cluster for ovirt-4.0). 3. In RHEV-M 4.0 storage page, add new domain with local storage type Test results: 1. After step3, the default path is blank in RHEV-M, type in prepared path in rhev-h(such as /home/local), add local storage successful. So this bug is fixed both in ovirt-node-ng-installer-ovirt-3.6-2016062004.iso and ovirt-node-ng-installer-ovirt-4.0-2016062004.iso, I will change the status to VERIFIED.
Since the problem described in this bug report should be resolved in oVirt 4.0.1 released on July 19th 2016, it has been closed with a resolution of CURRENT RELEASE. For information on the release, and how to update to this release, follow the link below. If the solution does not work for you, open a new bug report. http://www.ovirt.org/release/4.0.1/