- Users - oVirt List Archives

Re: oVirt upgrade version from 4.2 to 4.3
by Strahil 20 May '19

20 May '19

I would recommend you to postpone your upgrade if you use gluster (without the API) , as creation of virtual disks via UI on gluster is having issues - only preallocated can be created. Best Regards, Strahil NikolovOn May 19, 2019 09:53, Yedidyah Bar David <didi(a)redhat.com> wrote: > > On Thu, May 16, 2019 at 3:40 PM <dmarini(a)it.iliad.com> wrote: > > > > I cannot find an official upgrade procedure from 4.2 to 4.3 oVirt version on this page: https://www.ovirt.org/documentation/upgrade-guide/upgrade-guide.html > > > > Can you help me? > > As others noted, the above should be sufficient, for general upgrade > instructions, even though it does require some updates. > > You probably want to read also: > > https://ovirt.org/release/4.3.0/ > > as well as all the other relevant pages in: > > https://ovirt.org/release/ > > Best regards, > > > > > Thanks > > _______________________________________________ > > Users mailing list -- users(a)ovirt.org > > To unsubscribe send an email to users-leave(a)ovirt.org > > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > > oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ > > List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/WG2EI6HL3S2AT… > > > > -- > Didi > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ > List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/KAJGM3URCFSNN…

3 2

oVirt upgrade version from 4.2 to 4.3
by dmarini＠it.iliad.com 19 May '19

19 May '19

I cannot find an official upgrade procedure from 4.2 to 4.3 oVirt version on this page: https://www.ovirt.org/documentation/upgrade-guide/upgrade-guide.html Can you help me? Thanks

5 6

Re: [ovirt-announce] Re: [ANN] oVirt 4.3.4 First Release Candidate is now available
by Strahil 19 May '19

19 May '19

OK, Can we summarize it: 1. VDO must 'emulate512=true' 2. 'network.remote-dio' should be off ? As per this: https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3/htm… We should have these: quick-read=off read-ahead=off io-cache=off stat-prefetch=off eager-lock=enable remote-dio=on quorum-type=auto server-quorum-type=server I'm a little bit confused here. Best Regards, Strahil NikolovOn May 19, 2019 07:44, Sahina Bose <sabose(a)redhat.com> wrote: > > > > On Sun, 19 May 2019 at 12:21 AM, Nir Soffer <nsoffer(a)redhat.com> wrote: >> >> On Fri, May 17, 2019 at 7:54 AM Gobinda Das <godas(a)redhat.com> wrote: >>> >>> From RHHI side default we are setting below volume options: >>> >>> { group: 'virt', >>> storage.owner-uid: '36', >>> storage.owner-gid: '36', >>> network.ping-timeout: '30', >>> performance.strict-o-direct: 'on', >>> network.remote-dio: 'off' >> >> >> According to the user reports, this configuration is not compatible with oVirt. >> >> Was this tested? > > > Yes, this is set by default in all test configuration. We’re checking on the bug, but the error is likely when the underlying device does not support 512b writes. > With network.remote-dio off gluster will ensure o-direct writes >> >> >>> } >>> >>> >>> On Fri, May 17, 2019 at 2:31 AM Strahil Nikolov <hunter86_bg(a)yahoo.com> wrote: >>>> >>>> Ok, setting 'gluster volume set data_fast4 network.remote-dio on' allowed me to create the storage domain without any issues. >>>> I set it on all 4 new gluster volumes and the storage domains were successfully created. >>>> >>>> I have created bug for that: >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1711060 >>>> >>>> If someone else already opened - please ping me to mark this one as duplicate. >>>> >>>> Best Regards, >>>> Strahil Nikolov >>>> >>>> >>>> В четвъртък, 16 май 2019 г., 22:27:01 ч. Гринуич+3, Darrell Budic <budic(a)onholyground.com> написа: >>>> >>>> >>>> On May 16, 2019, at 1:41 PM, Nir Soffer <nsoffer(a)redhat.com> wrote: >>>> >>>>> >>>>> On Thu, May 16, 2019 at 8:38 PM Darrell Budic <budic(a)onholyground.com> wrote: >>>>>> >>>>>> I tried adding a new storage domain on my hyper converged test cluster running Ovirt 4.3.3.7 and gluster 6.1. I was able to create the new gluster volume fine, but it’s not able to add the gluster storage domain (as either a managed gluster volume or directly entering values). The created gluster volume mounts and looks fine from the CLI. Errors in VDSM log: >>>>>> >>>>> ... >>>>>> >>>>>> 2019-05-16 10:25:09,584-0500 ERROR (jsonrpc/5) [storage.fileSD] Underlying file system doesn't supportdirect IO (fileSD:110) >>>>>> 2019-05-16 10:25:09,584-0500 INFO (jsonrpc/5) [vdsm.api] FINISH createStorageDomain error=Storage Domain target is unsupported: () from=::ffff:10.100.90.5,44732, flow_id=31d993dd, task_id=ecea28f3-60d4-476d-9ba8-b753b7c9940d (api:52) >>>>> >>>>> >>>>> The direct I/O check has failed. >>>>> >>>>> >>>>> So something is wrong in the files system. >>>>> >>>>> To confirm, you can try to do: >>>>> >>>>> dd if=/dev/zero of=/path/to/mountoint/test bs=4096 count=1 oflag=direct >>>>> >>>>> This will probably fail with: >>>>> dd: failed to open '/path/to/mountoint/test': Invalid argument >>>>> >>>>> If it succeeds, but oVirt fail to connect to this domain, file a bug and we will investigate. >>>>> >>>>> Nir >>>> >>>> >>>> Yep, it fails as expected. Just to check, it is working on pre-existing volumes, so I poked around at gluster settings for the new volume. It has network.remote-dio=off set on the new volume, but enabled on old volumes. After enabling it, I’m able to run the dd test: >>>> >>>> [root@boneyard mnt]# gluster vol set test network.remote-dio enable >>>> volume set: success >>>> [root@boneyard mnt]# dd if=/dev/zero of=testfile bs=4096 count=1 oflag=direct >>>> 1+0 records in >>>> 1+0 records out >>>> 4096 bytes (4.1 kB) copied, 0.0018285 s, 2.2 MB/s >>>> >>>> I’m also able to add the storage domain in ovirt now. >>>> >>>> I see network.remote-dio=enable is part of the gluster virt group, so apparently it’s not getting set by ovirt duding the volume creation/optimze for storage? >>>> >>>> >>>> >>>> _______________________________________________ >>>> Users mailing list -- users(a)ovirt.org >>>> To unsubscribe send an email to users-leave(a)ovirt.org >>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >>>> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ >>>> List Archives: >>>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/OPBXHYOHZA4XR… >>>> >>>> _______________________________________________ >>>> Users mailing list -- users(a)ovirt.org >>>> To unsubscribe send an email to users-leave(a)ovirt.org >>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >>>> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ >>>> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/B7K24XYG3M43C… >>> >>> >>> >>> -- >>> >>> >>> Thanks, >>> Gobinda

