[ovirt-users] NFS and pass discards\unmap question

2017-02-02 Thread Sergey Kulikov 

I've upgraded to 4.1 release, it have great feature "Pass discards", that now 
can be used without vdsm hooks,
After upgrade I've tested it with NFS 4.1 storage, exported from netapp, but 
unfortunately found out, that
it's not working, after some investigation, I've found, that NFS 
implementation(even 4.1) in Centos 7
doesn't support sparse files and fallocate(FALLOC_FL_PUNCH_HOLE), that quemu 
uses for file storage, it was
added only in kernel 3.18, and sparse files is also announced feature of 
upcoming NFS4.2,
sparsify also not working on this data domains(runs, but nothing happens).

This test also shows, that FALLOC_FL_PUNCH_HOLE not working, it was executed on 
centos ovirt host with mounted nfs share:
# truncate -s 1024 test1
# fallocate -p -o 0 -l 1024 test1
fallocate: keep size mode (-n option) unsupported

Is there any plans to backport this feature to node-ng, or centos? or we should 
wait for RHEL 8?
NFS is more and more popular, so discards is VERY useful feature.
I'm also planning to test fallocate on latest fedora with 4.x kernel and 
mounted nfs.

Thanks for your work!

-- 

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [Call for feedback] did you install/update to 4.1.0?

2017-02-03 Thread Sergey Kulikov 
Title: Re: [ovirt-users] [Call for feedback] did you install/update to 4.1.0?










On Thu, Feb 2, 2017 at 9:59 PM,  wrote:


Updated from 4.0.6
Docs are quite incomplete, it's not mentioned about installing ovirt-release41 on centos HV and ovirt-nodes manually, you need to guess.
Also links in release notes are broken ( https://www.ovirt.org/release/4.1.0/ )
They are going to https://www.ovirt.org/release/4.1.0/Hosted_Engine_Howto , but docs for 4.1.0 are absent.


Thanks, opened https://github.com/oVirt/ovirt-site/issues/765
I'd like to ask you if you can push your suggestion on documentation fixes / improvements editing the website following "Edit this page on GitHub" link at the bottom of the page.
Any help getting documentation updated and more useful to users is really appreciated.




Sure, thanks for pointing to that feature, you've already done this work for me)
I'll use github for any new suggestions.









Upgrade went well, everything migrated without problems(I need to restart VMs only to change cluster level to 4.1).
Good news, SPICE HTML 5 client now working for me on Win client with firefox, before on 4.x it was sending connect requests forever.

There is some bugs I've found playing with new version:
1) some storage tabs displaying "No items to display "
for example:
if I'm expanding System\Data centers\[dc name]\ and selecting Storage it displays nothing in main tab, but displays all domains in tree,
if I'm selecting [dc name] and Storage tab, also nothing,
but in System \ Strorage tab all domains present,
also in Clusters\[cluster name]\ Storage tab they present.

Thanks, opened https://bugzilla.redhat.com/show_bug.cgi?id=1418924

 

2) links to embedded files and clients aren't working, engine says 404, examples:
https://[your manager's address]/ovirt-engine/services/files/spice/usbdk-x64.msi
https://[your manager's address]/ovirt-engine/services/files/spice/virt-viewer-x64.msi
and other,
but they are in docs(in ovirt and also in rhel)


Thanks, opened https://bugzilla.redhat.com/show_bug.cgi?id=1418923

 

3) there is also link in "Console options" menu (right click on VM) called "Console Client Resources", it's going to dead location:
http://www.ovirt.org/documentation/admin-guide/virt/console-client-resources 
If you are going to fix issue №2 maybe also adding links directly to installation files embedded will be more helpful for users) 


Thanks, opened https://bugzilla.redhat.com/show_bug.cgi?id=1418921

 
4) little disappointed about "pass discards" on NFS storage, as I've found NFS implementation(even 4.1) in Centos 7 doesn't support
fallocate(FALLOC_FL_PUNCH_HOLE), that quemu uses for file storage, it was added only in kernel 3.18, sparsify also not working, but I'll mail separate
thread with this question.

-- 



Thursday, February 2, 2017, 15:19:29:





Hi,
did you install/update to 4.1.0? Let us know your experience!
We end up knowing only when things doesn't work well, let us know it works fine for you :-)

If you're not planning an update to 4.1.0 in the near future, let us know why.
Maybe we can help.

Thanks!
-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com





-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com




___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] node-ng update failed from ovirt-node-ng-4.1.0-0 to ovirt-node-ng-image-4.1.0-1, and NM + iscsi boo issue

2017-02-06 Thread Sergey Kulikov 

1) I've updated from 4.0.6 to 4.1.0 (on Feb 01 node-ng was at version 4.1.0-0)
After some time engine alerted, that this node have updates to 
ovirt-node-ng-image-4.1.0-1,
but update from engine timed out, there were hanging processes in ps on this 
node:

root 36309  0.0  0.0 113120  1564 ?Ss   19:04   0:00 bash -c umask 
0077; MYTMP="$(TMPDIR="${OVIRT_TMPDIR}" mktemp -d -t ovirt-XX)"; trap 
"chmod -R u+rwX \"${MYTMP}\" > /dev/null 2>&1; rm -fr \"${MYTMP}\" > /dev/null 
2>&1" 0; tar --warning=no-timestamp -C "${MYTMP}" -x &&  
"${MYTMP}"/ovirt-host-mgmt DIALOG/dialect=str:machine 
DIALOG/customization=bool:True
root 36339  0.2  0.0 496700 94208 ?S19:04   0:21 /bin/python 
/tmp/ovirt-GCmVusccfe/pythonlib/otopi/__main__.py 
"BASE/pluginPath=str:/tmp/ovirt-GCmVusccfe/otopi-plugins"  
APPEND:BASE/pluginGroups=str:ovirt-host-common:ovirt-host-mgmt 
DIALOG/dialect=str:machine DIALOG/customization=bool:True
root 37498  0.0  0.0 113124  1452 ?S19:09   0:00 /bin/sh 
/var/tmp/rpm-tmp.4UqJ4e 1
root 37560  0.0  0.0  0 0 ?S<   21:42   0:00 [kworker/21:2H]
root 37626  0.0  0.0 174516  5996 ?S19:09   0:00 rpm -Uvh 
--quiet --justdb 
/usr/share/imgbased/ovirt-node-ng-image-update-4.1.0-1.el7.centos.noarch.rpm

they were hanging forever, I ended up with rebooting the node, no errors in 
log, it was just hanging at:

