On February 7, 2020 11:28:17 AM GMT+02:00, "Goorkate, B.J." <b.j.goork...@umcutrecht.nl> wrote: >Hi, > >There is just one unsynced entry which comes back every time: the >dom_md/ids file. > >When I add/delete a VM it's gone for a short while, but then it >reappears. > >I did a brick replace to a node which is already upgraded. After that >I'll do the same with the brick on the remaining not-yet-upgraded node, >just to be sure. Luckily we have the hardware for it. > >We're migrating from 4.2.8 (I think) to 4.3.7.2. > >Regards, > >Bertjan > > >On Thu, Feb 06, 2020 at 12:43:48PM +0200, Strahil Nikolov wrote: >> On February 6, 2020 9:42:13 AM GMT+02:00, "Goorkate, B.J." ><b.j.goork...@umcutrecht.nl> wrote: >> >Hi Strahil, >> > >> >The 0-xlator-message still occurs, but not frequent. Yesterdag a >couple >> >of times, but the 4th there were no entries at all. >> > >> >What I did find out, was that the unsynced entries belonged to >> >VM-images which were on specific hosts. >> > >> >Yesterday I migrated them all to other hosts and the unsynced >entries >> >were gone except for 3. After a 'stat' of those files/directories, >they >> >were gone too. >> > >> >I think I can migrate the remaining hosts now. An option would be to >> >move the bricks of the not-yet-upgraded hosts to upgraded hosts. I >have >> >spare disks. What do you think? >> > >> >Regards, >> > >> >Bertjan >> > >> > >> > >> > >> >On Tue, Feb 04, 2020 at 06:40:21PM +0000, Strahil Nikolov wrote: >> >> Did you manage to fix the issue with the 0-xlator ? If yes, >most >> >probably >> >> the issue will be OK. Yet 'probably' doesn't meant that they >> >'will' be OK. >> >> If it was my lab - I would go ahead only if the 0-xlator issue >is >> >> over.Yet, a lab is a different thing than prod - so it is your >> >sole >> >> decision. >> >> Did you test the upgrade prior moving to Prod ? >> >> About the hooks - I had such issue before and I had to >reinstall >> >the >> >> gluster rpms to solve it. >> >> Best Regards, >> >> Strahil Nikolov >> >> В вторник, 4 февруари 2020 г., 16:35:27 ч. Гринуич+2, Goorkate, >> >B.J. >> >> <b.j.goork...@umcutrecht.nl> написа: >> >> Hi Strahil, >> >> >> >> Thanks for your time so far! >> >> >> >> The packages seem fine on all of the 3 nodes. >> >> Only /var/lib/glusterd/glusterd.info is modified and on the not >> >yet >> >> upgraded nodes these files are missing: >> >> >> >> missing /var/lib/glusterd/hooks/1/set/post/S30samba-set.sh >> >> missing /var/lib/glusterd/hooks/1/start/post/S29CTDBsetup.sh >> >> missing >/var/lib/glusterd/hooks/1/start/post/S30samba-start.sh >> >> missing >/var/lib/glusterd/hooks/1/stop/pre/S29CTDB-teardown.sh >> >> missing /var/lib/glusterd/hooks/1/stop/pre/S30samba-stop.sh >> >> >> >> But that doesn't seem relevant... >> >> >> >> I stopped a couple of virtual machines with image files with >> >unsynched >> >> entries. When they were turned off, I couldn't find them >anymore >> >in the >> >> unsyced entries list. When I turned them on again, some >> >re-appeared, some >> >> didn't. >> >> >> >> I really don't know where to look next. >> >> >> >> The big question is: will the problems be resolved when I >upgrade >> >the two >> >> remaining nodes, or will it get worse? >> >> >> >> Regards, >> >> >> >> Bertjan >> >> >> >> On Sun, Feb 02, 2020 at 08:06:58PM +0000, Strahil Nikolov >wrote: >> >> > It seems that something went "off". >> >> > That '0-xlator: dlsym(xlator_api) missing: >> >> > /usr/lib64/glusterfs/6.6/rpc-transport/socket.so: >undefined >> >symbol: >> >> > xlator_api' is really worrisome. >> >> > I think that you might have a bad package and based on the >> >info it >> >> could >> >> > be glusterfs-libs which should provide >> >/usr/lib64/libgfrpc.so.0 . I'm >> >> > currently on gluster v7.0 and I can't check it on my >> >installation. >> >> > Run a for loop to check the rpms: >> >> > for i in $(rpm -qa | grep gluster) ; do echo "$i :" ; rpm >-V >> >$i'; >> >> > echo;echo; done >> >> > Most probably you can safely redo (on the upgraded node) >the >> >last yum >> >> > transaction: >> >> > yum history >> >> > yum history info <ID> -> verify the gluster packages were >> >installed >> >> here >> >> > yum history redo <ID> >> >> > If kernel, glibc, systemd were not in this transaction , >you >> >can stop >> >> > gluster and start it again: >> >> > Node in maintenance in oVirt >> >> > systemctl stop ovirt-ha-agent ovirt-ha-broker vdsmd >> >supervdsmd >> >> > systemctl stop sanlock >> >> > systemctl stop glusterd >> >> > /usr/share/glusterfs/scripts/stop-all-gluster-processes.sh >> >> > And then power up again: >> >> > systemctl start glusterd >> >> > gluster volume status -> check all connected >> >> > systemctl start sanlock supervdsmd vdsmd >> >> > systemctl start ovirt-ha-broker ovirt-ha-agent >> >> > Check situation. >> >> > Yet, you need to make gluster stop complaining , before >you >> >can take >> >> care >> >> > of the heal. Usually 'rsync' is my best friend - but this >is >> >when >> >> gluster >> >> > is working normally - and your case is far from normal. >> >> > If redo doesn't work for you -> try the "yum history >> >rollback" to >> >> recover >> >> > to last good state. >> >> > I think that 'BOOM Boot Manager' is best in such cases. >> >> > Note: Never take any of my words for granted. I'm not >running >> >oVirt >> >> in >> >> > production and some of my methods might not be OK for your >> >> environment. >> >> > Best Regards, >> >> > Strahil Nikolov >> >> > В неделя, 2 февруари 2020 г., 08:56:01 ч. Гринуич+2, Mark >> >Lamers >> >> > <mark.r.lam...@gmail.com> написа: >> >> > >> >> > Hi Strahil, >> >> > >> >> > Bertjan is not in the office today, so I will reply if >okay >> >with you. >> >> > >> >> > First I like to describe the status of our network >> >> > >> >> > There are three bricks: >> >> > >> >> > and 5 nodes: >> >> > >> >> > Every host has a management and migrate vlan iface on a >> >different >> >> bond >> >> > iface. >> >> > >> >> > The last octet of the ipaddress is similar >> >> > >> >> > The output from 'gluster volume heal <volname> info' gives >a >> >long >> >> list of >> >> > shards from all three nodes, the file is attached as >> >> > 'gluster_volume_heal_info.txt'. The node without shards in >> >the list >> >> is the >> >> > updated node to gluster6, oVirt 4.3. That is curious i >think. >> >> > >> >> > Further more I find the following errors ' E ' in the >> >glusterd.log >> >> of the >> >> > upgrated host: >> >> > >> >> > [2020-01-26 17:40:46.147730] E [MSGID: 106118] >> >> > [glusterd-syncop.c:1896:gd_sync_task_begin] 0-management: >> >Unable to >> >> > acquire lock for vmstore1 >> >> > [2020-01-26 22:47:16.655651] E [MSGID: 106118] >> >> > [glusterd-syncop.c:1896:gd_sync_task_begin] 0-management: >> >Unable to >> >> > acquire lock for vmstore1 >> >> > [2020-01-27 07:07:51.815490] E [MSGID: 106118] >> >> > [glusterd-syncop.c:1896:gd_sync_task_begin] 0-management: >> >Unable to >> >> > acquire lock for vmstore1 >> >> > [2020-01-27 18:28:14.953974] E [MSGID: 106118] >> >> > [glusterd-syncop.c:1896:gd_sync_task_begin] 0-management: >> >Unable to >> >> > acquire lock for vmstore1 >> >> > [2020-01-27 18:58:22.629457] E [MSGID: 106118] >> >> > [glusterd-op-sm.c:4133:glusterd_op_ac_lock] 0-management: >> >Unable to >> >> > acquire lock for vmstore1 >> >> > [2020-01-27 18:58:22.629595] E [MSGID: 106376] >> >> > [glusterd-op-sm.c:8150:glusterd_op_sm] 0-management: >handler >> >> returned: -1 >> >> > [2020-01-27 18:58:22.756430] E [MSGID: 106117] >> >> > [glusterd-op-sm.c:4189:glusterd_op_ac_unlock] >0-management: >> >Unable to >> >> > release lock for vmstore1 >> >> > [2020-01-27 18:58:22.756581] E [MSGID: 106376] >> >> > [glusterd-op-sm.c:8150:glusterd_op_sm] 0-management: >handler >> >> returned: -1 >> >> > [2020-01-28 05:31:52.427196] E [MSGID: 106118] >> >> > [glusterd-op-sm.c:4133:glusterd_op_ac_lock] 0-management: >> >Unable to >> >> > acquire lock for vmstore1 >> >> > [2020-01-28 05:31:52.427315] E [MSGID: 106376] >> >> > [glusterd-op-sm.c:8150:glusterd_op_sm] 0-management: >handler >> >> returned: -1 >> >> > [2020-01-28 05:31:52.537799] E [MSGID: 106115] >> >> > [glusterd-mgmt.c:117:gd_mgmt_v3_collate_errors] >0-management: >> >Locking >> >> > failed on 10.13.250.14. Please check log file for details. >> >> > [2020-01-28 05:31:52.537973] E [MSGID: 106150] >> >> > [glusterd-syncop.c:1931:gd_sync_task_begin] 0-management: >> >Locking >> >> Peers >> >> > Failed. >> >> > [2020-01-28 05:31:52.539620] E [MSGID: 106117] >> >> > [glusterd-op-sm.c:4189:glusterd_op_ac_unlock] >0-management: >> >Unable to >> >> > release lock for vmstore1 >> >> > [2020-01-28 05:31:52.539759] E [MSGID: 106376] >> >> > [glusterd-op-sm.c:8150:glusterd_op_sm] 0-management: >handler >> >> returned: -1 >> >> > [2020-01-28 05:31:52.539937] E [MSGID: 106115] >> >> > [glusterd-mgmt.c:117:gd_mgmt_v3_collate_errors] >0-management: >> >> Unlocking >> >> > failed on 10.13.250.14. Please check log file for details. >> >> > [2020-01-28 05:31:52.540446] E [MSGID: 106151] >> >> > [glusterd-syncop.c:1616:gd_unlock_op_phase] 0-management: >> >Failed to >> >> unlock >> >> > on some peer(s) >> >> > [2020-01-28 08:51:45.638694] E [MSGID: 106118] >> >> > [glusterd-syncop.c:1896:gd_sync_task_begin] 0-management: >> >Unable to >> >> > acquire lock for vmstore1 >> >> > [2020-01-28 08:52:45.709950] E [MSGID: 106118] >> >> > [glusterd-syncop.c:1896:gd_sync_task_begin] 0-management: >> >Unable to >> >> > acquire lock for vmstore1 >> >> > [2020-01-28 08:54:12.455555] E [MSGID: 101097] >> >> > [xlator.c:218:xlator_volopt_dynload] 0-xlator: >> >dlsym(xlator_api) >> >> missing: >> >> > /usr/lib64/glusterfs/6.6/rpc-transport/socket.so: >undefined >> >symbol: >> >> > xlator_api >> >> > [2020-01-28 08:54:16.214779] E [MSGID: 106118] >> >> > [glusterd-syncop.c:1896:gd_sync_task_begin] 0-management: >> >Unable to >> >> > acquire lock for vmstore1 >> >> > [2020-01-28 08:57:59.496842] E [MSGID: 106118] >> >> > [glusterd-op-sm.c:4133:glusterd_op_ac_lock] 0-management: >> >Unable to >> >> > acquire lock for vmstore1 >> >> > [2020-01-28 08:57:59.496905] E [MSGID: 106376] >> >> > [glusterd-op-sm.c:8150:glusterd_op_sm] 0-management: >handler >> >> returned: -1 >> >> > [2020-01-28 08:57:59.505119] E >> >[rpcsvc.c:1577:rpcsvc_submit_generic] >> >> > 0-rpc-service: failed to submit message (XID: 0x2, >Program: >> >GlusterD >> >> svc >> >> > cli read-only, ProgVers: 2, Proc: 5) to rpc-transport >> >> (socket.management) >> >> > [2020-01-28 08:57:59.505135] E [MSGID: 106430] >> >> > [glusterd-utils.c:558:glusterd_submit_reply] 0-glusterd: >> >Reply >> >> submission >> >> > failed >> >> > [2020-01-28 08:57:59.647456] E [MSGID: 106117] >> >> > [glusterd-op-sm.c:4189:glusterd_op_ac_unlock] >0-management: >> >Unable to >> >> > release lock for vmstore1 >> >> > [2020-01-28 08:57:59.647508] E [MSGID: 106376] >> >> > [glusterd-op-sm.c:8150:glusterd_op_sm] 0-management: >handler >> >> returned: 1 >> >> > [2020-01-28 08:57:59.654929] E >> >[rpcsvc.c:1577:rpcsvc_submit_generic] >> >> > 0-rpc-service: failed to submit message (XID: 0x2, >Program: >> >GlusterD >> >> svc >> >> > cli, ProgVers: 2, Proc: 27) to rpc-transport >> >(socket.management) >> >> > [2020-01-28 08:57:59.654943] E [MSGID: 106430] >> >> > [glusterd-utils.c:558:glusterd_submit_reply] 0-glusterd: >> >Reply >> >> submission >> >> > failed >> >> > [2020-01-28 09:07:34.941350] E [MSGID: 106118] >> >> > [glusterd-op-sm.c:4133:glusterd_op_ac_lock] 0-management: >> >Unable to >> >> > acquire lock for vmstore1 >> >> > [2020-01-28 09:07:34.941391] E [MSGID: 106376] >> >> > [glusterd-op-sm.c:8150:glusterd_op_sm] 0-management: >handler >> >> returned: -1 >> >> > [2020-01-28 09:07:35.042466] E [MSGID: 106117] >> >> > [glusterd-op-sm.c:4189:glusterd_op_ac_unlock] >0-management: >> >Unable to >> >> > release lock for vmstore1 >> >> > [2020-01-28 09:07:35.042510] E [MSGID: 106376] >> >> > [glusterd-op-sm.c:8150:glusterd_op_sm] 0-management: >handler >> >> returned: -1 >> >> > [2020-01-28 09:13:32.329172] E [MSGID: 106244] >> >[glusterd.c:1785:init] >> >> > 0-management: creation of 1 listeners failed, continuing >with >> >> succeeded >> >> > transport >> >> > [2020-01-28 09:13:44.024431] E [MSGID: 101097] >> >> > [xlator.c:218:xlator_volopt_dynload] 0-xlator: >> >dlsym(xlator_api) >> >> missing: >> >> > /usr/lib64/glusterfs/6.6/rpc-transport/socket.so: >undefined >> >symbol: >> >> > xlator_api >> >> > [2020-01-28 09:45:46.347499] E [MSGID: 106118] >> >> > [glusterd-syncop.c:1896:gd_sync_task_begin] 0-management: >> >Unable to >> >> > acquire lock for vmstore1 >> >> > [2020-01-28 09:46:45.837466] E [MSGID: 106118] >> >> > [glusterd-syncop.c:1896:gd_sync_task_begin] 0-management: >> >Unable to >> >> > acquire lock for vmstore1 >> >> > [2020-01-28 09:47:45.976186] E [MSGID: 106118] >> >> > [glusterd-syncop.c:1896:gd_sync_task_begin] 0-management: >> >Unable to >> >> > acquire lock for vmstore1 >> >> > [2020-01-28 09:48:24.976568] E >> >[rpc-clnt.c:346:saved_frames_unwind] >> >> (--> >> >> > >> >/lib64/libglusterfs.so.0(_gf_log_callingfn+0x13b)[0x7f61c7c07adb] >> >> (--> >> >> > /lib64/libgfrpc.so.0(+0xd7e4)[0x7f61c79ae7e4] (--> >> >> > /lib64/libgfrpc.so.0(+0xd8fe)[0x7f61c79ae8fe] (--> >> >> > >> >> >> >>/lib64/libgfrpc.so.0(rpc_clnt_connection_cleanup+0x97)[0x7f61c79af987] >> >> > (--> /lib64/libgfrpc.so.0(+0xf518)[0x7f61c79b0518] ))))) >> >> 0-management: >> >> > forced unwinding frame type(glusterd mgmt v3) op(--(1)) >> >called at >> >> > 2020-01-28 09:44:45.743365 (xid=0x52) >> >> > [2020-01-28 09:48:24.976640] E [MSGID: 106115] >> >> > [glusterd-mgmt.c:117:gd_mgmt_v3_collate_errors] >0-management: >> >Locking >> >> > failed on 10.13.250.11. Please check log file for details. >> >> > [2020-01-28 09:48:24.976743] E [MSGID: 106150] >> >> > [glusterd-syncop.c:1931:gd_sync_task_begin] 0-management: >> >Locking >> >> Peers >> >> > Failed. >> >> > [2020-01-28 09:48:24.977361] E >> >[rpc-clnt.c:346:saved_frames_unwind] >> >> (--> >> >> > >> >/lib64/libglusterfs.so.0(_gf_log_callingfn+0x13b)[0x7f61c7c07adb] >> >> (--> >> >> > /lib64/libgfrpc.so.0(+0xd7e4)[0x7f61c79ae7e4] (--> >> >> > /lib64/libgfrpc.so.0(+0xd8fe)[0x7f61c79ae8fe] (--> >> >> > >> >> >> >>/lib64/libgfrpc.so.0(rpc_clnt_connection_cleanup+0x97)[0x7f61c79af987] >> >> > (--> /lib64/libgfrpc.so.0(+0xf518)[0x7f61c79b0518] ))))) >> >> 0-management: >> >> > forced unwinding frame type(glusterd mgmt) op(--(3)) >called >> >at >> >> 2020-01-28 >> >> > 09:46:03.586874 (xid=0x53) >> >> > [2020-01-28 09:48:24.977417] E [MSGID: 106152] >> >> > [glusterd-syncop.c:104:gd_collate_errors] 0-glusterd: >Staging >> >failed >> >> on >> >> > 10.13.250.11. Please check log file for details. >> >> > [2020-01-28 09:48:24.977631] E >> >[rpcsvc.c:1577:rpcsvc_submit_generic] >> >> > 0-rpc-service: failed to submit message (XID: 0x2, >Program: >> >GlusterD >> >> svc >> >> > cli, ProgVers: 2, Proc: 22) to rpc-transport >> >(socket.management) >> >> > [2020-01-28 09:48:24.977664] E [MSGID: 106430] >> >> > [glusterd-utils.c:558:glusterd_submit_reply] 0-glusterd: >> >Reply >> >> submission >> >> > failed >> >> > [2020-01-28 09:48:24.977744] E [MSGID: 106115] >> >> > [glusterd-mgmt.c:117:gd_mgmt_v3_collate_errors] >0-management: >> >> Unlocking >> >> > failed on 10.13.250.13. Please check log file for details. >> >> > [2020-01-28 09:48:24.977861] E [MSGID: 106115] >> >> > [glusterd-mgmt.c:117:gd_mgmt_v3_collate_errors] >0-management: >> >> Unlocking >> >> > failed on 10.13.250.15. Please check log file for details. >> >> > [2020-01-28 09:48:25.012037] E [MSGID: 106115] >> >> > [glusterd-mgmt.c:117:gd_mgmt_v3_collate_errors] >0-management: >> >> Unlocking >> >> > failed on 10.13.250.14. Please check log file for details. >> >> > [2020-01-28 09:48:25.012148] E [MSGID: 106151] >> >> > [glusterd-syncop.c:1616:gd_unlock_op_phase] 0-management: >> >Failed to >> >> unlock >> >> > on some peer(s) >> >> > [2020-01-28 09:48:25.012315] E [MSGID: 106117] >> >> > [glusterd-syncop.c:1640:gd_unlock_op_phase] 0-management: >> >Unable to >> >> > release lock for vmstore1 >> >> > [2020-01-28 09:48:25.012425] E >> >[rpcsvc.c:1577:rpcsvc_submit_generic] >> >> > 0-rpc-service: failed to submit message (XID: 0x2, >Program: >> >GlusterD >> >> svc >> >> > cli, ProgVers: 2, Proc: 27) to rpc-transport >> >(socket.management) >> >> > [2020-01-28 09:48:25.012452] E [MSGID: 106430] >> >> > [glusterd-utils.c:558:glusterd_submit_reply] 0-glusterd: >> >Reply >> >> submission >> >> > failed >> >> > [2020-01-28 09:50:46.105492] E [MSGID: 101097] >> >> > [xlator.c:218:xlator_volopt_dynload] 0-xlator: >> >dlsym(xlator_api) >> >> missing: >> >> > /usr/lib64/glusterfs/6.6/rpc-transport/socket.so: >undefined >> >symbol: >> >> > xlator_api >> >> > [2020-01-28 10:13:16.199982] E [MSGID: 106118] >> >> > [glusterd-op-sm.c:4133:glusterd_op_ac_lock] 0-management: >> >Unable to >> >> > acquire lock for vmstore1 >> >> > [2020-01-28 10:13:16.200078] E [MSGID: 106376] >> >> > [glusterd-op-sm.c:8150:glusterd_op_sm] 0-management: >handler >> >> returned: -1 >> >> > [2020-01-28 10:13:16.345918] E [MSGID: 106117] >> >> > [glusterd-op-sm.c:4189:glusterd_op_ac_unlock] >0-management: >> >Unable to >> >> > release lock for vmstore1 >> >> > [2020-01-28 10:13:16.346012] E [MSGID: 106376] >> >> > [glusterd-op-sm.c:8150:glusterd_op_sm] 0-management: >handler >> >> returned: -1 >> >> > [2020-01-28 12:42:46.212783] E [MSGID: 106118] >> >> > [glusterd-syncop.c:1896:gd_sync_task_begin] 0-management: >> >Unable to >> >> > acquire lock for vmstore1 >> >> > [2020-01-28 13:25:49.857368] E [MSGID: 101097] >> >> > [xlator.c:218:xlator_volopt_dynload] 0-xlator: >> >dlsym(xlator_api) >> >> missing: >> >> > /usr/lib64/glusterfs/6.6/rpc-transport/socket.so: >undefined >> >symbol: >> >> > xlator_api >> >> > [2020-01-29 13:26:03.031179] E [MSGID: 101097] >> >> > [xlator.c:218:xlator_volopt_dynload] 0-xlator: >> >dlsym(xlator_api) >> >> missing: >> >> > /usr/lib64/glusterfs/6.6/rpc-transport/socket.so: >undefined >> >symbol: >> >> > xlator_api >> >> > [2020-01-30 12:33:18.590063] E [MSGID: 101097] >> >> > [xlator.c:218:xlator_volopt_dynload] 0-xlator: >> >dlsym(xlator_api) >> >> missing: >> >> > /usr/lib64/glusterfs/6.6/rpc-transport/socket.so: >undefined >> >symbol: >> >> > xlator_api >> >> > [2020-01-30 13:34:57.027468] E [MSGID: 101097] >> >> > [xlator.c:218:xlator_volopt_dynload] 0-xlator: >> >dlsym(xlator_api) >> >> missing: >> >> > /usr/lib64/glusterfs/6.6/rpc-transport/socket.so: >undefined >> >symbol: >> >> > xlator_api >> >> > [2020-01-30 15:08:10.814931] E [MSGID: 101097] >> >> > [xlator.c:218:xlator_volopt_dynload] 0-xlator: >> >dlsym(xlator_api) >> >> missing: >> >> > /usr/lib64/glusterfs/6.6/rpc-transport/socket.so: >undefined >> >symbol: >> >> > xlator_api >> >> > [2020-01-31 09:40:22.725825] E [MSGID: 101097] >> >> > [xlator.c:218:xlator_volopt_dynload] 0-xlator: >> >dlsym(xlator_api) >> >> missing: >> >> > /usr/lib64/glusterfs/6.6/rpc-transport/socket.so: >undefined >> >symbol: >> >> > xlator_api >> >> > >> >> > I 'm curious for your opinion of the data sofar. >> >> > >> >> > Love to here from you (or ather members of the list) >> >> > >> >> > Regards Mark Lamers >> >> > >> >> > _______________________________________________ >> >> > Users mailing list -- users@ovirt.org >> >> > To unsubscribe send an email to users-le...@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/VUBWMDUN3GMKGOT63J2Y2A5X7VXXW3H3/ >> >> >> >> > _______________________________________________ >> >> > Users mailing list -- users@ovirt.org >> >> > To unsubscribe send an email to users-le...@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/PF2ONI7EHIXWXRBCJIZCVCFHYYKCYZSI/ >> >> >> >> >> >>------------------------------------------------------------------------------ >> >> >> >> De informatie opgenomen in dit bericht kan vertrouwelijk zijn >en >> >is >> >> uitsluitend bestemd voor de geadresseerde. Indien u dit bericht >> >onterecht >> >> ontvangt, wordt u verzocht de inhoud niet te gebruiken en de >> >afzender >> >> direct >> >> te informeren door het bericht te retourneren. Het Universitair >> >Medisch >> >> Centrum Utrecht is een publiekrechtelijke rechtspersoon in de >zin >> >van de >> >> W.H.W. >> >> (Wet Hoger Onderwijs en Wetenschappelijk Onderzoek) en staat >> >geregistreerd >> >> bij >> >> de Kamer van Koophandel voor Midden-Nederland onder nr. >30244197. >> >> >> >> Denk s.v.p aan het milieu voor u deze e-mail afdrukt. >> >> >> >> >> >>------------------------------------------------------------------------------ >> >> >> >> This message may contain confidential information and is >intended >> >> exclusively >> >> for the addressee. If you receive this message unintentionally, >> >please do >> >> not >> >> use the contents but notify the sender immediately by return >> >e-mail. >> >> University >> >> Medical Center Utrecht is a legal person by public law and is >> >registered >> >> at >> >> the Chamber of Commerce for Midden-Nederland under no. >30244197. >> >> >> >> Please consider the environment before printing this e-mail. >> >> Hi Bertjan, >> >> If you healed everything - I think there is no need to migrate >bricks. >> Just a precaution - keep a test VM for testing power off and power >on after each node is upgraded. >> >> What version are you upgrading to ? >> >> Best Regards, >> Strahil Nikolov >_______________________________________________ >Users mailing list -- users@ovirt.org >To unsubscribe send an email to users-le...@ovirt.org >Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >oVirt Code o
You can check on the bricks which has the newest (usually the diff is in the timestamp inside) and copy that on the rest of the bricks. Then a heal can clear the pending heal entry. Sadly this happens for some time and I never had such issues with oVirt 4.2 on gluster v3. Best Regards, Strahil Nikolov _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/ETSAW3DN7TKIQQRMDTE4ONSQ3FTXOFEJ/