1 0

Re: [ovirt-announce] Re: [ANN] oVirt 4.3.4 First Release Candidate is now available
by Strahil 19 May '19

19 May '19

This is my previous e-mail: On May 16, 2019 15:23, Strahil Nikolov <hunter86_bg(a)yahoo.com> wrote: It seems that the issue is within the 'dd' command as it stays waiting for input: [root@ovirt1 mnt]# /usr/bin/dd iflag=fullblock of=file oflag=direct,seek_bytes seek=1048576 bs=256512 count=1 conv=notrunc,nocreat,fsync ^C0+0 records in 0+0 records out 0 bytes (0 B) copied, 19.3282 s, 0.0 kB/s Changing the dd command works and shows that the gluster is working: [root@ovirt1 mnt]# cat /dev/urandom | /usr/bin/dd of=file oflag=direct,seek_bytes seek=1048576 bs=256512 count=1 conv=notrunc,nocreat,fsync 0+1 records in 0+1 records out 131072 bytes (131 kB) copied, 0.00705081 s, 18.6 MB/s Best Regards, Strahil Nikolov ----- Препратено съобщение ----- От: Strahil Nikolov <hunter86_bg(a)yahoo.com> До: Users <users(a)ovirt.org> Изпратено: четвъртък, 16 май 2019 г., 5:56:44 ч. Гринуич-4 Тема: ovirt 4.3.3.7 cannot create a gluster storage domain Hey guys, I have recently updated (yesterday) my platform to latest available (v4.3.3.7) and upgraded to gluster v6.1 .The setup is hyperconverged 3 node cluster with ovirt1/gluster1 & ovirt2/gluster2 as replica nodes (glusterX is for gluster communication) while ovirt3 is the arbiter. Today I have tried to add new domain storages but they fail with the following: 2019-05-16 10:15:21,296+0300 INFO (jsonrpc/2) [vdsm.api] FINISH createStorageDomain error=Command ['/usr/bin/dd', 'iflag=fullblock', u'of=/rhev/data-center/mnt/glusterSD/gluster1:_data__fast2/591d9b61-5c7d-4388-a6b7-ab03181dff8a/dom_md/xleases', 'oflag=direct,seek_bytes', 'seek=1048576', 'bs=256512', 'count=1', 'conv=notrunc,nocreat,fsync'] failed with rc=1 out='[suppressed]' err="/usr/bin/dd: error writing '/rhev/data-center/mnt/glusterSD/gluster1:_data__fast2/591d9b61-5c7d-4388-a6b7-ab03181dff8a/dom_md/xleases': Invalid argument\n1+0 records in\n0+0 records out\n0 bytes (0 B) copied, 0.0138582 s, 0.0 kB/s\n" from=::ffff:192.168.1.2,43864, flow_id=4a54578a, task_id=d2535d0f-c7f7-4f31-a10f-704923ce1790 (api:52) 2019-05-16 10:15:21,296+0300 ERROR (jsonrpc/2) [storage.TaskManager.Task] (Task='d2535d0f-c7f7-4f31-a10f-704923ce1790') Unexpected error (task:875) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 882, in _run return fn(*args, **kargs) File "<string>", line 2, in createStorageDomain File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 50, in method ret = func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 2614, in createStorageDomain storageType, domVersion, block_size, alignment) File "/usr/lib/python2.7/site-packages/vdsm/storage/nfsSD.py", line 106, in create block_size) File "/usr/lib/python2.7/site-packages/vdsm/storage/fileSD.py", line 466, in _prepareMetadata cls.format_external_leases(sdUUID, xleases_path) File "/usr/lib/python2.7/site-packages/vdsm/storage/sd.py", line 1255, in format_external_leases xlease.format_index(lockspace, backend) File "/usr/lib/python2.7/site-packages/vdsm/storage/xlease.py", line 681, in format_index index.dump(file) File "/usr/lib/python2.7/site-packages/vdsm/storage/xlease.py", line 843, in dump file.pwrite(INDEX_BASE, self._buf) File "/usr/lib/python2.7/site-packages/vdsm/storage/xlease.py", line 1076, in pwr It seems that the 'dd' is having trouble checking the new gluster volume. The output is from the RC1 , but as you see Darell's situation is maybe the same.On May 16, 2019 21:41, Nir Soffer <nsoffer(a)redhat.com> wrote: > > On Thu, May 16, 2019 at 8:38 PM Darrell Budic <budic(a)onholyground.com> wrote: >> >> I tried adding a new storage domain on my hyper converged test cluster running Ovirt 4.3.3.7 and gluster 6.1. I was able to create the new gluster volume fine, but it’s not able to add the gluster storage domain (as either a managed gluster volume or directly entering values). The created gluster volume mounts and looks fine from the CLI. Errors in VDSM log: >> > ... >> >> 2019-05-16 10:25:09,584-0500 ERROR (jsonrpc/5) [storage.fileSD] Underlying file system doesn't supportdirect IO (fileSD:110) >> 2019-05-16 10:25:09,584-0500 INFO (jsonrpc/5) [vdsm.api] FINISH createStorageDomain error=Storage Domain target is unsupported: () from=::ffff:10.100.90.5,44732, flow_id=31d993dd, task_id=ecea28f3-60d4-476d-9ba8-b753b7c9940d (api:52) > > > The direct I/O check has failed. > > This is the code doing the check: > > 98 def validateFileSystemFeatures(sdUUID, mountDir): > 99 try: > 100 # Don't unlink this file, we don't have the cluster lock yet as it > 101 # requires direct IO which is what we are trying to test for. This > 102 # means that unlinking the file might cause a race. Since we don't > 103 # care what the content of the file is, just that we managed to > 104 # open it O_DIRECT. > 105 testFilePath = os.path.join(mountDir, "__DIRECT_IO_TEST__") > 106 oop.getProcessPool(sdUUID).directTouch(testFilePath) > 107 except OSError as e: > 108 if e.errno == errno.EINVAL: > 109 log = logging.getLogger("storage.fileSD") > 110 log.error("Underlying file system doesn't support"