2017-02-03 19:09:16 DEBUG otopi.plugins.otopi.dialog.machine 
dialog.__logString:204 DIALOG:SEND   ***CONFIRM GPG_KEY Confirm use of GPG 
Key userid=oVirt  hexkeyid=FE590CB7
2017-02-03 19:09:16 DEBUG otopi.plugins.otopi.dialog.machine 
dialog.__logString:204 DIALOG:SEND   ###
2017-02-03 19:09:16 DEBUG otopi.plugins.otopi.dialog.machine 
dialog.__logString:204 DIALOG:SEND   ### Please confirm 'GPG_KEY' Confirm 
use of GPG Key userid=oVirt  hexkeyid=FE590CB7
2017-02-03 19:09:16 DEBUG otopi.plugins.otopi.dialog.machine 
dialog.__logString:204 DIALOG:SEND   ### Response is CONFIRM GPG_KEY=yes|no 
or ABORT GPG_KEY
2017-02-03 19:09:16 DEBUG otopi.plugins.otopi.dialog.machine 
dialog.__logString:204 DIALOG:RECEIVECONFIRM GPG_KEY=yes
2017-02-03 19:09:16 INFO otopi.plugins.otopi.packagers.yumpackager 
yumpackager.info:80 Yum Status: Running Test Transaction
Running Transaction Check
2017-02-03 19:09:16 INFO otopi.plugins.otopi.packagers.yumpackager 
yumpackager.info:80 Yum Status: Running Transaction
2017-02-03 19:09:16 INFO otopi.plugins.otopi.packagers.yumpackager 
yumpackager.info:80 Yum install: 1/2: 
ovirt-node-ng-image-4.1.0-1.el7.centos.noarch
2017-02-03 19:09:20 DEBUG otopi.plugins.otopi.packagers.yumpackager 
yumpackager.verbose:76 Yum Done: ovirt-node-ng-image-4.1.0-1.el7.centos.noarch
2017-02-03 19:09:20 INFO otopi.plugins.otopi.packagers.yumpackager 
yumpackager.info:80 Yum install: 2/2: 
ovirt-node-ng-image-update-4.1.0-1.el7.centos.noarch

now my node have this layout:
# imgbase layout
ovirt-node-ng-4.1.0-0.20170201.0
 +- ovirt-node-ng-4.1.0-0.20170201.0+1
(so update failed)
but 4.1.0-1 rpms are marked as "installed" and yum can't find any updates, can 
I rollback to base layout without installed  4.1.0-1 rms ?
imgbase rollback needs at least 2 layers over base.

Or maybe the only way is to reinstall this node?

2) And another question, how can I disable NetworkManger permanently, or 
exclude some interfaces permanently?
I've tried to disable NetworkManger by systemctl, but after update from 4.0 to 
4.1 it was re-enabled(so it's not persistent between updates).
I've an issue with iscsi root and enabled NetworkManger, because NM tries to 
bring down\up my iscsi interfaces on boot, and sometimes FS remounting RO
because of IO errors, I can't put NM_CONTROLLED=no in ifcfg, because ifcfg is 
generated by dracut at every boot.


-

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] node-ng update failed from ovirt-node-ng-4.1.0-0 to ovirt-node-ng-image-4.1.0-1, and NM + iscsi boo issue

2017-02-07 Thread Sergey Kulikov 

There is no new lv, I can remove rpm and reinstall manually to reproduce with 
any debug options, if you want.
I left host in maintenance mode. 
should I also remove ovirt-node-ng-image ? I found something strange:
# rpm -q ovirt-node-ng-image  
ovirt-node-ng-image-4.1.0-1.el7.centos.noarch

# rpm -ql ovirt-node-ng-image
/usr/share/ovirt-node-ng/image
/usr/share/ovirt-node-ng/image/ovirt-node-ng-4.1.0-0.20170201.0.el7.squashfs.img
/usr/share/ovirt-node-ng/image/product.img

version is 4.1.0-1, but squashfs file is 4.1.0-0


About iscsi... I've disabled NM in 4.0.6, everything was ok, it was re-enabled 
only after update, I don't
think iscsi root affects NM status.
The problem is only with reboot, 1 time out of ~4 reboots it's falling to RO.
Also I have centos hosts and NM stays disabled there, maybe I should try 
"unmanaged-devices="
in NM config, but I think it's not ideal, NM is useless for this setup)

-- 



 Tuesday, February 7, 2017, 07:14:55:

> Hey Sergey -


> If you check "lvs" and ensure that there's not actually a new LV
> from the update, you can cleanly 'rpm -e
> ovirt-node-ng-image-update', and be ok without redeploying.


> Unfortunately, it's hard to tell from the logs (and '--justdb'
> hanging) what's happening here, but I'll try to reproduce.


> NetworkManager disablement should "stick" across upgrades, but it's
> possible that iscsi roots are doing something here. I'll check for a dracut 
> flag, also...

> On Mon, Feb 6, 2017 at 1:14 PM, Sandro Bonazzola <sbona...@redhat.com> wrote:

> Adding Douglas and Ryan


> Il 06/Feb/2017 13:32, "Sergey Kulikov" <ser...@msm.ru> ha scritto:


>  1) I've updated from 4.0.6 to 4.1.0 (on Feb 01 node-ng was at version 
> 4.1.0-0)
>  After some time engine alerted, that this node have updates to 
> ovirt-node-ng-image-4.1.0-1,
>  but update from engine timed out, there were hanging processes in ps on this 
> node:
>  
>  root     36309  0.0  0.0 113120  1564 ?        Ss   19:04   0:00
> bash -c umask 0077; MYTMP="$(TMPDIR="${OVIRT_TMPDIR}" mktemp -d -t
> ovirt-XX)"; trap "chmod -R u+rwX \"${MYTMP}\" > /dev/null
> 2>&1; rm -fr \"${MYTMP}\" > /dev/null 2>&1" 0; tar
> --warning=no-timestamp -C "${MYTMP}" -x && 
> "${MYTMP}"/ovirt-host-mgmt DIALOG/dialect=str:machine 
> DIALOG/customization=bool:True
>  root     36339  0.2  0.0 496700 94208 ?        S    19:04   0:21
> /bin/python /tmp/ovirt-GCmVusccfe/pythonlib/otopi/__main__.py
> "BASE/pluginPath=str:/tmp/ovirt-GCmVusccfe/otopi-plugins" 
> APPEND:BASE/pluginGroups=str:ovirt-host-common:ovirt-host-mgmt
> DIALOG/dialect=str:machine DIALOG/customization=bool:True
>  root     37498  0.0  0.0 113124  1452 ?        S    19:09   0:00 /bin/sh 
> /var/tmp/rpm-tmp.4UqJ4e 1
>  root     37560  0.0  0.0      0     0 ?        S<   21:42   0:00 
> [kworker/21:2H]
>  root     37626  0.0  0.0 174516  5996 ?        S    19:09   0:00
> rpm -Uvh --quiet --justdb
> /usr/share/imgbased/ovirt-node-ng-image-update-4.1.0-1.el7.centos.noarch.rpm
>  
>  they were hanging forever, I ended up with rebooting the node, no
> errors in log, it was just hanging at:
>  
>  2017-02-03 19:09:16 DEBUG otopi.plugins.otopi.dialog.machine
> dialog.__logString:204 DIALOG:SEND       ***CONFIRM GPG_KEY Confirm
> use of GPG Key userid=oVirt <in...@ovirt.org> hexkeyid=FE590CB7
>  2017-02-03 19:09:16 DEBUG otopi.plugins.otopi.dialog.machine
> dialog.__logString:204 DIALOG:SEND       ###
>  2017-02-03 19:09:16 DEBUG otopi.plugins.otopi.dialog.machine
> dialog.__logString:204 DIALOG:SEND       ### Please confirm
> 'GPG_KEY' Confirm use of GPG Key userid=oVirt <in...@ovirt.org> 
> hexkeyid=FE590CB7
>  2017-02-03 19:09:16 DEBUG otopi.plugins.otopi.dialog.machine
> dialog.__logString:204 DIALOG:SEND       ### Response is CONFIRM 
> GPG_KEY=yes|no or ABORT GPG_KEY
>  2017-02-03 19:09:16 DEBUG otopi.plugins.otopi.dialog.machine
> dialog.__logString:204 DIALOG:RECEIVE    CONFIRM GPG_KEY=yes
>  2017-02-03 19:09:16 INFO otopi.plugins.otopi.packagers.yumpackager
> yumpackager.info:80 Yum Status: Running Test Transaction
>  Running Transaction Check
>  2017-02-03 19:09:16 INFO otopi.plugins.otopi.packagers.yumpackager
> yumpackager.info:80 Yum Status: Running Transaction
>  2017-02-03 19:09:16 INFO otopi.plugins.otopi.packagers.yumpackager
> yumpackager.info:80 Yum install: 1/2:
> ovirt-node-ng-image-4.1.0-1.el7.centos.noarch
>  2017-02-03 19:09:20 DEBUG
> otopi.plugins.otopi.packagers.yumpackager yumpackager.verbose:76 Yum
> Done: ovirt-node-ng-image-4.1.0-1.el7.centos.noarch
>  2017-02-03 19:09:20 INFO otopi.plugins.otopi.packagers.yumpackager
> yumpackager.info:80 Y

[ovirt-users] seem that SuperUser role isn't super.

2017-02-07 Thread Sergey Kulikov 

I've tried to add publickey to user, that have SuperUser role defined (tried as 
admin@internal, and as another user with SuperUser role),
But UI says, that no permission for logged in user, finally I was able to add 
publickey only after assigning UserProfileEditor role to that users.

oVirt 4.1
engine log:
2017-02-08 00:09:27,525+03 INFO  
[org.ovirt.engine.core.bll.AddUserProfileCommand] (default task-3) 
[e64e31a3-5fdd-414a-a882-737a638162a7] No permission found for user 
'002c-002c-002c-002c-018a' or one of the groups he is member of, 
when running action 'AddUserProfile', Required permissions are: Action type: 
'USER' Action group: 'EDIT_PROFILE' Object type: 'System'  Object ID: 
'002c-002c-002c-002c-018a'.

-- 

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] seem that SuperUser role isn't super.

2017-02-07 Thread Sergey Kulikov 
And also it seems strange, that user can't edit own profile, or it was designed 
that way?
If user disallowed to edit own profile there is even no way for admin to manage 
user keys,
I can't find such options in UI for editing user profiles, only for assigning 
permissions.
or maybe I need to add global role for everyone to allow editing own profile?

-- 



 Wednesday, February 8, 2017, 00:26:00:


> I've tried to add publickey to user, that have SuperUser role
> defined (tried as admin@internal, and as another user with SuperUser role),
> But UI says, that no permission for logged in user, finally I was
> able to add publickey only after assigning UserProfileEditor role to that 
> users.

> oVirt 4.1
> engine log:
> 2017-02-08 00:09:27,525+03 INFO 
> [org.ovirt.engine.core.bll.AddUserProfileCommand] (default task-3)
> [e64e31a3-5fdd-414a-a882-737a638162a7] No permission found for user
> '002c-002c-002c-002c-018a' or one of the groups he is
> member of, when running action 'AddUserProfile', Required
> permissions are: Action type: 'USER' Action group: 'EDIT_PROFILE'
> Object type: 'System'  Object ID:
> '002c-002c-002c-002c-018a'.

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] seem that SuperUser role isn't super.

2017-02-07 Thread Sergey Kulikov 

But admin can't even edit own profile in admin UI, using links at top(specially 
designed for that), it looks like a bug)

-- 



 Wednesday, February 8, 2017, 00:31:19:

> Hi Sergey,

> One thing that confused me when I first started was the difference between
> Admin permissions and User permissions.  They are, apparently, two
> separate sets, and which set gets looked at depends on which portal you're
> using.  If you give someone a User permission they can't use the admin
> functions (even if those admin functions require the same permission), and
> vice-versa (and admin role can't use the user functions).

> This bit me early on.

> -derek

> On Tue, February 7, 2017 4:26 pm, Sergey Kulikov wrote:
>>
>> I've tried to add publickey to user, that have SuperUser role defined
>> (tried as admin@internal, and as another user with SuperUser role),
>> But UI says, that no permission for logged in user, finally I was able to
>> add publickey only after assigning UserProfileEditor role to that users.
>>
>> oVirt 4.1
>> engine log:
>> 2017-02-08 00:09:27,525+03 INFO
>> [org.ovirt.engine.core.bll.AddUserProfileCommand] (default task-3)
>> [e64e31a3-5fdd-414a-a882-737a638162a7] No permission found for user
>> '002c-002c-002c-002c-018a' or one of the groups he is member
>> of, when running action 'AddUserProfile', Required permissions are: Action
>> type: 'USER' Action group: 'EDIT_PROFILE' Object type: 'System'  Object
>> ID: '002c-002c-002c-002c-018a'.
>>
>> --
>>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] NFS and pass discards\unmap question

2017-02-03 Thread Sergey Kulikov 


Unfortunately I can't browse this bug:
"You are not authorized to access bug #1079385."
Can you email me details on ths bug?
I think that's the reason I can't find this fix for rhel\centos in google)


-- 



 Friday, February 3, 2017, 14:45:43:





> On Thu, Feb 2, 2017 at 11:45 PM, Sergey Kulikov <ser...@msm.ru> wrote:


>  I've upgraded to 4.1 release, it have great feature "Pass
> discards", that now can be used without vdsm hooks,
>  After upgrade I've tested it with NFS 4.1 storage, exported from
> netapp, but unfortunately found out, that
>  it's not working, after some investigation, I've found, that NFS
> implementation(even 4.1) in Centos 7
>  doesn't support sparse files and fallocate(FALLOC_FL_PUNCH_HOLE),
> that quemu uses for file storage, it was
>  added only in kernel 3.18, and sparse files is also announced feature of 
> upcoming NFS4.2,
>  sparsify also not working on this data domains(runs, but nothing happens).
>  
>  This test also shows, that FALLOC_FL_PUNCH_HOLE not working, it
> was executed on centos ovirt host with mounted nfs share:
>  # truncate -s 1024 test1
>  # fallocate -p -o 0 -l 1024 test1
>  fallocate: keep size mode (-n option) unsupported
>  
>  Is there any plans to backport this feature to node-ng, or centos? or we 
> should wait for RHEL 8?