4 3

Re: Gluster VM image Resync Time
by Strahil 18 May '19

18 May '19

By default ovirt uses 'sharding' which splits the files into logical chunks. This greatly reduces healing time, as VM's disk is not always completely overwritten and only the shards that are different will be healed. Maybe you should change the default shard size. Best Regards, Strahil NikolovOn Mar 27, 2019 08:24, Indivar Nair <indivar.nair(a)techterra.in> wrote: > > Hi All, > > We are planning a 2 + 1 arbitrated mirrored Gluster setup. > We would have around 50 - 60 VMs, with an average 500GB disk size. > > Now in case one of the Gluster Nodes go completely out of sync, roughly, how long would it take to resync? (as per your experience) > Will it impact the working of VMs in any way? > Is there anything to be taken care of, in advance, to prepare for such a situation? > > Regards, > > > Indivar Nair >

4 7

Any plans for oVirt and SBD fencing (a.k.a. poison pill)
by hunter86_bg＠yahoo.com 18 May '19

18 May '19

Hello Community, Do you have any idea if SBD fencing mechanism will be implemented in the nearest future? It will be nice to be able to resset a host just like corosync/pacemaker cluster implementation.

4 3

HostedEngine Deployment fails activating NFS Storage Domain hosted_storage via GUI Step 4
by Ralf Schenk 17 May '19