> Interesting, I was under the impression it was fixed some time ago,
> for 7.2[1] (kernel-3.10.0-313.el7)
> Perhaps you are not mounted with 4.2?


> Y.
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1079385
>  
>  NFS is more and more popular, so discards is VERY useful feature.
>  I'm also planning to test fallocate on latest fedora with 4.x kernel and 
> mounted nfs.
>  
>  Thanks for your work!
>  
>  --
>  
>  ___
>  Users mailing list
>  Users@ovirt.org
>  http://lists.ovirt.org/mailman/listinfo/users
>  

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] NFS and pass discards\unmap question

2017-02-03 Thread Sergey Kulikov 


Hm... maybe I need to set any options, is there any way to force ovirt to mount 
with this extension, or version 4.2
there is only 4.1 selection in "New Domain" menu.
Current mount options:
type nfs4 
(rw,relatime,vers=4.1,rsize=65536,wsize=65536,namlen=255,soft,nosharecache,proto=tcp,port=0,timeo=600,retrans=6,sec=sys,local_lock=none)

it should work only if forced option vers=4.2 ?
I thought it's implemented as feature to older version, not 4.2, there is few 
info about this.


-- 



 Friday, February 3, 2017, 14:45:43:





> On Thu, Feb 2, 2017 at 11:45 PM, Sergey Kulikov <ser...@msm.ru> wrote:


>  I've upgraded to 4.1 release, it have great feature "Pass
> discards", that now can be used without vdsm hooks,
>  After upgrade I've tested it with NFS 4.1 storage, exported from
> netapp, but unfortunately found out, that
>  it's not working, after some investigation, I've found, that NFS
> implementation(even 4.1) in Centos 7
>  doesn't support sparse files and fallocate(FALLOC_FL_PUNCH_HOLE),
> that quemu uses for file storage, it was
>  added only in kernel 3.18, and sparse files is also announced feature of 
> upcoming NFS4.2,
>  sparsify also not working on this data domains(runs, but nothing happens).
>  
>  This test also shows, that FALLOC_FL_PUNCH_HOLE not working, it
> was executed on centos ovirt host with mounted nfs share:
>  # truncate -s 1024 test1
>  # fallocate -p -o 0 -l 1024 test1
>  fallocate: keep size mode (-n option) unsupported
>  
>  Is there any plans to backport this feature to node-ng, or centos? or we 
> should wait for RHEL 8?




> Interesting, I was under the impression it was fixed some time ago,
> for 7.2[1] (kernel-3.10.0-313.el7)
> Perhaps you are not mounted with 4.2?


> Y.
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1079385
>  
>  NFS is more and more popular, so discards is VERY useful feature.
>  I'm also planning to test fallocate on latest fedora with 4.x kernel and 
> mounted nfs.
>  
>  Thanks for your work!
>  
>  --
>  
>  ___
>  Users mailing list
>  Users@ovirt.org
>  http://lists.ovirt.org/mailman/listinfo/users
>  

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] NFS and pass discards\unmap question

2017-02-03 Thread Sergey Kulikov 

Thanks! I think now It's question to NetApp, when they'll make 4.2 available,
I've tried to manually mount v4.2 on host,
but unfortunately:
# mount -o vers=4.2 10.1.1.111:/test /tmp/123 
mount.nfs: Protocol not supported

so, my NetApp is vers=4.1 max (

-- 



 Friday, February 3, 2017, 15:54:54:





> On Feb 3, 2017 1:50 PM, "Nir Soffer" <nsof...@redhat.com> wrote:

> On Fri, Feb 3, 2017 at 2:29 PM, Sergey Kulikov <ser...@msm.ru> wrote:
 >>
 >>
 >> Hm... maybe I need to set any options, is there any way to force ovirt to 
 >> mount with this extension, or version 4.2
 >> there is only 4.1 selection in "New Domain" menu.
 >> Current mount options:
 >> type nfs4 
 >> (rw,relatime,vers=4.1,rsize=65536,wsize=65536,namlen=255,soft,nosharecache,proto=tcp,port=0,timeo=600,retrans=6,sec=sys,local_lock=none)
 >>
 >> it should work only if forced option vers=4.2 ?
 >> I thought it's implemented as feature to older version, not 4.2, there is 
 >> few info about this.
>  
>  Looks like ovirt engine does not allow nfs version 4.2.




> But custom options can be used. 
> Y. 


>  
>  We have this RFE:
>  https://bugzilla.redhat.com/1406398
>  
>  So practically, both sparsify and pass discard with NFS are useless
>  in the current version.
>  
>  I think this should be fix for next 4.1 build.
>  
>  Nir
>  

 >>
 >>
 >> --
 >>
 >>
 >>
 >>  Friday, February 3, 2017, 14:45:43:
 >>
 >>
 >>
 >>
 >>
 >>> On Thu, Feb 2, 2017 at 11:45 PM, Sergey Kulikov <ser...@msm.ru> wrote:
 >>
 >>
 >>>  I've upgraded to 4.1 release, it have great feature "Pass
 >>> discards", that now can be used without vdsm hooks,
 >>>  After upgrade I've tested it with NFS 4.1 storage, exported from
 >>> netapp, but unfortunately found out, that
 >>>  it's not working, after some investigation, I've found, that NFS
 >>> implementation(even 4.1) in Centos 7
 >>>  doesn't support sparse files and fallocate(FALLOC_FL_PUNCH_HOLE),
 >>> that quemu uses for file storage, it was
 >>>  added only in kernel 3.18, and sparse files is also announced feature of 
 >>>upcoming NFS4.2,
 >>>  sparsify also not working on this data domains(runs, but nothing happens).
 >>>
 >>>  This test also shows, that FALLOC_FL_PUNCH_HOLE not working, it
 >>> was executed on centos ovirt host with mounted nfs share:
 >>>  # truncate -s 1024 test1
 >>>  # fallocate -p -o 0 -l 1024 test1
 >>>  fallocate: keep size mode (-n option) unsupported
 >>>
 >>>  Is there any plans to backport this feature to node-ng, or centos? or we 
 >>>should wait for RHEL 8?
 >>
 >>
 >>
 >>
 >>> Interesting, I was under the impression it was fixed some time ago,
 >>> for 7.2[1] (kernel-3.10.0-313.el7)
 >>> Perhaps you are not mounted with 4.2?
 >>
 >>
 >>> Y.
 >>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1079385
 >>>
 >>>  NFS is more and more popular, so discards is VERY useful feature.
 >>>  I'm also planning to test fallocate on latest fedora with 4.x kernel and 
 >>>mounted nfs.
 >>>
 >>>  Thanks for your work!
 >>>
 >>>  --
 >>>
 >>>  ___
 >>>  Users mailing list
 >>>  Users@ovirt.org
 >>>  http://lists.ovirt.org/mailman/listinfo/users
 >>>
 >>
 >> ___
 >> Users mailing list
 >> Users@ovirt.org
 >> http://lists.ovirt.org/mailman/listinfo/users
>  

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] strange behavior of ovirt-node ng update