17 May '19

Hello, I'm deploying HostedEngine to a NFS Storage. HostedEngineLocal ist setup and running already. But Step 4 (Moving to hosted_storage Domain on NFS) fails. The Host ist Node-NG 4.3.3.1 based. The intended NFS Domain gets mounted in the host but activation (I think via EngineAPI fails): [ INFO ] TASK [ovirt.hosted_engine_setup : Activate storage domain] [ ERROR ] Error: Fault reason is "Operation Failed". Fault detail is "[]". HTTP response code is 400. [ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "Fault reason is \"Operation Failed\". Fault detail is \"[]\". HTTP response code is 400."} mount in host shows: storage.rxmgmt.databay.de:/ovirt/hosted_storage on /rhev/data-center/mnt/storage.rxmgmt.databay.de:_ovirt_hosted__storage type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,soft,nosharecache,proto=tcp,timeo=600,retrans=6,sec=sys,clientaddr=172.16.252.231,local_lock=none,addr=172.16.252.3) I also sshd into the locally running engine vi 192.168.122.XX and the VM can mount the storage domain, too: [root@engine01 ~]# mount storage.rxmgmt.databay.de:/ovirt/hosted_storage /mnt/ -o vers=4.1 [root@engine01 ~]# mount | grep nfs sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime) storage.rxmgmt.databay.de:/ovirt/hosted_storage on /mnt type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.122.71,local_lock=none,addr=172.16.252.3) [root@engine01 ~]# ls -al /mnt/ total 18 drwxrwxr-x. 3 vdsm kvm 4 Apr 30 12:59 . dr-xr-xr-x. 17 root root 224 Apr 16 14:31 .. drwxr-xr-x. 4 vdsm kvm 4 Apr 30 12:40 4dc42146-b3fb-47ec-bf06-8d9bf7cdf893 -rwxr-xr-x. 1 vdsm kvm 0 Apr 30 12:55 __DIRECT_IO_TEST__ Anything I can do ? Log-Extract of ovirt-hosted-engine-setup-ansible-create_storage_domain included. -- *Ralf Schenk* fon +49 (0) 24 05 / 40 83 70 fax +49 (0) 24 05 / 40 83 759 mail *rs(a)databay.de* <mailto:rs@databay.de> *Databay AG* Jens-Otto-Krag-Straße 11 D-52146 Würselen *www.databay.de* <http://www.databay.de> Sitz/Amtsgericht Aachen • HRB:8437 • USt-IdNr.: DE 210844202 Vorstand: Ralf Schenk, Dipl.-Ing. Jens Conze, Aresch Yavari, Dipl.-Kfm. Philipp Hermanns Aufsichtsratsvorsitzender: Wilhelm Dohmen ------------------------------------------------------------------------

3 9

Re: Host needs to be reinstalled after configuring power management
by Michael Watters 17 May '19

17 May '19