2017-03-23 Thread Sergey Kulikov 

I have one Ovirt Node in my test cluster(others are centos), I'm observing 
strange behavior of update
checker in engine.
In options I can see:
engine=# select * from vdc_options where 
option_name='OvirtNodePackageNamesForCheckUpdate'; 
 option_id | option_name |option_value| 
version 
---+-++-
   124 | OvirtNodePackageNamesForCheckUpdate | ovirt-node-ng-image-update | 
general
(1 row)

so it tries to check for updated version of ovirt-node-ng-image-update, but 
there is no ovirt-node-ng-image-update package installed inside updated node 
image, so engine always shows
available updates on this node to the same version:
> Check for available updates on host XXX was completed successfully with 
> message 'found updates for packages ovirt-node-ng-image-4.1.1-1.el7.centos, 
> ovirt-node-ng-image-update-4.1.1-1.el7.centos'. 
I saw a bug in bugzilla, that it should be fixed in 4.0
Initially engine was set up as 4.x version, after that updated between releases 
and finally to 4.1.0,
and today to 4.1.1.
I saw this behavior on 4.1.0 node and also on 4.1.1, on this page:
http://www.ovirt.org/node/4.0/update/
Maybe my OvirtNodePackageNamesForCheckUpdate was changed between releases, but 
engine-setup left it untouched
and i should change it manually? If so, what it should look like?

-- 

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] trying to test engine metrics, using ovirt-engine-metrics package

2017-06-02 Thread Sergey Kulikov 

Hi! I'm trying to deploy metrics in my ovirt test enviroment, configured 
fluentd on dst host, configured
/etc/ovirt-engine-metrics/config.yml , after that trying to execute:
/usr/share/ovirt-engine-metrics/setup/ansible/configure_ovirt_hosts_for_metrics.sh
4 host are configured correctly (This is Centos 7.3 Hypervisors)
1 host fails (this is the only ovirt-node host)
Error: 
fatal: []: FAILED! => {"changed": false, "failed": true, 
"msg": "OSError: [Errno 0] Error\n"}
After some digging into metrics ansible scripts I've found out, that it's 
setting port permissions in selinux:

on ok host it looks like:
# semanage port -l | grep collectd_port_t
collectd_port_tudp  8125, 25826

on host with errors:
# semanage port -l | grep collectd_port_t
collectd_port_tudp  25826

I've tried to set it manually with no luck:
# semanage port -a -t collectd_port_t -p udp 8125
libsemanage.semanage_module_info_set_name: Name 200 is invalid.
OSError: Error

maybe something is wrong in Ovirt-Node selinux, or it should be preconfigured 
in node image?
Is there anything I can try to fix it?

-- 

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] oVirt virtio drivers for fedora 5

2017-12-29 Thread Sergey Kulikov 
Title: Re: [ovirt-users] oVirt virtio drivers for fedora 5



Maybe you can make this two disks larger, make more extended partitions on them and move partitions from disks 3 and 4 to this two and modify fstab accordingly?
Or if you don't need separate mount points you can extend space on / and move data to / filesystem tree and remove fstab entries,
and use only 1 virtual disk, if it's acceptable.
All this can be done from modern OS, you can connect all 4 disks via virtio drivers, connect 5th disk, move data to it, install fedora5 bootloader,
modify fstab and than reattach to original vm via IDE.

-- 



 Wednesday, December 27, 2017, 16:07:59:





Hi,
We have converted a very old fedora 5 server to run on oVirt. However, since the Fedora 5 does not have virtio drivers, or virtio-scsi drivers, the disks are connected to virtual IDE interface. The problem here is on a single IDE interface, we cannot connect more than 2 disks. But the old converted server had 4 disks on 2 IDE controllers. 
First question is can we add one more virtual IDE Controller to the VM? If yes, please share the procedure. Or whether any one can share the proper virtio or virtio scsi for fedora 5 OS drivers so that we can get other two inactive disks working.
Unfortunately we cannot upgrade from Fedora 5 at the moment. 
Await your inputs.
-- 
Thanks & Regards,

Anantha Raghava

Do not print this e-mail unless required. Save Paper & trees.




___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Found some bugs with NFS.

2018-01-22 Thread Sergey Kulikov 
This is test environment, running Centos 7.4, oVirt 4.2.0, kernel 
3.10.0-693.11.6.el7.x86_64 (3.10.0-693.11.1 and 3.10.0-693 have same bugs)


1. Can't force NFS to 4.0.
Some time ago, I've set my NFS version for all storage domains to V4, because 
there was a bug with Netapp data ontap 8.x
and RHEL, using NFS 4.1(NFS mount started to hang after a while, STATEID 
problems) v4 on centos 7.2 and 7.3 was mounting NFS as 4.0,
so there were no problems related to NFS, after some time Centos 7.4 was 
released, and I've noticed that mount points started to hang again,
NFS was mounted with vers=4.1, and it's not possible to change to 4.0, both 
options "V4" and "V4.1" mounts as 4.1. Looks like V4 option is 
system default version for 4.X, and as I know it was changed in Centos 7.4 from 
4.0 to 4.1, maybe 4.0 option should be added
to force 4.0 version? because adding vers=/nfsvers= in "Additional mount 
options" is denied by ovirt.
I know, I can turn it off on netapp side, but there may be situations where 
storage is out of control. And 4.0 version can't be
set on ovirt side.

2. This bug isn't directly related to ovirt, but affects it.
Don't really shure that this is right place to report.
As I've said before there were bug with NFS 4.1, Netapp data ontap 8 and RHEL 
7.x, but it was fixed in otap 9.x,
Now we have 9.x ONTAP on Netapp and it brought new bugs with RHEL 7.4 :D
After updating to centos 7.4 nfs domains in ovirt started to hang\lock again, 
This happens randomly, on random hosts, after few
days of uptime, entire datacenter goes offline, hosts down, storage domains 
down, some vms in UP and some in unknown state, but
actually VMs are working, HostedEngine also working, but I can't control the 
environment.
There are many hanging ioprocess(>1300) and vdsm processes(>1300) on some 
hosts, also there are some dd commands, that are checking
storage hanging:
├─vdsmd─┬─2*[dd]
│   ├─1304*[ioprocess───{ioprocess}]
│   ├─12*[ioprocess───4*[{ioprocess}]]
│   └─1365*[{vdsmd}]
vdsm 19470  0.0  0.0   4360   348 ?D<   Jan21   0:00 /usr/bin/dd 
if=/rhev/data-center/mnt/10.xx.xx.xx:_test__nfs__sas_iso/6cd147b4-8039-4f8a-8aa7-5fd54d81/dom_md/metadata
 of=/dev/null bs=4096 count=1 iflag=direct
vdsm 40707  0.0  0.0   4360   348 ?D<   00:44   0:00 /usr/bin/dd 
if=/rhev/data-center/mnt/10.xx.xx.xx:_test__nfs__sas_export/58d9e2c2-8fef-4abc-be13-a273d6af320f/dom_md/metadata
 of=/dev/null bs=4096 count=1 iflag=direct

vdsm is hanging at 100% cpu load
If I'll try to ls this files ls will hang.

I've made some dump of traffic, so looks like problem with STATID, I've found 2 
issues on RedHat web site, but they aren't
publically available, so i can't read the solution:
https://access.redhat.com/solutions/3214331   (in my case I have STATEID test)
https://access.redhat.com/solutions/3164451   (in my case there is no manager 
thread)
But it looks' that I've another issue with stateid,
According to dumps my hosts are sending: TEST_STATEID
netapp reply is: Status: NFS4ERR_BAD_STATEID (10025)
After this host sends: Network File System, Ops(5): SEQUENCE, PUTFH, OPEN, 
ACCESS, GETATTR
Reply: V4 Reply (Call In 17) OPEN StateID: 0xa205
Request: V4 Call (Reply In 22) READ StateID: 0xca5f Offset: 0 Len: 4096
Reply: V4 Reply (Call In 19) READ Status: NFS4ERR_BAD_STATEID


Entire conversaion looks like:
No. Time   Source Destination   Protocol  Length 
Info
  1 0.00   10._host_  10._netapp_NFS  238V4 
Call (Reply In 2) TEST_STATEID
  2 0.000251   10._netapp_10._host_  NFS  170V4 
Reply (Call In 1) TEST_STATEID (here is Status: NFS4ERR_BAD_STATEID (10025))
  3 0.000352   10._host_  10._netapp_NFS  338V4 
Call (Reply In 4) OPEN DH: 0xa2c3ad28/
  4 0.000857   10._netapp_10._host_  NFS  394V4 
Reply (Call In 3) OPEN StateID: 0xa205
  5 0.000934   10._host_  10._netapp_NFS  302V4 
Call (Reply In 8) READ StateID: 0xca5f Offset: 0 Len: 4096
  6 0.000964   10._host_  10._netapp_NFS  302V4 
Call (Reply In 9) READ StateID: 0xca5f Offset: 0 Len: 4096
  7 0.001133   10._netapp_10._host_  TCP  70 
2049 → 683 [ACK] Seq=425 Ack=901 Win=10240 Len=0 TSval=225608100 TSecr=302215289
  8 0.001258   10._netapp_10._host_  NFS  170V4 
Reply (Call In 5) READ Status: NFS4ERR_BAD_STATEID
  9 0.001320   10._netapp_10._host_  NFS  170V4 
Reply (Call In 6) READ Status: NFS4ERR_BAD_STATEID

Sometimes clearing locks on netapp(vserver locks break) and killing 
dd\ioprocess will help for a while.
Right now I've my test setup in this state, looks like lock problem is always 
with metadata\disk check, but not domain itself,
I can read and write other files in this mountpoint from the same

Re: [ovirt-users] Found some bugs with NFS.

2018-01-23 Thread Sergey Kulikov 
Title: Re: [ovirt-users] Found some bugs with NFS.



I'll post second part there.
Unfotunately I can't use fedora as ovirt node(unsupported), and share hangs only after some time,
I'm trying to find out what type of IO, leads to this hang, I'll try on other OSes if I'll find what
to try.
But first part is directly related to ovirt, I think.
 

-- 



 Tuesday, January 23, 2018, 21:59:12:







On Tue, Jan 23, 2018 at 6:47 PM, Sergey Kulikov <ser...@msm.ru> wrote:

Or maybe somebody can point me to the right place for submitting this?
Thanks. :)

CentOS have a bugtracker[1], but I think it's worthwhile understanding if it is reproducible with other OS. Fedora, for example.
Y.

[1] https://bugs.centos.org/main_page.php 
---



 Monday, January 22, 2018, 14:10:53:

> This is test environment, running Centos 7.4, oVirt 4.2.0, kernel 3.10.0-693.11.6.el7.x86_64 (3.10.0-693.11.1 and 3.10.0-693 have same bugs)
>
>
> 1. Can't force NFS to 4.0.
> Some time ago, I've set my NFS version for all storage domains to V4, because there was a bug with Netapp data ontap 8.x
> and RHEL, using NFS 4.1(NFS mount started to hang after a while, STATEID problems) v4 on centos 7.2 and 7.3 was mounting NFS as 4.0,
> so there were no problems related to NFS, after some time Centos 7.4 was released, and I've noticed that mount points started to hang again,
> NFS was mounted with vers=4.1, and it's not possible to change to 4.0, both options "V4" and "V4.1" mounts as 4.1. Looks like V4 option is
> system default version for 4.X, and as I know it was changed in Centos 7.4 from 4.0 to 4.1, maybe 4.0 option should be added
> to force 4.0 version? because adding vers=/nfsvers= in "Additional mount options" is denied by ovirt.
> I know, I can turn it off on netapp side, but there may be situations where storage is out of control. And 4.0 version can't be
> set on ovirt side.
>
> 2. This bug isn't directly related to ovirt, but affects it.
> Don't really shure that this is right place to report.
> As I've said before there were bug with NFS 4.1, Netapp data ontap 8 and RHEL 7.x, but it was fixed in otap 9.x,
> Now we have 9.x ONTAP on Netapp and it brought new bugs with RHEL 7.4 :D
> After updating to centos 7.4 nfs domains in ovirt started to hang\lock again, This happens randomly, on random hosts, after few
> days of uptime, entire datacenter goes offline, hosts down, storage domains down, some vms in UP and some in unknown state, but
> actually VMs are working, HostedEngine also working, but I can't control the environment.
> There are many hanging ioprocess(>1300) and vdsm processes(>1300) on some hosts, also there are some dd commands, that are checking
> storage hanging:
>         ├─vdsmd─┬─2*[dd]
>         │       ├─1304*[ioprocess───{ioprocess}]
>         │       ├─12*[ioprocess───4*[{ioprocess}]]
>         │       └─1365*[{vdsmd}]
> vdsm     19470  0.0  0.0   4360   348 ?        D<   Jan21   0:00 /usr/bin/dd if=/rhev/data-center/mnt/10.xx.xx.xx:_test__nfs__sas_iso/6cd147b4-8039-4f8a-8aa7-5fd54d81/dom_md/metadata of=/dev/null bs=4096 count=1 iflag=direct
> vdsm     40707  0.0  0.0   4360   348 ?        D<   00:44   0:00 /usr/bin/dd if=/rhev/data-center/mnt/10.xx.xx.xx:_test__nfs__sas_export/58d9e2c2-8fef-4abc-be13-a273d6af320f/dom_md/metadata of=/dev/null bs=4096 count=1 iflag=direct
>
> vdsm is hanging at 100% cpu load
> If I'll try to ls this files ls will hang.
>
> I've made some dump of traffic, so looks like problem with STATID, I've found 2 issues on RedHat web site, but they aren't
> publically available, so i can't read the solution:
> https://access.redhat.com/solutions/3214331   (in my case I have STATEID test)
> https://access.redhat.com/solutions/3164451   (in my case there is no manager thread)
> But it looks' that I've another issue with stateid,
> According to dumps my hosts are sending: TEST_STATEID
> netapp reply is: Status: NFS4ERR_BAD_STATEID (10025)
> After this host sends: Network File System, Ops(5): SEQUENCE, PUTFH, OPEN, ACCESS, GETATTR
> Reply: V4 Reply (Call In 17) OPEN StateID: 0xa205
> Request: V4 Call (Reply In 22) READ StateID: 0xca5f Offset: 0 Len: 4096
> Reply: V4 Reply (Call In 19) READ Status: NFS4ERR_BAD_STATEID
>
>
> Entire conversaion looks like:
> No.     Time           Source             Destination       Protocol  Length Info
>       1 0.00       10._host_          10._netapp_        NFS      238    V4 Call (Reply In 2) TEST_STATEID
>       2 0.000251       10._netapp_        10._host_          NFS      170    V4 Reply (Call In 1) TEST_STATEID (here is Status: NFS4ERR_BAD_STATEID (10025))
>       3 0.000352       10._host_          10._netapp_        NFS      338    V4 Call (Reply In 4) OPEN DH: 0xa2c3ad28/
>       4 0.000857       10._netapp_        10._host_          NFS      394    