Same here. The ssh host keys on our host nodes never change but there must be something in the ovirt database that needs to be updated. On 5/16/19 6:20 PM, Andrew DeMaria wrote: > That did the trick, thank you! That is really strange behavior however > considering the fingerprint did not change.. > > On Thu, May 16, 2019 at 7:14 AM Michael Watters <wattersm(a)watters.ws > <mailto:wattersm@watters.ws>> wrote: > > Had the same message on our cluster. The solution was to click > edit on each host and refetch the ssh host key. I'm not sure why > this is necessary in the first place however. > > > On 5/14/19 3:15 PM, Andrew DeMaria wrote: >> Hi, >> >> I am running ovirt 4.3 and have found the following action item >> immediately after configuring power management for a host: >> >> Host needs to be reinstalled as important configuration changes >> were applied on it. >> >> >> The thing is - I've just freshly installed this host and it seems >> strange that I need to reinstall it. >> Is there a better way to install a host and configure power >> management without having to reinstall it after? >> >> >> Thanks, >> >> Andrew >> >> _______________________________________________ >> Users mailing list -- users(a)ovirt.org <mailto:users@ovirt.org> >> To unsubscribe send an email to users-leave(a)ovirt.org <mailto:users-leave@ovirt.org> >> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ >> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/5HMTDLIYVJJEP… > _______________________________________________ > Users mailing list -- users(a)ovirt.org <mailto:users@ovirt.org> > To unsubscribe send an email to users-leave(a)ovirt.org > <mailto:users-leave@ovirt.org> > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/users@ovirt.org/message/P6NHGE2EJ7PYH… >

1 0

Re: Dropped RX Packets
by Karli Sjöberg 17 May '19

17 May '19

1 0

Re: seal a rhel8 vm for templating fails
by Strahil 16 May '19

16 May '19

Can you try on a linux host to seal the VM via virt-sysprep ? Maybe virt-sysprep is not EL 8 ready... Best Regards, Strahil NikolovOn May 16, 2019 19:15, Nathanaël Blanchet <blanchet(a)abes.fr> wrote: > > Hi, > > I was used to successfully seal some el7 vms when templating, but with > rhel8, it always fails with that logs: > > 2019-05-16 15:45:03,499+02 ERROR > [org.ovirt.engine.core.bll.AddVmTemplateCommand] > (EE-ManagedThreadFactory-engineScheduled-Thread-55) > [db02e602-4b9d-4935-908c-e9e8c90a808b] Ending command > 'org.ovirt.engine.core.bll.AddVmTemplateCommand' with failure. > 2019-05-16 15:45:03,533+02 INFO > [org.ovirt.engine.core.vdsbroker.SetVmStatusVDSCommand] > (EE-ManagedThreadFactory-engineScheduled-Thread-55) > [db02e602-4b9d-4935-908c-e9e8c90a808b] START, SetVmStatusVDSCommand( > SetVmStatusVDSCommandParameters:{vmId='b79d8d62-212a-4f62-b236-3be6f1ed251e', > status='Down', exitStatus='Normal'}), log id: 7e657121 > 2019-05-16 15:45:03,538+02 INFO > [org.ovirt.engine.core.vdsbroker.SetVmStatusVDSCommand] > (EE-ManagedThreadFactory-engineScheduled-Thread-55) > [db02e602-4b9d-4935-908c-e9e8c90a808b] FINISH, SetVmStatusVDSCommand, > log id: 7e657121 > 2019-05-16 15:45:03,546+02 INFO > [org.ovirt.engine.core.bll.AddVmTemplateCommand] > (EE-ManagedThreadFactory-engineScheduled-Thread-55) > [db02e602-4b9d-4935-908c-e9e8c90a808b] Lock freed to object > 'EngineLock:{exclusiveLocks='[rhel8.0=TEMPLATE_NAME, > 8fb93ef2-d8a1-4d95-afed-c37131312462=TEMPLATE, > 3ae1ad71-193b-4222-9727-159b402fef49=DISK]', > sharedLocks='[b79d8d62-212a-4f62-b236-3be6f1ed251e=VM]'}' > 2019-05-16 15:45:03,560+02 ERROR > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] > (EE-ManagedThreadFactory-engineScheduled-Thread-55) > [db02e602-4b9d-4935-908c-e9e8c90a808b] EVENT_ID: > USER_ADD_VM_TEMPLATE_SEAL_FAILURE(1,324), Failed to seal Template > rhel8.0 (VM: thym-rhel8). > > But I successfully make a el8 template without sealing, but the issue is > that subscription-manager doesn't activate properly when creating new > vms from it. > > ovirt 3.3.3 > > -- > Nathanaël Blanchet > > Supervision réseau > Pôle Infrastrutures Informatiques > 227 avenue Professeur-Jean-Louis-Viala > 34193 MONTPELLIER CEDEX 5 > Tél. 33 (0)4 67 54 84 55 > Fax 33 (0)4 67 54 84 14 > blanchet(a)abes.fr > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ > List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/OO7EGM25KWGV5…

2 1