Re: [ovirt-users] Found some bugs with NFS.

2018-01-23 Thread Sergey Kulikov 

Or maybe somebody can point me to the right place for submitting this?
Thanks. :)

---



 Monday, January 22, 2018, 14:10:53:

> This is test environment, running Centos 7.4, oVirt 4.2.0, kernel 
> 3.10.0-693.11.6.el7.x86_64 (3.10.0-693.11.1 and 3.10.0-693 have same bugs)
> 
> 
> 1. Can't force NFS to 4.0.
> Some time ago, I've set my NFS version for all storage domains to V4, because 
> there was a bug with Netapp data ontap 8.x
> and RHEL, using NFS 4.1(NFS mount started to hang after a while, STATEID 
> problems) v4 on centos 7.2 and 7.3 was mounting NFS as 4.0,
> so there were no problems related to NFS, after some time Centos 7.4 was 
> released, and I've noticed that mount points started to hang again,
> NFS was mounted with vers=4.1, and it's not possible to change to 4.0, both 
> options "V4" and "V4.1" mounts as 4.1. Looks like V4 option is 
> system default version for 4.X, and as I know it was changed in Centos 7.4 
> from 4.0 to 4.1, maybe 4.0 option should be added
> to force 4.0 version? because adding vers=/nfsvers= in "Additional mount 
> options" is denied by ovirt.
> I know, I can turn it off on netapp side, but there may be situations where 
> storage is out of control. And 4.0 version can't be
> set on ovirt side.
> 
> 2. This bug isn't directly related to ovirt, but affects it.
> Don't really shure that this is right place to report.
> As I've said before there were bug with NFS 4.1, Netapp data ontap 8 and RHEL 
> 7.x, but it was fixed in otap 9.x,
> Now we have 9.x ONTAP on Netapp and it brought new bugs with RHEL 7.4 :D
> After updating to centos 7.4 nfs domains in ovirt started to hang\lock again, 
> This happens randomly, on random hosts, after few
> days of uptime, entire datacenter goes offline, hosts down, storage domains 
> down, some vms in UP and some in unknown state, but
> actually VMs are working, HostedEngine also working, but I can't control the 
> environment.
> There are many hanging ioprocess(>1300) and vdsm processes(>1300) on some 
> hosts, also there are some dd commands, that are checking
> storage hanging:
> ├─vdsmd─┬─2*[dd]
> │   ├─1304*[ioprocess───{ioprocess}]
> │   ├─12*[ioprocess───4*[{ioprocess}]]
> │   └─1365*[{vdsmd}]
> vdsm 19470  0.0  0.0   4360   348 ?D<   Jan21   0:00 /usr/bin/dd 
> if=/rhev/data-center/mnt/10.xx.xx.xx:_test__nfs__sas_iso/6cd147b4-8039-4f8a-8aa7-5fd54d81/dom_md/metadata
>  of=/dev/null bs=4096 count=1 iflag=direct
> vdsm 40707  0.0  0.0   4360   348 ?D<   00:44   0:00 /usr/bin/dd 
> if=/rhev/data-center/mnt/10.xx.xx.xx:_test__nfs__sas_export/58d9e2c2-8fef-4abc-be13-a273d6af320f/dom_md/metadata
>  of=/dev/null bs=4096 count=1 iflag=direct
> 
> vdsm is hanging at 100% cpu load
> If I'll try to ls this files ls will hang.
> 
> I've made some dump of traffic, so looks like problem with STATID, I've found 
> 2 issues on RedHat web site, but they aren't
> publically available, so i can't read the solution:
> https://access.redhat.com/solutions/3214331   (in my case I have STATEID test)
> https://access.redhat.com/solutions/3164451   (in my case there is no manager 
> thread)
> But it looks' that I've another issue with stateid,
> According to dumps my hosts are sending: TEST_STATEID
> netapp reply is: Status: NFS4ERR_BAD_STATEID (10025)
> After this host sends: Network File System, Ops(5): SEQUENCE, PUTFH, OPEN, 
> ACCESS, GETATTR
> Reply: V4 Reply (Call In 17) OPEN StateID: 0xa205
> Request: V4 Call (Reply In 22) READ StateID: 0xca5f Offset: 0 Len: 4096
> Reply: V4 Reply (Call In 19) READ Status: NFS4ERR_BAD_STATEID
> 
> 
> Entire conversaion looks like:
> No. Time   Source Destination   Protocol  Length 
> Info
>   1 0.00   10._host_  10._netapp_NFS  238
> V4 Call (Reply In 2) TEST_STATEID
>   2 0.000251   10._netapp_10._host_  NFS  170
> V4 Reply (Call In 1) TEST_STATEID (here is Status: NFS4ERR_BAD_STATEID 
> (10025))
>   3 0.000352   10._host_  10._netapp_NFS  338
> V4 Call (Reply In 4) OPEN DH: 0xa2c3ad28/
>   4 0.000857   10._netapp_10._host_  NFS  394
> V4 Reply (Call In 3) OPEN StateID: 0xa205
>   5 0.000934   10._host_  10._netapp_NFS  302
> V4 Call (Reply In 8) READ StateID: 0xca5f Offset: 0 Len: 4096
>   6 0.000964   10._host_  10._netapp_NFS  302
> V4 Call (Reply In 9) READ StateID: 0xca5f Offset: 0 Len: 4096
>   7 0.001133   10._netapp_10._host_  TCP  70 
> 2049 → 683 [ACK] Seq=425 Ack=901 Win=10240 Len=0 TSval=225608100 
> TSecr=302215289
>   8 0.001258   10._netapp_10._host_  NFS  170
> V4 Reply (Call In 5) READ Status: NFS4ERR_BAD_STATEID
>   9 0.001320   10._netapp_10._host_  NFS  170
> V4 Reply (Call In 6) READ Status:

[ovirt-users] update to 4.4 fails with "Domain format is different from master storage domain format" (v4.3 cluster with V4 NFS storage domains)

2020-09-29 Thread Sergey Kulikov 

Hello, I'm trying to update our hosted-engine ovirt to version 4.4 from 4.3.10 
and everything goes fine until 
hosted-engine --deploy tries to add new hosted_storage domain, we have NFS 
storage domains, and it 
fails with error:

[ INFO  ] TASK [ovirt.hosted_engine_setup : Activate storage domain]
[ ERROR ] ovirtsdk4.Error: Fault reason is "Operation Failed". Fault detail is 
"[Domain format is different from master storage domain format]". HTTP response 
code is 400.
[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "Fault 
reason is \"Operation Failed\". Fault detail is \"[Domain format is different 
from master storage domain format]\". HTTP response code is 400."}

It looks like storage domains in data center should have been upgraded to V5 
when DC and cluster 
compatibility version was updated to 4.3, but looks like it was implemented in 
ovirt 4.3.3 and this 
setup was updated from 4.2 to 4.3 before 4.3.3 was released, so I ended up with 
4.3 DCs and clusters 
with V4 storage domain format.
Is there any way to convert V4 to V5 (there are running VMs on them) to be able 
upgrade to 4.4?


-- 
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/VCKOKLB6ZVE6674HDRWVEXI5RTXIF6WZ/

[ovirt-users] Re: update to 4.4 fails with "Domain format is different from master storage domain format" (v4.3 cluster with V4 NFS storage domains)

2020-09-30 Thread Sergey Kulikov 


I was able to finish update manually creating hosted_storage domain from new 
engine web interface 
after first failure, in this case it was created with format V4 and ansible 
playbook doesn't
recreate it, after updating engine and host updating cluster compatibility 
level to 4.4 also updated
all storages to V5 format.

One more strange behavior was observed in this tasks:
[ INFO  ] TASK [ovirt.hosted_engine_setup : Make the engine aware that the 
external VM is stopped]
[ INFO  ] TASK [ovirt.hosted_engine_setup : Wait for the local bootstrap VM to 
be down at engine eyes]

it can fail, because engine can't connect to deploy host and local VM has 
unknown status, stopping 
firewalld at this moment solves it, this may be caused by "iptables" firewall 
type set in hosted 
engine cluster, maybe in this case firewalld not configured by hosted-engine 
--deploy ? 

-- 



 Tuesday, September 29, 2020, 19:47:39:


> Hello, I'm trying to update our hosted-engine ovirt to version 4.4 from 
> 4.3.10 and everything goes fine until
> hosted-engine --deploy tries to add new hosted_storage domain, we have NFS 
> storage domains, and it 
> fails with error:

> [ INFO  ] TASK [ovirt.hosted_engine_setup : Activate storage domain]
> [ ERROR ] ovirtsdk4.Error: Fault reason is "Operation Failed". Fault detail 
> is "[Domain format is
> different from master storage domain format]". HTTP response code is 400.
> [ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "Fault 
> reason is \"Operation
> Failed\". Fault detail is \"[Domain format is different from master storage 
> domain format]\". HTTP response code is 400."}

> It looks like storage domains in data center should have been upgraded to V5 
> when DC and cluster 
> compatibility version was updated to 4.3, but looks like it was implemented 
> in ovirt 4.3.3 and this 
> setup was updated from 4.2 to 4.3 before 4.3.3 was released, so I ended up 
> with 4.3 DCs and clusters
> with V4 storage domain format.
> Is there any way to convert V4 to V5 (there are running VMs on them) to be 
> able upgrade to 4.4?

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/63UEFFXWZIRKF4IJKGXFD332HZ7IEM53/

[ovirt-users] Re: update to 4.4 fails with "Domain format is different from master storage domain format" (v4.3 cluster with V4 NFS storage domains)

2020-09-30 Thread Sergey Kulikov 
No, this is fresh storage(completely empty dir) and hosted-engine deploy 
creates V5 format domain in V4 DC, 
where master domain is also V4, I can see this in web available from local 
deploy VM. And storage is 
automatically renamed by deploy script.

-- 



 Wednesday, September 30, 2020, 19:09:18:

> Are you trying to use the same storage domain ?
> I hope not, as this is not supposed to be done like that.As far as I remember 
> - you need fresh storage.

> Best Regards,
> Strahil NIkolov






> В вторник, 29 септември 2020 г., 20:07:51 Гринуич+3, Sergey Kulikov 
>  написа: 






> Hello, I'm trying to update our hosted-engine ovirt to version 4.4 from 
> 4.3.10 and everything goes fine until
> hosted-engine --deploy tries to add new hosted_storage domain, we have NFS 
> storage domains, and it 
> fails with error:

> [ INFO  ] TASK [ovirt.hosted_engine_setup : Activate storage domain]
> [ ERROR ] ovirtsdk4.Error: Fault reason is "Operation Failed". Fault detail 
> is "[Domain format is
> different from master storage domain format]". HTTP response code is 400.
> [ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "Fault 
> reason is \"Operation
> Failed\". Fault detail is \"[Domain format is different from master storage 
> domain format]\". HTTP response code is 400."}

> It looks like storage domains in data center should have been upgraded to V5 
> when DC and cluster 
> compatibility version was updated to 4.3, but looks like it was implemented 
> in ovirt 4.3.3 and this 
> setup was updated from 4.2 to 4.3 before 4.3.3 was released, so I ended up 
> with 4.3 DCs and clusters
> with V4 storage domain format.
> Is there any way to convert V4 to V5 (there are running VMs on them) to be 
> able upgrade to 4.4?

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/I3MKEBAW2NOGPWA46UG4ZSTBII2YSFWZ/