[ovirt-users] Re: Cannot copy or move disks

[Sahina Bose]

+Gobinda Das 
 +Ritesh Chikatwar  +Vinayakswami Hariharmath

Vinayak, could you look at this?


On Mon, Nov 16, 2020 at 3:10 PM Nir Soffer  wrote:

> On Sun, Nov 15, 2020 at 10:27 PM  wrote:
> >
> > So, you think it's really a bug?
>
> I'm pretty sure this is a bug on gluster side.
>
> >
> > 
> > De: "Nir Soffer" 
> > Para: supo...@logicworks.pt
> > Cc: "users" , "Sahina Bose" ,
> "Krutika Dhananjay" , "Nisan, Tal"  >
> > Enviadas: Domingo, 15 De Novembro de 2020 15:03:21
> > Assunto: Re: [ovirt-users] Cannot copy or move disks
> >
> > On Sat, Nov 14, 2020 at 4:45 PM  wrote:
> > >
> > > Hello,
> > >
> > > I just update to Version 4.4.3.11-1.el8. Engine and host
> > >
> > > and now I cannot copy or move disks.
> > >
> > > Storage domains are glusterfs
> > >
> > > # gluster --version
> > > glusterfs 7.8
> > >
> > > Here is what I found on vdsm.log
> > >
> > > 2020-11-14 14:08:16,917+ INFO  (tasks/5) [storage.SANLock]
> Releasing Lease(name='01178644-2ad6-4d37-8657-f33f547bee6b',
> path='/rhev/data-center/mnt/glusterSD/node1-teste.aclou
> > > d.pt:_data2/83f8bbfd-cfa3-46d9-a823-c36054826d13/images/97977cbf-eecc-4476-a11f-7798425d40c4/01178644-2ad6-4d37-8657-f33f547bee6b.lease',
> offset=0) (clusterlock:530)
> > > 2020-11-14 14:08:17,015+ INFO  (tasks/5) [storage.SANLock]
> Successfully released Lease(name='01178644-2ad6-4d37-8657-f33f547bee6b',
> path='/rhev/data-center/mnt/glusterSD/node1
> > > -teste.acloud.pt:_data2/83f8bbfd-cfa3-46d9-a823-c36054826d13/images/97977cbf-eecc-4476-a11f-7798425d40c4/01178644-2ad6-4d37-8657-f33f547bee6b.lease',
> offset=0) (clusterlock:540)
> > > 2020-11-14 14:08:17,016+ ERROR (tasks/5) [root] Job
> '8cd732fc-d69b-4c32-8b35-e4a8e47396fb' failed (jobs:223)
> > > Traceback (most recent call last):
> > >  File "/usr/lib/python3.6/site-packages/vdsm/jobs.py", line 159, in run
> > >self._run()
> > >  File
> "/usr/lib/python3.6/site-packages/vdsm/storage/sdm/api/copy_data.py", line
> 110, in _run
> > >self._operation.run()
> > >  File "/usr/lib/python3.6/site-packages/vdsm/storage/qemuimg.py", line
> 374, in run
> > >for data in self._operation.watch():
> > >  File "/usr/lib/python3.6/site-packages/vdsm/storage/operation.py",
> line 106, in watch
> > >self._finalize(b"", err)
> > >  File "/usr/lib/python3.6/site-packages/vdsm/storage/operation.py",
> line 179, in _finalize
> > >raise cmdutils.Error(self._cmd, rc, out, err)
> > > vdsm.common.cmdutils.Error: Command ['/usr/bin/qemu-img', 'convert',
> '-p', '-t', 'none', '-T', 'none', '-f', 'raw', '-O', 'raw',
> '/rhev/data-center/mnt/glusterSD/node1-teste.aclou
> > > d.pt:_data2/83f8bbfd-cfa3-46d9-a823-c36054826d13/images/789f6e50-b954-4dda-a6d5-077fdfb357d2/d95a3e83-74d2-40a6-9f8f-e6ae68794051',
> '/rhev/data-center/mnt/glusterSD/node1-teste.ac
> > > loud.pt:_data2/83f8bbfd-cfa3-46d9-a823-c36054826d13/images/97977cbf-eecc-4476-a11f-7798425d40c4/01178644-2ad6-4d37-8657-f33f547bee6b']
> failed with rc=1 out=b'' err=bytearray(b'qem
> > > u-img: error while reading sector 260177858: No such file or
> directory\n')
> >
> > This is an impossible error for read(), preadv() etc.
> >
> > > 2020-11-14 14:08:17,017+ INFO  (tasks/5) [root] Job
> '8cd732fc-d69b-4c32-8b35-e4a8e47396fb' will be deleted in 3600 seconds
> (jobs:251)
> > > 2020-11-14 14:08:17,017+ INFO  (tasks/5)
> [storage.ThreadPool.WorkerThread] FINISH task
> 6cb1d496-d1ca-40b5-a488-a72982738bab (threadPool:151)
> > > 2020-11-14 14:08:17,316+ INFO  (jsonrpc/2) [api.host] START
> getJobs(job_type='storage',
> job_ids=['8cd732fc-d69b-4c32-8b35-e4a8e47396fb'])
> from=:::192.168.5.165,36616, flow
> > > _id=49320e0a-14fb-4cbb-bdfd-b2546c260bf7 (api:48)
> >
> > This was reported here a long time ago with various versions of gluster.
> > I don't think we got any response from gluster folks about it yet.
> >
> > Can you file an oVirt bug about this?
> >
> > Nir
>
>
>
___
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/O5WZE5ETTNBXGDREWIFFK7P724F7ZT23/

[ovirt-users] Re: CLI for HCI setup

[Sahina Bose]

There's the ansible playbooks that you can use -
https://github.com/gluster/gluster-ansible/tree/master/playbooks/hc-ansible-deployment

On Thu, Sep 3, 2020 at 12:26 AM Michael Thomas  wrote:

> Is there a CLI for setting up a hyperconverged environment with
> glusterfs?  The docs that I've found detail how to do it using the
> cockpit interface[1], but I'd prefer to use a cli similar to
> 'hosted-engine --deploy' if it is available.
>
> Thanks,
>
> --Mike
> [1]
> https://www.ovirt.org/documentation/gluster-hyperconverged/chap-Deploying_Hyperconverged.html
> ___
> 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/KBSWDQXASO7PT5ZTWCH34DXSPJAQ3DMO/
>
___
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/QFGERQDT7VM4VKYO2XBZ2BY3MJHZ3CAG/

[ovirt-users] Re: Multiple Gluster ACL issues with oVirt

[Sahina Bose]

Thanks Strahil.

Adding Sas and Ravi for their inputs.

On Sun, 21 Jun 2020 at 6:11 PM, Strahil Nikolov 
wrote:

> Hello Sahina, Sandro,
>
> I have noticed that the ACL issue with Gluster (
> https://github.com/gluster/glusterfs/issues/876) is  happening to
> multiple oVirt users  (so far at least 5)  and I think that this  issue
> needs greater attention.
> Did anyone from the RHHI team managed  to reproduce the  bug  ?
>
> 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/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/AGCTENWEXPTDCNZFZDYRXPRZ2QF422SL/

[ovirt-users] Re: Hyperconverged setup - storage architecture - scaling

[Sahina Bose]

On Thu, Jan 9, 2020 at 10:22 PM C Williams  wrote:

>   Hello,
>
> I did not see an answer to this ...
>
> "> 3. If the limit of hosts per datacenter is 250, then (in theory ) the
> recomended way in reaching this treshold would be to create 20 separated
> oVirt logical clusters with 12 nodes per each ( and datacenter managed from
> one ha-engine ) ?"
>
> I have an existing oVirt datacenter with its own engine, hypervisors, etc.
> Could I create hyperconverged clusters managed by my current datacenter ?
> Ex. Cluster 1 -- 12 hyperconverged physical machines (storage/compute),
> Cluster 2 -- 12 hyperconverged physical machines, etc.
>

Yes, you can add multiple clusters to be managed by your existing engine.
The deployment flow would be different though, as the installation via
cockpit also deploys the engine for the servers selected.
You would need to create a custom ansible playbook that sets up the gluster
volumes and add the hosts to the existing engine. (or do the creation of
cluster and gluster volumes via the engine UI)


> Please let me know.
>
> Thank You
>
> C Williams
>
> On Tue, Jan 29, 2019 at 4:21 AM Sahina Bose  wrote:
>
>> On Mon, Jan 28, 2019 at 6:22 PM Leo David  wrote:
>> >
>> > Hello Everyone,
>> > Reading through the document:
>> > "Red Hat Hyperconverged Infrastructure for Virtualization 1.5
>> >  Automating RHHI for Virtualization deployment"
>> >
>> > Regarding storage scaling,  i see the following statements:
>> >
>> > 2.7. SCALING
>> > Red Hat Hyperconverged Infrastructure for Virtualization is supported
>> for one node, and for clusters of 3, 6, 9, and 12 nodes.
>> > The initial deployment is either 1 or 3 nodes.
>> > There are two supported methods of horizontally scaling Red Hat
>> Hyperconverged Infrastructure for Virtualization:
>> >
>> > 1 Add new hyperconverged nodes to the cluster, in sets of three, up to
>> the maximum of 12 hyperconverged nodes.
>> >
>> > 2 Create new Gluster volumes using new disks on existing hyperconverged
>> nodes.
>> > You cannot create a volume that spans more than 3 nodes, or expand an
>> existing volume so that it spans across more than 3 nodes at a time
>> >
>> > 2.9.1. Prerequisites for geo-replication
>> > Be aware of the following requirements and limitations when configuring
>> geo-replication:
>> > One geo-replicated volume only
>> > Red Hat Hyperconverged Infrastructure for Virtualization (RHHI for
>> Virtualization) supports only one geo-replicated volume. Red Hat recommends
>> backing up the volume that stores the data of your virtual machines, as
>> this is usually contains the most valuable data.
>> > --
>> >
>> > Also  in oVirtEngine UI, when I add a brick to an existing volume i get
>> the following warning:
>> >
>> > "Expanding gluster volume in a hyper-converged setup is not recommended
>> as it could lead to degraded performance. To expand storage for cluster, it
>> is advised to add additional gluster volumes."
>> >
>> > Those things are raising a couple of questions that maybe for some for
>> you guys are easy to answer, but for me it creates a bit of confusion...
>> > I am also referring to RedHat product documentation,  because I  treat
>> oVirt as production-ready as RHHI is.
>>
>> oVirt and RHHI though as close to each other as possible do differ in
>> the versions used of the various components and the support
>> limitations imposed.
>> >
>> > 1. Is there any reason for not going to distributed-replicated volumes
>> ( ie: spread one volume across 6,9, or 12 nodes ) ?
>> > - ie: is recomanded that in a 9 nodes scenario I should have 3
>> separated volumes,  but how should I deal with the folowing question
>>
>> The reason for this limitation was a bug encountered when scaling a
>> replica 3 volume to distribute-replica. This has since been fixed in
>> the latest release of glusterfs.
>>
>> >
>> > 2. If only one geo-replicated volume can be configured,  how should I
>> deal with 2nd and 3rd volume replication for disaster recovery
>>
>> It is possible to have more than 1 geo-replicated volume as long as
>> your network and CPU resources support this.
>>
>> >
>> > 3. If the limit of hosts per datacenter is 250, then (in theory ) the
>> recomended way in reaching this treshold would be to create 20 separated
>> oVirt logical clusters with 12 nodes per each ( and datacenter managed from
>>

[ovirt-users] Re: ovirt 4.3.7 + Gluster in hyperconverged (production design)

[Sahina Bose]

On Tue, Dec 24, 2019 at 3:26 AM  wrote:

> Hi,
> After playing a bit with oVirt and Gluster in our pre-production
> environment for the last year, we have decided to move forward with a our
> production design using ovirt 4.3.7 + Gluster in a hyperconverged setup.
>
> For this we are looking get answers to a few questions that will help out
> with our design and  eventually lead to our production deployment phase:
>
> Current HW specs (total servers = 18):
> 1.- Server type: DL380 GEN 9
> 2.- Memory: 256GB
> 3.-Disk QTY per hypervisor:
> - 2x600GB SAS (RAID 0) for the OS
> - 9x1.2TB SSD (RAID[0, 6..]..? ) for GLUSTER.
> 4.-Network:
> - Bond1: 2x10Gbps
> - Bond2: 2x10Gbps (for migration and gluster)
>
> Our plan is to build 2x9 node clusters, however the following questions
> come up:
>
> 1.-Should we build 2 separate environments each with its own engine? or
> should we do 1 engine that will manage both clusters?
>

If you want the environments independent of each other, having separate
with its own engine make sense. Also the example ansible playbooks deploy
the environment with engine, so if you choose otherwise, you may need to
tweak the deployment scripts

2.-What would be the best gluster volume layout for #1 above with regards
> to RAID configuration:
> - JBOD or RAID6 or…?.
> - what is the benefit or downside of using JBOD vs RAID 6 for this
> particular scenario?
>
Preferably RAID6. With JBOD, you would have to create a 9x3 distributed
replicate volume and leave the healing of data to gluster, while with RAID
if you lose a disk this is at RAID controller level.


> 3.-Would you recommend Ansible-based deployment (if supported)? If yes
> where would I find the documentation for it? or should we just deploy using
> the UI?.
> - I have reviewed the following and in Chapter 5 it only mentions Web UI
> https://access.redhat.com/documentation/en-us/red_hat_hyperconverged_infrastructure_for_virtualization/1.6/html-single/deploying_red_hat_hyperconverged_infrastructure_for_virtualization/index#deployment_workflow
> - Also looked at
> https://github.com/gluster/gluster-ansible/tree/master/playbooks/hc-ansible-deployment
> but could not get it to work properly.
>

If you want to deploy a 12 node setup, then an ansible playbook is
available. +Gobinda Das  in case you have questions on
this.

>
> 4.-what is the recommended max server qty in a hyperconverged setup with
> gluster, 12, 15, 18...?
>
>
12 is the tested configuration, but there's no technical limitation against
expanding to 15 or 18.

Thanks,
>
> Adrian
> ___
> 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/TZEIOQW5KXIF47SZDZPMLUBWTP5QUPMZ/
>
___
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/KDP4VN567PCD6VMUD77IWJO5FL4AHDZJ/

[ovirt-users] Re: ovirt 4.3.7 geo-replication not working

[Sahina Bose]

+Sunny Kumar 

On Thu, Dec 12, 2019 at 6:33 AM Strahil  wrote:

> Hi Adrian,
>
> Have you checked the passwordless  rsync between master and slave volume
> nodes ?
>
> Best Regards,
> Strahil NikolovOn Dec 11, 2019 22:36, adrianquint...@gmail.com wrote:
> >
> > Hi,
> > I am trying to setup geo-replication between 2 sites, but I keep
> getting:
> > [root@host1 ~]#  gluster vol geo-rep geo-master 
> > slave1.mydomain2.com::geo-slave
> status
> >
> > MASTER NODE MASTER VOLMASTER
> BRICK SLAVE USER
> SLAVE  SLAVE NODESTATUSCRAWL STATUS
> LAST_SYNCED
> >
> --
>
> > host1.mydomain1.comgeo-master
> /gluster_bricks/geo-master/geo-masterroot  
> slave1.mydomain2.com::geo-slave
> N/A   FaultyN/A N/A
> > host2.mydomain2.comgeo-master
> /gluster_bricks/geo-master/geo-masterroot  
> slave1.mydomain2.com::geo-slave
> N/A   FaultyN/A N/A
> > vmm11.virt.iad3pgeo-master
> /gluster_bricks/geo-master/geo-masterroot  
> slave1.mydomain2.com::geo-slave
> N/A   FaultyN/A N/A
> >
> >
> > oVirt GUI has an icon in the volume that says "volume data is being
> geo-replicated" but we know that is not the case
> > From the logs i can see:
> > [2019-12-11 19:57:48.441557] I [fuse-bridge.c:6810:fini] 0-fuse:
> Unmounting '/tmp/gsyncd-aux-mount-5WaCmt'.
> > [2019-12-11 19:57:48.441578] I [fuse-bridge.c:6815:fini] 0-fuse: Closing
> fuse connection to '/tmp/gsyncd-aux-mount-5WaCmt'
> >
> > and
> > [2019-12-11 19:45:14.785758] I [monitor(monitor):278:monitor] Monitor:
> worker died in startup phase brick=/gluster_bricks/geo-master/geo-master
> >
> > thoughts?
> >
> > thanks,
> >
> > Adrian
> > ___
> > 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/TPTAODQ3Q4ZDKJ7W5BCKYC4NNM3TFQ2V/
> ___
> 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/ZAN3VFGL347RJZS2XEYR552XBJLYUQVS/
>
___
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/JBQXKPDIGD3SLWAF4D42IWPN2HUTOECH/

[ovirt-users] Re: Beginning oVirt / Hyperconverged

[Sahina Bose]

On Tue, Nov 12, 2019 at 3:27 AM  wrote:

> I guess this is a little late now... but:
>
> I wanted to do the same, especially because the additional servers (beyond
> 3) would lower the relative storage cost overhead when using erasure
> coding, but it's 'off the trodden path' and I cannot recommend it, after
> seeing just how fragile the whole house of cards is already.
>

Right, we only support replica 3 or replica 2 + arbiter, not erasure coded
gluster volumes or replica 4.


> The ability to extend a HCI cluster with additional storage nodes is very
> much in the genes of Gluster, but oVirt is a little more than just Gluster
> and while this capability is on the roadmap according to the RHEV roadmap
> RH Summit video, it's not there today.
>
> But here is what you can already do:
> * Save your pennies until you have enough for an extra two servers: HCI is
> supposed to do great with 6 or 9 boxes (das rutschte einfach so
> raus...sorry!)
>
> * You can always add any additional host as a compute host. I guess you
> shouldn't add it as a host for the hosted-engine VM (extra tick mark), not
> because it's impossible, but because it doesn't help making things more
> resilient. The extra compute nodes are well managed with all capabilities
> of oVirt (HA, live-migration etc.), because that's actually very close to
> the original usage model. Of course, you won't benefit from the local
> storage capacity. There is a facility for adding local storage to hosts,
> but I didn't find any documentation on usage or recommendations and would
> represent an obstacle to things like live-migration.
>
> * You can turn the forth host into a 'single-node HCI' for disaster
> recovery testing (that's what I did, except that I didn't get very far
> yet). Single node-HCI obviously has zero redundancy, but it also loses
> benefits like GUI based upgrades (a chicken and egg issue). But the ability
> to play with an additional DC and replication may be well worth allocating
> the fourth machine to that purpose. Once you have lost a three-way HCI to
> operator error or because of a software issue (as I have), that backup
> seems mightily attractive, even if there doesn't seem to be any easy way to
> extend that into a triple (wouldn't it be nice if you could do that without
> even an interruption?). But a manual rebuild of the primary triple and
> back-migration from the surviving single node HCI could save your job and
> work.
>
> * You can always add nodes to the existing Gluster, but perhaps best not
> extend the pre-configured Gluster volumes across the extra nodes. While
> that sounds easy and attractive, I seriously doubt it is supported by the
> current code base, making the management engine and the VDSM agent
> essentially blind to the extra nodes or incapable of properly handling
> faults and failures. But extra volumes to be used as application level
> container storage or similar should be fine, even if they won't be properly
> managed by oVirt.
>

You can expand the existing gluster volumes across the extra nodes. The
configuration of the volume is still a replica 3 or replica 2 + arbiter
depending on how you initially set it up - and that would mean that it can
only tolerate 1 node failure in the replica set subvolume.


> In my lab installations I moved the disks around on the four hosts so that
> the two primary nodes and the fourth (DR) node had a full complement, while
> the arbiter node had to manage with a subset of the boot SSD being used to
> host the arbitration brick. In theory you should be able to manage better
> in a three node HCI by spreading the three "normal" volumes "clockwise"
> around the nodes. I used that setup for my initial Gluster based tests (not
> using the HCI wizard), but that has oVirt treat the Gluster like a SAN.
>
> The HCI wizard doesn't support the clockwise or round-robin allocation,
> but if you feel adventurous you should be able to turn a standard
> installation into that, purely operating with brick
> additions/changes/removals but again, given the fragility of the stack and
> the extend of the documentation, I'd recommend against it.
>

You can now also edit your ansible playbook to specify the placement of the
bricks across nodes during deployment - see
https://github.com/gluster/gluster-ansible-features/pull/34, but does
require some tweaking.


> A full three-way replication (instead of 2+1 arbitration) can be
> beneficial if your cluster runs on standard sized "Lego" left-overs and you
> can get an extra box easily. But it will actually add write amplification
> as a bit of a CPU overhead, but perhaps more importantly, at the network
> level. If you got 10Gbit or better and slower storage, that may not be an
> issue, if you got SSDs and Gbit, you can easily loose 33% write bandwidth,
> while read-bandwith should be unaffected.
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> 

[ovirt-users] Re: [ANN] oVirt 4.3.7 Third Release Candidate is now available for testing

[Sahina Bose]

ction(just an example , many more are there):
>
> VDSM ovirt3.localdomain command SpmStatusVDS failed: Cannot inquire
> Lease(name='SDM',
> path=u'/rhev/data-center/mnt/glusterSD/gluster1:_data__fast3/ecc3bf0e-8214-45c1-98a6-0afa642e591f/dom_md/leases',
> offset=1048576): (2, 'Sanlock get hosts failure', 'No such file or
> directory')
>
> I will try to collect a fresh log and see what is it complaining about
> this time.
>
> Best Regards,
> Strahil Nikolov
>
> >Hi Sahina,
>
> >I have a strange situation:
> >1. When I try to access the file via 'sudo -u vdsm dd if=disk of=test
> bs=4M' the command fails on aprox 60MB.
> >2. If I run same command as root , remove the file and then run again via
> vdsm user -> this time no i/o error reported.
>
> >My guess is that I need to check what's going on the bricks themselve ...
>
> >Best Regards,
> >Strahil Nikolov
>
>
> В вторник, 19 ноември 2019 г., 0:02:16 ч. Гринуич-5, Sahina Bose <
> sab...@redhat.com> написа:
>
>
>
>
> On Tue, Nov 19, 2019 at 10:10 AM Strahil Nikolov 
> wrote:
>
> Hi Sahina,
>
> Sadly engine logs have no errors.
> I've got only an I/O error, but in the debug of the vdsm I can clearly see
> that "qemu-img" is giving an "OK".
> During the upgrade I got some metadata files pending heal, but I have
> recovered the conflict manually and should be OK.
> Today I have defined one of the VMs manually (virsh define) and then
> started it , but the issue is the same.
> It seems to be storage-related issue,as VMs that are on specific domain
> can be started , but most of my VMs are on the fast storage domains and
> none of them can be started.
>
> After the gluster snapshot restore , the engine is having issues and I
> have to separately investigate that (as I poweroff my HostedEngine before
> creating the snapshot).
>
> The logs can be find at :
> https://drive.google.com/open?id=1VAZFZWWrpimDeVuZT0sWFVXy76scr4NM
>
>
> Any ideas where to look at , as I can definitely read (using "dd if=disk"
> or qemu-img info) the disks of the rhel7 VM ?
>
>
> The vdsm logs have this:
> 2019-11-17 10:21:23,892+0200 INFO  (libvirt/events) [virt.vm]
> (vmId='b3c4d84a-9784-470c-b70e-7ad7cc45e913') abnormal vm stop device
> ua-94f763e9-fd96-4bee-a6b2-31af841a918b error eother (vm:5075)
> 2019-11-17 10:21:23,892+0200 INFO  (libvirt/events) [virt.vm]
> (vmId='b3c4d84a-9784-470c-b70e-7ad7cc45e913') CPU stopped: onIOError
> (vm:6062)
> 2019-11-17 10:21:23,893+0200 DEBUG (libvirt/events) [jsonrpc.Notification]
> Sending event {"params": {"notify_time": 4356025830,
> "b3c4d84a-9784-470c-b70e-7ad7cc45e913": {"status": "WaitForLaunch",
> "ioerror": {"alias": "ua-94f763e9-fd96-4bee-a6b2-31af841a918b", "name":
> "sda", "path":
> "/rhev/data-center/mnt/glusterSD/gluster1:_data__fast/396604d9-2a9e-49cd-9563-fdc79981f67b/images/94f763e9-fd96-4bee-a6b2-31af841a918b/5b1d3113-5cca-4582-9029-634b16338a2f"},
> "pauseCode": "EOTHER"}}, "jsonrpc": "2.0", "method":
> "|virt|VM_status|b3c4d84a-9784-470c-b70e-7ad7cc45e913"} (__init__:181)
>
> Can you check the permissions of the file
> /rhev/data-center/mnt/glusterSD/gluster1:_data__fast/396604d9-2a9e-49cd-9563-fdc79981f67b/images/94f763e9-fd96-4bee-a6b2-31af841a918b/5b1d3113-5cca-4582-9029-634b16338a2f.
> Was it reset after upgrade?
>
> Are you able to copy this file to a different location and try running a
> VM with this image?
>
> Any errors in the mount log of gluster1:_data__fast volume?
>
>
> Best Regards,
> Strahil Nikolov
>
>
>
>
> В понеделник, 18 ноември 2019 г., 11:38:13 ч. Гринуич+2, Sahina Bose <
> sab...@redhat.com> написа:
>
>
>
>
> On Mon, Nov 18, 2019 at 2:58 PM Sandro Bonazzola 
> wrote:
>
> +Sahina Bose  +Gobinda Das  +Nir
> Soffer  +Tal Nisan  can you please
> help here?
>
>
> Il giorno dom 17 nov 2019 alle ore 16:00 Strahil Nikolov <
> hunter86...@yahoo.com> ha scritto:
>
> So far,
>
> I have rolled back the engine and the 3 hosts - still cannot manipulate
> the storage.
> It seems that gluster itself is working, but vdsm and the oVirt stack
> cannot access the storage - cannot create new VM disks, cannot start a VM
> and I'm on the verge of redeploy.
>
>
>
> Any errors in vdsm logs? engine logs?
>
>
>
> Best Regards,
> Strahil Nikolov
>
> В събота, 16 ноември 2019 г., 15:40:25 ч. Гринуич+2, Strahil <
> hunter86...@yahoo.com> написа:
>
>
> I got upgraded  to  RC3 and now  cannot power any VM

[ovirt-users] Re: [ANN] oVirt 4.3.7 Third Release Candidate is now available for testing

[Sahina Bose]

On Tue, Nov 19, 2019 at 10:10 AM Strahil Nikolov 
wrote:

> Hi Sahina,
>
> Sadly engine logs have no errors.
> I've got only an I/O error, but in the debug of the vdsm I can clearly see
> that "qemu-img" is giving an "OK".
> During the upgrade I got some metadata files pending heal, but I have
> recovered the conflict manually and should be OK.
> Today I have defined one of the VMs manually (virsh define) and then
> started it , but the issue is the same.
> It seems to be storage-related issue,as VMs that are on specific domain
> can be started , but most of my VMs are on the fast storage domains and
> none of them can be started.
>
> After the gluster snapshot restore , the engine is having issues and I
> have to separately investigate that (as I poweroff my HostedEngine before
> creating the snapshot).
>
> The logs can be find at :
> https://drive.google.com/open?id=1VAZFZWWrpimDeVuZT0sWFVXy76scr4NM
>
>
> Any ideas where to look at , as I can definitely read (using "dd if=disk"
> or qemu-img info) the disks of the rhel7 VM ?
>

The vdsm logs have this:
2019-11-17 10:21:23,892+0200 INFO  (libvirt/events) [virt.vm]
(vmId='b3c4d84a-9784-470c-b70e-7ad7cc45e913') abnormal vm stop device
ua-94f763e9-fd96-4bee-a6b2-31af841a918b error eother (vm:5075)
2019-11-17 10:21:23,892+0200 INFO  (libvirt/events) [virt.vm]
(vmId='b3c4d84a-9784-470c-b70e-7ad7cc45e913') CPU stopped: onIOError
(vm:6062)
2019-11-17 10:21:23,893+0200 DEBUG (libvirt/events) [jsonrpc.Notification]
Sending event {"params": {"notify_time": 4356025830,
"b3c4d84a-9784-470c-b70e-7ad7cc45e913": {"status": "WaitForLaunch",
"ioerror": {"alias": "ua-94f763e9-fd96-4bee-a6b2-31af841a918b", "name":
"sda", "path":
"/rhev/data-center/mnt/glusterSD/gluster1:_data__fast/396604d9-2a9e-49cd-9563-fdc79981f67b/images/94f763e9-fd96-4bee-a6b2-31af841a918b/5b1d3113-5cca-4582-9029-634b16338a2f"},
"pauseCode": "EOTHER"}}, "jsonrpc": "2.0", "method":
"|virt|VM_status|b3c4d84a-9784-470c-b70e-7ad7cc45e913"} (__init__:181)

Can you check the permissions of the file
/rhev/data-center/mnt/glusterSD/gluster1:_data__fast/396604d9-2a9e-49cd-9563-fdc79981f67b/images/94f763e9-fd96-4bee-a6b2-31af841a918b/5b1d3113-5cca-4582-9029-634b16338a2f.
Was it reset after upgrade?

Are you able to copy this file to a different location and try running a VM
with this image?

Any errors in the mount log of gluster1:_data__fast volume?


> Best Regards,
> Strahil Nikolov
>
>
>
>
> В понеделник, 18 ноември 2019 г., 11:38:13 ч. Гринуич+2, Sahina Bose <
> sab...@redhat.com> написа:
>
>
>
>
> On Mon, Nov 18, 2019 at 2:58 PM Sandro Bonazzola 
> wrote:
>
> +Sahina Bose  +Gobinda Das  +Nir
> Soffer  +Tal Nisan  can you please
> help here?
>
>
> Il giorno dom 17 nov 2019 alle ore 16:00 Strahil Nikolov <
> hunter86...@yahoo.com> ha scritto:
>
> So far,
>
> I have rolled back the engine and the 3 hosts - still cannot manipulate
> the storage.
> It seems that gluster itself is working, but vdsm and the oVirt stack
> cannot access the storage - cannot create new VM disks, cannot start a VM
> and I'm on the verge of redeploy.
>
>
>
> Any errors in vdsm logs? engine logs?
>
>
>
> Best Regards,
> Strahil Nikolov
>
> В събота, 16 ноември 2019 г., 15:40:25 ч. Гринуич+2, Strahil <
> hunter86...@yahoo.com> написа:
>
>
> I got upgraded  to  RC3 and now  cannot power any VM .
> Constantly getting I/O error, but checking at gluster level - I can dd
> from each disk or even create a new one.
>
> Removing the HighAvailability doesn't help.
>
> I guess I should restore  the engine from the gluster snapshot and
> rollback via 'yum history undo last'.
>
> Does anyone else have my issues  ?
>
> Best Regards,
> Strahil Nikolov
> On Nov 13, 2019 15:31, Sandro Bonazzola  wrote:
>
>
>
> Il giorno mer 13 nov 2019 alle ore 14:25 Sandro Bonazzola <
> sbona...@redhat.com> ha scritto:
>
>
>
> Il giorno mer 13 nov 2019 alle ore 13:56 Florian Schmid <
> fsch...@ubimet.com> ha scritto:
>
> Hello,
>
> I have a question about bugs, which are flagged as [downstream clone -
> 4.3.7], but are not yet released.
>
> I'm talking about this bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=1749202
>
> I can't see it in 4.3.7 release notes. Will it be included in a further
> release candidate? This fix is very important I think and I can't upgrade
> yet because of this bug.
>
>
>
> Looking at the bug, the fix was done with $ git tag --contains
> 12bd5cb1fe7c95e29b4065fca968913722fe9e

[ovirt-users] Re: Gluster & Hyper Converged setup

[Sahina Bose]

You will need to edit to provide the correct device during installation.
Check output of lsblk

On Mon, Nov 18, 2019 at 5:19 PM  wrote:

> Logical Volumes Create new Logical Volume
> 1.35 TiB Pool for Thin Volumes  pool00
> 1 GiB ext4 File System  /dev/onn_ovirt1/home
> 1.32 TiB Inactive volumeovirt-node-ng-4.3.6-0.20190926.0
> ___
> 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/5ZP4B7IPBDUYCBSLNUWDA5VGLK67UDZ5/
>
___
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/7DFKI7DVJNLRDJAGUUIZW6IP4AAL75VX/

[ovirt-users] Re: [ANN] oVirt 4.3.7 Third Release Candidate is now available for testing

[Sahina Bose]

On Mon, Nov 18, 2019 at 2:58 PM Sandro Bonazzola 
wrote:

> +Sahina Bose  +Gobinda Das  +Nir
> Soffer  +Tal Nisan  can you please
> help here?
>
>
> Il giorno dom 17 nov 2019 alle ore 16:00 Strahil Nikolov <
> hunter86...@yahoo.com> ha scritto:
>
>> So far,
>>
>> I have rolled back the engine and the 3 hosts - still cannot manipulate
>> the storage.
>> It seems that gluster itself is working, but vdsm and the oVirt stack
>> cannot access the storage - cannot create new VM disks, cannot start a VM
>> and I'm on the verge of redeploy.
>>
>

Any errors in vdsm logs? engine logs?



>> Best Regards,
>> Strahil Nikolov
>>
>> В събота, 16 ноември 2019 г., 15:40:25 ч. Гринуич+2, Strahil <
>> hunter86...@yahoo.com> написа:
>>
>>
>> I got upgraded  to  RC3 and now  cannot power any VM .
>> Constantly getting I/O error, but checking at gluster level - I can dd
>> from each disk or even create a new one.
>>
>> Removing the HighAvailability doesn't help.
>>
>> I guess I should restore  the engine from the gluster snapshot and
>> rollback via 'yum history undo last'.
>>
>> Does anyone else have my issues  ?
>>
>> Best Regards,
>> Strahil Nikolov
>> On Nov 13, 2019 15:31, Sandro Bonazzola  wrote:
>>
>>
>>
>> Il giorno mer 13 nov 2019 alle ore 14:25 Sandro Bonazzola <
>> sbona...@redhat.com> ha scritto:
>>
>>
>>
>> Il giorno mer 13 nov 2019 alle ore 13:56 Florian Schmid <
>> fsch...@ubimet.com> ha scritto:
>>
>> Hello,
>>
>> I have a question about bugs, which are flagged as [downstream clone -
>> 4.3.7], but are not yet released.
>>
>> I'm talking about this bug:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1749202
>>
>> I can't see it in 4.3.7 release notes. Will it be included in a further
>> release candidate? This fix is very important I think and I can't upgrade
>> yet because of this bug.
>>
>>
>>
>> Looking at the bug, the fix was done with $ git tag --contains
>> 12bd5cb1fe7c95e29b4065fca968913722fe9eaa
>> ovirt-engine-4.3.6.6
>> ovirt-engine-4.3.6.7
>> ovirt-engine-4.3.7.0
>> ovirt-engine-4.3.7.1
>>
>> So the fix is already included in release oVirt 4.3.6.
>>
>>
>> Sent a fix to 4.3.6 release notes:
>> https://github.com/oVirt/ovirt-site/pull/2143. @Ryan Barry
>>  can you please review?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> BR Florian Schmid
>>
>> --
>> *Von: *"Sandro Bonazzola" 
>> *An: *"users" 
>> *Gesendet: *Mittwoch, 13. November 2019 13:34:59
>> *Betreff: *[ovirt-users] [ANN] oVirt 4.3.7 Third Release Candidate is
>> now available for testing
>>
>> The oVirt Project is pleased to announce the availability of the oVirt
>> 4.3.7 Third Release Candidate for testing, as of November 13th, 2019.
>>
>> This update is a release candidate of the seventh in a series of
>> stabilization updates to the 4.3 series.
>> This is pre-release software. This pre-release should not to be used in
>> production.
>>
>> This release is available now on x86_64 architecture for:
>> * Red Hat Enterprise Linux 7.7 or later (but <8)
>> * CentOS Linux (or similar) 7.7 or later (but <8)
>>
>> This release supports Hypervisor Hosts on x86_64 and ppc64le
>> architectures for:
>> * Red Hat Enterprise Linux 7.7 or later (but <8)
>> * CentOS Linux (or similar) 7.7 or later (but <8)
>> * oVirt Node 4.3 (available for x86_64 only) has been built consuming
>> CentOS 7.7 Release
>>
>> See the release notes [1] for known issues, new features and bugs fixed.
>>
>> While testing this release candidate please note that oVirt node now
>> includes:
>> - ansible 2.9.0
>> - GlusterFS 6.6
>>
>> Notes:
>> - oVirt Appliance is already available
>> - oVirt Node is already available
>>
>> Additional Resources:
>> * Read more about the oVirt 4.3.7 release highlights:
>> http://www.ovirt.org/release/4.3.7/
>> * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt
>> * Check out the latest project news on the oVirt blog:
>> http://www.ovirt.org/blog/
>>
>> [1] http://www.ovirt.org/release/4.3.7/
>> [2] http://resources.ovirt.org/pub/ovirt-4.3-pre/iso/
>>
>> --
>>
>> Sandro Bonazzola
>>
>> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>>
>> Red Hat EME

[ovirt-users] Re: [oVirt HC] Gluster traffic still flows on mgmt even after choosing a different Gluster nw

[Sahina Bose]

On Thu, Oct 17, 2019 at 7:22 PM Jayme  wrote:

> Thanks for the info, but where does it get the new hostname from?  Do I
> need to change the actual server hostnames of my nodes?  If I were to do
> that then the hosts would not be accessible due to the fact that the
> gluster storage subnet is isolated.
>
> I guess I'm confused about what gdeploy does during a new HCI deployment.
> I understand that you are now suppose to use hostnames that resolve to the
> storage network subnet in the first step and then specify FQDNs for
> management in the next step.  Where do the FQDNs actually get used?
>

In the cockpit based deployment, the hostnames in the first step is used to
"peer probe" and create the gluster cluster. The bricks use this interface
when the volume is created ensuring the data traffic is on this interface.

>From the ovirt-engine, when a network is tagged as gluster network, the IP
associated with this interface is also added as additonal hostname to the
gluster cluster. Any brick/volume created after this, will then use the
gluster networks IP to create the brick.
If the volume was created using the management network, you can change the
hostname that the brick is using with this command [1]
gluster volume reset-brick VOLNAME MGMT-HOSTNAME:BRICKPATH
GLUSTERNW-HOSTNAME:BRICKPATH commit force

This is assuming both of these paths ( MGMT-HOSTNAME:BRICKPATH
GLUSTERNW-HOSTNAME:BRICKPATH) refer to same brick, and gluster has been
peer probed with both MGMT-HOSTNAME and GLUSTERNW-HOSTNAME. Since I/O is
affected during the operation, this has to be performed one brick at a time
so that your VMs continue to be online.

[1]
https://docs.gluster.org/en/latest/release-notes/3.9.0/#introducing-reset-brick-command

<https://docs.gluster.org/en/latest/release-notes/3.9.0/#introducing-reset-brick-command>

>
> Can someone confirm if the hostname of oVirt host nodes should as shown by
> the "#hostname" command should resolve to IPs on the gluster storage
> network?
>
> On Thu, Oct 17, 2019 at 10:40 AM Strahil  wrote:
>
>> The reset-brick and replace-brick affects only one brick and notifies the
>> gluster cluster that a new hostname:/brick_path is being used.
>>
>> Of course, you need a hostname that resolves to the IP that is on the
>> storage network.
>>
>> WARNING: Ensure that no heals are pending as the commands are wiping the
>> brick and data there is lost.
>>
>> Best Regards,
>> Strahil Nikolov
>> On Oct 17, 2019 15:28, Jayme  wrote:
>>
>> What does the reset brick option do and is it safe to do this on a live
>> system or do all VMs need to be brought down first?  How does resetting the
>> brick fix the issue with gluster peers using the server hostnames which are
>> attached to IPs on the ovirtmanagement network?
>>
>> On Thu, Oct 17, 2019 at 4:16 AM Sahina Bose  wrote:
>>
>>
>>
>> On Wed, Oct 16, 2019 at 8:38 PM Jayme  wrote:
>>
>> Is there a way to fix this on a hci deployment which is already in
>> operation?  I do have a separate gluster network which is chosen for
>> migration and gluster network but when I originally deployed I used just
>> one set of host names which resolve to management network subnet.
>>
>>
>> You will need to change the interface that's used by the bricks. You can
>> do this by using the "Reset brick" option, once the gluster management
>> network is set correctly on the storage interface from ovirt-engine
>>
>>
>>
>> I appear to have a situation where gluster traffic may be going through
>> both networks in seeing what looks like gluster traffic on both the gluster
>> interface and ovirt management.
>>
>> On Wed, Oct 16, 2019 at 11:34 AM Stefano Stagnaro <
>> stefa...@prismatelecomtesting.com> wrote:
>>
>> Thank you Simone for the clarifications.
>>
>> I've redeployed with both management and storage FQDNs; now everything
>> seems to be in its place.
>>
>> I only have a couple of questions:
>>
>> 1) In the Gluster deployment Wizard, section 1 (Hosts) and 2 (Additional
>> Hosts) are misleading; should be renamed in something like "Host
>> Configuration: Storage side" / "Host Configuration: Management side".
>>
>> 2) what is the real function of the "Gluster Network" cluster traffic
>> type? What it actually does?
>>
>> Thanks,
>> Stefano.
>> ___
>> 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 C

[ovirt-users] Re: [oVirt HC] Gluster traffic still flows on mgmt even after choosing a different Gluster nw

[Sahina Bose]

On Wed, Oct 16, 2019 at 8:38 PM Jayme  wrote:

> Is there a way to fix this on a hci deployment which is already in
> operation?  I do have a separate gluster network which is chosen for
> migration and gluster network but when I originally deployed I used just
> one set of host names which resolve to management network subnet.
>

You will need to change the interface that's used by the bricks. You can do
this by using the "Reset brick" option, once the gluster management network
is set correctly on the storage interface from ovirt-engine

>
>
> I appear to have a situation where gluster traffic may be going through
> both networks in seeing what looks like gluster traffic on both the gluster
> interface and ovirt management.
>
> On Wed, Oct 16, 2019 at 11:34 AM Stefano Stagnaro <
> stefa...@prismatelecomtesting.com> wrote:
>
>> Thank you Simone for the clarifications.
>>
>> I've redeployed with both management and storage FQDNs; now everything
>> seems to be in its place.
>>
>> I only have a couple of questions:
>>
>> 1) In the Gluster deployment Wizard, section 1 (Hosts) and 2 (Additional
>> Hosts) are misleading; should be renamed in something like "Host
>> Configuration: Storage side" / "Host Configuration: Management side".
>>
>> 2) what is the real function of the "Gluster Network" cluster traffic
>> type? What it actually does?
>>
>> Thanks,
>> Stefano.
>> ___
>> 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/NTNXPJMOZEYVHIZV2SJXXOVXMXCXS2XP/
>>
> ___
> 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/KO5CLJNLRZOGLNGVGFMBADSDWNEUUAUG/
>
___
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/ZTSOGJJHO7ZL4WHGDERD2XKTCSM7/

[ovirt-users] Re: oVirt 4.3.5/6 HC: Reinstall fails from WEB UI

[Sahina Bose]

"Host host1.example.com cannot access the Storage Domain(s) attached to the
Data Center Default-DC1."

Can you check the vdsm logs from this host to check why the storage domains
are not attached?


On Thu, Oct 17, 2019 at 9:43 AM Strahil  wrote:

> Ssh to host and check the status of :
> sanlock.service
> supervdsmd.service
> vdsmd.service
> ovirt-ha-broker.service
> ovirt-ha-agent.service
>
> For example if sanlock is working, but supervdsmd is not - try to restart
> it.
> If it fais, run:
> systemctl cat supervdsmd.service
>
> And execute the commands in sections:
> ExecStartPre
> ExecStart
>
> And report any issues, then follow the next service in the chain.
>
> Best Regards,
> Strahil Nikolov
> On Oct 16, 2019 23:52, adrianquint...@gmail.com wrote: > > Hi, > I am
> trying to re-install a host from the web UI in oVirt 4.3.5, but it always
> fails and goes to "Setting Host state to Non-Operational" > > From the
> engine.log I see the following WARN/ERROR: > 2019-10-16 16:32:57,263-04
> WARN
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (EE-ManagedThreadFactory-engineScheduled-Thread-43) [491c8bd9] EVENT_ID:
> VDS_SET_NONOPERATIONAL_DOMAIN(522), Host host1.example.com cannot access
> the Storage Domain(s) attached to the Data Center Default-DC1. Setting
> Host state to Non-Operational. > 2019-10-16 16:32:57,271-04 WARN
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (EE-ManagedThreadFactory-engineScheduled-Thread-43) [491c8bd9] EVENT_ID:
> VDS_ALERT_FENCE_TEST_FAILED(9,001), Power Management test failed for Host
> host1.example.com.There is no other host in the data center that can be
> used to test the power management settings. > 2019-10-16 16:32:57,276-04
> WARN
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (EE-ManagedThreadFactory-engineScheduled-Thread-43) [491c8bd9] EVENT_ID:
> CONNECT_STORAGE_POOL_FAILED(995), Failed to connect Host host1.example.com
> to Storage Pool Default-DC1 > 2019-10-16 16:35:06,151-04 ERROR
> [org.ovirt.engine.core.bll.InitVdsOnUpCommand]
> (EE-ManagedThreadFactory-engine-Thread-137245) [] Could not connect host '
> host1.example.com' to pool 'Default-DC1': Error storage pool connection:
> (u"spUUID=7d3fb14c-ebf0-11e9-9ee5-00163e05e135,
> msdUUID=4b87a5de-c976-4982-8b62-7cffef4a22d8, masterVersion=1, hostID=1,
> domainsMap={u'8c2df9c6-b505-4499-abb9-0d15db80f33e': u'active',
> u'4b87a5de-c976-4982-8b62-7cffef4a22d8': u'active',
> u'5d9f7d05-1fcc-4f99-9470-4e57cd15f128': u'active',
> u'fe24d88e-6acf-42d7-a857-eaf1f8deb24a': u'active'}",) > 2019-10-16
> 16:35:06,248-04 WARN
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (EE-ManagedThreadFactory-engineScheduled-Thread-91) [690baf86] EVENT_ID:
> VDS_SET_NONOPERATIONAL_DOMAIN(522), Host host1.example.com cannot access
> the Storage Domain(s) attached to the Data Center Default-DC1. Setting
> Host state to Non-Operational. > 2019-10-16 16:35:06,256-04 WARN
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (EE-ManagedThreadFactory-engineScheduled-Thread-91) [690baf86] EVENT_ID:
> VDS_ALERT_FENCE_TEST_FAILED(9,001), Power Management test failed for Host
> host1.example.com.There is no other host in the data center that can be
> used to test the power management settings. > 2019-10-16 16:35:06,261-04
> WARN
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (EE-ManagedThreadFactory-engineScheduled-Thread-91) [690baf86] EVENT_ID:
> CONNECT_STORAGE_POOL_FAILED(995), Failed to connect Host host1.example.com
> to Storage Pool Default-DC1 > 2019-10-16 16:37:46,011-04 ERROR
> [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp Reactor)
> [] Connection timeout for host 'host1.example.com', last response arrived
> 1501 ms ago. > 2019-10-16 16:41:57,095-04 ERROR
> [org.ovirt.engine.core.bll.InitVdsOnUpCommand]
> (EE-ManagedThreadFactory-engine-Thread-137527) [17f3aadd] Could not connect
> host 'host1.example.com' to pool 'Default-DC1': Error storage pool
> connection: (u"spUUID=7d3fb14c-ebf0-11e9-9ee5-00163e05e135,
> msdUUID=4b87a5de-c976-4982-8b62-7cffef4a22d8, masterVersion=1, hostID=1,
> domainsMap={u'8c2df9c6-b505-4499-abb9-0d15db80f33e': u'active',
> u'4b87a5de-c976-4982-8b62-7cffef4a22d8': u'active',
> u'5d9f7d05-1fcc-4f99-9470-4e57cd15f128': u'active',
> u'fe24d88e-6acf-42d7-a857-eaf1f8deb24a': u'active'}",) > 2019-10-16
> 16:41:57,199-04 WARN
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (EE-ManagedThreadFactory-engineScheduled-Thread-22) [508ddb44] EVENT_ID:
> VDS_SET_NONOPERATIONAL_DOMAIN(522), Host host1.example.com cannot access
> the Storage Domain(s) attached to the Data Center Default-DC1. Setting
> Host state to Non-Operational. > 2019-10-16 16:41:57,211-04 WARN
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (EE-ManagedThreadFactory-engineScheduled-Thread-22) [508ddb44] EVENT_ID:
> 

[ovirt-users] Re: is it possible to add host on which ovirt is installed ?

[Sahina Bose]

On Tue, Oct 8, 2019 at 4:18 PM  wrote:

> Hi.
>
> I am confused now.
>
> removed all previous configuration and follwed instruction:
>
>
> https://www.ovirt.org/documentation/gluster-hyperconverged/chap-Single_node_hyperconverged.html
>
> Than I read:
>
> Deploying on oVirt Node based Hosts
> oVirt Node contains all the required packages to set up the hyperconverged
> environment. Refer to oVirt Nodes for instructions on installing oVirt Node
> on the host. You can proceed to setting up the hyperconverged environment
> if you have an oVirt Node based host.
>
> What I found, is that oVirt Node is a separate installation for separate
> machine.
>
> So now I am confused :(
>
>
> What exacly steps I need to perform, to have GUI in which I can create
> virtual machines, having only one server available :) ?
>

If your server is not running oVirt Node - you can follow the steps listed
in "Deploying on Enterprise Linux Hosts" in the same doc


> Thanks in advance.
> ___
> 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/OVLMMA2JJYP3HIU4W6KDSYMKE6WFYRTP/
>
___
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/SBQRYLHHKBYKOSEZLDN7SXZXHSVLDM7C/

[ovirt-users] Re: Change hostname of physical hosts under an oVirt and Gluster combination

[Sahina Bose]

On Tue, Sep 24, 2019 at 6:38 PM TomK  wrote:

> Hey Sahina,
>
> Thanks very much.
>
> I've taken a quick glance and it does mention I need a third host which
> I don't have.
>
> However, since I wrote, I removed everything.  Had to force remove hosts
> however the gluster setup and data in it stayed (Or so I'm thinking).
>
> I'll read the article more thoroughly however is there a specific
> procedure for adding existing oVirt gluster volumes back into a cluster?
>
> One additional question.  Is the sequence below correct?
>
> 1) Create Data Center
> 2) Create Cluster within the DC
>

When you create the cluster - there's an Import cluster option, if I
remember correctly. This should discover the peers and volumes and add it
to the engine

3) Create a Domain within the Cluster
> 4) Add hosts to DC
> 5) Import Gluster Volume
>

4 & 5 not required if you change step 2 to import.
You are running into errors below because the engine sees the addition of
new hosts as gluster peer probing to a new cluster


>
> Some issues.  I create a DC, add a Cluster then add the Host to it. Then
> I try to add another the second node but it says It's already in a
> cluster.  There is no other cluster and the second host is not listed
> anywhere.
>
> So I try to remove the first host to restart from the beginning.  It
> says I can't remove the only host now till it's in maintenance.
> Maintenance is grayed out.  I wait a bit guessing there's background
> processes running and can finally remove to readd.
>
> When I try to redo the operation and get to the step of adding another
> host, I get:
>
> "Error while executing action: Server mdskvm-p02.nix.mds.xyz is already
> part of another cluster."
>
> But I can clearly see it's not there via another oVirt UI window.
>
> oVirt:
> ovirt-engine-4.2.1.7-1.el7.centos.noarch
>
> Hosts:
> root@mdskvm-p01: ovirt-host-4.2.3-1.el7.x86_64
> root@mdskvm-p02: ovirt-host-4.2.3-1.el7.x86_64
>
> System prevents me from removing and restarting the process again with a:
>
> Failed Deleting Gluster Volume mdsgv01
>
> Logs show:
>
> 2019-09-24 09:07:26,765-04 INFO
> [org.ovirt.engine.core.vdsbroker.gluster.GlusterServersListVDSCommand]
> (default task-54) [7186786c-6e3f-4c48-858e-4e404e68d130] START,
> GlusterServersListVDSCommand(HostName = mdskvm-p01.nix.mds.xyz,
> VdsIdVDSCommandParametersBase:{hostId='0c3943d4-b95a-41f4-bb9c-30731128e057'}),
>
> log id: 50f2b07d
> 2019-09-24 09:07:26,948-04 INFO
> [org.ovirt.engine.core.vdsbroker.gluster.DeleteGlusterVolumeVDSCommand]
> (EE-ManagedThreadFactory-engine-Thread-348908)
> [7c0605a8-afe1-49a1-ad8f-299ca40a805d] FINISH,
> DeleteGlusterVolumeVDSCommand, log id: 1e8800f1
> 2019-09-24 09:07:26,954-04 ERROR
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (EE-ManagedThreadFactory-engine-Thread-348908)
> [7c0605a8-afe1-49a1-ad8f-299ca40a805d] EVENT_ID:
> GLUSTER_VOLUME_DELETE_FAILED(4,011), Could not delete Gluster Volume
> mdsgv01 on cluster NIX-DC.
> 2019-09-24 09:07:26,960-04 INFO
> [org.ovirt.engine.core.bll.gluster.DeleteGlusterVolumeCommand]
> (EE-ManagedThreadFactory-engine-Thread-348908)
> [7c0605a8-afe1-49a1-ad8f-299ca40a805d] Lock freed to object
> 'EngineLock:{exclusiveLocks='[f8686ba2-2e9b-499b-9d2f-050e3425ec9e=GLUSTER]',
>
> sharedLocks=''}'
> 2019-09-24 09:07:26,963-04 INFO
> [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListVDSCommand]
> (DefaultQuartzScheduler6) [51432e7f] START,
> GlusterVolumesListVDSCommand(HostName = mdskvm-p01.nix.mds.xyz,
> GlusterVolumesListVDSParameters:{hostId='0c3943d4-b95a-41f4-bb9c-30731128e057'}),
>
> log id: 34d8d3d9
> 2019-09-24 09:07:27,386-04 WARN
> [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturn]
> (DefaultQuartzScheduler6) [51432e7f] Could not add brick
> 'mdskvm-p02.nix.mds.xyz:/mnt/p02-d01/glusterv02' to volume
> 'f5b57076-dbd4-4d77-ae13-c1f3ee3adbe0' - server uuid
> 'ad7d956a-a121-422e-8c5c-56765bdf6a62' not found in cluster
> 'f8686ba2-2e9b-499b-9d2f-050e3425ec9e'
>
>
>
> Cheers,
> TK
>
> On 9/24/2019 5:17 AM, Sahina Bose wrote:
> >
> >
> > On Mon, Sep 23, 2019 at 6:34 AM TomK  > <mailto:tomk...@mdevsys.com>> wrote:
> >
> > Or in other words, how do I remove all resources, clusters,
> > datacenters,
> > hosts and readd them under different names?
> >
> >
> > Does this answer your question -
> >
> https://access.redhat.com/documentation/en-us/red_hat_hyperconverged_infrastructure_for_virtualization/1.5/html-single/maintaining_red_hat_hyperconverged_infrastructure_for_virtualization/index#replacing_gluster_host_diff_fqdn
> >
> >
> >  

[ovirt-users] Re: Change hostname of physical hosts under an oVirt and Gluster combination

[Sahina Bose]

On Mon, Sep 23, 2019 at 6:34 AM TomK  wrote:

> Or in other words, how do I remove all resources, clusters, datacenters,
> hosts and readd them under different names?
>

Does this answer your question -
https://access.redhat.com/documentation/en-us/red_hat_hyperconverged_infrastructure_for_virtualization/1.5/html-single/maintaining_red_hat_hyperconverged_infrastructure_for_virtualization/index#replacing_gluster_host_diff_fqdn


> Cheers,
> TK
>
>
> On 9/22/2019 6:48 PM, TomK wrote:
> > Hey All,
> >
> > Would like to change the hostname of hosts within a gluster volume
> > that's been added to oVirt.
> >
> > I also need to readd the bricks to the gluster volume under the new
> > hostname.  What's the recommended approach to do so when all this is
> > added to oVirt?
> >
>
>
> --
> Thx,
> TK.
> ___
> 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/3GROTSXKJX4UGKXZAV33AA4UFDUNSJBT/
>
___
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/L4VQBZCDGGRCTZ55CXYYQN2TMWD47DOP/

[ovirt-users] Re: Creating Bricks via the REST API

[Sahina Bose]

On Mon, Sep 23, 2019 at 9:08 PM Amit Bawer  wrote:

> +Sahina Bose 
> Thanks for your clarification Julian, creating new Gluster brick from
> ovirt's REST API is not currently supported, only from UI.
>

That's right. We do have a bug tracking this -
https://bugzilla.redhat.com/show_bug.cgi?id=1601336

>
> On Mon, Sep 23, 2019 at 6:25 PM Julian Schill 
> wrote:
>
>> > This is documented in section 6.92.2. of [1]
>> >
>> > [1]
>> >
>> https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/.
>> ..
>>
>> Section 6.92.2 documents a POST request that lets one add *existing*
>> bricks to an existing volume.
>> This doesn't answer my question on how one can create *new* bricks via
>> the REST API.
>> ___
>> 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/QMPFTXA2WX3JMB6AJNIAHS4XLBJPXXVC/
>>
>
___
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/LM335E5PLWQK5XK3FR4P7DYKSKYHKAJU/

[ovirt-users] Re: Gluster: Bricks remove failed

[Sahina Bose]

Ok, so you want to reduce the replica count to 2?
In this case there will not be any data migration. +Ravishankar
Narayanankutty 

On Thu, Sep 12, 2019 at 2:12 PM  wrote:

> Hi Sahina.
> It was
>
> gluster volume status engine
> Status of volume: engine
> Gluster process TCP Port  RDMA Port  Online
> Pid
>
> --
> Brick octavius:/engine/datastore49156 0  Y
>  15669
> Brick tiberius:/engine/datastore49157 0  Y
>  18277
> Brick clemens:/engine/datastore 49156 0  Y
>  16193
> Self-heal Daemon on localhost   N/A   N/AY
>  36483
> Self-heal Daemon on tiberiusN/A   N/AY
>  32164
> Self-heal Daemon on clemens N/A   N/AY
>  10695
>
> Task Status of Volume engine
>
> --
> There are no active volume tasks
> ___
> 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/Z5LPC3Y5U6BE4N3TOP3QB4Q3S5QWCGMT/
>
___
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/PMAQBRV5V4BWRKIM5OI4MBKJHGRIFGOS/

[ovirt-users] Re: Gluster: Bricks remove failed

[Sahina Bose]

Can you provide the output of gluster volume info before the remove-brick
was done. It's not clear if you were reducing the replica count or removing
a replica subvolume.


On Wed, Sep 11, 2019 at 4:23 PM  wrote:

> Hi.
> There is an ovirt-hosted-engine on gluster volume engine
> Replicate replica count 3
>
> Migrate to other drives.
> I do:
> gluster volume add-brick engine clemens:/gluster-bricks/engine
> tiberius:/gluster-bricks/engine octavius:/gluster-bricks/engine force
> volume add-brick: success
>
> gluster volume remove-brick engine tiberius:/engine/datastore
> clemens:/engine/datastore octavius:/engine/datastore start
> volume remove-brick start: success
> ID: dd9453d3-b688-4ed8-ad37-ba901615046c
>
> gluster volume remove-brick engine octavius:/engine/datastore status
>  Node Rebalanced-files  size   scanned  failures
>  skipped   status  run time in h:m:s
> -  ---   ---   ---   ---
>  ---  --
> localhost750.0GB34 1
>0completed0:00:02
> clemens   1121.0MB31 0
>  0completed0:00:02
>  tiberius   1225.0MB36 0
>0completed0:00:02
>
> gluster volume status engine
> Status of volume: engine
> Gluster process TCP Port  RDMA Port  Online
> Pid
>
> --
> Brick octavius:/engine/datastore49156 0  Y
>  15669
> Brick tiberius:/engine/datastore49156 0  Y
>  15930
> Brick clemens:/engine/datastore 49156 0  Y
>  16193
> Brick clemens:/gluster-bricks/engine49159 0  Y
>  6168
> Brick tiberius:/gluster-bricks/engine   49163 0  Y
>  29524
> Brick octavius:/gluster-bricks/engine   49159 0  Y
>  50056
> Self-heal Daemon on localhost   N/A   N/AY
>  50087
> Self-heal Daemon on clemens N/A   N/AY
>  6263
> Self-heal Daemon on tiberiusN/A   N/AY
>  29583
>
> Task Status of Volume engine
>
> --
> Task : Remove brick
> ID   : dd9453d3-b688-4ed8-ad37-ba901615046c
> Removed bricks:
> tiberius:/engine/datastore
> clemens:/engine/datastore
> octavius:/engine/datastore
> Status   : completed
>
>
> But the data did not migrate
>
> du -hs /gluster-bricks/engine/ /engine/datastore/
> 49M /gluster-bricks/engine/
> 20G /engine/datastore/
>
> Can you give some advice?
> ___
> 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/Q2KHWTOXBWO6FQKKTM36OIEMN2B6GYQK/
>
___
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/WD5AMFARITLPV3ZU2TSVKIH7A3OIP5EK/

[ovirt-users] Re: ovirt with glusterfs data domain - very slow writing speed on Windows server virtual machine

[Sahina Bose]

More details on the tests you ran, and also gluster profile data while you
were running the tests can help analyse.
Similar to my request to another user on thread, you can also help provide
some feedback on the data gathering ansible scripts by trying out
https://github.com/gluster/gluster-ansible-maintenance/pull/4
These scripts gather data from the hosts, and perform I/O tests on the
VM. +Sachidananda
URS 

On Thu, Aug 15, 2019 at 1:39 PM 
wrote:

> Hi folks,
>
>  I have been experimenting with oVirt cluster based on glusterfs for the
> past few days. (first-timer). The cluster is up and running and it consists
> of 4 nodes and has 4 replicas. When I try to deploy Windows Server VM I
> encounter the following issue: The disk of the VM has ok reading speed (
> close to bare metal) but the writing speed is very slow. ( about 10 times
> slower than it is supposed to be). Can anyone give me any suggestion,
> please? Thanks in advance! Here are the settings of the glusterfs volume:
>
> Volume Name: bottle-volume
> Type: Replicate
> Volume ID: 869b8d1e-1266-4820-8dcd-4fea92346b90
> Status: Started
> Snapshot Count: 0
> Number of Bricks: 1 x 4 = 4
> Transport-type: tcp
> Bricks:
> Brick1:
> cnode01.bottleship.local:/gluster_bricks/brick-cnode01/brick-cnode01
> Brick2:
> cnode02.bottleship.local:/gluster_bricks/brick-cnode02/brick-cnode02
> Brick3:
> cnode03.bottleship.local:/gluster_bricks/brick-cnode03/brick-cnode03
> Brick4:
> cnode04.bottleship.local:/gluster_bricks/brick-cnode04/brick-cnode04
> Options Reconfigured:
> network.ping-timeout: 30
> cluster.granular-entry-heal: enable
> performance.strict-o-direct: on
> storage.owner-gid: 36
> storage.owner-uid: 36
> server.event-threads: 4
> client.event-threads: 4
> cluster.choose-local: off
> features.shard: on
> cluster.shd-wait-qlength: 1
> cluster.shd-max-threads: 8
> cluster.locking-scheme: granular
> cluster.data-self-heal-algorithm: full
> cluster.server-quorum-type: server
> cluster.quorum-type: auto
> cluster.eager-lock: enable
> network.remote-dio: off
> performance.low-prio-threads: 32
> performance.io-cache: off
> performance.read-ahead: off
> performance.quick-read: off
> auth.allow: *
> user.cifs: off
> transport.address-family: inet
> nfs.disable: on
> performance.client-io-threads: off
> server.allow-insecure: on
>
> Please let me know if you need any more configuration info or hardware
> specs.
>
> best,
>
> Lyubo
> ___
> 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/JRD7377WQX6FQAZRLJ6YUHIYRRAFZLIY/
>
___
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/PDZG4R4LUMWEUSY3SWCDWS7PIAK2JYN6/

[ovirt-users] Re: Does cluster upgrade wait for heal before proceeding to next host?

[Sahina Bose]

On Fri, Aug 9, 2019 at 3:41 PM Martin Perina  wrote:

>
>
> On Thu, Aug 8, 2019 at 10:25 AM Sandro Bonazzola 
> wrote:
>
>>
>>
>> Il giorno mar 6 ago 2019 alle ore 23:17 Jayme  ha
>> scritto:
>>
>>> I’m aware of the heal process but it’s unclear to me if the update
>>> continues to run while the volumes are healing and resumes when they are
>>> done. There doesn’t seem to be any indication in the ui (unless I’m
>>> mistaken)
>>>
>>
>> Adding @Martin Perina  , @Sahina Bose
>>and @Laura Wright   on this,
>> hyperconverged deployments using cluster upgrade command would probably
>> need some improvement.
>>
>
> The cluster upgrade process continues to the 2nd host after the 1st host
> becomes Up. If 2nd host then fails to switch to maintenance, we stop the
> upgrade process to prevent breakage.
> Sahina, is gluster healing process status exposed in RESTAPI? If so, does
> it makes sense to wait for healing to be finished before trying to move
> next host to maintenance? Or any other ideas how to improve?
>

I need to cross-check this, if we expose the heal count in the gluster
bricks. Moving a host to maintenance does check if there are pending heal
entries or possibility of quorum loss. And this would prevent the
additional hosts to upgrade.
+Gobinda Das  +Sachidananda URS 


>>
>>
>>>
>>> On Tue, Aug 6, 2019 at 6:06 PM Robert O'Kane  wrote:
>>>
>>>> Hello,
>>>>
>>>> Often(?), updates to a hypervisor that also has (provides) a Gluster
>>>> brick takes the hypervisor offline (updates often require a reboot).
>>>>
>>>> This reboot then makes the brick "out of sync" and it has to be
>>>> resync'd.
>>>>
>>>> I find it a "feature" than another host that is also part of a gluster
>>>> domain can not be updated (rebooted) before all the bricks are updated
>>>> in order to guarantee there is not data loss. It is called Quorum, or?
>>>>
>>>> Always let the heal process end. Then the next update can start.
>>>> For me there is ALWAYS a healing time before Gluster is happy again.
>>>>
>>>> Cheers,
>>>>
>>>> Robert O'Kane
>>>>
>>>>
>>>> Am 06.08.2019 um 16:38 schrieb Shani Leviim:
>>>> > Hi Jayme,
>>>> > I can't recall such a healing time.
>>>> > Can you please retry and attach the engine & vdsm logs so we'll be
>>>> smarter?
>>>> >
>>>> > *Regards,
>>>> > *
>>>> > *Shani Leviim
>>>> > *
>>>> >
>>>> >
>>>> > On Tue, Aug 6, 2019 at 5:24 PM Jayme >>> > <mailto:jay...@gmail.com>> wrote:
>>>> >
>>>> > I've yet to have cluster upgrade finish updating my three host HCI
>>>> > cluster.  The most recent try was today moving from oVirt 4.3.3 to
>>>> > 4.3.5.5.  The first host updates normally, but when it moves on to
>>>> > the second host it fails to put it in maintenance and the cluster
>>>> > upgrade stops.
>>>> >
>>>> > I suspect this is due to that fact that after my hosts are updated
>>>> > it takes 10 minutes or more for all volumes to sync/heal.  I have
>>>> > 2Tb SSDs.
>>>> >
>>>> > Does the cluster upgrade process take heal time in to account
>>>> before
>>>> > attempting to place the next host in maintenance to upgrade it? Or
>>>> > is there something else that may be at fault here, or perhaps a
>>>> > reason why the heal process takes 10 minutes after reboot to
>>>> complete?
>>>> > ___
>>>> > Users mailing list -- users@ovirt.org <mailto:users@ovirt.org>
>>>> > To unsubscribe send an email to users-le...@ovirt.org
>>>> > <mailto: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/5XM3QB3364ZYIPAKY4KTTOSJZMCWHUPD/
>>>> >
>>>> >
>>>> > __

[ovirt-users] Re: oVirt 4.3.5 WARN no gluster network found in cluster

[Sahina Bose]

On Mon, Aug 26, 2019 at 10:57 PM  wrote:

> Hi,
> Yes I have glusternet shows the role  of "migration" and "gluster".
> Hosts show 1 network connected to management and the other to logical
> network "glusternet"
>

What does "ping host1.example.com" return? Does it return the IP address of
the network associated with glusternet?
The hostname in the brick - in your case "host1.example.com" from
host1.example.com:/gluster_bricks/engine/engine, should be resolvable to a
valid address from the engine host.


> Just not sure if I am interpreting right?
> thanks,
>
> ___
> 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/MFQE6XRVHA76PI47O253VHV4EK3M5QDQ/
>
___
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/6RJ6FGOPP4LIABP5NINSDHISLTVHXJVU/

[ovirt-users] Re: oVirt 4.3.5 glusterfs 6.3 performance tunning

[Sahina Bose]

+Krutika Dhananjay  +Sachidananda URS 


Adrian, can you provide more details on the performance issue you're seeing?
We do have some scripts to collect data to analyse. Perhaps you can run
this and provide us the details in a bug. The ansible scripts to do this is
still under review -
https://github.com/gluster/gluster-ansible-maintenance/pull/4
But would be great if you can provide us some feedback on this as well.

On Thu, Aug 22, 2019 at 7:50 AM  wrote:

> Hello,
> I have a hyperconverged setup using ovirt 4.3.5 and the "optimize for
> ovirt store" seems to fail on gluster volumes.
> I am seeing poor performance and trying to see how should I tune gluster
> to give better performance.
> Can you provide any suggestions on the following volume
> settings(parameters)?
>
> option Value
> -- -
> cluster.lookup-unhashedon
> cluster.lookup-optimizeon
> cluster.min-free-disk  10%
> cluster.min-free-inodes5%
> cluster.rebalance-statsoff
> cluster.subvols-per-directory  (null)
> cluster.readdir-optimize   off
> cluster.rsync-hash-regex   (null)
> cluster.extra-hash-regex   (null)
> cluster.dht-xattr-name trusted.glusterfs.dht
> cluster.randomize-hash-range-by-gfid   off
> cluster.rebal-throttle normal
> cluster.lock-migration off
> cluster.force-migrationoff
> cluster.local-volume-name  (null)
> cluster.weighted-rebalance on
> cluster.switch-pattern (null)
> cluster.entry-change-log   on
> cluster.read-subvolume (null)
> cluster.read-subvolume-index-1
> cluster.read-hash-mode  1
> cluster.background-self-heal-count  8
> cluster.metadata-self-heal off
> cluster.data-self-heal off
> cluster.entry-self-healoff
> cluster.self-heal-daemon   on
> cluster.heal-timeout600
> cluster.self-heal-window-size   1
> cluster.data-change-logon
> cluster.metadata-change-logon
> cluster.data-self-heal-algorithm   full
> cluster.eager-lock enable
> disperse.eager-lockon
> disperse.other-eager-lock  on
> disperse.eager-lock-timeout 1
> disperse.other-eager-lock-timeout   1
> cluster.quorum-typeauto
> cluster.quorum-count   (null)
> cluster.choose-local   off
> cluster.self-heal-readdir-size 1KB
> cluster.post-op-delay-secs  1
> cluster.ensure-durability  on
> cluster.consistent-metadatano
> cluster.heal-wait-queue-length  128
> cluster.favorite-child-policy  none
> cluster.full-lock  yes
> diagnostics.latency-measurementoff
> diagnostics.dump-fd-stats  off
> diagnostics.count-fop-hits off
> diagnostics.brick-log-levelINFO
> diagnostics.client-log-level   INFO
> diagnostics.brick-sys-log-levelCRITICAL
> diagnostics.client-sys-log-level   CRITICAL
> diagnostics.brick-logger   (null)
> diagnostics.client-logger  (null)
> diagnostics.brick-log-format   (null)
> diagnostics.client-log-format  (null)
> diagnostics.brick-log-buf-size  5
> diagnostics.client-log-buf-size 5
> diagnostics.brick-log-flush-timeout 120
> diagnostics.client-log-flush-timeout120
> diagnostics.stats-dump-interval 0
> diagnostics.fop-sample-interval 0
> diagnostics.stats-dump-format  json
> diagnostics.fop-sample-buf-size 65535
> diagnostics.stats-dnscache-ttl-sec  86400
> performance.cache-max-file-size 0
> performance.cache-min-file-size 0
> performance.cache-refresh-timeout   1
> performance.cache-priority
> performance.cache-size 32MB
> performance.io-thread-count 16
> performance.high-prio-threads   16
> performance.normal-prio-threads 16
> performance.low-prio-threads32
> performance.least-prio-threads  1
> performance.enable-least-priority  on
> performance.iot-watchdog-secs  (null)
> performance.iot-cleanup-disconnected-   reqsoff
> performance.iot-pass-through   false
> performance.io-cache-pass-through  false
> performance.cache-size 128MB
> performance.qr-cache-timeout1
> performance.cache-invalidation false
> performance.ctime-invalidation false
> performance.flush-behind   on
> performance.nfs.flush-behind   on
> performance.write-behind-window-size   1MB
> performance.resync-failed-syncs-after   -fsyncoff
> performance.nfs.write-behind-window-s   ize1MB
> performance.strict-o-directon
> performance.nfs.strict-o-directoff
> performance.strict-write-ordering  off
> performance.nfs.strict-write-ordering  off
> performance.write-behind-trickling-wr   iteson
> performance.aggregate-size 128KB
> performance.nfs.write-behind-tricklin   g-writeson
> performance.lazy-open  yes
> performance.read-after-openyes
> performance.open-behind-pass-through   false
> performance.read-ahead-page-count   4
> performance.read-ahead-pass-throughfalse
> performance.readdir-ahead-pass-throug   h  false
> 

[ovirt-users] Re: Procedure to replace out out of three hyperconverged nodes

[Sahina Bose]

On Mon, Aug 19, 2019 at 10:55 PM  wrote:

> On my silent Atom based three node Hyperconverged journey I hit upon a
> snag: Evidently they are too slow for Ansible.
>
> The Gluster storage part went all great and perfect on fresh oVirt node
> images that I had configured to leave an empty partition instead of the
> standard /dev/sdb, but the HostedEngine setup part would then fail without
> any log-visible error while the transient VM HostedEngineLocal was supposed
> to be launched and the Wizard would just show "deployment failed" and go
> ahead and delete the VM.
>
> I then moved the SSD to a more powerful Xeon-D 1541 CPU and after some
> fiddling with the network (I miss good old eth0!), this also failed the
> deployment, but also failed to delete the temporary VM image, because that
> actually turned out to be running: I could even connect to its console and
> investigate the logs for any clues as to what might have gone wrong
> (nothing visible): Evidently Ansible was running out of patience just a
> tiny bit too early.
>
> And then I kicked it into high-gear with an i7-7700K again using the same
> SSD with a working three node Gluster all in sync, which still took what
> felt like an hour to creep through every step, but got it done, primary
> node on i7, secondary nodes on Atoms, with full migration capabilities etc.
>
> I then had to do some fiddling, because the HostedEngine had configued the
> Cluster CPU architecture to Skylake-Spectre, but after that I migrated it
> to an Atom node and was now ready to move the primary to the intended Atom
> hardware target.
>
> But at that point the overlay network has already been configured and
> evidently it's tied to the device name of the 10Gbit NIC on the i7
> workstation and I haven't been able to make it work with the Atom. The
> Gluster runs fine, but the CPU node is reported "non-operational" and
> re-installation fails, because the ovirtmgmt network isn't properly
> configured.
>
> That specific issue may be seem way out of what oVirt should support, yet
> a HA-embedded edge platform may very well see nodes having to be replaced
> or renewed with as little interruption or downtime as possible, which is
> why I am asking the larger question:
>
> How can you replace a) a failed "burned" node or b) upgrade nodes while
> maintaining fault tolerance?
>

a) You could add a new node to the cluster, replace bricks on the failed
node with ones on new node and remove the failed node.

b) Cluster supports rolling upgrade. So nodes are updated one at a time,
ensuring there's always 2 replicas of gluster bricks online so there's no
data unavailability


> The distinction in b) would be that it's a planned maneuver during normal
> operations without downtime.
>
> I'd want to do it pretty much like I have been playing with compute nodes,
> creating new ones, pushing VMs on them, pushing them out to other hosts,
> removing and replacing them seamlessly... Except that the Gluster nodes are
> special and much harder to replace, than a pure Gluster storage brick...
> from what I see
>
> I welcome any help
> - for fixing the network config in my limiping Atom 1:3 cluster
> - eliminating the need to fiddle with an i7 because of Ansible timing
> - ensuring long-term operability of a software defined datacenter with
> changing hardware
> ___
> 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/ICV5HRJFHWENZNBCQCFNIL7NDD7YYD33/
>
___
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/654YRP3UZVYOLEBQNK7MAMVLNFEPHOB4/

[ovirt-users] Re: gluster

[Sahina Bose]

On Mon, Sep 9, 2019 at 7:22 PM Kaustav Majumder  wrote:

> Well almost. Create a new cluster and  (Check) Enable Gluster Service .
> Upon adding new hosts to this cluster (via ui) gluster will be
> automatically configured on them.
>
>
> On Mon, Sep 9, 2019 at 6:56 PM  wrote:
>
>> So doing this seems to assume that gluster is already configured on the
>> hosts.  What if it’s not configured yet, can I use the web config to do
>> this or it has to be done separate of ovirt ?
>>
>
You can reinstall the hosts one at a time as well to ensure the packages
are all configured correctly


>>
>> Thanks again
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* Kaustav Majumder 
>> *Sent:* September 9, 2019 8:08 AM
>> *To:* mailing-ov...@qic.ca
>> *Cc:* users@ovirt.org
>> *Subject:* [ovirt-users] Re: gluster
>>
>>
>>
>> Hi,
>> You can try this.
>> Engine-UI -> Compute -> Clusters -> New -> (Check) Enable Gluster Service
>> -> (Check) Import existing gluster configuration -> Enter details of one
>> gluster host.
>> Engine will add all host in peer with gluster under the new Cluster.
>>
>>
>>
>> On Mon, Sep 9, 2019 at 5:31 PM  wrote:
>>
>> Hi,
>>
>>
>>
>> I see options to deploy ovirt with gluster during the initial rollout,
>> however I can’t seem to find information as to how I can add it following a
>> non gluster initial setup:
>>
>>
>>
>> GlusterFS Version:
>>
>> [N/A]
>>
>>
>>
>> Thanks
>>
>>
>>
>> Simon
>>
>> ___
>> 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/KNRQN76L3XGNLYXYEIRYVDCJGU5BBGL5/
>>
>>
>>
>>
>> --
>>
>> *Thanks,*
>>
>> *Kaustav Majumder*
>>
>
>
> --
>
> Thanks,
>
> Kaustav Majumder
> ___
> 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/GR4XHNGO57K57N6JKB4XE5P3HX7RRMY5/
>
___
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/SG2JCDQDTEFCHJ5ACUXFQBBCE5MV4REL/

[ovirt-users] Re: LiveStoreageMigration failed

[Sahina Bose]

On Thu, Jul 18, 2019 at 9:02 PM Strahil Nikolov 
wrote:

>  According to this one (GlusterFS Storage Domain — oVirt) libgfapi support
> is disabled by default due to incompatibility with Live Storage Migration.
> VM can not be migrated to the GlusterFS storage domain.
> I guess someone from the devs have to confirm that this is still valid.
>

Yes, this is waiting for libvirt fix -
https://bugzilla.redhat.com/show_bug.cgi?id=760547

Best Regards,Strahil Nikolov
>
> В четвъртък, 18 юли 2019 г., 11:16:26 ч. Гринуич+3, Christoph Köhler <
> koeh...@luis.uni-hannover.de> написа:
>
>  Hello,
>
> I try to migrate a disk of a running vm from gluster 3.12.15 to gluster
> 3.12.15 but it fails. libGfApi set to true by engine-config.
>
> ° taking a snapshot first, is working. Then at engine-log:
>
> 2019-07-18 09:29:13,932+02 ERROR
> [org.ovirt.engine.core.vdsbroker.vdsbroker.VmReplicateDiskStartVDSCommand]
> (EE-ManagedThreadFactory-engineScheduled-Thread-84)
> [c957e011-37e0-43aa-abe7-9bb633c38c5f] Failed in
> 'VmReplicateDiskStartVDS' method
>
> 2019-07-18 09:29:13,936+02 ERROR
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (EE-ManagedThreadFactory-engineScheduled-Thread-84)
> [c957e011-37e0-43aa-abe7-9bb633c38c5f] EVENT_ID:
> VDS_BROKER_COMMAND_FAILURE(10,802), VDSM ovvirt07 command
> VmReplicateDiskStartVDS failed: Drive replication error
>
> 2019-07-18 09:29:13,936+02 INFO
> [org.ovirt.engine.core.vdsbroker.vdsbroker.VmReplicateDiskStartVDSCommand]
> (EE-ManagedThreadFactory-engineScheduled-Thread-84)
> [c957e011-37e0-43aa-abe7-9bb633c38c5f] Command
> 'org.ovirt.engine.core.vdsbroker.vdsbroker.VmReplicateDiskStartVDSCommand'
> return value 'StatusOnlyReturn [status=Status [code=55, message=Drive
> replication error]]'
>
> 2019-07-18 09:29:13,936+02 INFO
> [org.ovirt.engine.core.vdsbroker.vdsbroker.VmReplicateDiskStartVDSCommand]
> (EE-ManagedThreadFactory-engineScheduled-Thread-84)
> [c957e011-37e0-43aa-abe7-9bb633c38c5f] HostName = ovvirt07
>
> 2019-07-18 09:29:13,937+02 ERROR
> [org.ovirt.engine.core.vdsbroker.vdsbroker.VmReplicateDiskStartVDSCommand]
> (EE-ManagedThreadFactory-engineScheduled-Thread-84)
> [c957e011-37e0-43aa-abe7-9bb633c38c5f] Command
> 'VmReplicateDiskStartVDSCommand(HostName = ovvirt07,
> VmReplicateDiskParameters:{hostId='3a7bf85c-e92d-4559-908e-5eed2f5608d4',
> vmId='3b79d0c0-47e9-47c3-8511-980a8cfe147c',
> storagePoolId='0001-0001-0001-0001-0311',
> srcStorageDomainId='e54d835a-d8a5-44ae-8e17-fcba1c54e46f',
> targetStorageDomainId='4dabb6d6-4be5-458c-811d-6d5e87699640',
> imageGroupId='d2964ff9-10f7-4b92-8327-d68f3cfd5b50',
> imageId='62656632-8984-4b7e-8be1-fd2547ca0f98'})' execution failed:
> VDSGenericException: VDSErrorException: Failed to
> VmReplicateDiskStartVDS, error = Drive replication error, code = 55
>
> 2019-07-18 09:29:13,937+02 INFO
> [org.ovirt.engine.core.vdsbroker.vdsbroker.VmReplicateDiskStartVDSCommand]
> (EE-ManagedThreadFactory-engineScheduled-Thread-84)
> [c957e011-37e0-43aa-abe7-9bb633c38c5f] FINISH,
> VmReplicateDiskStartVDSCommand, return: , log id: 5b2afb0b
>
> 2019-07-18 09:29:13,937+02 ERROR
> [org.ovirt.engine.core.bll.storage.lsm.LiveMigrateDiskCommand]
> (EE-ManagedThreadFactory-engineScheduled-Thread-84)
> [c957e011-37e0-43aa-abe7-9bb633c38c5f] Failed VmReplicateDiskStart (Disk
> 'd2964ff9-10f7-4b92-8327-d68f3cfd5b50' , VM
> '3b79d0c0-47e9-47c3-8511-980a8cfe147c')
>
> 2019-07-18 09:29:13,938+02 ERROR
> [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback]
> (EE-ManagedThreadFactory-engineScheduled-Thread-84)
> [c957e011-37e0-43aa-abe7-9bb633c38c5f] Command 'LiveMigrateDisk' id:
> '8174c74c-8ab0-49fa-abfc-44d8b7c691e0' with children
> [03672b60-443b-47ba-834c-ac306d7129d0,
> 562522fc-6691-47fe-93bf-ef2c45e85676] failed when attempting to perform
> the next operation, marking as 'ACTIVE'
>
> 2019-07-18 09:29:13,938+02 ERROR
> [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback]
> (EE-ManagedThreadFactory-engineScheduled-Thread-84)
> [c957e011-37e0-43aa-abe7-9bb633c38c5f] EngineException: Drive
> replication error (Failed with error replicaErr and code 55):
> org.ovirt.engine.core.common.errors.EngineException: EngineException:
> Drive replication error (Failed with error replicaErr and code 55)
> at
> org.ovirt.engine.core.bll.storage.lsm.LiveMigrateDiskCommand.replicateDiskStart(LiveMigrateDiskCommand.java:526)
>
> [bll.jar:]
> at
> org.ovirt.engine.core.bll.storage.lsm.LiveMigrateDiskCommand.performNextOperation(LiveMigrateDiskCommand.java:233)
>
> [bll.jar:]
> at
> org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback.childCommandsExecutionEnded(SerialChildCommandsExecutionCallback.java:32)
>
> [bll.jar:]
> at
> org.ovirt.engine.core.bll.ChildCommandsCallbackBase.doPolling(ChildCommandsCallbackBase.java:77)
>
> [bll.jar:]
> at
> 

[ovirt-users] Re: hosted engine, Hyperconverged recovery

[Sahina Bose]

On Wed, Jul 17, 2019 at 7:50 PM Doron Fediuck  wrote:

> Adding relevant folks.
> Sahina?
>
> On Thu, 11 Jul 2019 at 00:24, William Kwan  wrote:
>
>> Hi,
>>
>> I need some direction to make sure we won't make more mistake in
>> recovering a 3-node self hosted engine with Gluster.
>>
>> Someone carelessly, very, wiped out the first few MB of the LVM PV on one
>> node.  We changed the quorum and brought up the Gluster and oVirt.   We ran
>> vgcfgrestore on the 'bad node' and we can run pvscan, vgscan and lvscan to
>> see the LV's.
>>
>
If you have 2/3 bricks online - storage would have been available. Can you
elaborate why you needed to change qourum


>>
>> What should I do next to prevent more damage or corrupt the glusterfs on
>> the other two nodes?
>>
>> Will this work?
>>   mkfs the LV's
>>   bring up gluster
>>   run gluster sync ?
>>
>
On the node where the bricks were wiped out,you need to
1. rebuild the bricks (i.e recreate the LVs and mount at the same brick
path as before)
2. Restart glusterd (if not started)
3. Reset the brick - from Volume -> Bricks subtab, select the relevant brick


>>
>> Thanks
>> Will
>>
>> ___
>> 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/P6ADINQ2UTUQTLAOGRFPX64B4BELNPNU/
>>
>
___
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/QOGNGPW73DAGGSEBHPGHVLGZMUIRWGLW/

[ovirt-users] Re: [Gluster-users] Update 4.2.8 --> 4.3.5

[Sahina Bose]

On Thu, Jul 11, 2019 at 11:15 PM Strahil  wrote:

> I'm addding gluster-users as I'm not sure if you can go gluster v3 -> v6
> directly.
>
> Theoretically speaking ,  there  should be no problem - but I don't know
> if you will observe any issues.
>
> @Gluster-users,
>
> Can someone share their thoughts about v3 to v6 migration  ?
>
> Best Regards,
> Strahil Nikolov
> On Jul 11, 2019 14:05, Christoph Köhler wrote: > > Hello! > > We have a
> 4.2.8 environment with some managed gluster-volumes as storage > domains
> and we want to go up to 4.3.5. > > How is that procedure especially with
> the gluster nodes in ovirt that > are running 3.12.15? My fear is on the
> jump to gluster 6. Do the cluster > work if the first node (of three) is
> upgraded? And what about the > sequence - first the hypervisors or first
> gluster nodes?


Since this is not a hyperconverged deployment - the gluster servers needs
to be upgraded first , and then the client i.e hypervisors.

> > Is there anyone who had done this? > > Greetings! > Christoph Köhler >
> ___ > 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/VWFS6YUKA77VP5DWGV7SBYGZREZDJMO7/
> ___
> Gluster-users mailing list
> gluster-us...@gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-users
___
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/Q7BJOQXFTDFZNMSKKOSASIOZOZOCHJW6/

[ovirt-users] Re: oVirt hyerconverged more than 12 node

[Sahina Bose]

On Mon, Jul 1, 2019 at 2:06 AM Strahil Nikolov 
wrote:

> I suspect this limitation is due to support obligations that come with a
> subscription from Red Hat.
> In oVirt , you don't have such agreement and thus no support even with a
> 3-node cluster.
>
>
This is correct.

Gluster scales up and out quite well and you will be able to deploy even
> larger clusters without issues.
> Of course , you can split your nodes into several smaller clusters - if
> you feel the need for.
>
> Best Regards,
> Strahil Nikolov
>
> В неделя, 30 юни 2019 г., 6:53:28 ч. Гринуич-4, wodel youchi <
> wodel.you...@gmail.com> написа:
>
>
> Hi,
>
> Here : 3.8 scalling
>
>
> https://access.redhat.com/documentation/en-us/red_hat_hyperconverged_infrastructure_for_virtualization/1.6/html/deploying_red_hat_hyperconverged_infrastructure_for_virtualization/rhhi-requirements#rhhi-req-scaling
>
> Regards.
>
> Le mer. 26 juin 2019 à 23:10, wodel youchi  a
> écrit :
>
> Hi,
>
> I am referring to Redhat documentation about Hyperconverged.
>
> Regards.
>
> Le mer. 26 juin 2019 à 20:51, Strahil  a écrit :
>
> Where did you read that?
>
> It seems I can't find such statement in the web.
>
> Best Regards
> Strahil Nikolov
> On Jun 26, 2019 11:52, wodel youchi  wrote:
>
> Hi,
>
> Anyone!!!???
>
> Regards.
>
> Le dim. 23 juin 2019 à 17:06, wodel youchi  a
> écrit :
>
> Hi,
>
> Could someone explain the 12 nodes limitation when installing oVirt
> Hyperconverged?
>
> Our client has 16 nodes, can we use them on a hyperconverged installation?
> for example creating two clusters, one with 9 nodes and the second with 6
> nodes.
>
> Regards.
>
> ___
> 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/BTVM2MHJB5H2P5VCQJIJV6QQRQRSJBIS/
>
___
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/ZLO5WC3OBH62YNWX2HVDYX4TOONCI3VY/

[ovirt-users] Re: Ovirt Hyperconverged Cluster

[Sahina Bose]

Did you manage to get past this error?

On Sat, Jun 29, 2019 at 3:32 AM Edward Berger  wrote:

> Maybe there is something already on the disk from before?
> gluster setup wants it completely blank, no detectable filesystem, no
> raid, etc.
> see what is there with fdisk.-l  see what PVs exist with pvs.
> Manually wipe, reboot and try again?
>
> On Fri, Jun 28, 2019 at 5:37 AM  wrote:
>
>> I have added the lvm global filter and  I have configured the
>> multipath.conf but gdploy stay blocked on the PV creation on sda.
>> I don't have any log in /var/log/ovirt-hosted-engine-setup
>> ___
>> 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/SHZOZFQXM6G6U3ZTMQ4EVR4YF3JI6XWK/
>>
> ___
> 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/CR3DS2MIQWSI7XRKWFUABR44IFCVSOS3/
>
___
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/WK4UDG5PVIWKIKALIDZF4LJFVBHMP4VF/

[ovirt-users] Re: HE deployment failing

[Sahina Bose]

On Mon, Jul 8, 2019 at 11:40 AM Parth Dhanjal  wrote:

> Hey!
>
> I used cockpit to deploy gluster.
> And the problem seems to be with
> 10.xx.xx.xx9:/engine 50G  3.6G   47G   8%
> /rhev/data-center/mnt/glusterSD/10.70.41.139:_engine
>
> Engine volume has 500G available
> Filesystem Size  Used Avail Use%
> Mounted on
> /dev/mapper/gluster_vg_sdb1-gluster_lv_engine  500G   37M  500G   1%
> /gluster_bricks/engine
>

Check that you have 500G on all the bricks of the volume if you're using
replica 3. It takes the minimum of the 3 bricks.


> On Fri, Jul 5, 2019 at 8:05 PM Strahil Nikolov 
> wrote:
>
>> Parth,
>>
>> did you use cockpit to deploy the gluster volume ?
>> it's interesting why the cockpit allowed the engine's volume to be so
>> small ...
>>
>> Best Regards,
>> Strahil Nikolov
>>
>> В петък, 5 юли 2019 г., 10:17:11 ч. Гринуич-4, Simone Tiraboschi <
>> stira...@redhat.com> написа:
>>
>>
>>
>>
>> On Fri, Jul 5, 2019 at 4:12 PM Parth Dhanjal  wrote:
>>
>> Hey!
>>
>> I'm trying to deploy a 3 node cluster with gluster storage.
>> After the gluster deployment is completed successfully, the creation of
>> storage domain fails during HE deployment giving the error:
>>
>> [ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg":
>> "Error: the target storage domain contains only 46.0GiB of available space
>> while a minimum of 61.0GiB is required If you wish to use the current
>> target storage domain by extending it, make sure it contains nothing before
>> adding it."}
>> I have tried to increase the disk size(provided in storage tab) to 90GiB.
>> But the deployment still fails. A 50GiB storage domain is created by
>> default even if some other size is provided.
>>
>>
>> The issue is on the size of the gluster volume not on the size of the
>> hosted-engine VM disk.
>> Please try extending the gluater volume.
>>
>>
>>
>>
>> Has anyone faced a similar issue?
>>
>> Regards
>> Parth Dhanjal
>> ___
>> 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/W2CM74EU6KPPJ2NL3HXBTYPHDO7BMZB6/
>>
>>
>>
>> --
>>
>> Simone Tiraboschi
>>
>> He / Him / His
>>
>> Principal Software Engineer
>>
>> Red Hat 
>>
>> stira...@redhat.com
>> @redhatjobs    redhatjobs
>>  @redhatjobs
>> 
>>
>> 
>> 
>> ___
>> 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/2MFPZNCLNLXOT3YNB4S5XKP546GDHBHY/
>>
>> ___
> 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/N6H7IASARUJGOY3IPKCS7ZWHJMGHTYNU/
>
___
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/TKMB3TP2K35BWIXI6GPDZRS56ER64HR5/

[ovirt-users] Re: Issues when Creating a Gluster Brick with Cache

[Sahina Bose]

On Mon, Jun 24, 2019 at 11:39 AM Robert Crawford <
robert.crawford4.14...@gmail.com> wrote:

> Hey Everyone,
>
> When in the server manager and creating a brick from the storage device
> the brick will fail whenever i attach a cache device to it.
>
> I'm not really sure why? It just says unknown.
>

The brick creation flow uses ansible roles to create the bricks and the
logs are at /var/log/ovirt-engine/brick-setup/
Can you take a look at ansible logs?

___
> 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/2XEP3P7SMUN2CWWNNVWC2ZDQVGFLMHGS/
>
___
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/4SQ7IFKMNR43T5CCRE2POLXV6OG4KATJ/

[ovirt-users] Re: Gluster 3.12 vs Engine 4.3.5

[Sahina Bose]

On Thu, Jun 20, 2019 at 11:17 AM Николаев Алексей <
alexeynikolaev.p...@yandex.ru> wrote:

> Hi community!
>
> Is it possible to continue using independent gluster 3.12 as a data domain
> with engine 4.3.5?
>

Yes.

___
> 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/VXDVKO4V7JNO2NRJ66JGC54Z6HM6GGDT/
>
___
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/NXOXXNPGQQRSCERRESSJZ73NH7HBLYNK/

[ovirt-users] Re: Feature Request: oVirt to warn when VDO is getting full

[Sahina Bose]

On Tue, Jun 4, 2019 at 3:26 PM Strahil  wrote:

> Hello All,
>
> I would like to ask how many of you use VDO  before asking the oVirt Devs
> to assess a feature in oVirt for monitoring the size of the VDOs on
> hyperconverged systems.
>
> I think such warning, will save a lot of headaches, but it will not be
> usefull if most of the community is not using VDO at all.
>

We do have a feature that monitors the space usage of VDO volumes. If this
is not working as expected, can you raise a bug.
Is the storage domain linked to the gluster volume using the VDO devices?

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/R2VAHSMRPJQA5P6O5IAX5UZFRXRCIJWO/
>
___
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/X6ZSQU3NTNPQWBROGB77QHQNU5ELIN5H/

[ovirt-users] Re: oVirt node loses gluster volume UUID after reboot, goes to emergency mode every time I reboot.

[Sahina Bose]

+Sachidananda URS 

On Wed, May 22, 2019 at 1:14 AM  wrote:

> I'm sorry, i'm still working on my linux knowledge, here is the output of
> my blkid on one of the servers:
>
> /dev/nvme0n1: PTTYPE="dos"
> /dev/nvme1n1: PTTYPE="dos"
> /dev/mapper/eui.6479a71892882020: PTTYPE="dos"
> /dev/mapper/eui.0025385881b40f60: PTTYPE="dos"
> /dev/mapper/eui.6479a71892882020p1:
> UUID="pfJiP3-HCgP-gCyQ-UIzT-akGk-vRpV-aySGZ2" TYPE="LVM2_member"
> /dev/mapper/eui.0025385881b40f60p1:
> UUID="Q0fyzN-9q0s-WDLe-r0IA-MFY0-tose-yzZeu2" TYPE="LVM2_member"
>
> /dev/mapper/Samsung_SSD_850_EVO_1TB_S21CNXAG615134H: PTTYPE="dos"
> /dev/mapper/Samsung_SSD_850_EVO_1TB_S21CNXAG615134H1:
> UUID="lQrtPt-nx0u-P6Or-f2YW-sN2o-jK9I-gp7P2m" TYPE="LVM2_member"
> /dev/mapper/vg_gluster_ssd-lv_gluster_ssd:
> UUID="890feffe-c11b-4c01-b839-a5906ab39ecb" TYPE="vdo"
> /dev/mapper/vg_gluster_nvme1-lv_gluster_nvme1:
> UUID="7049fd2a-788d-44cb-9dc5-7b4c0ee309fb" TYPE="vdo"
> /dev/mapper/vg_gluster_nvme2-lv_gluster_nvme2:
> UUID="2c541b70-32c5-496e-863f-ea68b50e7671" TYPE="vdo"
> /dev/mapper/vdo_gluster_ssd: UUID="e59a68d5-2b73-487a-ac5e-409e11402ab5"
> TYPE="xfs"
> /dev/mapper/vdo_gluster_nvme1: UUID="d5f53f17-bca1-4cb9-86d5-34a468c062e7"
> TYPE="xfs"
> /dev/mapper/vdo_gluster_nvme2: UUID="40a41b5f-be87-4994-b6ea-793cdfc076a4"
> TYPE="xfs"
>
> #2
> /dev/nvme0n1: PTTYPE="dos"
> /dev/nvme1n1: PTTYPE="dos"
> /dev/mapper/eui.6479a71892882020: PTTYPE="dos"
> /dev/mapper/eui.6479a71892882020p1:
> UUID="GiBSqT-JJ3r-Tn3X-lzCr-zW3D-F3IE-OpE4Ga" TYPE="LVM2_member"
> /dev/mapper/nvme.126f-324831323230303337383138-4144415441205358383030304e50-0001:
> PTTYPE="dos"
> /dev/sda: PTTYPE="gpt"
> /dev/mapper/nvme.126f-324831323230303337383138-4144415441205358383030304e50-0001p1:
> UUID="JBhj79-Uk0E-DdLE-Ibof-VwBq-T5nZ-F8d57O" TYPE="LVM2_member"
> /dev/sdb: PTTYPE="dos"
> /dev/mapper/Samsung_SSD_860_EVO_1TB_S3Z8NB0K843638B: PTTYPE="dos"
> /dev/mapper/Samsung_SSD_860_EVO_1TB_S3Z8NB0K843638B1:
> UUID="6yp5YM-D1be-M27p-AEF5-w1pv-uXNF-2vkiJZ" TYPE="LVM2_member"
> /dev/mapper/vg_gluster_ssd-lv_gluster_ssd:
> UUID="9643695c-0ace-4cba-a42c-3f337a7d5133" TYPE="vdo"
> /dev/mapper/vg_gluster_nvme2-lv_gluster_nvme2:
> UUID="79f5bacc-cbe7-4b67-be05-414f68818f41" TYPE="vdo"
> /dev/mapper/vg_gluster_nvme1-lv_gluster_nvme1:
> UUID="2438a550-5fb4-48f4-a5ef-5cff5e7d5ba8" TYPE="vdo"
> /dev/mapper/vdo_gluster_ssd: UUID="5bb67f61-9d14-4d0b-8aa4-ae3905276797"
> TYPE="xfs"
> /dev/mapper/vdo_gluster_nvme1: UUID="732f939c-f133-4e48-8dc8-c9d21dbc0853"
> TYPE="xfs"
> /dev/mapper/vdo_gluster_nvme2: UUID="f55082ca-1269-4477-9bf8-7190f1add9ef"
> TYPE="xfs"
>
> #3
> /dev/nvme1n1: UUID="8f1dc44e-f35f-438a-9abc-54757fd7ef32" TYPE="vdo"
> /dev/nvme0n1: PTTYPE="dos"
> /dev/mapper/nvme.c0a9-313931304531454644323630-4354353030503153534438-0001:
> UUID="8f1dc44e-f35f-438a-9abc-54757fd7ef32" TYPE="vdo"
> /dev/mapper/eui.6479a71892882020: PTTYPE="dos"
> /dev/mapper/eui.6479a71892882020p1:
> UUID="FwBRJJ-ofHI-1kHq-uEf1-H3Fn-SQcw-qWYvmL" TYPE="LVM2_member"
> /dev/sda: PTTYPE="gpt"
> /dev/mapper/Samsung_SSD_850_EVO_1TB_S2RENX0J302798A: PTTYPE="gpt"
> /dev/mapper/Samsung_SSD_850_EVO_1TB_S2RENX0J302798A1:
> UUID="weCmOq-VZ1a-Itf5-SOIS-AYLp-Ud5N-S1H2bR" TYPE="LVM2_member"
> PARTUUID="920ef5fd-e525-4cf0-99d5-3951d3013c19"
> /dev/mapper/vg_gluster_ssd-lv_gluster_ssd:
> UUID="fbaffbde-74f0-4e4a-9564-64ca84398cde" TYPE="vdo"
> /dev/mapper/vg_gluster_nvme2-lv_gluster_nvme2:
> UUID="ae0bd2ad-7da9-485b-824a-72038571c5ba" TYPE="vdo"
> /dev/mapper/vdo_gluster_ssd: UUID="f0f56784-bc71-46c7-8bfe-6b71327c87c9"
> TYPE="xfs"
> /dev/mapper/vdo_gluster_nvme1: UUID="0ddc1180-f228-4209-82f1-1607a46aed1f"
> TYPE="xfs"
> /dev/mapper/vdo_gluster_nvme2: UUID="bcb7144a-6ce0-4b3f-9537-f465c46d4843"
> TYPE="xfs"
>
> I don't have any errors on mount until I reboot, and once I reboot it
> takes ~6hrs for everything to work 100% since I have to delete the mount
> commands out of stab for the 3 gluster volumes and reboot.  I'da rather
> wait until the next update to do that.
>
> I don't have a variable file or playbook since I made the storage
> manually, I stopped using the playbook since at that point I couldn't
> enable RDMA or over-provision the disks correctly unless I made them
> manually.  But as I said, this is something in 4.3.3 as if I go back to
> 4.3.2 I can reboot no problem.
> ___
> 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/EDGJVIYPMHN5HYARBNCN36NRSTKMSLLW/
>
___
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: 

[ovirt-users] Re: Scale out ovirt 4.3 (from 3 to 6 or 9 nodes) with hyperconverged setup and Gluster

[Sahina Bose]

On Tue, May 21, 2019 at 2:36 AM Strahil Nikolov 
wrote:

> Hey Sahina,
>
> it seems that almost all of my devices are locked - just like Fred's.
> What exactly does it mean - I don't have any issues with my bricks/storage
> domains.
>


If the devices show up as locked - it means the disk cannot be used to
create a brick. This is when the disk either already has a filesystem or is
in use.
But if the device is a clean device and it still shows up as locked - this
could be a bug with how python-blivet/ vdsm reads this

The code to check is implemented as
_canCreateBrick(device):
if not device or device.kids > 0 or device.format.type or \
   hasattr(device.format, 'mountpoint') or \
   device.type in ['cdrom', 'lvmvg', 'lvmthinpool', 'lvmlv',
'lvmthinlv']:
return False
return True


> Best Regards,
> Strahil Nikolov
>
> В понеделник, 20 май 2019 г., 14:56:11 ч. Гринуич+3, Sahina Bose <
> sab...@redhat.com> написа:
>
>
> To scale existing volumes - you need to add bricks and run rebalance on
> the gluster volume so that data is correctly redistributed as Alex
> mentioned.
> We do support expanding existing volumes as the bug
> https://bugzilla.redhat.com/show_bug.cgi?id=1471031 has been fixed
>
> As to procedure to expand volumes:
> 1. Create bricks from UI - select Host -> Storage Device -> Storage
> device. Click on "Create Brick"
> If the device is shown as locked, make sure there's no signature on
> device.  If multipath entries have been created for local devices, you can
> blacklist those devices in multipath.conf and restart multipath.
> (If you see device as locked even after you do this -please report back).
> 2. Expand volume using Volume -> Bricks -> Add Bricks, and select the 3
> bricks created in previous step
> 3. Run Rebalance on the volume. Volume -> Rebalance.
>
>
> On Thu, May 16, 2019 at 2:48 PM Fred Rolland  wrote:
>
> Sahina,
> Can someone from your team review the steps done by Adrian?
> Thanks,
> Freddy
>
> On Thu, Apr 25, 2019 at 5:14 PM Adrian Quintero 
> wrote:
>
> Ok, I will remove the extra 3 hosts, rebuild them from scratch and
> re-attach them to clear any possible issues and try out the suggestions
> provided.
>
> thank you!
>
> On Thu, Apr 25, 2019 at 9:22 AM Strahil Nikolov 
> wrote:
>
> I have the same locks , despite I have blacklisted all local disks:
>
> # VDSM PRIVATE
> blacklist {
> devnode "*"
> wwid Crucial_CT256MX100SSD1_14390D52DCF5
> wwid WDC_WD5000AZRX-00A8LB0_WD-WCC1U0056126
> wwid WDC_WD5003ABYX-01WERA0_WD-WMAYP2335378
> wwid
> nvme.1cc1-324a31313230303131353936-414441544120535838323030504e50-0001
> }
>
> If you have multipath reconfigured, do not forget to rebuild the initramfs
> (dracut -f). It's a linux issue , and not oVirt one.
>
> In your case you had something like this:
>/dev/VG/LV
>   /dev/disk/by-id/pvuuid
>  /dev/mapper/multipath-uuid
> /dev/sdb
>
> Linux will not allow you to work with /dev/sdb , when multipath is locking
> the block device.
>
> Best Regards,
> Strahil Nikolov
>
> В четвъртък, 25 април 2019 г., 8:30:16 ч. Гринуич-4, Adrian Quintero <
> adrianquint...@gmail.com> написа:
>
>
> under Compute, hosts, select the host that has the locks on /dev/sdb,
> /dev/sdc, etc.., select storage devices and in here is where you see a
> small column with a bunch of lock images showing for each row.
>
>
> However as a work around, on the newly added hosts (3 total), I had to
> manually modify /etc/multipath.conf and add the following at the end as
> this is what I noticed from the original 3 node setup.
>
> -
> # VDSM REVISION 1.3
> # VDSM PRIVATE
> # BEGIN Added by gluster_hci role
>
> blacklist {
> devnode "*"
> }
> # END Added by gluster_hci role
> --
> After this I restarted multipath and the lock went away and was able to
> configure the new bricks thru the UI, however my concern is what will
> happen if I reboot the server will the disks be read the same way by the OS?
>
> Also now able to expand the gluster with a new replicate 3 volume if
> needed using http://host4.mydomain.com:9090.
>
>
> thanks again
>
> On Thu, Apr 25, 2019 at 8:00 AM Strahil Nikolov 
> wrote:
>
> In which menu do you see it this way ?
>
> Best Regards,
> Strahil Nikolov
>
> В сряда, 24 април 2019 г., 8:55:22 ч. Гринуич-4, Adrian Quintero <
> adrianquint...@gmail.com> написа:
>
>
> Strahil,
> this is the issue I am seeing now
>

[ovirt-users] Re: Scale out ovirt 4.3 (from 3 to 6 or 9 nodes) with hyperconverged setup and Gluster

[Sahina Bose]

On Mon, May 20, 2019 at 9:55 PM Adrian Quintero 
wrote:

> Sahina,
> Yesterday I started with a fresh install, I completely wiped clean all the
> disks, recreated the arrays from within my controller of our DL380 Gen 9's.
>
> OS: RAID 1 (2x600GB HDDs): /dev/sda// Using ovirt node 4.3.3.1 iso.
> engine and VMSTORE1: JBOD (1x3TB HDD):/dev/sdb
> DATA1: JBOD (1x3TB HDD): /dev/sdc
> DATA2: JBOD (1x3TB HDD): /dev/sdd
> Caching disk: JOBD (1x440GB SDD): /dev/sde
>
> *After the OS install on the first 3 servers and setting up ssh keys,  I
> started the Hyperconverged deploy process:*
> 1.-Logged int to the first server http://host1.example.com:9090
> 2.-Selected Hyperconverged, clicked on "Run Gluster Wizard"
> 3.-Followed the wizard steps (Hosts, FQDNs, Packages, Volumes, Bricks,
> Review)
> *Hosts/FQDNs:*
> host1.example.com
> host2.example.com
> host3.example.com
> *Packages:*
> *Volumes:*
> engine:replicate:/gluster_bricks/engine/engine
> vmstore1:replicate:/gluster_bricks/vmstore1/vmstore1
> data1:replicate:/gluster_bricks/data1/data1
> data2:replicate:/gluster_bricks/data2/data2
> *Bricks:*
> engine:/dev/sdb:100GB:/gluster_bricks/engine
> vmstore1:/dev/sdb:2600GB:/gluster_bricks/vmstrore1
> data1:/dev/sdc:2700GB:/gluster_bricks/data1
> data2:/dev/sdd:2700GB:/gluster_bricks/data2
> LV Cache:
> /dev/sde:400GB:writethrough
> 4.-After I hit deploy on the last step of the "Wizard" that is when I get
> the disk filter error.
> TASK [gluster.infra/roles/backend_setup : Create volume groups]
> 
> failed: [vmm10.virt.iad3p] (item={u'vgname': u'gluster_vg_sdb', u'pvname':
> u'/dev/sdb'}) => {"changed": false, "err": "  Device /dev/sdb excluded by a
> filter.\n", "item": {"pvname": "/dev/sdb", "vgname": "gluster_vg_sdb"},
> "msg": "Creating physical volume '/dev/sdb' failed", "rc": 5}
> failed: [vmm12.virt.iad3p] (item={u'vgname': u'gluster_vg_sdb', u'pvname':
> u'/dev/sdb'}) => {"changed": false, "err": "  Device /dev/sdb excluded by a
> filter.\n", "item": {"pvname": "/dev/sdb", "vgname": "gluster_vg_sdb"},
> "msg": "Creating physical volume '/dev/sdb' failed", "rc": 5}
> failed: [vmm11.virt.iad3p] (item={u'vgname': u'gluster_vg_sdb', u'pvname':
> u'/dev/sdb'}) => {"changed": false, "err": "  Device /dev/sdb excluded by a
> filter.\n", "item": {"pvname": "/dev/sdb", "vgname": "gluster_vg_sdb"},
> "msg": "Creating physical volume '/dev/sdb' failed", "rc": 5}
> failed: [vmm12.virt.iad3p] (item={u'vgname': u'gluster_vg_sdc', u'pvname':
> u'/dev/sdc'}) => {"changed": false, "err": "  Device /dev/sdc excluded by a
> filter.\n", "item": {"pvname": "/dev/sdc", "vgname": "gluster_vg_sdc"},
> "msg": "Creating physical volume '/dev/sdc' failed", "rc": 5}
> failed: [vmm10.virt.iad3p] (item={u'vgname': u'gluster_vg_sdc', u'pvname':
> u'/dev/sdc'}) => {"changed": false, "err": "  Device /dev/sdc excluded by a
> filter.\n", "item": {"pvname": "/dev/sdc", "vgname": "gluster_vg_sdc"},
> "msg": "Creating physical volume '/dev/sdc' failed", "rc": 5}
> failed: [vmm11.virt.iad3p] (item={u'vgname': u'gluster_vg_sdc', u'pvname':
> u'/dev/sdc'}) => {"changed": false, "err": "  Device /dev/sdc excluded by a
> filter.\n", "item": {"pvname": "/dev/sdc", "vgname": "gluster_vg_sdc"},
> "msg": "Creating physical volume '/dev/sdc' failed", "rc": 5}
> failed: [vmm10.virt.iad3p] (item={u'vgname': u'gluster_vg_sdd', u'pvname':
> u'/dev/sdd'}) => {"changed": false, "err": "  Device /dev/sdd excluded by a
> filter.\n", "item": {"pvname": "/dev/sdd", "vgname": "gluster_vg_sdd"},
> "msg": "Creating physical volume '/dev/sdd' failed", "rc": 5}
> failed: [vmm12.virt.iad3p] (item={u'vgname': u'gluster_vg_sdd', u'pvname':
> u'/dev/sdd'}) => {"changed": false, "err": "  Device /dev/sdd excluded by a
> filter.\n", "item": {"pvname": "/dev/sdd", "vgname": "gluster_vg_sdd"},
> "msg": "Creating physical volume '/dev/sdd' failed", "r

[ovirt-users] Re: Scale out ovirt 4.3 (from 3 to 6 or 9 nodes) with hyperconverged setup and Gluster

[Sahina Bose]

To scale existing volumes - you need to add bricks and run rebalance on the
gluster volume so that data is correctly redistributed as Alex mentioned.
We do support expanding existing volumes as the bug
https://bugzilla.redhat.com/show_bug.cgi?id=1471031 has been fixed

As to procedure to expand volumes:
1. Create bricks from UI - select Host -> Storage Device -> Storage device.
Click on "Create Brick"
If the device is shown as locked, make sure there's no signature on
device.  If multipath entries have been created for local devices, you can
blacklist those devices in multipath.conf and restart multipath.
(If you see device as locked even after you do this -please report back).
2. Expand volume using Volume -> Bricks -> Add Bricks, and select the 3
bricks created in previous step
3. Run Rebalance on the volume. Volume -> Rebalance.


On Thu, May 16, 2019 at 2:48 PM Fred Rolland  wrote:

> Sahina,
> Can someone from your team review the steps done by Adrian?
> Thanks,
> Freddy
>
> On Thu, Apr 25, 2019 at 5:14 PM Adrian Quintero 
> wrote:
>
>> Ok, I will remove the extra 3 hosts, rebuild them from scratch and
>> re-attach them to clear any possible issues and try out the suggestions
>> provided.
>>
>> thank you!
>>
>> On Thu, Apr 25, 2019 at 9:22 AM Strahil Nikolov 
>> wrote:
>>
>>> I have the same locks , despite I have blacklisted all local disks:
>>>
>>> # VDSM PRIVATE
>>> blacklist {
>>> devnode "*"
>>> wwid Crucial_CT256MX100SSD1_14390D52DCF5
>>> wwid WDC_WD5000AZRX-00A8LB0_WD-WCC1U0056126
>>> wwid WDC_WD5003ABYX-01WERA0_WD-WMAYP2335378
>>> wwid
>>> nvme.1cc1-324a31313230303131353936-414441544120535838323030504e50-0001
>>> }
>>>
>>> If you have multipath reconfigured, do not forget to rebuild the
>>> initramfs (dracut -f). It's a linux issue , and not oVirt one.
>>>
>>> In your case you had something like this:
>>>/dev/VG/LV
>>>   /dev/disk/by-id/pvuuid
>>>  /dev/mapper/multipath-uuid
>>> /dev/sdb
>>>
>>> Linux will not allow you to work with /dev/sdb , when multipath is
>>> locking the block device.
>>>
>>> Best Regards,
>>> Strahil Nikolov
>>>
>>> В четвъртък, 25 април 2019 г., 8:30:16 ч. Гринуич-4, Adrian Quintero <
>>> adrianquint...@gmail.com> написа:
>>>
>>>
>>> under Compute, hosts, select the host that has the locks on /dev/sdb,
>>> /dev/sdc, etc.., select storage devices and in here is where you see a
>>> small column with a bunch of lock images showing for each row.
>>>
>>>
>>> However as a work around, on the newly added hosts (3 total), I had to
>>> manually modify /etc/multipath.conf and add the following at the end as
>>> this is what I noticed from the original 3 node setup.
>>>
>>> -
>>> # VDSM REVISION 1.3
>>> # VDSM PRIVATE
>>> # BEGIN Added by gluster_hci role
>>>
>>> blacklist {
>>> devnode "*"
>>> }
>>> # END Added by gluster_hci role
>>> --
>>> After this I restarted multipath and the lock went away and was able to
>>> configure the new bricks thru the UI, however my concern is what will
>>> happen if I reboot the server will the disks be read the same way by the OS?
>>>
>>> Also now able to expand the gluster with a new replicate 3 volume if
>>> needed using http://host4.mydomain.com:9090.
>>>
>>>
>>> thanks again
>>>
>>> On Thu, Apr 25, 2019 at 8:00 AM Strahil Nikolov 
>>> wrote:
>>>
>>> In which menu do you see it this way ?
>>>
>>> Best Regards,
>>> Strahil Nikolov
>>>
>>> В сряда, 24 април 2019 г., 8:55:22 ч. Гринуич-4, Adrian Quintero <
>>> adrianquint...@gmail.com> написа:
>>>
>>>
>>> Strahil,
>>> this is the issue I am seeing now
>>>
>>> [image: image.png]
>>>
>>> The is thru the UI when I try to create a new brick.
>>>
>>> So my concern is if I modify the filters on the OS what impact will that
>>> have after server reboots?
>>>
>>> thanks,
>>>
>>>
>>>
>>> On Mon, Apr 22, 2019 at 11:39 PM Strahil  wrote:
>>>
>>> I have edited my multipath.conf to exclude local disks , but you need to
>>> set '#VDSM private' as per the comments in the header of the file.
>>> Otherwise, use the /dev/mapper/multipath-device notation - as you would
>>> do with any linux.
>>>
>>> Best Regards,
>>> Strahil NikolovOn Apr 23, 2019 01:07, adrianquint...@gmail.com wrote:
>>> >
>>> > Thanks Alex, that makes more sense now  while trying to follow the
>>> instructions provided I see that all my disks /dev/sdb, /dev/sdc, /dev/sdd
>>> are locked and inidicating " multpath_member" hence not letting me create
>>> new bricks. And on the logs I see
>>> >
>>> > Device /dev/sdb excluded by a filter.\n", "item": {"pvname":
>>> "/dev/sdb", "vgname": "gluster_vg_sdb"}, "msg": "Creating physical volume
>>> '/dev/sdb' failed", "rc": 5}
>>> > Same thing for sdc, sdd
>>> >
>>> > Should I manually edit the filters inside the OS, what will be the
>>> impact?
>>> >
>>> > thanks again.
>>> > 

[ovirt-users] Re: oVirt upgrade version from 4.2 to 4.3

[Sahina Bose]

On Sun, May 19, 2019 at 4:11 PM Strahil  wrote:

> 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.
>

+Gobinda Das  +Satheesaran Sundaramoorthi

Sas, can you log a bug on this?


> Best Regards,
> Strahil NikolovOn May 19, 2019 09:53, Yedidyah Bar David 
> wrote:
> >
> > On Thu, May 16, 2019 at 3:40 PM  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@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/WG2EI6HL3S2AT6PITGEAJQFGKC6XMYRD/
> >
> >
> >
> > --
> > Didi
> > ___
> > 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/KAJGM3URCFSNN6S6X3VZFFOSJF52A4RS/
> ___
> 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/6T7MO4AA7QHKGTD2E7OUNMSFLM4TXRPA/
>
___
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/MWAETC4FN3OSMRGGGX6FIOMQUCZM7P42/

[ovirt-users] Re: oVirt node loses gluster volume UUID after reboot, goes to emergency mode every time I reboot.

[Sahina Bose]

Adding Sachi

On Thu, May 9, 2019 at 2:01 AM  wrote:

> This only started to happen with oVirt node 4.3, 4.2 didn't have issue.
> Since I updated to 4.3, every reboot the host goes into emergency mode.
> First few times this happened I re-installed O/S from scratch, but after
> some digging I found out that the drives it mounts in /etc/fstab cause the
> problem, specifically these mounts.  All three are single drives, one is an
> SSD and the other 2 are individual NVME drives.
>
> UUID=732f939c-f133-4e48-8dc8-c9d21dbc0853 /gluster_bricks/storage_nvme1
> auto defaults 0 0
> UUID=5bb67f61-9d14-4d0b-8aa4-ae3905276797 /gluster_bricks/storage_ssd auto
> defaults 0 0
> UUID=f55082ca-1269-4477-9bf8-7190f1add9ef /gluster_bricks/storage_nvme2
> auto defaults 0 0
>
> In order to get the host to actually boot, I have to go to console, delete
> those mounts, reboot, and then re-add them, and they end up with new
> UUIDs.  all of these hosts reliably rebooted in 4.2 and earlier, but all
> the versions of 4.3 have this same problem (I keep updating to hope issue
> is fixed).
>
> ___
> 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/I4UKZAWPQDXWA47AKTQD43PAUCK2JBJN/
>
___
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/U6Y36PGDKND7XYYKZI7UII64T4AMBOIL/

[ovirt-users] Re: [ovirt-announce] Re: [ANN] oVirt 4.3.4 First Release Candidate is now available

[Sahina Bose]

On Sun, 19 May 2019 at 12:21 AM, Nir Soffer  wrote:

> On Fri, May 17, 2019 at 7:54 AM Gobinda Das  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 
>> 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 <
>>> bu...@onholyground.com> написа:
>>>
>>>
>>> On May 16, 2019, at 1:41 PM, Nir Soffer  wrote:
>>>
>>>
>>> On Thu, May 16, 2019 at 8:38 PM Darrell Budic 
>>> 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=:::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@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/OPBXHYOHZA4XR5CHU7KMD2ISQWLFRG5N/
>>>
>>> ___
>>> 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/B7K24XYG3M43CMMM7MMFARH52QEBXIU5/
>>>
>>
>>
>> --
>>
>>
>> Thanks,
>> Gobinda
>>
>
___
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/6XLDDMCQUQQ3AKN7RMTIPVE47DUVRR4O/

[ovirt-users] Re: [ovirt-announce] Re: [ANN] oVirt 4.3.4 First Release Candidate is now available

[Sahina Bose]

On Fri, 17 May 2019 at 2:13 AM, Strahil Nikolov 
wrote:

>
> >This may be another issue. This command works only for storage with 512
> bytes sector size.
>
> >Hyperconverge systems may use VDO, and it must be configured in
> compatibility mode to >support
> >512 bytes sector size.
>
> >I'm not sure how this is configured but Sahina should know.
>
> >Nir
>
> I do use VDO.
>

There’s a 512b emulation property that needs to be set on for the vdo
volume.


>
___
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/A77B5ME42N3JMLDLSVORL3REDXQXUJ4J/

[ovirt-users] Re: Gluster service failure

[Sahina Bose]

This looks like a bug displaying status in the UI (similar to
https://bugzilla.redhat.com/show_bug.cgi?id=1381175 ?). Could you also
attach engine logs from the timeframe that you notice the issue in UI.

Do all nodes in the cluster return peer status as Connected? (Engine logs
will help determine this info)

On Thu, Oct 6, 2016 at 1:40 PM, Sandro Bonazzola 
wrote:

> Sahina, can you have a look?
>
> On Thu, Oct 6, 2016 at 10:09 AM, Koen Vanoppen 
> wrote:
>
>> Dear all,
>>
>> One little issue. I have 1 hypervisor in my datacenter that keeps having
>> it's gluster status disconnected in the GUI. But if I look on the server,
>> the service is running. I added the logs after I clicked on the "Restart
>> gluster service"
>>
>> Kind regards,
>>
>> Koen
>>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
>
>
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> 
>

--
IMPORTANT!
This message has been scanned for viruses and phishing links.
However, it is your responsibility to evaluate the links and attachments you 
choose to click.
If you are uncertain, we always try to help.
Greetings helpd...@actnet.se



--
IMPORTANT!
This message has been scanned for viruses and phishing links.
However, it is your responsibility to evaluate the links and attachments you 
choose to click.
If you are uncertain, we always try to help.
Greetings helpd...@actnet.se


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
___
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/CXJSAZ7XOJ4RIVEWDEJCMY3FCPFMCYWH/

[ovirt-users] Re: hosted-engine and GlusterFS on Vlan help

[Sahina Bose]

On Tue, Oct 4, 2016 at 9:51 PM, Hanson  wrote:

> Running iperf3 between node1 & node2, I can achieve almost 10gbps without
> ever going out to the gateway...
>
> So switching between port to port on the switch is working properly on the
> vlan.
>
> This must be a problem in the gluster settings? Where do I start
> troubleshooting here?


Is it the gluster traffic that's routed via gateway?

By moving VM, did you mean migrating VM from one host to another? In this
case, there's no storage migration. Why do you think this is a problem in
gluster settings?



>
>
>
> On 10/04/2016 10:38 AM, Hanson wrote:
>
>> Hi Guys,
>>
>> I've converted my lab from using 802.3ad with bonding>bridged vlans to
>> one link with two vlan bridges and am now having traffic jumping to the
>> gateway when moving VM's/ISO/etc.
>>
>> 802.3ad = node1>switch1>node2
>> 801.1q = node1>switch1>gateway>switch1>node2
>>
>> I assume I've setup the same vlan style, though this time I used the gui
>> on the initial host install... setting up the vlans with their parent being
>> eth0.
>>
>> Hosted-engine on deploy then creates ovirtmgmt on top of eth0.11 ...
>>
>> Switch is tagged for vlans 10 & 11. Including a PVID of 11 for good
>> measure. (Gluster is vlan 11)
>>
>> I'd expect the traffic from node to node to be going from port to port
>> like it did in 802.3ad, what have I done wrong or is it using the gui
>> initially?
>>
>> This is how the current setup looks:
>>
>> /var/lib/vdsm/Persistent/netconf/nets/ovirtmgmt:
>> {
>> "ipv6autoconf": false,
>> "nameservers": [],
>> "nic": "eth0",
>> "vlan": 11,
>> "ipaddr": "10.0.3.11",
>> "switch": "legacy",
>> "mtu": 1500,
>> "netmask": "255.255.255.0",
>> "dhcpv6": false,
>> "stp": false,
>> "bridged": true,
>> "gateway": "10.0.3.1",
>> "defaultRoute": true
>> }
>>
>> /etc/sysconfig/network-scripts/ifcfg-ovirtmgmt:
>> # Generated by VDSM version 4.18.13-1.el7.centos
>> DEVICE=ovirtmgmt
>> TYPE=Bridge
>> DELAY=0
>> STP=off
>> ONBOOT=yes
>> IPADDR=10.0.3.11
>> NETMASK=255.255.255.0
>> GATEWAY=10.0.3.1
>> BOOTPROTO=none
>> DEFROUTE=yes
>> NM_CONTROLLED=no
>> IPV6INIT=no
>> VLAN_ID=11
>> MTU=1500
>>
>> Thanks!!
>>
>> ___
>> 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
>

--
IMPORTANT!
This message has been scanned for viruses and phishing links.
However, it is your responsibility to evaluate the links and attachments you 
choose to click.
If you are uncertain, we always try to help.
Greetings helpd...@actnet.se



--
IMPORTANT!
This message has been scanned for viruses and phishing links.
However, it is your responsibility to evaluate the links and attachments you 
choose to click.
If you are uncertain, we always try to help.
Greetings helpd...@actnet.se


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
___
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/KBGZ3VPGNRJZLXVZ3MIZR6JSZ2JT4XMK/

[ovirt-users] Re: 4.0 - 2nd node fails on deploy

[Sahina Bose]

On Wed, Oct 5, 2016 at 1:56 PM, Jason Jeffrey  wrote:

> HI,
>
>
>
> Logs attached
>

Have you probed 2 interfaces for same host, that is - dcasrv02 and
dcastor02? Does "gluster peer status" understand both names as for same
host?

>From glusterd logs and the mount logs - the connection between the peers is
lost, and quorum is lost, which is reaffirming what Simone said earlier.
Logs seem to indicate network issues - check the direct link setup. See
below

From mount logs:
[2016-10-04 17:26:15.718300] E [socket.c:2292:socket_connect_finish]
0-engine-client-2: connection to 10.100.103.3:24007 failed (No route to
host)
[2016-10-04 17:26:15.718345] W [MSGID: 108001]
[afr-common.c:4379:afr_notify] 0-engine-replicate-0: Client-quorum is not
met
[2016-10-04 17:26:16.428290] E [socket.c:2292:socket_connect_finish]
0-engine-client-1: connection to 10.100.101.2:24007 failed (No route to
host)
[2016-10-04 17:26:16.428336] E [MSGID: 108006]
[afr-common.c:4321:afr_notify] 0-engine-replicate-0: All subvolumes are
down. Going offline until atleast one of them comes back up

And in glusterd logs:
[2016-10-04 17:24:39.522402] E [socket.c:2292:socket_connect_finish]
0-management: connection to 10.100.50.82:24007 failed (No route to host)
[2016-10-04 17:24:39.522578] I [MSGID: 106004]
[glusterd-handler.c:5201:__glusterd_peer_rpc_notify] 0-management: Peer
 (<1e788fc9-dfe9-4753-92c7-76a95c8d0891>), in state , has disconnected from glusterd.
[2016-10-04 17:24:39.523272] C [MSGID: 106002]
[glusterd-server-quorum.c:351:glusterd_do_volume_quorum_action]
0-management: Server quorum lost for volume engine. Stopping local bricks.
[2016-10-04 17:24:39.523314] I [MSGID: 106132]
[glusterd-utils.c:1560:glusterd_service_stop] 0-management: brick already
stopped
[2016-10-04 17:24:39.526188] E [socket.c:2292:socket_connect_finish]
0-management: connection to 10.100.103.3:24007 failed (No route to host)
[2016-10-04 17:24:39.526219] I [MSGID: 106004]
[glusterd-handler.c:5201:__glusterd_peer_rpc_notify] 0-management: Peer
 (<9a9c037e-96cd-4f73-9800-a1df5cdd2818>), in state , has disconnected from glusterd.



> Thanks
>
>
>
> *From:* Sahina Bose [mailto:sab...@redhat.com]
> *Sent:* 05 October 2016 08:11
> *To:* Jason Jeffrey ; gluster-us...@gluster.org;
> Ravishankar Narayanankutty 
> *Cc:* Simone Tiraboschi ; users 
>
> *Subject:* Re: [ovirt-users] 4.0 - 2nd node fails on deploy
>
>
>
> [Adding gluster-users ML]
>
> The brick logs are filled with errors :
> [2016-10-05 19:30:28.659061] E [MSGID: 113077] 
> [posix-handle.c:309:posix_handle_pump]
> 0-engine-posix: malformed internal link /var/run/vdsm/storage/
> 0a021563-91b5-4f49-9c6b-fff45e85a025/d84f0551-0f2b-457c-808c-6369c6708d43/
> 1b5a5e34-818c-4914-8192-2f05733b5583 for /xpool/engine/brick/.
> glusterfs/b9/8e/b98ed8d2-3bf9-4b11-92fd-ca5324e131a8
> [2016-10-05 19:30:28.659069] E [MSGID: 113091] [posix.c:180:posix_lookup]
> 0-engine-posix: Failed to create inode handle for path
> 
> The message "E [MSGID: 113018] [posix.c:198:posix_lookup] 0-engine-posix:
> lstat on null failed" repeated 3 times between [2016-10-05 19:30:28.656529]
> and [2016-10-05 19:30:28.659076]
> [2016-10-05 19:30:28.659087] W [MSGID: 115005]
> [server-resolve.c:126:resolve_gfid_cbk] 0-engine-server:
> b98ed8d2-3bf9-4b11-92fd-ca5324e131a8: failed to resolve (Success)
>
> - Ravi, the above are from the data brick of the arbiter volume. Can you
> take a look?
>
>
>
> Jason,
>
> Could you also provide the mount logs from the first host
> (/var/log/glusterfs/rhev-data-center-mnt-glusterSD*engine.log) and
> glusterd log (/var/log/glusterfs/etc-glusterfs-glusterd.vol.log) around
> the same time frame.
>
>
>
>
>
> On Wed, Oct 5, 2016 at 3:28 AM, Jason Jeffrey  wrote:
>
> Hi,
>
>
>
> Servers are powered  off  when I’m not looking at the problem.
>
>
>
> There may have been instances where all three were not powered on, during
> the same period.
>
>
>
> Glusterhd log attached, the xpool-engine-brick log is over 1 GB in size,
> I’ve taken a sample of the last  couple days, looks to be highly repative.
>
>
>
> Cheers
>
>
>
> Jason
>
>
>
>
>
>
>
>
>
> *From:* Simone Tiraboschi [mailto:stira...@redhat.com]
> *Sent:* 04 October 2016 16:50
>
>
> *To:* Jason Jeffrey 
> *Cc:* users 
> *Subject:* Re: [ovirt-users] 4.0 - 2nd node fails on deploy
>
>
>
>
>
>
>
> On Tue, Oct 4, 2016 at 5:22 PM, Jason Jeffrey  wrote:
>
> Hi,
>
>
>
> DCASTORXX is a hosts entry for dedicated  direct 10GB links (each private
> /28) between the x3 servers  i.e 1=> 2&3, 2=> 1&3, etc) planned to be used
> solely for storage.
>
>
>
> I,e
>
>
>
> 10.100.5

[ovirt-users] Re: 4.0 - 2nd node fails on deploy

[Sahina Bose]

[Adding gluster-users ML]
The brick logs are filled with errors :
[2016-10-05 19:30:28.659061] E [MSGID: 113077]
[posix-handle.c:309:posix_handle_pump] 0-engine-posix: malformed internal
link
/var/run/vdsm/storage/0a021563-91b5-4f49-9c6b-fff45e85a025/d84f0551-0f2b-457c-808c-6369c6708d43/1b5a5e34-818c-4914-8192-2f05733b5583
for
/xpool/engine/brick/.glusterfs/b9/8e/b98ed8d2-3bf9-4b11-92fd-ca5324e131a8
[2016-10-05 19:30:28.659069] E [MSGID: 113091] [posix.c:180:posix_lookup]
0-engine-posix: Failed to create inode handle for path

The message "E [MSGID: 113018] [posix.c:198:posix_lookup] 0-engine-posix:
lstat on null failed" repeated 3 times between [2016-10-05 19:30:28.656529]
and [2016-10-05 19:30:28.659076]
[2016-10-05 19:30:28.659087] W [MSGID: 115005]
[server-resolve.c:126:resolve_gfid_cbk] 0-engine-server:
b98ed8d2-3bf9-4b11-92fd-ca5324e131a8: failed to resolve (Success)

- Ravi, the above are from the data brick of the arbiter volume. Can you
take a look?

Jason,
Could you also provide the mount logs from the first host
(/var/log/glusterfs/rhev-data-center-mnt-glusterSD*engine.log) and glusterd
log (/var/log/glusterfs/etc-glusterfs-glusterd.vol.log) around the same
time frame.



On Wed, Oct 5, 2016 at 3:28 AM, Jason Jeffrey  wrote:

> Hi,
>
>
>
> Servers are powered  off  when I’m not looking at the problem.
>
>
>
> There may have been instances where all three were not powered on, during
> the same period.
>
>
>
> Glusterhd log attached, the xpool-engine-brick log is over 1 GB in size,
> I’ve taken a sample of the last  couple days, looks to be highly repative.
>
>
>
> Cheers
>
>
>
> Jason
>
>
>
>
>
>
>
>
>
> *From:* Simone Tiraboschi [mailto:stira...@redhat.com]
> *Sent:* 04 October 2016 16:50
>
> *To:* Jason Jeffrey 
> *Cc:* users 
> *Subject:* Re: [ovirt-users] 4.0 - 2nd node fails on deploy
>
>
>
>
>
>
>
> On Tue, Oct 4, 2016 at 5:22 PM, Jason Jeffrey  wrote:
>
> Hi,
>
>
>
> DCASTORXX is a hosts entry for dedicated  direct 10GB links (each private
> /28) between the x3 servers  i.e 1=> 2&3, 2=> 1&3, etc) planned to be used
> solely for storage.
>
>
>
> I,e
>
>
>
> 10.100.50.81dcasrv01
>
> 10.100.101.1dcastor01
>
> 10.100.50.82dcasrv02
>
> 10.100.101.2dcastor02
>
> 10.100.50.83dcasrv03
>
> 10.100.103.3dcastor03
>
>
>
> These were setup with the gluster commands
>
>
>
> · gluster volume create iso replica 3 arbiter 1
> dcastor01:/xpool/iso/brick   dcastor02:/xpool/iso/brick
> dcastor03:/xpool/iso/brick
>
> · gluster volume create export replica 3 arbiter 1
> dcastor02:/xpool/export/brick  dcastor03:/xpool/export/brick
> dcastor01:/xpool/export/brick
>
> · gluster volume create engine replica 3 arbiter 1
> dcastor01:/xpool/engine/brick dcastor02:/xpool/engine/brick
> dcastor03:/xpool/engine/brick
>
> · gluster volume create data replica 3 arbiter 1
> dcastor01:/xpool/data/brick  dcastor03:/xpool/data/brick
> dcastor02:/xpool/data/bricky
>
>
>
>
>
> So yes, DCASRV01 is the server (pri) and have local bricks access through
> DCASTOR01 interface
>
>
>
> Is the issue here not the incorrect soft link ?
>
>
>
> No, this should be fine.
>
>
>
> The issue is that periodically your gluster volume losses its server
> quorum and become unavailable.
>
> It happened more than once from your logs.
>
>
>
> Can you please attach also gluster logs for that volume?
>
>
>
>
>
> lrwxrwxrwx. 1 vdsm kvm  132 Oct  3 17:27 hosted-engine.metadata ->
> /var/run/vdsm/storage/bbb70623-194a-46d2-a164-76a4876ecaaf/fd44dbf9-473a-
> 496a-9996-c8abe3278390/cee9440c-4eb8-453b-bc04-c47e6f9cbc93
>
> [root@dcasrv01 /]# ls -al /var/run/vdsm/storage/bbb70623-194a-46d2-a164-
> 76a4876ecaaf/
>
> ls: cannot access /var/run/vdsm/storage/bbb70623-194a-46d2-a164-76a4876ecaaf/:
> No such file or directory
>
> But the data does exist
>
> [root@dcasrv01 fd44dbf9-473a-496a-9996-c8abe3278390]# ls -al
>
> drwxr-xr-x. 2 vdsm kvm4096 Oct  3 17:17 .
>
> drwxr-xr-x. 6 vdsm kvm4096 Oct  3 17:17 ..
>
> -rw-rw. 2 vdsm kvm 1028096 Oct  3 20:48 cee9440c-4eb8-453b-bc04-
> c47e6f9cbc93
>
> -rw-rw. 2 vdsm kvm 1048576 Oct  3 17:17 cee9440c-4eb8-453b-bc04-
> c47e6f9cbc93.lease
>
> -rw-r--r--. 2 vdsm kvm 283 Oct  3 17:17 
> cee9440c-4eb8-453b-bc04-c47e6f9cbc93.meta
>
>
>
>
> Thanks
>
>
>
> Jason
>
>
>
>
>
>
>
> *From:* Simone Tiraboschi [mailto:stira...@redhat.com]
> *Sent:* 04 October 2016 14:40
>
>
> *To:* Jason Jeffrey 
> *Cc:* users 
> *Subject:* Re: [ovirt-users] 4.0 - 2nd node fails on deploy
>
>
>
>
>
>
>
> On Tue, Oct 4, 2016 at 10:51 AM, Simone Tiraboschi 
> wrote:
>
>
>
>
>
> On Mon, Oct 3, 2016 at 11:56 PM, Jason Jeffrey  wrote:
>
> Hi,
>
>
>
> Another problem has appeared, after rebooting the primary the VM will not
> start.
>
>
>
> Appears the symlink is broken between gluster mount ref and vdsm
>
>
>
> The first host was correctly deployed but it seas that you are facing some
> issue connecting the storage.
>
> Can you please attach vdsm logs and /var/log/messages from the 

[ovirt-users] Re: Ovirt nodeNG RDMA support?

[Sahina Bose]

Rafi, can you take a look?

On Mon, May 6, 2019 at 10:29 PM  wrote:
>
> this is what I see in the logs when I try to add RDMA:
>
> [2019-05-06 16:54:50.305297] I [MSGID: 106521] 
> [glusterd-op-sm.c:2953:glusterd_op_set_volume] 0-management: changing 
> transport-type for volume storage_ssd to tcp,rdma
> [2019-05-06 16:54:50.309122] W [MSGID: 101095] 
> [xlator.c:180:xlator_volopt_dynload] 0-xlator: 
> /usr/lib64/glusterfs/5.3/xlator/nfs/server.so: cannot open shared object 
> file: No such file or directory
> [2019-05-06 16:54:50.321422] E [MSGID: 106068] 
> [glusterd-volgen.c:1025:volgen_write_volfile] 0-management: failed to create 
> volfile
> [2019-05-06 16:54:50.321463] E 
> [glusterd-volgen.c:6556:glusterd_create_volfiles] 0-management: Could not 
> generate gfproxy client volfiles
> [2019-05-06 16:54:50.321476] E [MSGID: 106068] 
> [glusterd-op-sm.c:3062:glusterd_op_set_volume] 0-management: Unable to create 
> volfile for 'volume set'
> [2019-05-06 16:54:50.321488] E [MSGID: 106122] 
> [glusterd-syncop.c:1434:gd_commit_op_phase] 0-management: Commit of operation 
> 'Volume Set' failed on localhost
> [2019-05-06 16:54:50.323610] E [MSGID: 101191] 
> [event-epoll.c:671:event_dispatch_epoll_worker] 0-epoll: Failed to dispatch 
> handler
>
> rmda status:
> root@Prometheus glusterfs]# systemctl status rdma
> ● rdma.service - Initialize the iWARP/InfiniBand/RDMA stack in the kernel
>Loaded: loaded (/usr/lib/systemd/system/rdma.service; enabled; vendor 
> preset: disabled)
>Active: active (exited) since Sun 2019-04-21 23:53:42 EDT; 2 weeks 0 days 
> ago
>  Docs: file:/etc/rdma/rdma.conf
>  Main PID: 4968 (code=exited, status=0/SUCCESS)
> Tasks: 0
>CGroup: /system.slice/rdma.service
>
> volume status:
>
> Gluster process TCP Port  RDMA Port  Online  Pid
> --
> Brick 10.100.50.12:/gluster_bricks/storage_
> nvme2/storage_nvme2 49153 0  Y   26888
> Brick 10.100.50.14:/gluster_bricks/storage_
> nvme2/storage_nvme2 49153 0  Y   3827
> Brick 10.100.50.16:/gluster_bricks/storage_
> nvme2/storage_nvme2 49153 0  Y   24238
> Self-heal Daemon on localhost   N/A   N/AY   29452
> Self-heal Daemon on 10.100.50.16N/A   N/AY   11058
> Self-heal Daemon on 10.100.50.14N/A   N/AY   8573
>
> ___
> 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/4JZJXH3OFH3RPILRCRZYCKEZNO2CSNTN/
___
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/7YDKDAFW4HALKZKUYXKMQDAZJ7PMFGBK/

[ovirt-users] Re: Ovirt nodeNG RDMA support?

[Sahina Bose]

On Tue, Apr 30, 2019 at 3:35 PM Sandro Bonazzola 
wrote:

>
>
> Il giorno ven 26 apr 2019 alle ore 01:56  ha
> scritto:
>
>> When I was able to load CentosOS as a host OS,  Was able to use RDMA, but
>> it seems like the 4.3x branch of nodeNG is missing RDMA support?  I enabled
>> rdma and started the service, but gluster refuses to recognize that RDMA is
>> available and always reports RDMA port as 0 and when I try to make a new
>> drive with tcp,rdma transport options, it always fails.
>>
>
> Sahina, any hint?
>

Adding Rafi. Any errors in glusterd logs?


>
>> ___
>> 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/E73V472TTQVOLIOSRCZSC5DV47VEKIDU/
>>
>
>
> --
>
> SANDRO BONAZZOLA
>
> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>
> Red Hat EMEA 
>
> sbona...@redhat.com
> 
>
___
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/DXWMJNS5XRY5RSADIJMWVIUXN6QWXSMM/

[ovirt-users] Re: Gluster and few iSCSI Datastores in one Data Center

[Sahina Bose]

There seem to be communication issues between vdsmd and supervdsmd
services. Can you check the status of both on the nodes? Perhaps try
restarting these

On Tue, Apr 23, 2019 at 6:01 PM  wrote:
>
> I decided to add another cluster to the existing data center (Enable Virt 
> Service + Enable Gluster Service).
> Three nodes. But after installing the nodes (without errors) Ovirt Engine 
> loses them cyclically. From the logs you can see that this happens when you 
> try to interrogate the connected block devices.
> These block devices are LVM for VM. I use several Datastores submitted via 
> iSCSI. About 2000 virtual machines and more than 2300 LVMs. All in the 
> neighbor cluster (one data center).
> Logs in https://drive.google.com/open?id=1ja7Usxx5YCFDgjD2X51z9tzn_ycPoC2g
>
> Why is this happening and what can be done in this case?
> ___
> 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/NNPWWJWJEIZTHRY7R3GMFANOO6JDVAPA/
___
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/SBVN5IVPA6WWDU5SLOD7O3PWKEOUTGTV/

[ovirt-users] Re: Gluster suggestions

[Sahina Bose]

On Tue, Apr 16, 2019 at 2:39 PM Magnus Isaksson  wrote:
>
> I have 2 hosts per cluster, and i have 2 clusters, 4 hosts (its an Huawei 
> x6000)
>
> I know oVirt don't support disperse, that's why i run gluster outside of 
> oVirt.
> And doing that i get a bit more freedom with setting up gluster.
> So what would be an good setup to be able to use as much space as possible 
> and some redundancy with the 4 hosts i have?

Even if you run gluster outside of oVirt, you are using the disperse
volume as storage domain?

For a supported config, you can create a distributed-replica+arbiter
gluster volume. Since you have 12 disks, you can use a 5 x 3 (arbiter)
setup, where a disk is partitioned to multiple arbiter bricks,
something like this (c11,c12, a31, a32 are arbiter bricks) :

a1 b1 c11
a2 b2 c12
 b3 c13 d1
a31 c2 d2
a32 c3 d3

>
> //Magnus
>
>
> ____
> From: Sahina Bose 
> Sent: 16 April 2019 10:55
> To: Magnus Isaksson
> Cc: users
> Subject: Re: [ovirt-users] Gluster suggestions
>
> On Tue, Apr 16, 2019 at 1:42 PM  wrote:
> >
> >  Hello
> >
> > I would like some suggestions on what type of solution with Gluster i 
> > should use.
> >
> > I have 4 hosts with 3 disks each, i want to user as much space as possible 
> > but also some redundancy, like raid5 or 6
> > The 4 hosts are running oVirt on CentOS 7
> > I have 2 clusters due to some licensing issues, so i cant use ovirts setup 
> > of gluster
>
> I did not quite get this - are you saying you can have only 2 nodes in
> one cluster?
>
> >
> > Today i have set it up as follows
> > Type: Disperse
> > Number of Bricks: 1 x (8 + 4) = 12
>
> Disperse volumes are not supported with oVirt. It's either replica 3
> or replica 2 + arbiter.
>
> >
> > So i have 3 bricks per host (one brick per disk)
> >
> > But this setup is not working very well, as soon as i get some traffic on 
> > the volume this start to fail on the ovirt nodes, loosing connection etc.
> >
> > All hosts are connected via 10G interface
> >
> > So any suggestions on how i would set this up as best is much appreciated.
> >
> > Regards
> >  Magnus Isaksson
> > ___
> > 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/AIEPMRANHFB7J2FH6IHTFJ2GUXVB37ZP/
___
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/GOQCLTCL6SWGSENS3BP36Z3JWEMX4IZA/

[ovirt-users] Re: hosted engine does not start

[Sahina Bose]

Can you check if there are any errors in the engine volume's mount
logs (/var/logs/glusterfs/rrhev-data-center-mnt-glusterSD-.log)

On Tue, Apr 16, 2019 at 2:33 PM Stefan Wolf  wrote:
>
> Sorry i forgot to wrote,
>
>
>
> This is everything I got.
>
>
>
> No keyboard input
>
>
>
> I ve read to mount the harddrive with losetup and use fsck
>
>
>
> [root@kvm360 /]# fdisk -lu 
> /mnt/36663740-576a-4498-b28e-0a402628c6a7/images/50d59094-7f24-4fed-9c4e-d3bb6b42eb6a/38252d8a-49fd-474e-a449-d40b3ef4b7dc
>
>
>
> Disk 
> /mnt/36663740-576a-4498-b28e-0a402628c6a7/images/50d59094-7f24-4fed-9c4e-d3bb6b42eb6a/38252d8a-49fd-474e-a449-d40b3ef4b7dc:
>  53.7 GB, 53687091200 bytes, 104857600 sectors
>
> Units = Sektoren of 1 * 512 = 512 bytes
>
> Sector size (logical/physical): 512 bytes / 512 bytes
>
> I/O size (minimum/optimal): 512 bytes / 512 bytes
>
> Disk label type: dos
>
> Disk identifier: 0x000aff89
>
>
>
>   
>Gerät  boot. AnfangEnde
>  Blöcke   Id  System
>
> /mnt/36663740-576a-4498-b28e-0a402628c6a7/images/50d59094-7f24-4fed-9c4e-d3bb6b42eb6a/38252d8a-49fd-474e-a449-d40b3ef4b7dc1
>*2048 2099199 1048576   83  Linux
>
> /mnt/36663740-576a-4498-b28e-0a402628c6a7/images/50d59094-7f24-4fed-9c4e-d3bb6b42eb6a/38252d8a-49fd-474e-a449-d40b3ef4b7dc2
>  20992009201254344956672   8e  Linux LVM
>
> /mnt/36663740-576a-4498-b28e-0a402628c6a7/images/50d59094-7f24-4fed-9c4e-d3bb6b42eb6a/38252d8a-49fd-474e-a449-d40b3ef4b7dc3
> 92012544   10481 6421504   83  Linux
>
> [root@kvm360 /]# losetup -o 2099200 /dev/loop0 
> /mnt/36663740-576a-4498-b28e-0a402628c6a7/images/50d59094-7f24-4fed-9c4e-d3bb6b42eb6a/38252d8a-49fd-474e-a449-d40b3ef4b7dc
>
> [root@kvm360 /]# mount /dev/loop0 /test/
>
> mount: /dev/loop0 is write-protected, mounting read-only
>
> mount: wrong fs type, bad option, bad superblock on /dev/loop0,
>
>missing codepage or helper program, or other error
>
>
>
>    In some cases useful info is found in syslog - try
>
>dmesg | tail or so.
>
> [root@kvm360 /]#
>
>
>
> But I suck on mounting partition
>
>
>
> -Ursprüngliche Nachricht-
> Von: Sahina Bose 
> Gesendet: Dienstag, 16. April 2019 10:57
> An: Stefan Wolf 
> Cc: users 
> Betreff: Re: [ovirt-users] hosted engine does not start
>
>
>
> On Tue, Apr 16, 2019 at 1:07 AM Stefan Wolf  wrote:
>
> >
>
> > Hello all,
>
> >
>
> >
>
> >
>
> > after a powerloss the hosted engine won’t start up anymore.
>
> >
>
> > I ‘ve the current ovirt installed.
>
> >
>
> > Storage is glusterfs und it is up and running
>
> >
>
> >
>
> >
>
> > It is trying to start up hosted engine but it does not work, but I can’t 
> > see where the problem is.
>
> >
>
> >
>
> >
>
> > [root@kvm320 ~]# hosted-engine --vm-status
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > --== Host 1 status ==--
>
> >
>
> >
>
> >
>
> > conf_on_shared_storage : True
>
> >
>
> > Status up-to-date  : True
>
> >
>
> > Hostname   : kvm380.durchhalten.intern
>
> >
>
> > Host ID: 1
>
> >
>
> > Engine status  : {"reason": "bad vm status", "health": 
> > "bad", "vm": "down", "detail": "Down"}
>
> >
>
> > Score  : 1800
>
> >
>
> > stopped: False
>
> >
>
> > Local maintenance  : False
>
> >
>
> > crc32  : 3ad6d0bd
>
> >
>
> > local_conf_timestamp   : 14594
>
> >
>
> > Host timestamp : 14594
>
> >
>
> > Extra metadata (valid at timestamp):
>
> >
>
> >metadata_parse_version=1
>
> >
>
> > metadata_feature_version=1
>
> >
>
> > timestamp=14594 (Mon Apr 15 21:25:12 2019)
>
> >
>
> > host-id=1
>
> >
>
> > score=1800
>
> >
>
> > vm_conf_refresh_time=14594 (Mon Apr 15 21:25:12 2019)
>
> >
>
> > conf_on_shared_storage=True
>
>

[ovirt-users] Re: hosted engine does not start

[Sahina Bose]

On Tue, Apr 16, 2019 at 1:07 AM Stefan Wolf  wrote:
>
> Hello all,
>
>
>
> after a powerloss the hosted engine won’t start up anymore.
>
> I ‘ve the current ovirt installed.
>
> Storage is glusterfs und it is up and running
>
>
>
> It is trying to start up hosted engine but it does not work, but I can’t see 
> where the problem is.
>
>
>
> [root@kvm320 ~]# hosted-engine --vm-status
>
>
>
>
>
> --== Host 1 status ==--
>
>
>
> conf_on_shared_storage : True
>
> Status up-to-date  : True
>
> Hostname   : kvm380.durchhalten.intern
>
> Host ID: 1
>
> Engine status  : {"reason": "bad vm status", "health": 
> "bad", "vm": "down", "detail": "Down"}
>
> Score  : 1800
>
> stopped: False
>
> Local maintenance  : False
>
> crc32  : 3ad6d0bd
>
> local_conf_timestamp   : 14594
>
> Host timestamp : 14594
>
> Extra metadata (valid at timestamp):
>
>metadata_parse_version=1
>
> metadata_feature_version=1
>
> timestamp=14594 (Mon Apr 15 21:25:12 2019)
>
> host-id=1
>
> score=1800
>
> vm_conf_refresh_time=14594 (Mon Apr 15 21:25:12 2019)
>
> conf_on_shared_storage=True
>
> maintenance=False
>
> state=GlobalMaintenance
>
> stopped=False
>
>
>
>
>
> --== Host 2 status ==--
>
>
>
> conf_on_shared_storage : True
>
> Status up-to-date  : True
>
> Hostname   : kvm320.durchhalten.intern
>
> Host ID: 2
>
> Engine status  : {"reason": "failed liveliness check", 
> "health": "bad", "vm": "up", "detail": "Up"}
>
> Score  : 0
>
> stopped: False
>
> Local maintenance  : False
>
> crc32  : e7d4840d
>
> local_conf_timestamp   : 21500
>
> Host timestamp : 21500
>
> Extra metadata (valid at timestamp):
>
> metadata_parse_version=1
>
> metadata_feature_version=1
>
> timestamp=21500 (Mon Apr 15 21:25:22 2019)
>
> host-id=2
>
> score=0
>
> vm_conf_refresh_time=21500 (Mon Apr 15 21:25:22 2019)
>
> conf_on_shared_storage=True
>
> maintenance=False
>
> state=ReinitializeFSM
>
> stopped=False
>
>
>
>
>
> --== Host 3 status ==--
>
>
>
> conf_on_shared_storage : True
>
> Status up-to-date  : True
>
> Hostname   : kvm360.durchhalten.intern
>
> Host ID: 3
>
> Engine status  : {"reason": "vm not running on this 
> host", "health": "bad", "vm": "down", "detail": "unknown"}
>
> Score  : 1800
>
> stopped: False
>
> Local maintenance  : False
>
> crc32  : cf9221cb
>
> local_conf_timestamp   : 22121
>
> Host timestamp : 22120
>
> Extra metadata (valid at timestamp):
>
> metadata_parse_version=1
>
> metadata_feature_version=1
>
> timestamp=22120 (Mon Apr 15 21:25:18 2019)
>
> host-id=3
>
> score=1800
>
> vm_conf_refresh_time=22121 (Mon Apr 15 21:25:18 2019)
>
> conf_on_shared_storage=True
>
> maintenance=False
>
> state=GlobalMaintenance
>
> stopped=False
>
>
>
> [root@kvm320 ~]# virsh -r list
>
> IdName   Status
>
> 
>
> 6 HostedEngine   laufend
>
>
>
> [root@kvm320 ~]# hosted-engine --console
>
> The engine VM is running on this host
>
> Verbunden mit der Domain: HostedEngine
>
> Escape-Zeichen ist ^]
>
> Fehler: Interner Fehler: Zeichengerät  kann nicht gefunden warden
>
>
>
> In engish it should be this
>
>
>
> [root@mgmt~]# hosted-engine --console
> The engine VM is running on this host
> Connected to domain HostedEngine
> Escape character is ^]
> error: internal error: cannot find character device
>
>
>
> This is in the log
>
>
>
> [root@kvm320 ~]# tail -f /var/log/ovirt-hosted-engine-ha/agent.log
>
> MainThread::INFO::2019-04-15 
> 21:28:33,032::hosted_engine::491::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
>  Current state EngineStarting (score: 1800)
>
> MainThread::INFO::2019-04-15 
> 21:28:43,050::states::779::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(consume)
>  VM is powering up..
>
> MainThread::INFO::2019-04-15 
> 21:28:43,165::hosted_engine::491::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
>  Current state EngineStarting (score: 1800)
>
> MainThread::INFO::2019-04-15 
> 

[ovirt-users] Re: Gluster suggestions

[Sahina Bose]

On Tue, Apr 16, 2019 at 1:42 PM  wrote:
>
>  Hello
>
> I would like some suggestions on what type of solution with Gluster i should 
> use.
>
> I have 4 hosts with 3 disks each, i want to user as much space as possible 
> but also some redundancy, like raid5 or 6
> The 4 hosts are running oVirt on CentOS 7
> I have 2 clusters due to some licensing issues, so i cant use ovirts setup of 
> gluster

I did not quite get this - are you saying you can have only 2 nodes in
one cluster?

>
> Today i have set it up as follows
> Type: Disperse
> Number of Bricks: 1 x (8 + 4) = 12

Disperse volumes are not supported with oVirt. It's either replica 3
or replica 2 + arbiter.

>
> So i have 3 bricks per host (one brick per disk)
>
> But this setup is not working very well, as soon as i get some traffic on the 
> volume this start to fail on the ovirt nodes, loosing connection etc.
>
> All hosts are connected via 10G interface
>
> So any suggestions on how i would set this up as best is much appreciated.
>
> Regards
>  Magnus Isaksson
> ___
> 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/AIEPMRANHFB7J2FH6IHTFJ2GUXVB37ZP/
___
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/42UQQCO2AINEP2KNQF3WXMPWGBSBDGQO/

[ovirt-users] Re: Gluster arbiter volume storage domain - change

[Sahina Bose]

On Tue, Apr 16, 2019 at 1:39 PM Leo David  wrote:
>
> Hi Everyone,
> I have wrongly configured the main gluster volume ( 12 identical 1tb ssd 
> disks, replica 3 distributed-replicated, across 6 nodes - 2 per node ) with 
> arbiter one.
> Oviously I am wasting storage space in this scenario with the arbiter bricks, 
> and I would like to convert the volume to non-arbitrated one, so having all 
> the data evenly spreaded across all the disks.
> Considering the the storage is being used by about 40 vms in production, what 
> would it be the steps, or is there any chance to change the volume type to 
> non-arbitrated on the fly and then rebalance ?
> Thank you very much !

Ravi, can you help here - to change from arbiter to replica 3?


> ___
> 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/UBEZWN35M365IKCIE3U6TRHDDX7TS75T/
___
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/J2LECLKUQAK5RM6A2JOQJHTXXVO7CYMN/

[ovirt-users] Re: Disk Locked

[Sahina Bose]

On Wed, Apr 3, 2019 at 5:33 PM Николаев Алексей
 wrote:
>
> Hi comminuty!
>
> I have issue like this https://bugzilla.redhat.com/show_bug.cgi?id=1506373 on 
> ovirt-engine 4.2.8.2-1.el7.
>
> Description of problem:
> VM disk left in LOCKED state when added.
>
> Version-Release number of selected component (if applicable):
>
> ovirt-engine 4.2.8.2-1.el7
> glusterfs 3.12.15
>
> How reproducible:
>
>
> Steps to Reproduce:
> 1.  Create a VM
> 2.  Add disks on Gluster Data Domain size of 4 TB.

Are the disks pre-allocated? What's the shard size property on the
gluster volume?

Any errors in vdsm log?

> 3.
>
> Actual results:
>
> VM disks are in LOCKED state and task never finished
>
> Expected results:
>
> VM disks shouldn't be in LOCKED state.
>
> Additional info:
>
> Stuck Task was found by
> /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select * from job;"
>
> and deleted by
> /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select 
> DeleteJob('0ad3ead5-8b99-404f-a671-069dfbbdbcb7');"
>
> But now disk in LOCKED state and can't be unlocked. How I can fix it?
> Thx.
>
> ___
> 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/5H7B5BHEUD3YOZ6J23LZLL4Q7RQ4X6JN/
___
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/TZMDG4GVTDFVVK2LGMVMN7F7BCL7DPPY/

[ovirt-users] Re: change self-hosted engine storage domain

[Sahina Bose]

On Wed, Apr 10, 2019 at 8:51 PM  wrote:
>
> Is it possible to change a self-hosted engine's storage domain's settings?
>
> I setup a 3-node ovirt + gluster cluster with a dedicated 'engine' storage 
> domain. I can see through the administration portal that the engine storage 
> domain is using a single gluster host and no backup volfile servers. The 
> single gluster host that the engine storage domain settings refer to had to 
> be removed, so now I'm getting issues where VDSM is reporting that it cannot 
> get the volume file information for the engine storage domain.
> I'm not sure how to go about changing the settings since the only way I've 
> seen how to do this is through the administration portal, which relies on the 
> engine VM (and its storage) being available.
>
> What I'd like to do is change the storage domain's path and add mount options 
> for the backup volfile servers.

You can use -

 hosted-engine --set-shared-config storage :/engine

hosted-engine --set-shared-config mnt_options
backup-volfile-servers=:

> ___
> 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/3NCQ5F7QDNSBQAJV7OEABKZTBI62KADM/
___
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/JK4ZPDCQX7DUG3QITSY7KIYN7EW7ZNOB/

[ovirt-users] Re: Second host fail to activate (hosted-engine)

[Sahina Bose]

On Wed, Apr 10, 2019 at 1:45 AM Ricardo Alonso  wrote:
>
> After installing the second host via the web gui (4.3.2.1-1.el7), it fails to 
> activate telling that wasn't possible to connect to the storage pool default 
> (glusterfs). Those are the logs:
>
> vdsm.log
>
> 2019-04-09 15:54:07,409-0400 INFO  (Reactor thread) 
> [ProtocolDetector.AcceptorImpl] Accepted connection from ::1:58130 
> (protocoldetector:61)
> 2019-04-09 15:54:07,419-0400 INFO  (Reactor thread) 
> [ProtocolDetector.Detector] Detected protocol stomp from ::1:58130 
> (protocoldetector:125)
> 2019-04-09 15:54:07,419-0400 INFO  (Reactor thread) [Broker.StompAdapter] 
> Processing CONNECT request (stompserver:95)
> 2019-04-09 15:54:07,420-0400 INFO  (JsonRpc (StompReactor)) 
> [Broker.StompAdapter] Subscribe command received (stompserver:124)
> 2019-04-09 15:54:07,461-0400 INFO  (jsonrpc/1) [jsonrpc.JsonRpcServer] RPC 
> call Host.ping2 succeeded in 0.00 seconds (__init__:312)
> 2019-04-09 15:54:07,466-0400 INFO  (jsonrpc/2) [jsonrpc.JsonRpcServer] RPC 
> call Host.ping2 succeeded in 0.00 seconds (__init__:312)
> 2019-04-09 15:54:07,469-0400 INFO  (jsonrpc/0) [vdsm.api] START 
> getStorageDomainInfo(sdUUID=u'd99fb087-66d5-4adf-9c0c-80e60de17917', 
> options=None) from=::1,58130, task_id=00c843c2-ab43-4813-9ded-29f6742c33b2 
> (api:48)
> 2019-04-09 15:54:07,484-0400 INFO  (jsonrpc/0) [vdsm.api] FINISH 
> getStorageDomainInfo error='VERSION' from=::1,58130, 
> task_id=00c843c2-ab43-4813-9ded-29f6742c33b2 (api:52)
> 2019-04-09 15:54:07,484-0400 ERROR (jsonrpc/0) [storage.TaskManager.Task] 
> (Task='00c843c2-ab43-4813-9ded-29f6742c33b2') 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 "", line 2, in getStorageDomainInfo
>   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 2741, in 
> getStorageDomainInfo
> dom = self.validateSdUUID(sdUUID)
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 305, in 
> validateSdUUID
> sdDom = sdCache.produce(sdUUID=sdUUID)
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/sdc.py", line 110, in 
> produce
> domain.getRealDomain()
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/sdc.py", line 51, in 
> getRealDomain
> return self._cache._realProduce(self._sdUUID)
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/sdc.py", line 134, in 
> _realProduce
> domain = self._findDomain(sdUUID)
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/sdc.py", line 151, in 
> _findDomain
> return findMethod(sdUUID)
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/glusterSD.py", line 56, 
> in findDomain
> return GlusterStorageDomain(GlusterStorageDomain.findDomainPath(sdUUID))
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/fileSD.py", line 394, 
> in __init__
> manifest = self.manifestClass(domainPath)
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/fileSD.py", line 179, 
> in __init__
> sd.StorageDomainManifest.__init__(self, sdUUID, domaindir, metadata)
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/sd.py", line 332, in 
> __init__
> self._domainLock = self._makeDomainLock()
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/sd.py", line 553, in 
> _makeDomainLock
> domVersion = self.getVersion()
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/sd.py", line 424, in 
> getVersion
> return self.getMetaParam(DMDK_VERSION)
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/sd.py", line 421, in 
> getMetaParam
> return self._metadata[key]
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/persistent.py", line 
> 91, in __getitem__
> return dec(self._dict[key])
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/persistent.py", line 
> 202, in __getitem__
> return self._metadata[key]
> KeyError: 'VERSION'
> 2019-04-09 15:54:07,484-0400 INFO  (jsonrpc/0) [storage.TaskManager.Task] 
> (Task='00c843c2-ab43-4813-9ded-29f6742c33b2') aborting: Task is aborted: 
> u"'VERSION'" - code 100 (task:1181)
> 2019-04-09 15:54:07,484-0400 ERROR (jsonrpc/0) [storage.Dispatcher] FINISH 
> getStorageDomainInfo error='VERSION' (dispatcher:87)
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/dispatcher.py", line 
> 74, in wrapper
> result = ctask.prepare(func, *args, **kwargs)
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 108, in 
> wrapper
> return m(self, *a, **kw)
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 1189, in 
> prepare
> raise self.error
> KeyError: 'VERSION'
> 2019-04-09 15:54:07,484-0400 INFO  (jsonrpc/0) [jsonrpc.JsonRpcServer] RPC 
> call StorageDomain.getInfo failed (error 350) in 0.01 seconds 

[ovirt-users] Re: HE - engine gluster volume - not mounted

[Sahina Bose]

On Tue, Apr 2, 2019 at 8:14 PM Leo David  wrote:
>
> Just to loop in,  i've forgot to hit "Reply all"
>
> I have deleted everything in the engine gluster mount path, unmounted the 
> engine gluster volume ( not deleted the volume ) ,  and started the wizard 
> with "Use already configured storage". I have pointed to use this gluster 
> volume,  volume gets mounted under the correct path, but installation still 
> 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."}

And I guess we don't have the engine logs to look at this?
Is there any way you can access the engine console to check?

>
> On the node's vdsm.log I can continuously see:
> 2019-04-02 13:02:18,832+0100 INFO  (jsonrpc/0) [jsonrpc.JsonRpcServer] RPC 
> call Host.getStats succeeded in 0.03 seconds (__init__:312)
> 2019-04-02 13:02:19,906+0100 INFO  (vmrecovery) [vdsm.api] START 
> getConnectedStoragePoolsList(options=None) from=internal, 
> task_id=769c3983-5160-44e4-b1d8-7ab4e41ddd34 (api:48)
> 2019-04-02 13:02:19,907+0100 INFO  (vmrecovery) [vdsm.api] FINISH 
> getConnectedStoragePoolsList return={'poollist': []} from=internal, 
> task_id=769c3983-5160-44e4-b1d8-7ab4e41ddd34 (api:54)
> 2019-04-02 13:02:19,907+0100 INFO  (vmrecovery) [vds] recovery: waiting for 
> storage pool to go up (clientIF:709)
> 2019-04-02 13:02:21,737+0100 INFO  (periodic/2) [vdsm.api] START 
> repoStats(domains=()) from=internal, 
> task_id=ba12fbc1-0170-41a2-82e6-8ccb05ae9e09 (api:48)
> 2019-04-02 13:02:21,738+0100 INFO  (periodic/2) [vdsm.api] FINISH repoStats 
> return={} from=internal, task_id=ba12fbc1-0170-41a2-82e6-8ccb05ae9e09 (api:54)
>

Any calls to "START connectStorageServer" in vdsm.log?

> Should I perform an "engine-cleanup",  delete lvms from Cockpit and start it 
> all over ?

I doubt if that would resolve issue since you did clean up files from the mount.

> Did anyone successfully used this particular iso image 
> "ovirt-node-ng-installer-4.3.2-2019031908.el7.iso" for a single node 
> installation ?
Sorry, don't know.

> Thank you !
> Leo
>
> On Tue, Apr 2, 2019 at 1:45 PM Sahina Bose  wrote:
>>
>> Is it possible you have not cleared the gluster volume between installs?
>>
>> What's the corresponding error in vdsm.log?
>>
>>
>> On Tue, Apr 2, 2019 at 4:07 PM Leo David  wrote:
>> >
>> > And there it is the last lines on the ansible_create_storage_domain log:
>> >
>> > 2019-04-02 10:53:49,139+0100 DEBUG var changed: host "localhost" var 
>> > "otopi_storage_domain_details" type "" value: "{
>> > "changed": false,
>> > "exception": "Traceback (most recent call last):\n  File 
>> > \"/tmp/ansible_ovirt_storage_domain_payload_6Jxg5v/__main__.py\", line 
>> > 664, in main\nstorage_domains_module.post_create_check(sd_id)\n  File 
>> > \"/tmp/ansible_ovirt_storage_domain_payload_6Jxg5v/__main__.py\", line 
>> > 526, in post_create_check\nid=storage_domain.id,\n  File 
>> > \"/usr/lib64/python2.7/site-packages/ovirtsdk4/services.py\", line 3053, 
>> > in add\nreturn self._internal_add(storage_domain, headers, query, 
>> > wait)\n  File \"/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py\", 
>> > line 232, in _internal_add\nreturn future.wait() if wait else future\n 
>> >  File \"/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py\", line 
>> > 55, in wait\nreturn self._code(response)\n  File 
>> > \"/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py\", line 229, in 
>> > callback\nself._check_fault(response)\n  File 
>> > \"/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py\", line 132, in 
>> > _check_fault\nself._raise_error(response, body)\n  File 
>> > \"/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py\", line 118, in 
>> > _raise_error\nraise error\nError: Fault reason is \"Operation 
>> > Failed\". Fault detail is \"[]\". HTTP response code is 400.\n",
>> > "failed": true,
>> > "msg": "Fault reason is \"Operation Failed\". Fault detail is \"[]\". 
>> > 

[ovirt-users] Re: HE - engine gluster volume - not mounted

[Sahina Bose]

Is it possible you have not cleared the gluster volume between installs?

What's the corresponding error in vdsm.log?


On Tue, Apr 2, 2019 at 4:07 PM Leo David  wrote:
>
> And there it is the last lines on the ansible_create_storage_domain log:
>
> 2019-04-02 10:53:49,139+0100 DEBUG var changed: host "localhost" var 
> "otopi_storage_domain_details" type "" value: "{
> "changed": false,
> "exception": "Traceback (most recent call last):\n  File 
> \"/tmp/ansible_ovirt_storage_domain_payload_6Jxg5v/__main__.py\", line 664, 
> in main\nstorage_domains_module.post_create_check(sd_id)\n  File 
> \"/tmp/ansible_ovirt_storage_domain_payload_6Jxg5v/__main__.py\", line 526, 
> in post_create_check\nid=storage_domain.id,\n  File 
> \"/usr/lib64/python2.7/site-packages/ovirtsdk4/services.py\", line 3053, in 
> add\nreturn self._internal_add(storage_domain, headers, query, wait)\n  
> File \"/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py\", line 232, 
> in _internal_add\nreturn future.wait() if wait else future\n  File 
> \"/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py\", line 55, in 
> wait\nreturn self._code(response)\n  File 
> \"/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py\", line 229, in 
> callback\nself._check_fault(response)\n  File 
> \"/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py\", line 132, in 
> _check_fault\nself._raise_error(response, body)\n  File 
> \"/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py\", line 118, in 
> _raise_error\nraise error\nError: Fault reason is \"Operation Failed\". 
> Fault detail is \"[]\". HTTP response code is 400.\n",
> "failed": true,
> "msg": "Fault reason is \"Operation Failed\". Fault detail is \"[]\". 
> HTTP response code is 400."
> }"
> 2019-04-02 10:53:49,141+0100 DEBUG var changed: host "localhost" var 
> "ansible_play_hosts" type "" value: "[]"
> 2019-04-02 10:53:49,141+0100 DEBUG var changed: host "localhost" var 
> "play_hosts" type "" value: "[]"
> 2019-04-02 10:53:49,142+0100 DEBUG var changed: host "localhost" var 
> "ansible_play_batch" type "" value: "[]"
> 2019-04-02 10:53:49,142+0100 ERROR ansible failed {'status': 'FAILED', 
> 'ansible_type': 'task', 'ansible_task': u'Activate storage domain', 
> 'ansible_result': u'type: \nstr: {\'_ansible_parsed\': True, 
> u\'exception\': u\'Traceback (most recent call last):\\n  File 
> "/tmp/ansible_ovirt_storage_domain_payload_6Jxg5v/__main__.py", line 664, in 
> main\\nstorage_domains_module.post_create_check(sd_id)\\n  File 
> "/tmp/ansible_ovirt_storage_domain_payload_6Jxg5v/__main__.py", line 526', 
> 'task_duration': 9, 'ansible_host': u'localhost', 'ansible_playbook': 
> u'/usr/share/ovirt-hosted-engine-setup/ansible/trigger_role.yml'}
> 2019-04-02 10:53:49,143+0100 DEBUG ansible on_any args 
>  kwargs 
> ignore_errors:None
> 2019-04-02 10:53:49,148+0100 INFO ansible stats {
> "ansible_playbook": 
> "/usr/share/ovirt-hosted-engine-setup/ansible/trigger_role.yml",
> "ansible_playbook_duration": "01:15 Minutes",
> "ansible_result": "type: \nstr: {u'localhost': 
> {'unreachable': 0, 'skipped': 6, 'ok': 23, 'changed': 0, 'failures': 1}}",
> "ansible_type": "finish",
> "status": "FAILED"
> }
> 2019-04-02 10:53:49,149+0100 INFO SUMMARY:
> DurationTask Name
> 
> [ < 1 sec ] Execute just a specific set of steps
> [  00:02  ] Force facts gathering
> [  00:02  ] Check local VM dir stat
> [  00:02  ] Obtain SSO token using username/password credentials
> [  00:02  ] Fetch host facts
> [  00:01  ] Fetch cluster ID
> [  00:02  ] Fetch cluster facts
> [  00:02  ] Fetch Datacenter facts
> [  00:01  ] Fetch Datacenter ID
> [  00:01  ] Fetch Datacenter name
> [  00:02  ] Add glusterfs storage domain
> [  00:02  ] Get storage domain details
> [  00:02  ] Find the appliance OVF
> [  00:02  ] Parse OVF
> [  00:02  ] Get required size
> [ FAILED  ] Activate storage domain
>
> Any ideea on how to escalate this issue ?
> It just does not make sense to not be able to install from scratch a fresh 
> node...
>
> Have a nice day  !
>
> Leo
>
>
> On Tue, Apr 2, 2019 at 12:11 PM Gobinda Das  wrote:
>>
>> Hi Leo,
>>  Can you please paste "df -Th" and "gluster v status" out put ?
>> Wanted to make sure engine mounted and volumes and bricks are up.
>> What does vdsm log say?
>>
>> On Tue, Apr 2, 2019 at 2:06 PM Leo David  wrote:
>>>
>>> Thank you very much !
>>> I have just installed a new fresh node,   and triggered the single instance 
>>> hyperconverged setup. It seems it fails at the hosted engine final steps of 
>>> deployment:
>>>  INFO ] TASK [ovirt.hosted_engine_setup : Get required size]
>>> [ INFO ] ok: [localhost]
>>> [ INFO ] TASK [ovirt.hosted_engine_setup : Remove unsuitable storage domain]
>>> [ INFO ] skipping: [localhost]
>>> [ INFO ] TASK [ovirt.hosted_engine_setup : Check storage domain free space]
>>> [ 

[ovirt-users] Re: oVirt Survey 2019 results

[Sahina Bose]

On Tue, Apr 2, 2019 at 12:07 PM Sandro Bonazzola 
wrote:

> Thanks to the 143 participants to oVirt Survey 2019!
> The survey is now closed and results are publicly available at
> https://bit.ly/2JYlI7U
> We'll analyze collected data in order to improve oVirt thanks to your
> feedback.
>
> As a first step after reading the results I'd like to invite the 30
> persons who replied they're willing to contribute code to send an email to
> de...@ovirt.org introducing themselves: we'll be more than happy to
> welcome them and helping them getting started.
>
> I would also like to invite the 17 people who replied they'd like to help
> organizing oVirt events in their area to either get in touch with me or
> introduce themselves to users@ovirt.org so we can discuss about events
> organization.
>
> Last but not least I'd like to invite the 38 people willing to contribute
> documentation and the one willing to contribute localization to introduce
> themselves to de...@ovirt.org.
>

Thank you all for the feedback.
I was looking at the feedback specific to Gluster. While it's disheartening
to see "Gluster weakest link in oVirt", I can understand where the feedback
and frustration is coming from.

Over the past month and in this survey, the common themes that have come up
- Ensure smoother upgrades for the hyperconverged deployments with
GlusterFS.  The oVirt 4.3 release with upgrade to gluster 5.3 caused
disruption for many users and we want to ensure this does not happen again.
To this end, we are working on adding upgrade tests to OST based CI .
Contributions are welcome.

- improve performance on gluster storage domain. While we have seen
promising results with gluster 6 release this is an ongoing effort. Please
help this effort with inputs on the specific workloads and usecases that
you run, gathering data and running tests.

- deployment issues. We have worked to improve the deployment flow in 4.3
by adding pre-checks and changing to gluster-ansible role based deployment.
We would love to hear specific issues that you're facing around this -
please raise bugs if you haven't already (
https://bugzilla.redhat.com/enter_bug.cgi?product=cockpit-ovirt)



> Thanks!
> --
>
> SANDRO BONAZZOLA
>
> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>
> Red Hat EMEA 
>
> sbona...@redhat.com
> 
> ___
> 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/4N5DYCXY2S6ZAUI7BWD4DEKZ6JL6MSGN/
>
___
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/BF4TKC2MIROT7QZBHZQITCAHQMQNGZ3Q/

[ovirt-users] Re: Actual size bigger than virtual size

[Sahina Bose]

On Fri, Mar 29, 2019 at 6:02 PM  wrote:
>
> Hi,
>
> Any help?
>
> Thanks
>
> José
>
> 
> From: supo...@logicworks.pt
> To: "users" 
> Sent: Wednesday, March 27, 2019 11:21:41 AM
> Subject: Actual size bigger than virtual size
>
> Hi,
>
> I have an all in one ovirt 4.2.2 with gluster storage and a couple of windows 
> 2012 VMs.
> One w2012 is showing actual size 209GiB and Virtual Size 150 GiB on a thin 
> provision disk. The vm shows 30,9 GB of used space.

I'm not sure I understand. Could you provide output of commands you
ran to clarify? What do you mean when you say vm shows 30,9 GB space -
is that in the UI?

>
> This VM is slower than the others mainly when we reboot the machine it takes 
> around 2 hours.
>
> Any idea?
>
> Thanks
>
>
> --
> 
> Jose Ferradeira
> http://www.logicworks.pt
>
> ___
> 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/XD7HTZCSF3JIAGDBVR5N3DDQSEZJAXIA/
___
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/UE6LULGIHZFNSJSZQBKGRC53DUDCZLQ2/

[ovirt-users] Re: CLUSTER_CANNOT_DISABLE_GLUSTER_WHEN_CLUSTER_CONTAINS_VOLUMES

[Sahina Bose]

On Fri, Mar 29, 2019 at 3:29 AM Arsène Gschwind 
wrote:

> On Thu, 2019-03-28 at 12:18 +, Arsène Gschwind wrote:
>
> On Wed, 2019-03-27 at 12:19 +0530, Sahina Bose wrote:
>
> On Wed, Mar 27, 2019 at 1:59 AM Arsène Gschwind
>
> <
>
> arsene.gschw...@unibas.ch
>
> > wrote:
>
>
> On Tue, 2019-03-26 at 18:09 +0530, Sahina Bose wrote:
>
>
> On Tue, Mar 26, 2019 at 3:00 PM Kaustav Majumder <
>
>
> kmaju...@redhat.com
>
>
>
> wrote:
>
>
>
> Let me rephrase
>
>
>
> On Tue, Mar 26, 2019 at 2:53 PM Arsène Gschwind <
>
>
> arsene.gschw...@unibas.ch
>
>
>
> wrote:
>
>
>
> Hi,
>
>
>
> Thanks for your answer but it seems that this BUG is resolved by oVirt 
> Release 4.3.2 and that's the version I've installed.
>
>
> Any other Idea?
>
>
>
>
> On Tue, 2019-03-26 at 12:59 +0530, Kaustav Majumder wrote:
>
>
>
> Hi,
>
>
> We have this since
>
>
> https://gerrit.ovirt.org/#/c/97365/
>
>
>
>
>
> this patch included the validator to disallow  disabling gluster when volumes 
> are present, hence you won't be able to do it currently.
>
>
>
> for bug :
>
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1589512
>
>
>
>  where volumes are present in the cluster.
>
>
>
> On Tue, Mar 26, 2019 at 12:46 PM Arsène Gschwind <
>
>
> arsene.gschw...@unibas.ch
>
>
>
> wrote:
>
>
>
> Any Idea about this?
>
>
>
> Is the "Enable Gluster Service" unchecked on your cluster?
>
>
> Looks like it see this value as disabled but there are gluster volumes
>
>
> being managed on the cluster?
>
>
> Yes, the "Enable Gluster Service" is unchecked ( I didn't realize this), this 
> must be happen during update from 4.2.8 to 4.3.2, it was definitively checked 
> before the upgrade.
>
> It is grayed out, is there a way to enable it again, I'm running a 
> hyperconverged installation on gluster volumes.
>
>
> The only case where this would be grayed out is if the install is
>
> running with "AllowClusterWithVirtGlusterEnabled" set to false
>
> You can check the value of option_name
>
> "AllowClusterWithVirtGlusterEnabled" by running
>
> #engine-config -g AllowClusterWithVirtGlusterEnabled - on the host
>
> running ovirt-engine
>
> This should be true to indicate cluster supports both gluster and virt
>
> services. Please change to true if false
>
>
> But I do wonder how it changed if it did.
>
> I've checked this setting and it's set to true
>
> # engine-config -g AllowClusterWithVirtGlusterEnabled
>
> AllowClusterWithVirtGlusterEnabled: true version: general
>
>
> And here a screenshot about the settings in the Admin Portal.
>
>
>
> I'm definitively sure the Enable Cluster Service was checked before since
> this environment was setup initially as hyperconverged and is running on
> gluster since then.
>
> Thanks,
> Arsene
>
> Additionally I'm not able to change any of the Cluster settings, doing
> will end with the same error.
> Is there a way to debug/resolve that problem?
>
Could you raise a bug to track?

Kaustav, can you take a look at this issue?


> Thanks a lot,
> Arsene
>
>
>
> Thanks
>
>
>
>
> rgds,
>
>
> Arsene
>
>
> On Wed, 2019-03-20 at 13:45 +, Arsène Gschwind wrote:
>
>
>
> Hi,
>
>
>
> I updated ou oVirt cluster to 4.3.2 and when i try to update the cluster 
> version to 4.3 i get the following error:
>
>
> CLUSTER_CANNOT_DISABLE_GLUSTER_WHEN_CLUSTER_CONTAINS_VOLUMES
>
>
>
> So far I remember I could update the cluster version to 4.2 without having to 
> stop everything.
>
>
> I've searched around about this error but couldn't find anything.
>
>
>
> The engine log says:
>
>
>
> 2019-03-20 14:33:28,125+01 INFO  
> [org.ovirt.engine.core.bll.UpdateClusterCommand] (default task-59) 
> [c93c7f4f-b9a3-4e10-82bf-f8bbda46cc87] Lock Acquired to object 
> 'EngineLock:{exclusiveLocks='[25682477-0bd2-4303-a5fd-0ae9adfd276c=TEMPLATE]',
>  sharedLocks='[119fad69-b4a2-441f-9056-354cd1b8a7aa=VM, 
> 1f696eca-c0a0-48ff-8aa9-b977345b5618=VM, 
> 95ee485d-7992-45b8-b1be-256223b5a89f=VM, 
> 432ed647-c150-425e-aac7-3cb5410f4bc8=VM, 
> 7c2646b1-8a4c-4618-b3c9-dfe563f29e00=VM, 
> 629e40c0-e83b-47e0-82bc-df42ec310ca4=VM, 
> 2e0741bd-33e2-4a8e-9624-a9b7bb70b664=VM, 
> 136d0ca0-478c-48d9-9af4-530f98ac30fd=VM, 
> dafaa8d2-c60c-44c8-b9a3-2b5f80f5aee3=VM, 
> 2112902c-ed42-4fbb-a187-167a5f5a446c=VM, 
> 5330b948-f0cd-4b2f-b722-28918f59c5ca=VM, 
> 3f06be8c-8af9-45e2-91b

[ovirt-users] Re: Gluster VM image Resync Time

[Sahina Bose]

On Wed, Mar 27, 2019 at 7:40 PM Indivar Nair  wrote:
>
> Hi Strahil,
>
> Ok. Looks like sharding should make the resyncs faster.
>
> I searched for more info on it, but couldn't find much.
> I believe it will still have to compare each shard to determine whether there 
> are any changes that need to be replicated.
> Am I right?

+Krutika Dhananjay
>
> Regards,
>
> Indivar Nair
>
>
>
> On Wed, Mar 27, 2019 at 4:34 PM Strahil  wrote:
>>
>> 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 Nikolov
>>
>> On Mar 27, 2019 08:24, Indivar Nair  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
>>
> ___
> 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/WZW5RRVHFRMAIBUZDUSTXTIF4Z4WW5Y5/
___
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/LBQTGIHCBJHBAKWC6VAR4UBK5K6YLVSG/

[ovirt-users] Re: CLUSTER_CANNOT_DISABLE_GLUSTER_WHEN_CLUSTER_CONTAINS_VOLUMES

[Sahina Bose]

On Wed, Mar 27, 2019 at 1:59 AM Arsène Gschwind
 wrote:
>
> On Tue, 2019-03-26 at 18:09 +0530, Sahina Bose wrote:
>
> On Tue, Mar 26, 2019 at 3:00 PM Kaustav Majumder <
>
> kmaju...@redhat.com
>
> > wrote:
>
>
> Let me rephrase
>
>
> On Tue, Mar 26, 2019 at 2:53 PM Arsène Gschwind <
>
> arsene.gschw...@unibas.ch
>
> > wrote:
>
>
> Hi,
>
>
> Thanks for your answer but it seems that this BUG is resolved by oVirt 
> Release 4.3.2 and that's the version I've installed.
>
> Any other Idea?
>
>
>
> On Tue, 2019-03-26 at 12:59 +0530, Kaustav Majumder wrote:
>
>
> Hi,
>
> We have this since
>
> https://gerrit.ovirt.org/#/c/97365/
>
>
>
> this patch included the validator to disallow  disabling gluster when volumes 
> are present, hence you won't be able to do it currently.
>
>
> for bug :
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1589512
>
>  where volumes are present in the cluster.
>
>
> On Tue, Mar 26, 2019 at 12:46 PM Arsène Gschwind <
>
> arsene.gschw...@unibas.ch
>
> > wrote:
>
>
> Any Idea about this?
>
>
> Is the "Enable Gluster Service" unchecked on your cluster?
>
> Looks like it see this value as disabled but there are gluster volumes
>
> being managed on the cluster?
>
> Yes, the "Enable Gluster Service" is unchecked ( I didn't realize this), this 
> must be happen during update from 4.2.8 to 4.3.2, it was definitively checked 
> before the upgrade.
> It is grayed out, is there a way to enable it again, I'm running a 
> hyperconverged installation on gluster volumes.

The only case where this would be grayed out is if the install is
running with "AllowClusterWithVirtGlusterEnabled" set to false
You can check the value of option_name
"AllowClusterWithVirtGlusterEnabled" by running
#engine-config -g AllowClusterWithVirtGlusterEnabled - on the host
running ovirt-engine
This should be true to indicate cluster supports both gluster and virt
services. Please change to true if false

But I do wonder how it changed if it did.

>
> Thanks
>
>
>
> rgds,
>
> Arsene
>
> On Wed, 2019-03-20 at 13:45 +, Arsène Gschwind wrote:
>
>
> Hi,
>
>
> I updated ou oVirt cluster to 4.3.2 and when i try to update the cluster 
> version to 4.3 i get the following error:
>
> CLUSTER_CANNOT_DISABLE_GLUSTER_WHEN_CLUSTER_CONTAINS_VOLUMES
>
>
> So far I remember I could update the cluster version to 4.2 without having to 
> stop everything.
>
> I've searched around about this error but couldn't find anything.
>
>
> The engine log says:
>
>
> 2019-03-20 14:33:28,125+01 INFO  
> [org.ovirt.engine.core.bll.UpdateClusterCommand] (default task-59) 
> [c93c7f4f-b9a3-4e10-82bf-f8bbda46cc87] Lock Acquired to object 
> 'EngineLock:{exclusiveLocks='[25682477-0bd2-4303-a5fd-0ae9adfd276c=TEMPLATE]',
>  sharedLocks='[119fad69-b4a2-441f-9056-354cd1b8a7aa=VM, 
> 1f696eca-c0a0-48ff-8aa9-b977345b5618=VM, 
> 95ee485d-7992-45b8-b1be-256223b5a89f=VM, 
> 432ed647-c150-425e-aac7-3cb5410f4bc8=VM, 
> 7c2646b1-8a4c-4618-b3c9-dfe563f29e00=VM, 
> 629e40c0-e83b-47e0-82bc-df42ec310ca4=VM, 
> 2e0741bd-33e2-4a8e-9624-a9b7bb70b664=VM, 
> 136d0ca0-478c-48d9-9af4-530f98ac30fd=VM, 
> dafaa8d2-c60c-44c8-b9a3-2b5f80f5aee3=VM, 
> 2112902c-ed42-4fbb-a187-167a5f5a446c=VM, 
> 5330b948-f0cd-4b2f-b722-28918f59c5ca=VM, 
> 3f06be8c-8af9-45e2-91bc-9946315192bf=VM, 
> 8cf338bf-8c94-4db4-b271-a85dbc5d6996=VM, 
> c0be6ae6-3d25-4a99-b93d-81b4ecd7c9d7=VM, 
> 8f4acfc6-3bb1-4863-bf97-d7924641b394=VM]'}'
>
>
> 2019-03-20 14:33:28,214+01 WARN  
> [org.ovirt.engine.core.bll.UpdateClusterCommand] (default task-59) 
> [c93c7f4f-b9a3-4e10-82bf-f8bbda46cc87] Validation of action 'UpdateCluster' 
> failed for user @yyy. Reasons: 
> VAR__TYPE__CLUSTER,VAR__ACTION__UPDATE,CLUSTER_CANNOT_DISABLE_GLUSTER_WHEN_CLUSTER_CONTAINS_VOLUMES
>
>
> 2019-03-20 14:33:28,215+01 INFO  
> [org.ovirt.engine.core.bll.UpdateClusterCommand] (default task-59) 
> [c93c7f4f-b9a3-4e10-82bf-f8bbda46cc87] Lock freed to object 
> 'EngineLock:{exclusiveLocks='[25682477-0bd2-4303-a5fd-0ae9adfd276c=TEMPLATE]',
>  sharedLocks='[119fad69-b4a2-441f-9056-354cd1b8a7aa=VM, 
> 1f696eca-c0a0-48ff-8aa9-b977345b5618=VM, 
> 95ee485d-7992-45b8-b1be-256223b5a89f=VM, 
> 432ed647-c150-425e-aac7-3cb5410f4bc8=VM, 
> 7c2646b1-8a4c-4618-b3c9-dfe563f29e00=VM, 
> 629e40c0-e83b-47e0-82bc-df42ec310ca4=VM, 
> 2e0741bd-33e2-4a8e-9624-a9b7bb70b664=VM, 
> 136d0ca0-478c-48d9-9af4-530f98ac30fd=VM, 
> dafaa8d2-c60c-44c8-b9a3-2b5f80f5aee3=VM, 
> 2112902c-ed42-4fbb-a187-167a5f5a446c=VM, 
> 5330b948-f0cd-4b2f-b722-28918f59c5ca=VM, 
> 3f06be8c-8af9-45e2-9

[ovirt-users] Re: VM disk corruption with LSM on Gluster

[Sahina Bose]

+Krutika Dhananjay and gluster ml

On Tue, Mar 26, 2019 at 6:16 PM Sander Hoentjen  wrote:
>
> Hello,
>
> tl;dr We have disk corruption when doing live storage migration on oVirt
> 4.2 with gluster 3.12.15. Any idea why?
>
> We have a 3-node oVirt cluster that is both compute and gluster-storage.
> The manager runs on separate hardware. We are running out of space on
> this volume, so we added another Gluster volume that is bigger, put a
> storage domain on it and then we migrated VM's to it with LSM. After
> some time, we noticed that (some of) the migrated VM's had corrupted
> filesystems. After moving everything back with export-import to the old
> domain where possible, and recovering from backups where needed we set
> off to investigate this issue.
>
> We are now at the point where we can reproduce this issue within a day.
> What we have found so far:
> 1) The corruption occurs at the very end of the replication step, most
> probably between START and FINISH of diskReplicateFinish, before the
> START merge step
> 2) In the corrupted VM, at some place where data should be, this data is
> replaced by zero's. This can be file-contents or a directory-structure
> or whatever.
> 3) The source gluster volume has different settings then the destination
> (Mostly because the defaults were different at creation time):
>
> Setting old(src)  new(dst)
> cluster.op-version  30800 30800 (the same)
> cluster.max-op-version  31202 31202 (the same)
> cluster.metadata-self-heal  off   on
> cluster.data-self-heal  off   on
> cluster.entry-self-heal off   on
> performance.low-prio-threads1632
> performance.strict-o-direct off   on
> network.ping-timeout4230
> network.remote-dio  enableoff
> transport.address-family- inet
> performance.stat-prefetch   off   on
> features.shard-block-size   512MB 64MB
> cluster.shd-max-threads 1 8
> cluster.shd-wait-qlength1024  1
> cluster.locking-scheme  full  granular
> cluster.granular-entry-heal noenable
>
> 4) To test, we migrate some VM's back and forth. The corruption does not
> occur every time. To this point it only occurs from old to new, but we
> don't have enough data-points to be sure about that.
>
> Anybody an idea what is causing the corruption? Is this the best list to
> ask, or should I ask on a Gluster list? I am not sure if this is oVirt
> specific or Gluster specific though.

Do you have logs from old and new gluster volumes? Any errors in the
new volume's fuse mount logs?

>
> Kind regards,
> Sander Hoentjen
> ___
> 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/43E2QYJYDHPYTIU3IFS53WS4WL5OFXUV/
___
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/LIW5BDIKZTJWJOBYPEDHSYPS3E7UCKSY/

[ovirt-users] Re: CLUSTER_CANNOT_DISABLE_GLUSTER_WHEN_CLUSTER_CONTAINS_VOLUMES

[Sahina Bose]

On Tue, Mar 26, 2019 at 3:00 PM Kaustav Majumder  wrote:
>
> Let me rephrase
>
> On Tue, Mar 26, 2019 at 2:53 PM Arsène Gschwind  
> wrote:
>>
>> Hi,
>>
>> Thanks for your answer but it seems that this BUG is resolved by oVirt 
>> Release 4.3.2 and that's the version I've installed.
>> Any other Idea?
>>
>>
>> On Tue, 2019-03-26 at 12:59 +0530, Kaustav Majumder wrote:
>>
>> Hi,
>> We have this since https://gerrit.ovirt.org/#/c/97365/
>
> this patch included the validator to disallow  disabling gluster when volumes 
> are present, hence you won't be able to do it currently.
>>
>> for bug : https://bugzilla.redhat.com/show_bug.cgi?id=1589512 where volumes 
>> are present in the cluster.
>>
>> On Tue, Mar 26, 2019 at 12:46 PM Arsène Gschwind  
>> wrote:
>>
>> Any Idea about this?

Is the "Enable Gluster Service" unchecked on your cluster?
Looks like it see this value as disabled but there are gluster volumes
being managed on the cluster?

>>
>> rgds,
>> Arsene
>> On Wed, 2019-03-20 at 13:45 +, Arsène Gschwind wrote:
>>
>> Hi,
>>
>> I updated ou oVirt cluster to 4.3.2 and when i try to update the cluster 
>> version to 4.3 i get the following error:
>> CLUSTER_CANNOT_DISABLE_GLUSTER_WHEN_CLUSTER_CONTAINS_VOLUMES
>>
>> So far I remember I could update the cluster version to 4.2 without having 
>> to stop everything.
>> I've searched around about this error but couldn't find anything.
>>
>> The engine log says:
>>
>> 2019-03-20 14:33:28,125+01 INFO  
>> [org.ovirt.engine.core.bll.UpdateClusterCommand] (default task-59) 
>> [c93c7f4f-b9a3-4e10-82bf-f8bbda46cc87] Lock Acquired to object 
>> 'EngineLock:{exclusiveLocks='[25682477-0bd2-4303-a5fd-0ae9adfd276c=TEMPLATE]',
>>  sharedLocks='[119fad69-b4a2-441f-9056-354cd1b8a7aa=VM, 
>> 1f696eca-c0a0-48ff-8aa9-b977345b5618=VM, 
>> 95ee485d-7992-45b8-b1be-256223b5a89f=VM, 
>> 432ed647-c150-425e-aac7-3cb5410f4bc8=VM, 
>> 7c2646b1-8a4c-4618-b3c9-dfe563f29e00=VM, 
>> 629e40c0-e83b-47e0-82bc-df42ec310ca4=VM, 
>> 2e0741bd-33e2-4a8e-9624-a9b7bb70b664=VM, 
>> 136d0ca0-478c-48d9-9af4-530f98ac30fd=VM, 
>> dafaa8d2-c60c-44c8-b9a3-2b5f80f5aee3=VM, 
>> 2112902c-ed42-4fbb-a187-167a5f5a446c=VM, 
>> 5330b948-f0cd-4b2f-b722-28918f59c5ca=VM, 
>> 3f06be8c-8af9-45e2-91bc-9946315192bf=VM, 
>> 8cf338bf-8c94-4db4-b271-a85dbc5d6996=VM, 
>> c0be6ae6-3d25-4a99-b93d-81b4ecd7c9d7=VM, 
>> 8f4acfc6-3bb1-4863-bf97-d7924641b394=VM]'}'
>>
>> 2019-03-20 14:33:28,214+01 WARN  
>> [org.ovirt.engine.core.bll.UpdateClusterCommand] (default task-59) 
>> [c93c7f4f-b9a3-4e10-82bf-f8bbda46cc87] Validation of action 'UpdateCluster' 
>> failed for user @yyy. Reasons: 
>> VAR__TYPE__CLUSTER,VAR__ACTION__UPDATE,CLUSTER_CANNOT_DISABLE_GLUSTER_WHEN_CLUSTER_CONTAINS_VOLUMES
>>
>> 2019-03-20 14:33:28,215+01 INFO  
>> [org.ovirt.engine.core.bll.UpdateClusterCommand] (default task-59) 
>> [c93c7f4f-b9a3-4e10-82bf-f8bbda46cc87] Lock freed to object 
>> 'EngineLock:{exclusiveLocks='[25682477-0bd2-4303-a5fd-0ae9adfd276c=TEMPLATE]',
>>  sharedLocks='[119fad69-b4a2-441f-9056-354cd1b8a7aa=VM, 
>> 1f696eca-c0a0-48ff-8aa9-b977345b5618=VM, 
>> 95ee485d-7992-45b8-b1be-256223b5a89f=VM, 
>> 432ed647-c150-425e-aac7-3cb5410f4bc8=VM, 
>> 7c2646b1-8a4c-4618-b3c9-dfe563f29e00=VM, 
>> 629e40c0-e83b-47e0-82bc-df42ec310ca4=VM, 
>> 2e0741bd-33e2-4a8e-9624-a9b7bb70b664=VM, 
>> 136d0ca0-478c-48d9-9af4-530f98ac30fd=VM, 
>> dafaa8d2-c60c-44c8-b9a3-2b5f80f5aee3=VM, 
>> 2112902c-ed42-4fbb-a187-167a5f5a446c=VM, 
>> 5330b948-f0cd-4b2f-b722-28918f59c5ca=VM, 
>> 3f06be8c-8af9-45e2-91bc-9946315192bf=VM, 
>> 8cf338bf-8c94-4db4-b271-a85dbc5d6996=VM, 
>> c0be6ae6-3d25-4a99-b93d-81b4ecd7c9d7=VM, 
>> 8f4acfc6-3bb1-4863-bf97-d7924641b394=VM]'}'
>>
>>
>> Any Idea for the reason of this error?
>>
>> Thanks
>>
>> ___
>>
>> 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/KIPTI7NP2RTZGV4CW57D77G4AG5V2KY4/
>>
>>
>> ___
>>

[ovirt-users] Re: OVirt Gluster Fail

[Sahina Bose]

You will first need to restore connectivity between the gluster peers
for heal to work. So restart glusterd on all hosts as Strahil
mentioned, and check if "gluster peer status" returns the other nodes
as connected. If not, please check the glusterd log to see what's
causing the issue. Share the logs if we need to look at it, along with
the version info


On Sun, Mar 24, 2019 at 1:08 AM Strahil  wrote:
>
> Hi Andrea,
>
> The cluster volumes might have sharding enabled and thus files larger than 
> shard size can be recovered only  via cluster.
>
> You  can try to restart gluster on all nodes and force heal:
> 1. Kill gluster processes:
> systemctl stop glusterd
> /usr/share/glusterfs/scripts/stop-all-gluster-processes.sh
>
> 2. Start gluster:
> systemctl start glusterd
>
> 3. Force heal:
> for i in $(gluster volume list);  do gluster volume heal $i full  ; done
> sleep 300
> for i in $(gluster volume list);  do gluster volume heal $i info summary ; 
> done
>
> Best Regards,
> Strahil Nikolov
>
> On Mar 23, 2019 13:51, commram...@tiscali.it wrote: > > During maintenance of 
> a machine the hosted engine crashed. > At that point there was no more chance 
> of managing anything. > > The VMs have paused, and were no longer manageable. 
> > I restarted the machine, but one point all the bricks were no longer 
> reachable. > > Now I am in a situation where the engine support is no longer 
> loaded. > > The gluster sees the peers connected and the services turned on 
> for the various bricks, but fails to heal the messages that I find for each 
> machine are the following > > # gluster volume heal engine info > Brick 
> 192.170.254.3:/bricks/engine/brick > > . > . > . > > Status: Connected Number 
> of entries: 190 > > Brick 192.170.254.4:/bricks/engine/brick > Status: Il 
> socket di destinazione non è connesso > Number of entries: - > > Brick 
> 192.170.254.6:/bricks/engine/brick > Status: Il socket di destinazione non è 
> connesso > Number of entries: - > > this for all the bricks (some have no 
> heal to do because the machines inside were turned off). > > In practice all 
> the bricks see only localhost as connected. > > How can I restore the 
> machines? > Is there a way to read data from the physical machine and export 
> it so that it can be reused? > Unfortunately we need to access that data. > > 
> Someone can help me. > > Thanks Andrea > 
> ___ > 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/EOIY7ZU4GOEMRUNY3CWF6R3JIQNPHLVA/
>  ___
> 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/NMBDYBOY4TZB37I6O6VYBCVVGM5H3Y3F/
___
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/IUVVKMLEN5NLBCANUHA6QU5FVNXTHUJ6/

[ovirt-users] Re: VM has been paused due to a storage I/O error

[Sahina Bose]

Can you check the gluster mount logs to check if there are storage
related errors.
For the VM that's paused, check which storage domain and gluster
volume the OS disk is on. For instance, if the name of the gluster
volume is data, check the logs under
/var/log/glusterfs/rhev-data-center-mnt-glusterSD-**_data.log

On Thu, Mar 14, 2019 at 12:30 PM xil...@126.com  wrote:
>
> There was a shutdown due to a fault of the physical machine. After shutdown, 
> HostedEngine was suspended. If I try to manually start HostedEngine, I/O 
> error will occur.When I restarted HostedEngine, it was back to normal.
>
> 
> xil...@126.com
>
>
> From: Strahil
> Date: 2019-03-14 14:36
> To: xilazz; Gianluca
> CC: users
> Subject: Re: [ovirt-users] Re: VM has been paused due to a storage I/O error
>
> This should not happen with replica 3  volumes.
> Are you sure you don't have a fluster brick out of sync/disconnected ?
>
> 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/WREBDQWXVGKDCX2SFO7PGLIHRZRIFSM3/
___
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/MTTTBN3PTE3XZM5HQGT5PSAL4D76U5XK/

[ovirt-users] Re: vdsm should decouple with managed glusterfs services

[Sahina Bose]

On Mon, Mar 18, 2019 at 4:15 PM levin  wrote:
>
> Hi Sahina,
>
> My cluster did not enabled fencing, is somewhere I can disable restart policy 
> from vdsm completely? So I can observe this case next time, and giving a fist 
> investigation on unresponsive node.
>
+Martin Perina - do you know if this is possible?

> Regards,
> Levin
>
>
> On 18/3/2019, 17:40, "Sahina Bose"  wrote:
>
> On Sun, Mar 17, 2019 at 12:56 PM  wrote:
> >
> > Hi, I had experience two time of 3-node hyper-converged 4.2.8 ovirt 
> cluster total outage due to vdsm reactivate the unresponsive node, and cause 
> the multiple glusterfs daemon restart. As a result, all VM was paused and 
> some of disk image was corrupted.
> >
> > At the very beginning, one of the ovirt node was overloaded due to high 
> memory and CPU, the hosted-engine have trouble to collect status from vdsm 
> and mark it as unresponsive and it start migrate the workload to healthy 
> node. However, when it start migrate, second ovirt node being unresponsive 
> where vdsm try reactivate the 1st unresponsive node and restart it's 
> glusterd. So the gluster domain was acquiring the quorum and waiting for 
> timeout.
> >
> > If 1st node reactivation is success and every other node can survive 
> the timeout, it will be an idea case. Unfortunately, the second node cannot 
> pick up the VM being migrated due to gluster I/O timeout, so second node at 
> that moment was marked as unresponsive, and so on... vdsm is restarting the 
> glusterd on the second node which cause disaster. All node are racing on 
> gluster volume self-healing, and i can't mark the cluster as maintenance mode 
> as well. What I can do is try to resume the paused VM via virsh and issue 
> shutdown for each domain, also hard shutdown for un-resumable VM.
> >
> > After number of VM shutdown and wait the gluster healing completed,  
> the cluster state back to normal, and I try to start the VM being manually 
> stopped, most of them can be started normally, but number of VM was crashed 
> or un-startable, instantly I  found the image files of un-startable VM was 
> owned by root(can't explain why), and can be restarted after chmod.  Two of 
> them still cannot start with  "bad volume specification" error. One of them 
> can start to boot loader, but the LVM metadata were lost.
> >
> > The impact was huge when vdsm restart the glusterd without human 
> invention.
>
> Is this even with the fencing policies set for ensuring gluster quorum
> is not lost?
>
> There are 2 policies that you need to enable at the cluster level -
> Skip fencing if Gluster bricks are UP
> Skip fencing if Gluster quorum not met
>
>
> > ___
> > 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/NIPHD7COR5ZBVQROOUU6R4Q45SDFAJ5K/
>
>
>
___
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/Z6OBWXWFMIWILZWEMZLEJNRMHL3VLBDF/

[ovirt-users] Re: vdsm should decouple with managed glusterfs services

[Sahina Bose]

On Sun, Mar 17, 2019 at 12:56 PM  wrote:
>
> Hi, I had experience two time of 3-node hyper-converged 4.2.8 ovirt cluster 
> total outage due to vdsm reactivate the unresponsive node, and cause the 
> multiple glusterfs daemon restart. As a result, all VM was paused and some of 
> disk image was corrupted.
>
> At the very beginning, one of the ovirt node was overloaded due to high 
> memory and CPU, the hosted-engine have trouble to collect status from vdsm 
> and mark it as unresponsive and it start migrate the workload to healthy 
> node. However, when it start migrate, second ovirt node being unresponsive 
> where vdsm try reactivate the 1st unresponsive node and restart it's 
> glusterd. So the gluster domain was acquiring the quorum and waiting for 
> timeout.
>
> If 1st node reactivation is success and every other node can survive the 
> timeout, it will be an idea case. Unfortunately, the second node cannot pick 
> up the VM being migrated due to gluster I/O timeout, so second node at that 
> moment was marked as unresponsive, and so on... vdsm is restarting the 
> glusterd on the second node which cause disaster. All node are racing on 
> gluster volume self-healing, and i can't mark the cluster as maintenance mode 
> as well. What I can do is try to resume the paused VM via virsh and issue 
> shutdown for each domain, also hard shutdown for un-resumable VM.
>
> After number of VM shutdown and wait the gluster healing completed,  the 
> cluster state back to normal, and I try to start the VM being manually 
> stopped, most of them can be started normally, but number of VM was crashed 
> or un-startable, instantly I  found the image files of un-startable VM was 
> owned by root(can't explain why), and can be restarted after chmod.  Two of 
> them still cannot start with  "bad volume specification" error. One of them 
> can start to boot loader, but the LVM metadata were lost.
>
> The impact was huge when vdsm restart the glusterd without human invention.

Is this even with the fencing policies set for ensuring gluster quorum
is not lost?

There are 2 policies that you need to enable at the cluster level -
Skip fencing if Gluster bricks are UP
Skip fencing if Gluster quorum not met


> ___
> 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/NIPHD7COR5ZBVQROOUU6R4Q45SDFAJ5K/
___
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/WL3F7PLMAGUBX6VFYKFRJE6YHWAQHFHU/

[ovirt-users] Re: alertMessage, [Warning! Low confirmed free space on gluster volume M2Stick1]

[Sahina Bose]

+Denis Chapligin

On Wed, Mar 6, 2019 at 2:03 PM Robert O'Kane  wrote:
>
> Hello,
>
> With my first "in Ovirt" made Gluster Storage I am getting some annoying 
> Warnings.
>
> On the Hypervisor(s) engine.log :
>
> 2019-03-05 13:07:45,281+01 INFO  
> [org.ovirt.engine.core.vdsbroker.gluster.GetGlusterVolumeAdvancedDetailsVDSCommand]
>  (DefaultQuartzScheduler5) [59957167] START,
> GetGlusterVolumeAdvancedDetailsVDSCommand(HostName = Hausesel3, 
> GlusterVolumeAdvancedDetailsVDSParameters:{hostId='d7db584e-03e3-4a37-abc7-73012a9f5ba8',
> volumeName='M2Stick1'}), log id: 74482de6
> 2019-03-05 13:07:46,814+01 INFO  
> [org.ovirt.engine.core.bll.lock.InMemoryLockManager] 
> (DefaultQuartzScheduler10) [6d40c5d0] Failed to acquire lock and wait lock
> 'EngineLock:{exclusiveLocks='[27f8ed93-c857-41ae-af16-e1af9f0b62d4=GLUSTER]', 
> sharedLocks=''}'
> 2019-03-05 13:07:46,823+01 INFO  
> [org.ovirt.engine.core.vdsbroker.gluster.GetGlusterVolumeAdvancedDetailsVDSCommand]
>  (DefaultQuartzScheduler5) [59957167]
> FINISH, GetGlusterVolumeAdvancedDetailsVDSCommand, return: 
> org.ovirt.engine.core.common.businessentities.gluster.GlusterVolumeAdvancedDetails@868edb00,
>  log id:
> 74482de6
>
>
> I find no other correlated messages in the Gluster logs.  Where else should I 
> look?
>
> It (seems) to work very well. Just these "Warnings" which only worry me due 
> to the "Failed to acquire lock" messages.
> This is one of 3 Gluster Storage Domains. The other 2 were "Hand made" and 
> exist since Ovirt-3.5 and show no messages.
>
>
> 1x standalone engine
> 6x Hypervisors  in 2 clusters.
>
> One other special condition:
>
> I am in the processes of moving my VM's to a second cluster (same Data 
> Center) with a different defined Gluster Network. (New 10Gb cards).
> All Hypervisors see all Networks. but since there is only one SPM, the SPM is 
> never a "Gluster Peer" of all Domains due to
> the "only one Gluster Network per Cluster" definition.  Is this the 
> Problem/Situation?
> There is another "Hand Made" Domain in the new Cluster but it does not have 
> any problems.  The only difference between the two is that the
> new Domain was created over the Ovirt Web interface.
>
> Cheers,
>
> Robert O'Kane
>
>
>
> engine:
>
> libgovirt-0.3.4-1.el7.x86_64
> libvirt-bash-completion-4.5.0-10.el7_6.4.x86_64
> libvirt-client-4.5.0-10.el7_6.4.x86_64
> libvirt-daemon-4.5.0-10.el7_6.4.x86_64
> libvirt-daemon-driver-interface-4.5.0-10.el7_6.4.x86_64
> libvirt-daemon-driver-network-4.5.0-10.el7_6.4.x86_64
> libvirt-daemon-driver-nodedev-4.5.0-10.el7_6.4.x86_64
> libvirt-daemon-driver-nwfilter-4.5.0-10.el7_6.4.x86_64
> libvirt-daemon-driver-qemu-4.5.0-10.el7_6.4.x86_64
> libvirt-daemon-driver-secret-4.5.0-10.el7_6.4.x86_64
> libvirt-daemon-driver-storage-4.5.0-10.el7_6.4.x86_64
> libvirt-daemon-driver-storage-core-4.5.0-10.el7_6.4.x86_64
> libvirt-daemon-driver-storage-disk-4.5.0-10.el7_6.4.x86_64
> libvirt-daemon-driver-storage-gluster-4.5.0-10.el7_6.4.x86_64
> libvirt-daemon-driver-storage-iscsi-4.5.0-10.el7_6.4.x86_64
> libvirt-daemon-driver-storage-logical-4.5.0-10.el7_6.4.x86_64
> libvirt-daemon-driver-storage-mpath-4.5.0-10.el7_6.4.x86_64
> libvirt-daemon-driver-storage-rbd-4.5.0-10.el7_6.4.x86_64
> libvirt-daemon-driver-storage-scsi-4.5.0-10.el7_6.4.x86_64
> libvirt-daemon-kvm-4.5.0-10.el7_6.4.x86_64
> libvirt-glib-1.0.0-1.el7.x86_64
> libvirt-libs-4.5.0-10.el7_6.4.x86_64
> libvirt-python-4.5.0-1.el7.x86_64
> ovirt-ansible-cluster-upgrade-1.1.10-1.el7.noarch
> ovirt-ansible-disaster-recovery-1.1.4-1.el7.noarch
> ovirt-ansible-engine-setup-1.1.6-1.el7.noarch
> ovirt-ansible-hosted-engine-setup-1.0.2-1.el7.noarch
> ovirt-ansible-image-template-1.1.9-1.el7.noarch
> ovirt-ansible-infra-1.1.10-1.el7.noarch
> ovirt-ansible-manageiq-1.1.13-1.el7.noarch
> ovirt-ansible-repositories-1.1.3-1.el7.noarch
> ovirt-ansible-roles-1.1.6-1.el7.noarch
> ovirt-ansible-shutdown-env-1.0.0-1.el7.noarch
> ovirt-ansible-v2v-conversion-host-1.9.0-1.el7.noarch
> ovirt-ansible-vm-infra-1.1.12-1.el7.noarch
> ovirt-cockpit-sso-0.0.4-1.el7.noarch
> ovirt-engine-4.2.8.2-1.el7.noarch
> ovirt-engine-api-explorer-0.0.2-1.el7.centos.noarch
> ovirt-engine-backend-4.2.8.2-1.el7.noarch
> ovirt-engine-cli-3.6.9.2-1.el7.centos.noarch
> ovirt-engine-dashboard-1.2.4-1.el7.noarch
> ovirt-engine-dbscripts-4.2.8.2-1.el7.noarch
> ovirt-engine-dwh-4.2.4.3-1.el7.noarch
> ovirt-engine-dwh-setup-4.2.4.3-1.el7.noarch
> ovirt-engine-extension-aaa-jdbc-1.1.7-1.el7.centos.noarch
> ovirt-engine-extension-aaa-ldap-1.3.8-1.el7.noarch
> ovirt-engine-extension-aaa-ldap-setup-1.3.8-1.el7.noarch
> ovirt-engine-extensions-api-impl-4.2.8.2-1.el7.noarch
> ovirt-engine-lib-4.2.8.2-1.el7.noarch
> ovirt-engine-metrics-1.1.8.1-1.el7.noarch
> ovirt-engine-restapi-4.2.8.2-1.el7.noarch
> ovirt-engine-sdk-python-3.6.9.1-1.el7.centos.noarch
> ovirt-engine-setup-4.2.8.2-1.el7.noarch
> ovirt-engine-setup-base-4.2.8.2-1.el7.noarch
> ovirt-engine-setup-plugin-ovirt-engine-4.2.8.2-1.el7.noarch
> 

[ovirt-users] Re: "gluster-ansible-roles is not installed on Host" error on Cockpit

[Sahina Bose]

We do have an updated rpm gluster-ansible-roles. +Sachidananda URS

On Sun, Mar 10, 2019 at 7:00 PM Hesham Ahmed  wrote:
>
> sac-gluster-ansible is there and is enabled:
>
> [sac-gluster-ansible]
> enabled=1
> name = Copr repo for gluster-ansible owned by sac
> baseurl = 
> https://copr-be.cloud.fedoraproject.org/results/sac/gluster-ansible/epel-7-$basearch/
> type = rpm-md
> skip_if_unavailable = False
> gpgcheck = 1
> gpgkey = 
> https://copr-be.cloud.fedoraproject.org/results/sac/gluster-ansible/pubkey.gpg
> repo_gpgcheck = 0
> enabled = 1
> enabled_metadata = 1
> includepkgs = ovirt-node-ng-image-update ovirt-node-ng-image
> ovirt-engine-appliance
>
> The issue doesn't appear to be missing packages but package naming.
> There is a package gluster-ansible installed which provides the
> gluster ansible roles:
>
> Installed Packages
> Name: gluster-ansible
> Arch: noarch
> Version : 0.6
> Release : 1
> Size: 56 k
> Repo: installed
> Summary : Ansible roles for GlusterFS deployment and management
> URL : https://github.com/gluster/gluster-ansible
> License : GPLv3
> Description : Collection of Ansible roles for the deploying and
> managing GlusterFS clusters.
>
> I can also confirm that just by changing the package name in the
> app.js as I previously mentioned allows complete HCI deployment and
> gluster volume creation from within Cockpit without any issues.
>
>
> On Sun, Mar 10, 2019 at 2:55 PM Strahil  wrote:
> >
> > Check if you have a repo called sac-gluster-ansible.
> >
> > Best Regards,
> > Strahil NikolovOn Mar 10, 2019 08:21, Hesham Ahmed  
> > wrote:
> > >
> > > On a new 4.3.1 oVirt Node installation, when trying to deploy HCI
> > > (also when trying adding a new gluster volume to existing clusters)
> > > using Cockpit, an error is displayed "gluster-ansible-roles is not
> > > installed on Host. To continue deployment, please install
> > > gluster-ansible-roles on Host and try again". There is no package
> > > named gluster-ansible-roles in the repositories:
> > >
> > > [root@localhost ~]# yum install gluster-ansible-roles
> > > Loaded plugins: enabled_repos_upload, fastestmirror, imgbased-persist,
> > > package_upload, product-id, search-disabled-repos,
> > > subscription-manager, vdsmupgrade
> > > This system is not registered with an entitlement server. You can use
> > > subscription-manager to register.
> > > Loading mirror speeds from cached hostfile
> > > * ovirt-4.3-epel: mirror.horizon.vn
> > > No package gluster-ansible-roles available.
> > > Error: Nothing to do
> > > Uploading Enabled Repositories Report
> > > Cannot upload enabled repos report, is this client registered?
> > >
> > > This is due to check introduced here:
> > > https://gerrit.ovirt.org/#/c/98023/1/dashboard/src/helpers/AnsibleUtil.js
> > >
> > > Changing the line from:
> > > [ "rpm", "-qa", "gluster-ansible-roles" ], { "superuser":"require" }
> > > to
> > > [ "rpm", "-qa", "gluster-ansible" ], { "superuser":"require" }
> > > resolves the issue. The above code snippet is installed at
> > > /usr/share/cockpit/ovirt-dashboard/app.js on oVirt node and can be
> > > patched by running "sed -i 's/gluster-ansible-roles/gluster-ansible/g'
> > > /usr/share/cockpit/ovirt-dashboard/app.js && systemctl restart
> > > cockpit"
> > > ___
> > > 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/243QJOXO2KTWYU5CDH3OC7WJ6Z2EL4CG/
> ___
> 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/WCS3VLTIOW4FF2BXHQQ4AGGJBHXJYXLS/
___
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/4RS5TWNWTFLI642W6RSQR7CA3MUIENHI/

[ovirt-users] Re: gdeployConfig.conf errors (Hyperconverged setup using GUI)

[Sahina Bose]

+Gobinda Das +Dhanjal Parth

On Mon, Mar 11, 2019 at 1:42 AM  wrote:
>
> Hello I am trying to run a Hyperconverged setup "COnfigure gluster storage 
> and ovirt hosted engine", however  I get the following error
>
> __
>  PLAY [gluster_servers] 
> *
>
> TASK [Create LVs with specified size for the VGs] 
> **
> failed: [ovirt01.grupokino.com] (item={u'lv': u'gluster_thinpool_sdb', 
> u'size': u'45GB', u'extent': u'100%FREE', u'vg': u'gluster_vg_sdb'}) => 
> {"changed": false, "item": {"extent": "100%FREE", "lv": 
> "gluster_thinpool_sdb", "size": "45GB", "vg": "gluster_vg_sdb"}, "msg": 
> "lvcreate: metadata/pv_map.c:198: consume_pv_area: Assertion `to_go <= 
> pva->count' failed.\n", "rc": -6}
> to retry, use: --limit @/tmp/tmpwo4SNB/lvcreate.retry
>
> PLAY RECAP 
> *
> ovirt01.grupokino.com  : ok=0changed=0unreachable=0failed=1
> __
>
> I know that oVirt Hosted Engine Setup GUI for "gluster wizard (gluster 
> deployment) does not populate the geodeployConfig.conf file properly 
> (Generated Gdeploy configuration : 
> /var/lib/ovirt-hosted-engine-setup/gdeploy/gdeployConfig.conf) so I have 
> tried to modify it to fit our needs but keep getting the above error 
> everytime.
>
> Any ideas or comments are welcome...Thanks!
>
>
>
>
> My servers are setup with 4x50GB disks, 1 for the OS and the rest for Gluster 
> Hyperconverged setup.
> __
> my gdeployConfig.conf file:
> __
> #gdeploy configuration generated by cockpit-gluster plugin
> [hosts]
> ovirt01.mydomain.com
> ovirt02.mydomain.com
> ovirt03.mydomain.com
>
> [script1:ovirt01.mydomain.com]
> action=execute
> ignore_script_errors=no
> file=/usr/share/gdeploy/scripts/grafton-sanity-check.sh -d sdb,sdc,sdd -h 
> ovirt01.mydomain.com, ovirt02.mydomain.com, ovirt03.mydomain.com
>
> [script1:ovirt02.mydomain.com]
> action=execute
> ignore_script_errors=no
> file=/usr/share/gdeploy/scripts/grafton-sanity-check.sh -d sdb,sdc,sdd -h 
> ovirt01.mydomain.com, ovirt02.mydomain.com, ovirt03.mydomain.com
>
> [script1:ovirt03.mydomain.com]
> action=execute
> ignore_script_errors=no
> file=/usr/share/gdeploy/scripts/grafton-sanity-check.sh -d sdb,sdc,sdd -h 
> ovirt01.mydomain.com, ovirt02.mydomain.com, ovirt03.mydomain.com
>
> [disktype]
> jbod
>
> [diskcount]
> 3
>
> [stripesize]
> 256
>
> [service1]
> action=enable
> service=chronyd
>
> [service2]
> action=restart
> service=chronyd
>
> [shell2]
> action=execute
> command=vdsm-tool configure --force
>
> [script3]
> action=execute
> file=/usr/share/gdeploy/scripts/blacklist_all_disks.sh
> ignore_script_errors=no
>
> [pv1:ovirt01.mydomain.com]
> action=create
> devices=sdb
> ignore_pv_errors=no
>
> [pv1:ovirt02.mydomain.com]
> action=create
> devices=sdb
> ignore_pv_errors=no
>
> [pv1:ovirt03.mydomain.com]
> action=create
> devices=sdb
> ignore_pv_errors=no
>
> [pv2:ovirt01.mydomain.com]
> action=create
> devices=sdc
> ignore_pv_errors=no
>
> [pv2:ovirt02.mydomain.com]
> action=create
> devices=sdc
> ignore_pv_errors=no
>
> [pv2:ovirt03.mydomain.com]
> action=create
> devices=sdc
> ignore_pv_errors=no
>
> [pv3:ovirt01.mydomain.com]
> action=create
> devices=sdd
> ignore_pv_errors=no
>
> [pv3:ovirt02.mydomain.com]
> action=create
> devices=sdd
> ignore_pv_errors=no
>
> [pv3:ovirt03.mydomain.com]
> action=create
> devices=sdd
> ignore_pv_errors=no
>
> [vg1:ovirt01.mydomain.com]
> action=create
> vgname=gluster_vg_sdb
> pvname=sdb
> ignore_vg_errors=no
>
> [vg1:ovirt02.mydomain.com]
> action=create
> vgname=gluster_vg_sdb
> pvname=sdb
> ignore_vg_errors=no
>
> [vg1:ovirt03.mydomain.com]
> action=create
> vgname=gluster_vg_sdb
> pvname=sdb
> ignore_vg_errors=no
>
> [vg2:ovirt01.mydomain.com]
> action=create
> vgname=gluster_vg_sdc
> pvname=sdc
> ignore_vg_errors=no
>
> [vg2:ovirt02.mydomain.com]
> action=create
> vgname=gluster_vg_sdc
> pvname=sdc
> ignore_vg_errors=no
>
> [vg2:ovirt03.mydomain.com]
> action=create
> vgname=gluster_vg_sdc
> pvname=sdc
> ignore_vg_errors=no
>
> [vg3:ovirt01.mydomain.com]
> action=create
> vgname=gluster_vg_sdd
> pvname=sdd
> ignore_vg_errors=no
>
> [vg3:ovirt02.mydomain.com]
> action=create
> vgname=gluster_vg_sdd
> pvname=sdd
> ignore_vg_errors=no
>
> [vg3:ovirt03.mydomain.com]
> action=create
> vgname=gluster_vg_sdd
> pvname=sdd
> ignore_vg_errors=no
>
> [lv1:ovirt01.mydomain.com]
> action=create
> poolname=gluster_thinpool_sdb
> ignore_lv_errors=no
> vgname=gluster_vg_sdb
> lvtype=thinpool
> size=45GB
> poolmetadatasize=3GB
>
> 

[ovirt-users] Re: Advice around ovirt 4.3 / gluster 5.x

[Sahina Bose]

Adding gluster ml

On Mon, Mar 4, 2019 at 7:17 AM Guillaume Pavese
 wrote:
>
> I got that too so upgraded to gluster6-rc0 nit still, this morning one engine 
> brick is down :
>
> [2019-03-04 01:33:22.492206] E [MSGID: 101191] 
> [event-epoll.c:765:event_dispatch_epoll_worker] 0-epoll: Failed to dispatch 
> handler
> [2019-03-04 01:38:34.601381] I [addr.c:54:compare_addr_and_update] 
> 0-/gluster_bricks/engine/engine: allowed = "*", received addr = "10.199.211.5"
> [2019-03-04 01:38:34.601410] I [login.c:110:gf_auth] 0-auth/login: allowed 
> user names: 9e360b5b-34d3-4076-bc7e-ed78e4e0dc01
> [2019-03-04 01:38:34.601421] I [MSGID: 115029] 
> [server-handshake.c:550:server_setvolume] 0-engine-server: accepted client 
> from 
> CTX_ID:f7603ec6-9914-408b-85e6-e64e9844e326-GRAPH_ID:0-PID:300490-HOST:ps-inf-int-kvm-fr-305-210.hostics.fr-PC_NAME:engine-client-0-RECON_NO:-0
>  (version: 6.0rc0) with subvol /gluster_bricks/engine/engine
> [2019-03-04 01:38:34.610400] I [MSGID: 115036] 
> [server.c:498:server_rpc_notify] 0-engine-server: disconnecting connection 
> from 
> CTX_ID:f7603ec6-9914-408b-85e6-e64e9844e326-GRAPH_ID:0-PID:300490-HOST:ps-inf-int-kvm-fr-305-210.hostics.fr-PC_NAME:engine-client-0-RECON_NO:-0
> [2019-03-04 01:38:34.610531] I [MSGID: 101055] 
> [client_t.c:436:gf_client_unref] 0-engine-server: Shutting down connection 
> CTX_ID:f7603ec6-9914-408b-85e6-e64e9844e326-GRAPH_ID:0-PID:300490-HOST:ps-inf-int-kvm-fr-305-210.hostics.fr-PC_NAME:engine-client-0-RECON_NO:-0
> [2019-03-04 01:38:34.610574] E [MSGID: 101191] 
> [event-epoll.c:765:event_dispatch_epoll_worker] 0-epoll: Failed to dispatch 
> handler
> [2019-03-04 01:39:18.520347] I [addr.c:54:compare_addr_and_update] 
> 0-/gluster_bricks/engine/engine: allowed = "*", received addr = "10.199.211.5"
> [2019-03-04 01:39:18.520373] I [login.c:110:gf_auth] 0-auth/login: allowed 
> user names: 9e360b5b-34d3-4076-bc7e-ed78e4e0dc01
> [2019-03-04 01:39:18.520383] I [MSGID: 115029] 
> [server-handshake.c:550:server_setvolume] 0-engine-server: accepted client 
> from 
> CTX_ID:f3be82ea-6340-4bd4-afb3-aa9db432f779-GRAPH_ID:0-PID:300885-HOST:ps-inf-int-kvm-fr-305-210.hostics.fr-PC_NAME:engine-client-0-RECON_NO:-0
>  (version: 6.0rc0) with subvol /gluster_bricks/engine/engine
> [2019-03-04 01:39:19.711947] I [MSGID: 115036] 
> [server.c:498:server_rpc_notify] 0-engine-server: disconnecting connection 
> from 
> CTX_ID:f3be82ea-6340-4bd4-afb3-aa9db432f779-GRAPH_ID:0-PID:300885-HOST:ps-inf-int-kvm-fr-305-210.hostics.fr-PC_NAME:engine-client-0-RECON_NO:-0
> [2019-03-04 01:39:19.712431] I [MSGID: 101055] 
> [client_t.c:436:gf_client_unref] 0-engine-server: Shutting down connection 
> CTX_ID:f3be82ea-6340-4bd4-afb3-aa9db432f779-GRAPH_ID:0-PID:300885-HOST:ps-inf-int-kvm-fr-305-210.hostics.fr-PC_NAME:engine-client-0-RECON_NO:-0
> [2019-03-04 01:39:19.712484] E [MSGID: 101191] 
> [event-epoll.c:765:event_dispatch_epoll_worker] 0-epoll: Failed to dispatch 
> handler
> (END)
>
>
> Guillaume Pavese
> Ingénieur Système et Réseau
> Interactiv-Group
>
>
> On Mon, Mar 4, 2019 at 3:56 AM Endre Karlson  wrote:
>>
>> I have tried bumping to 5.4 now and still getting alot of "Failed 
>> Eventhandler" errors in the logs, any ideas guys?
>>
>> Den søn. 3. mar. 2019 kl. 09:03 skrev Guillaume Pavese 
>> :
>>>
>>> Gluster 5.4 is released but not yet in official repository
>>> If like me you can not wait the official release of Gluster 5.4 with the 
>>> instability bugfixes (planned for around March 12 hopefully), you can use 
>>> the following repository :
>>>
>>> For Gluster 5.4-1 :
>>>
>>> #/etc/yum.repos.d/Gluster5-Testing.repo
>>> [Gluster5-Testing]
>>> name=Gluster5-Testing $basearch
>>> baseurl=https://cbs.centos.org/repos/storage7-gluster-5-testing/os/$basearch/
>>> enabled=1
>>> #metadata_expire=60m
>>> gpgcheck=0
>>>
>>>
>>> If adventurous ;)  Gluster 6-rc0 :
>>>
>>> #/etc/yum.repos.d/Gluster6-Testing.repo
>>> [Gluster6-Testing]
>>> name=Gluster6-Testing $basearch
>>> baseurl=https://cbs.centos.org/repos/storage7-gluster-6-testing/os/$basearch/
>>> enabled=1
>>> #metadata_expire=60m
>>> gpgcheck=0
>>>
>>>
>>> GLHF
>>>
>>> Guillaume Pavese
>>> Ingénieur Système et Réseau
>>> Interactiv-Group
>>>
>>>
>>> On Sun, Mar 3, 2019 at 6:16 AM Endre Karlson  
>>> wrote:

 Hi, should we downgrade / reinstall our cluster? we have a 4 node cluster 
 that's breakin apart daily due to the issues with GlusterFS after 
 upgrading from 4.2.8 that was rock solid. I am wondering why 4.3 was 
 released as a stable version at all?? **FRUSTRATION**

 Endre
 ___
 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: 
 

[ovirt-users] Re: error: "cannot set lock, no free lockspace" (localized)

[Sahina Bose]

Looking at the logs:

In the vdsm log:
2019-02-26 17:07:09,440+0400 ERROR (check/loop) [storage.Monitor]
Error checking path
/rhev/data-center/mnt/glusterSD/ovirtnode1.miac:_vmstore/01f6fd06-9ad1-4957-bcda-df24dc4cc4f5/dom_md/metadata
(monitor:498)
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/vdsm/storage/monitor.py",
line 496, in _pathChecked
delay = result.delay()
  File "/usr/lib/python2.7/site-packages/vdsm/storage/check.py", line
391, in delay
raise exception.MiscFileReadException(self.path, self.rc, self.err)
MiscFileReadException: Internal file read failure:
(u'/rhev/data-center/mnt/glusterSD/ovirtnode1.miac:_vmstore/01f6fd06-9ad1-4957-bcda-df24dc4cc4f5/dom_md/metadata',
1, 'Read timeout')

Does this match the below error (UTC time), from gluster mount log/
07:01:23.040258] W [socket.c:600:__socket_rwv] 0-vmstore-client-1:
readv on 172.16.100.5:49155 failed (No data available)
[2019-02-28 07:01:23.040287] I [MSGID: 114018]
[client.c:2285:client_rpc_notify] 0-vmstore-client-1: disconnected
from vmstore-client-1. Client process will keep trying to connect to
glusterd until brick's port is available

Also, what does the below error translate to in English? I think the
error is to do with storage unavailability during the time. Was there
an issue with network connection during the time?

2019-02-26 17:08:20,271+0400 WARN  (qgapoller/3)
[virt.periodic.VmDispatcher] could not run  at
0x7ff7341cd668> on ['de76aa6c-a211-41de-8d85-7d2821c3980d',
'7a3af2e7-8296-4fe0-ac55-c52a4b1de93f'] (periodic:323)
2019-02-26 17:08:20,823+0400 ERROR (vm/d546add1) [virt.vm]
(vmId='d546add1-126a-4490-bc83-469bab659854') The vm start process
failed (vm:948)
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 877,
in _startUnderlyingVm
self._run()
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2898, in _run
dom.createWithFlags(flags)
  File "/usr/lib/python2.7/site-packages/vdsm/common/libvirtconnection.py",
line 130, in wrapper
ret = f(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/vdsm/common/function.py",
line 92, in wrapper
return func(inst, *args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1099, in
createWithFlags
if ret == -1: raise libvirtError ('virDomainCreateWithFlags()
failed', dom=self)
libvirtError: Не удалось установить блокировку: На устройстве не
осталось свободного места[2019-02-28


On Fri, Mar 1, 2019 at 1:08 PM Mike Lykov  wrote:
>
> 01.03.2019 9:51, Sahina Bose пишет:
> > Any errors in vdsm.log or gluster mount log for this volume?
> >
>
> I cannot find any.
> Here is full logs from one node for that period:
>
> https://yadi.sk/d/BzLBb8VGNEwidw
> file name ovirtnode1-logs-260219.tar.gz
>
> gluster, vdsm logs for all volumes
>
> sanlock client status now (can it contain any useful info for "cannot set 
> lock" error?):
> node without any VMs
>
> [root@ovirtnode5 ~]# sanlock client status
> daemon 165297fa-c9e7-47ec-8949-80f39f52304c.ovirtnode5
> p -1 helper
> p -1 listener
> p -1 status
> s 
> 01f6fd06-9ad1-4957-bcda-df24dc4cc4f5:2:/rhev/data-center/mnt/glusterSD/ovirtnode1.miac\:_vmstore/01f6fd06-9ad1-4957-bcda-df24dc4cc4f5/dom_md/ids:0
> s 
> 64f18bf1-4eb6-4b3e-a216-9681091a3bc7:2:/rhev/data-center/mnt/glusterSD/ovirtnode1.miac\:_data/64f18bf1-4eb6-4b3e-a216-9681091a3bc7/dom_md/ids:0
> s 
> hosted-engine:2:/var/run/vdsm/storage/0571ac7b-a28e-4e20-9cd8-4803e40ec602/1c7d4c4d-4ae4-4743-a61c-1437459dcc14/699eec1d-c713-4e66-8587-27792d9a2b32:0
> s 
> 0571ac7b-a28e-4e20-9cd8-4803e40ec602:2:/rhev/data-center/mnt/glusterSD/ovirtstor1.miac\:_engine/0571ac7b-a28e-4e20-9cd8-4803e40ec602/dom_md/ids:0
>
> node with VMs
>
> [root@ovirtnode1 /]# sanlock client status
> daemon 71784659-0fac-4802-8c0d-0efe3ab977d9.ovirtnode1
> p -1 helper
> p -1 listener
> p 36456 miac_serv2
> p 48024 miac_gitlab_runner
> p 10151
> p 50624 e-l-k.miac
> p 455336 openfire.miac
> p 456445 miac_serv3
> p 458384 debian9_2
> p -1 status
> s 
> 01f6fd06-9ad1-4957-bcda-df24dc4cc4f5:1:/rhev/data-center/mnt/glusterSD/ovirtnode1.miac\:_vmstore/01f6fd06-9ad1-4957-bcda-df24dc4cc4f5/dom_md/ids:0
> s 
> 64f18bf1-4eb6-4b3e-a216-9681091a3bc7:1:/rhev/data-center/mnt/glusterSD/ovirtnode1.miac\:_data/64f18bf1-4eb6-4b3e-a216-9681091a3bc7/dom_md/ids:0
> s 
> hosted-engine:1:/var/run/vdsm/storage/0571ac7b-a28e-4e20-9cd8-4803e40ec602/1c7d4c4d-4ae4-4743-a61c-1437459dcc14/699eec1d-c713-4e66-8587-27792d9a2b32:0
> s 
> 0571ac7b-a28e-4e20-9cd8-4803e40ec602:1:/rhev/data-center/mnt/glusterSD/ovirtstor1.miac\:_engine/0571ac7b-a28e-4e20-9cd8-4803e40ec602/dom_md/ids:0
> r 
> 01f6fd06-9ad1-4957-bcda-df24dc4cc4f5:b19996be-1548-41ad-afe3-1726ee38d368:/rhev/d

[ovirt-users] Re: error: "cannot set lock, no free lockspace" (localized)

[Sahina Bose]

Any errors in vdsm.log or gluster mount log for this volume?

On Wed, Feb 27, 2019 at 1:07 PM Mike Lykov  wrote:
>
>
> Hi all. I have a HCI setup, glusterfs 3.12, ovirt 4.2.7, 4 nodes
>
> Yesterday I see 3 VMs detected by engine as "not responding" (it is marked as 
> HA VMs)
> (it all located on ovirtnode1 server)
> Two of them are restarted by engine on other nodes successfully, but one are 
> not. All get LOCALIZED message like 'cannot set lock: no free space on 
> device'  - what is this ? Why engine get that errors, and why some VMs can 
> restart automatically, some not (but successfully restarted bu user via webui 
> after some pause?)
> Who knows, what are you think? Full engine logs may be uploaded.
>
> from engine.log: start event
> ---
> 2019-02-26 17:04:05,308+04 INFO  
> [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] 
> (EE-ManagedThreadFactory-engineScheduled-Thread-59) [] VM 
> 'd546add1-126a-4490-bc83-469bab659854'(openfire.miac) moved from 'Up' --> 
> 'NotResponding'
> 2019-02-26 17:04:05,865+04 WARN  
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
> (EE-ManagedThreadFactory-engineScheduled-Thread-59) [] EVENT_ID: 
> VM_NOT_RESPONDING(126), VM openfire.miac is not responding.
> 2019-02-26 17:04:05,865+04 INFO  
> [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] 
> (EE-ManagedThreadFactory-engineScheduled-Thread-59) [] VM 
> '7a3af2e7-8296-4fe0-ac55-c52a4b1de93f'(e-l-k.miac) moved from 'Up' --> 
> 'NotResponding'
> 2019-02-26 17:04:05,894+04 WARN  
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
> (EE-ManagedThreadFactory-engineScheduled-Thread-59) [] EVENT_ID: 
> VM_NOT_RESPONDING(126), VM e-l-k.miac is not responding.
> 2019-02-26 17:04:05,895+04 INFO  
> [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] 
> (EE-ManagedThreadFactory-engineScheduled-Thread-59) [] VM 
> 'de76aa6c-a211-41de-8d85-7d2821c3980d'(tsgr-mon) moved from 'Up' --> 
> 'NotResponding'
> 2019-02-26 17:04:05,926+04 WARN  
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
> (EE-ManagedThreadFactory-engineScheduled-Thread-59) [] EVENT_ID: 
> VM_NOT_RESPONDING(126), VM tsgr-mon is not responding.
> ---
> 2019-02-26 17:04:22,237+04 ERROR 
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
> (ForkJoinPool-1-worker-9) [] EVENT_ID: VM_DOWN_ERROR(119), VM openfire.miac 
> is down with error. Exit message: VM has been terminated on the host.
> 
> 2019-02-26 17:04:22,374+04 INFO  [org.ovirt.engine.core.bll.VdsEventListener] 
> (ForkJoinPool-1-worker-9) [] Highly Available VM went down. Attempting to 
> restart. VM Name 'openfire.miac', VM Id 'd546add1-126a-4490-bc83-469bab659854'
> ...
> 2019-02-26 17:04:27,737+04 ERROR 
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
> (EE-ManagedThreadFactory-engineScheduled-Thread-5) [] EVENT_ID: 
> VM_DOWN_ERROR(119), VM openfire.miac is down with error. Exit message: 
> resource busy: Failed to acquire lock: Lease is held by another host.
> ...
> 2019-02-26 17:04:28,350+04 INFO  
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
> (EE-ManagedThreadFactory-engine-Thread-2886073) [] EVENT_ID: 
> VDS_INITIATED_RUN_VM(506), Trying to restart VM openfire.miac on Host 
> ovirtnode6.miac
> 2019-02-26 17:04:31,841+04 ERROR 
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
> (ForkJoinPool-1-worker-2) [] EVENT_ID: VM_DOWN_ERROR(119), VM openfire.miac 
> is down with error. Exit message: resource busy: Failed to acquire lock: 
> Lease is held by another host.
> 2019-02-26 17:04:31,877+04 ERROR 
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
> (EE-ManagedThreadFactory-engine-Thread-2886082) [] EVENT_ID: 
> VDS_INITIATED_RUN_VM_FAILED(507), Failed to restart VM openfire.miac on Host 
> ovirtnode6.miac
> ...
> 2019-02-26 17:04:31,994+04 INFO  
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
> (EE-ManagedThreadFactory-engine-Thread-2886082) [] EVENT_ID: 
> VDS_INITIATED_RUN_VM(506), Trying to restart VM openfire.miac on Host 
> ovirtnode1.miac
> .
> 2019-02-26 17:04:36,054+04 ERROR 
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
> (ForkJoinPool-1-worker-9) [] EVENT_ID: VM_DOWN_ERROR(119), VM openfire.miac 
> is down with error. Exit message: Не удалось установить блокировку: На 
> устройстве не осталось свободного места.
> 2019-02-26 17:04:36,054+04 INFO  
> [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] 
> (ForkJoinPool-1-worker-9) [] add VM 
> 'd546add1-126a-4490-bc83-469bab659854'(openfire.miac) to rerun treatment
> 2019-02-26 17:04:36,091+04 ERROR 
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
> (EE-ManagedThreadFactory-engine-Thread-2886083) [] EVENT_ID: 
> VDS_INITIATED_RUN_VM_FAILED(507), Failed to restart VM openfire.miac on Host 
> ovirtnode1.miac

[ovirt-users] Re: [oVirt 4.3.1-RC2 Test Day] Hyperconverged HE Deployment

[Sahina Bose]

On Wed, Feb 27, 2019 at 4:06 PM Guillaume Pavese
 wrote:
>
> Hi, I tried again today to deploy HE on Gluster with oVirt 4.3.1 RC2 on a 
> clean Nested environment (no precedent deploy attempts to clean before...).
>
> Gluster was deployed without problem from cockpit.
> I then snapshoted my vms before trying to deploy HE both from cockpit, then 
> from cmdline.
> Both attempts failed at the same spot :
>
> [ INFO ] Creating Storage Domain
> [ INFO ] TASK [ovirt.hosted_engine_setup : Execute just a specific set of 
> steps]
> [ INFO ] ok: [localhost]
> [ INFO ] TASK [ovirt.hosted_engine_setup : Force facts gathering]
> [ INFO ] ok: [localhost]
> [ INFO ] TASK [ovirt.hosted_engine_setup : Check local VM dir stat]
> [ INFO ] ok: [localhost]
> [ INFO ] TASK [ovirt.hosted_engine_setup : Enforce local VM dir existence]
> [ INFO ] skipping: [localhost]
> [ INFO ] TASK [ovirt.hosted_engine_setup : include_tasks]
> [ INFO ] ok: [localhost]
> [ INFO ] TASK [ovirt.hosted_engine_setup : Obtain SSO token using 
> username/password credentials]
> [ ERROR ] ConnectionError: Error while sending HTTP request: (7, 'Failed 
> connect to vs-inf-int-ovt-fr-301-210.hostics.fr:443; No route to host')
> [ ERROR ] fatal: [localhost]: FAILED! => {"attempts": 50, "changed": false, 
> "msg": "Error while sending HTTP request: (7, 'Failed connect to 
> vs-inf-int-ovt-fr-301-210.hostics.fr:443; No route to host')"}
> Please specify the storage you would like to use (glusterfs, iscsi, fc, 
> nfs)[nfs]:
>
>
>
> [root@vs-inf-int-kvm-fr-301-210 ~]# traceroute 
> vs-inf-int-ovt-fr-301-210.hostics.fr
> traceroute to vs-inf-int-ovt-fr-301-210.hostics.fr (192.168.122.147), 30 hops 
> max, 60 byte packets
> 1 vs-inf-int-kvm-fr-301-210.hostics.fr (192.168.122.1) 3006.344 ms !H 
> 3006.290 ms !H 3006.275 ms !H
>
>

vs-inf-int-ovt-fr-301-210.hostics.fr is this the HE VM FQDN?
+Simone Tiraboschi
>
>
> Guillaume Pavese
> Ingénieur Système et Réseau
> Interactiv-Group
> ___
> 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/5JEA5726OHI2MTOHEBV3VYAKDNDNSNMJ/
___
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/JLJ4MCD2SMU6WUDZEXSRPM7POIMACK3Z/

[ovirt-users] Re: VM poor iops

[Sahina Bose]

On Wed, Feb 27, 2019 at 11:21 AM Leo David  wrote:
>
> Thank you Sahina, I'm in that conversation too :).
> On the other hand...
> In this case, setting this option on, would only make sense in multi-node 
> setups, and not in single instance ones, where we only have one hypervisor 
> accsessing the volume.
> Please correct me if this is wrong.
> Have a nice day,

In single instance deployments too, the option ensures all writes
(with o-direct flag) are flushed to disk and not cached.
>
> Leo
>
>
> On Tue, Feb 26, 2019, 08:24 Sahina Bose  wrote:
>>
>>
>>
>>
>> On Fri, Sep 14, 2018 at 3:35 PM Paolo Margara  
>> wrote:
>>>
>>> Hi,
>>>
>>> but performance.strict-o-direct is not one of the option enabled by gdeploy 
>>> during installation because it's supposed to give some sort of benefit?
>>
>>
>> See 
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/VS764WDBR2PLGGDZVRGBEM6OJCAFEM3R/
>>  on why the option is set.
>>
>>>
>>> Paolo
>>>
>>>
>>> Il 14/09/2018 11:34, Leo David ha scritto:
>>>
>>> performance.strict-o-direct:  on
>>> This was the bloody option that created the botleneck ! It was ON.
>>> So now i get an average of 17k random writes,  which is not bad at all. 
>>> Below,  the volume options that worked for me:
>>>
>>> performance.strict-write-ordering: off
>>> performance.strict-o-direct: off
>>> server.event-threads: 4
>>> client.event-threads: 4
>>> performance.read-ahead: off
>>> network.ping-timeout: 30
>>> performance.quick-read: off
>>> cluster.eager-lock: enable
>>> performance.stat-prefetch: on
>>> performance.low-prio-threads: 32
>>> network.remote-dio: off
>>> user.cifs: off
>>> performance.io-cache: off
>>> server.allow-insecure: on
>>> features.shard: on
>>> transport.address-family: inet
>>> storage.owner-uid: 36
>>> storage.owner-gid: 36
>>> nfs.disable: on
>>>
>>> If any other tweaks can be done,  please let me know.
>>> Thank you !
>>>
>>> Leo
>>>
>>>
>>> On Fri, Sep 14, 2018 at 12:01 PM, Leo David  wrote:
>>>>
>>>> Hi Everyone,
>>>> So i have decided to take out all of the gluster volume custom options,  
>>>> and add them one by one while activating/deactivating the storage domain & 
>>>> rebooting one vm after each  added option :(
>>>>
>>>> The default options that giving bad iops ( ~1-2k) performance are :
>>>>
>>>> performance.stat-prefetch on
>>>> cluster.eager-lock enable
>>>> performance.io-cache off
>>>> performance.read-ahead off
>>>> performance.quick-read off
>>>> user.cifs off
>>>> network.ping-timeout 30
>>>> network.remote-dio off
>>>> performance.strict-o-direct on
>>>> performance.low-prio-threads 32
>>>>
>>>> After adding only:
>>>>
>>>>
>>>> server.allow-insecure on
>>>> features.shard on
>>>> storage.owner-gid 36
>>>> storage.owner-uid 36
>>>> transport.address-family inet
>>>> nfs.disable on
>>>>
>>>> The performance increased to 7k-10k iops.
>>>>
>>>> The problem is that i don't know if that's sufficient ( maybe it can be 
>>>> more improved ) , or even worse than this there might be chances to into 
>>>> different volume issues by taking out some volume really needed options...
>>>>
>>>> If would have handy the default options that are applied to volumes as 
>>>> optimization in a 3way replica, I think that might help..
>>>>
>>>> Any thoughts ?
>>>>
>>>> Thank you very much !
>>>>
>>>>
>>>> Leo
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Sep 14, 2018 at 8:54 AM, Leo David  wrote:
>>>>>
>>>>> Any thoughs on these ? Is that UI optimization only a gluster volume 
>>>>> custom configuration ? If so, i guess it can be done from cli, but I am 
>>>>> not aware of the corect optimized parameters of the volume
>>>>>
>>>>>
>>>>> On Thu, Sep 13, 2018, 18:25 Leo David  wrote:
>>>>>>
>>>>>> Thank you Jayme. I am trying

[ovirt-users] Re: VM poor iops

[Sahina Bose]

On Fri, Sep 14, 2018 at 3:35 PM Paolo Margara 
wrote:

> Hi,
>
> but performance.strict-o-direct is not one of the option enabled by
> gdeploy during installation because it's supposed to give some sort of
> benefit?
>

See
https://lists.ovirt.org/archives/list/users@ovirt.org/message/VS764WDBR2PLGGDZVRGBEM6OJCAFEM3R/
on why the option is set.


> Paolo
>
> Il 14/09/2018 11:34, Leo David ha scritto:
>
> performance.strict-o-direct:  on
> This was the bloody option that created the botleneck ! It was ON.
> So now i get an average of 17k random writes,  which is not bad at all.
> Below,  the volume options that worked for me:
>
> performance.strict-write-ordering: off
> performance.strict-o-direct: off
> server.event-threads: 4
> client.event-threads: 4
> performance.read-ahead: off
> network.ping-timeout: 30
> performance.quick-read: off
> cluster.eager-lock: enable
> performance.stat-prefetch: on
> performance.low-prio-threads: 32
> network.remote-dio: off
> user.cifs: off
> performance.io-cache: off
> server.allow-insecure: on
> features.shard: on
> transport.address-family: inet
> storage.owner-uid: 36
> storage.owner-gid: 36
> nfs.disable: on
>
> If any other tweaks can be done,  please let me know.
> Thank you !
>
> Leo
>
>
> On Fri, Sep 14, 2018 at 12:01 PM, Leo David  wrote:
>
>> Hi Everyone,
>> So i have decided to take out all of the gluster volume custom options,
>> and add them one by one while activating/deactivating the storage domain &
>> rebooting one vm after each  added option :(
>>
>> The default options that giving bad iops ( ~1-2k) performance are :
>>
>> performance.stat-prefetch on
>> cluster.eager-lock enable
>> performance.io-cache off
>> performance.read-ahead off
>> performance.quick-read off
>> user.cifs off
>> network.ping-timeout 30
>> network.remote-dio off
>> performance.strict-o-direct on
>> performance.low-prio-threads 32
>>
>> After adding only:
>>
>>
>> server.allow-insecure on
>> features.shard on
>> storage.owner-gid 36
>> storage.owner-uid 36
>> transport.address-family inet
>> nfs.disable on
>> The performance increased to 7k-10k iops.
>>
>> The problem is that i don't know if that's sufficient ( maybe it can be
>> more improved ) , or even worse than this there might be chances to into
>> different volume issues by taking out some volume really needed options...
>>
>> If would have handy the default options that are applied to volumes as
>> optimization in a 3way replica, I think that might help..
>>
>> Any thoughts ?
>>
>> Thank you very much !
>>
>>
>> Leo
>>
>>
>>
>>
>>
>> On Fri, Sep 14, 2018 at 8:54 AM, Leo David  wrote:
>>
>>> Any thoughs on these ? Is that UI optimization only a gluster volume
>>> custom configuration ? If so, i guess it can be done from cli, but I am not
>>> aware of the corect optimized parameters of the volume
>>>
>>>
>>> On Thu, Sep 13, 2018, 18:25 Leo David  wrote:
>>>
 Thank you Jayme. I am trying to do this, but I am getting an error,
 since the volume is replica 1 distribute, and it seems that oVirt expects a
 replica 3 volume.
 Would it be another way to optimize the volume in this situation ?


 On Thu, Sep 13, 2018, 17:49 Jayme  wrote:

> I had similar problems until I clicked "optimize volume for vmstore"
> in the admin GUI for each data volume.  I'm not sure if this is what is
> causing your problem here but I'd recommend trying that first.  It is
> suppose to be optimized by default but for some reason my ovirt 4.2 
> cockpit
> deploy did not apply those settings automatically.
>
> On Thu, Sep 13, 2018 at 10:21 AM Leo David  wrote:
>
>> Hi Everyone,
>> I am encountering the following issue on a single instance
>> hyper-converged 4.2 setup.
>> The following fio test was done:
>>
>> fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1
>> --name=test --filename=test --bs=4k --iodepth=64 --size=4G
>> --readwrite=randwrite
>> The results are very poor doing the test inside of a vm with a
>> prealocated disk on the ssd store:  ~2k IOPS
>> Same test done on the oVirt node directly on the mounted ssd_lvm:
>> ~30k IOPS
>> Same test done, this time on the gluster mount path: ~20K IOPS
>>
>> What could be the issue that the vms have this slow hdd performance (
>> 2k on ssd !! )?
>> Thank you very much !
>>
>>
>>
>>
>> --
>> Best regards, Leo David
>> ___
>> 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/FCCIZFRWINWWLQSYWRPF6HNKPQMZB2XP/
>>
>
>>
>>
>> --
>> Best regards, Leo David
>>
>
>
>
> --
> Best 

[ovirt-users] Re: Problem deploying self-hosted engine on ovirt 4.3.0

[Sahina Bose]

On Mon, Feb 25, 2019 at 2:51 PM matteo fedeli  wrote:
>
> oh, ovirt-engine-appliance where I can found?

ovirt-engine-appliance rpm is present in the oVirt repo
(https://resources.ovirt.org/pub/ovirt-4.3/rpm/el7/x86_64/ for 4.3)
>
> At the end I wait in total 3 hour (is not too much?) and the deploy arrived 
> almost at the end but in the last step i get this error:
> http://oi64.tinypic.com/312yfev.jpg. To retry i do 
> /usr/sbin/ovirt-hosted-engine-cleanup and cleaned engine folder... I add that 
> I seen varius skipping...
>
> But now I get this: http://oi64.tinypic.com/kbpxzl.jpg. Before the second 
> deploy the node status and gluster was all ok...

The error seems to indicate that you do not have enough space in /var/tmp

> ___
> 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/67G4NISLNTKKW6QIJADAZ5GXH2ZHZXG2/
___
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/JQCDSOVJLWQUPSSD5WYKKHQTLDOYSMAP/

[ovirt-users] Re: Expand existing gluster storage in ovirt 4.2/4.3

[Sahina Bose]

On Thu, Feb 21, 2019 at 8:47 PM  wrote:
>
> Hello,
> I have a 3 node ovirt 4.3 cluster that I've setup and using gluster 
> (Hyperconverged setup)
> I need to increase the amount of storage and compute so I added a 4th host 
> (server4.example.com) if it is possible to expand the amount of bricks 
> (storage) in the "data" volume?
>
> I did some research and from that research the following caught my eye: old 
> post 
> "https://medium.com/@tumballi/scale-your-gluster-cluster-1-node-at-a-time-62dd6614194e;
> So the question is, if taking that approach feasible? , is it even possible 
> an oVirt point of view?
>

Expanding by 1 node is only possible if you have sufficient space on
the existing nodes in order to create a replica 2 + arbiter volume.
The post talks of how you can create your volumes in a way that you
can move the bricks around so that the each of the bricks in a replica
set reside on a separate server. We do not have an automatic way to
provision and rebalance the bricks yet in order to expand by 1 node.

>
>
> ---
> My gluster volume:
> ---
> Volume Name: data
> Type: Replicate
> Volume ID: 003ffea0-b441-43cb-a38f-ccdf6ffb77f8
> Status: Started
> Snapshot Count: 0
> Number of Bricks: 1 x (2 + 1) = 3
> Transport-type: tcp
> Bricks:
> Brick1: server1.example1.com:/gluster_bricks/data/data
> Brick2: server2.example.com:/gluster_bricks/data/data
> Brick3: server3.example.com:/gluster_bricks/data/data (arbiter)
> Options Reconfigured:
> cluster.granular-entry-heal: enable
> performance.strict-o-direct: on
> network.ping-timeout: 30
> storage.owner-gid: 36
> storage.owner-uid: 36
> cluster.choose-local: off
> user.cifs: off
> features.shard: on
> cluster.shd-wait-qlength: 1
> cluster.shd-max-threads: 8
> cluster.locking-scheme: granular
> cluster.data-self-heal-algorithm: full
> cluster.server-quorum-type: server
> cluster.quorum-type: auto
> cluster.eager-lock: enable
> network.remote-dio: enable
> performance.low-prio-threads: 32
> performance.io-cache: off
> performance.read-ahead: off
> performance.quick-read: off
> transport.address-family: inet
> nfs.disable: on
> performance.client-io-threads: off
>
>
> Thanks.
> ___
> 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/HKPAM65CSDJ7LQTZTAUQSBDOFDZM7RQS/
___
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/4NNGYOLCFJ4SN2QEO34TSWYGSKBVGEL2/

[ovirt-users] Re: Stuck completing last step of 4.3 upgrade

[Sahina Bose]

On Thu, Feb 21, 2019 at 11:11 PM Jason P. Thomas  wrote:
>
> On 2/20/19 5:33 PM, Darrell Budic wrote:
>
> I was just helping Tristam on #ovirt with a similar problem, we found that 
> his two upgraded nodes were running multiple glusterfsd processes per brick 
> (but not all bricks). His volume & brick files in /var/lib/gluster looked 
> normal, but starting glusterd would often spawn extra fsd processes per 
> brick, seemed random. Gluster bug? Maybe related to  
> https://bugzilla.redhat.com/show_bug.cgi?id=1651246, but I’m helping debug 
> this one second hand… Possibly related to the brick crashes? We wound up 
> stopping glusterd, killing off all the fsds, restarting glusterd, and 
> repeating until it only spawned one fsd per brick. Did that to each updated 
> server, then restarted glusterd on the not-yet-updated server to get it 
> talking to the right bricks. That seemed to get to a mostly stable gluster 
> environment, but he’s still seeing 1-2 files listed as needing healing on the 
> upgraded bricks (but not the 3.12 brick). Mainly the DIRECT_IO_TEST and one 
> of the dom/ids files, but he can probably update that. Did manage to get his 
> engine going again, waiting to see if he’s stable now.
>
> Anyway, figured it was worth posting about so people could check for multiple 
> brick processes (glusterfsd) if they hit this stability issue as well, maybe 
> find common ground.
>
> Note: also encountered https://bugzilla.redhat.com/show_bug.cgi?id=1348434 
> trying to get his engine back up, restarting libvirtd let us get it going 
> again. Maybe un-needed if he’d been able to complete his third node upgrades, 
> but he got stuck before then, so...
>
>   -Darrell
>
> Stable is a relative term.  My unsynced entries total for each of my 4 
> volumes changes drastically (with the exception of the engine volume, it 
> pretty much bounces between 1 and 4).  The cluster has been "healing" for 18 
> hours or so and only the unupgraded HC node has healed bricks.  I did have 
> the problem that some files/directories were owned by root:root.  These VMs 
> did not boot until I changed ownership to 36:36.  Even after 18 hours, 
> there's anywhere from 20-386 entries in vol heal info for my 3 non engine 
> bricks.  Overnight I had one brick on one volume go down on one HC node.  
> When I bounced glusterd, it brought up a new fsd process for that brick.  I 
> killed the old one and now vol status reports the right pid on each of the 
> nodes.  This is quite the debacle.  If I can provide any info that might help 
> get this debacle moving in the right direction, let me know.

Can you provide the gluster brick logs and glusterd logs from the
servers (from /var/log/glusterfs/). Since you mention that heal seems
to be stuck, could you also provide the heal logs from
/var/log/glusterfs/glustershd.log
If you can log a bug with these logs, that would be great - please use
https://bugzilla.redhat.com/enter_bug.cgi?product=GlusterFS to log the
bug.


>
> Jason aka Tristam
>
>
> On Feb 14, 2019, at 1:12 AM, Sahina Bose  wrote:
>
> On Thu, Feb 14, 2019 at 2:39 AM Ron Jerome  wrote:
>
>
>
>
> Can you be more specific? What things did you see, and did you report bugs?
>
>
> I've got this one: https://bugzilla.redhat.com/show_bug.cgi?id=1649054
> and this one: https://bugzilla.redhat.com/show_bug.cgi?id=1651246
> and I've got bricks randomly going offline and getting out of sync with the 
> others at which point I've had to manually stop and start the volume to get 
> things back in sync.
>
>
> Thanks for reporting these. Will follow up on the bugs to ensure
> they're addressed.
> Regarding brciks going offline - are the brick processes crashing? Can
> you provide logs of glusterd and bricks. Or is this to do with
> ovirt-engine and brick status not being in sync?
>
> ___
> 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/3RVMLCRK4BWCSBTWVXU2JTIDBWU7WEOP/
>
> ___
> 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/4PKJSVDIH3V4H7Q2RKS2C4ZUMWDODQY6/
>
>
>
> _

[ovirt-users] Re: Ovirt 4.2.8.. Possible bug?

[Sahina Bose]

This looks like a bug, if you selected jbod but is not reflected in
the generated gdeploy config file. +Gobinda Das ?

On Fri, Feb 22, 2019 at 8:59 PM Sandro Bonazzola  wrote:
>
>
>
> Il ven 22 feb 2019, 15:31 matteo fedeli  ha scritto:
>>
>> sorry, but I don't understand...
>
>
>
> I added to the discussion an engineer that may be able to help you.
>
>
>> ___
>> 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/EVCRSE7EOWJPGFYHIJUDFYQY5RARGYTR/
>
> ___
> 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/OLF5MMINOOCHZHDDZZDR5ECTF3A3ZGJL/
___
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/UDBQBASLR5PVSILAMQPGWSOKHSSC7YU2/

[ovirt-users] Re: Gluster setup Problem

[Sahina Bose]

+Gobinda Das +Dhanjal Parth can you please check?

On Fri, Feb 22, 2019 at 11:52 PM Matthew Roth  wrote:
>
> I have 3 servers,  Node 1 is 3tb /dev/sda, Node 2, 3tb /dev/sdb,  node3 3tb 
> /dev/sdb
>
> I start the process for gluster deployment. I change node 1 to sda and all 
> the other ones to sdb. I get no errors however,
>
> when I get to
> Creating physical Volume all it does is spin forever . doesnt get any 
> further. I can leave it there for 5 hours and doesn't go anywhere.
>
> #gdeploy configuration generated by cockpit-gluster plugin
> [hosts]
> cmdnode1.cmd911.com
> cmdnode2.cmd911.com
> cmdnode3.cmd911.com
>
> [script1:cmdnode1.cmd911.com]
> action=execute
> ignore_script_errors=no
> file=/usr/share/gdeploy/scripts/grafton-sanity-check.sh -d sda -h 
> cmdnode1.cmd911.com, cmdnode2.cmd911.com, cmdnode3.cmd911.com
>
> [script1:cmdnode2.cmd911.com]
> action=execute
> ignore_script_errors=no
> file=/usr/share/gdeploy/scripts/grafton-sanity-check.sh -d sdb -h 
> cmdnode1.cmd911.com, cmdnode2.cmd911.com, cmdnode3.cmd911.com
>
> [script1:cmdnode3.cmd911.com]
> action=execute
> ignore_script_errors=no
> file=/usr/share/gdeploy/scripts/grafton-sanity-check.sh -d sdb -h 
> cmdnode1.cmd911.com, cmdnode2.cmd911.com, cmdnode3.cmd911.com
>
> [disktype]
> raid6
>
> [diskcount]
> 12
>
> [stripesize]
> 256
>
> [service1]
> action=enable
> service=chronyd
>
> [service2]
> action=restart
> service=chronyd
>
> [shell2]
> action=execute
> command=vdsm-tool configure --force
>
> [script3]
> action=execute
> file=/usr/share/gdeploy/scripts/blacklist_all_disks.sh
> ignore_script_errors=no
>
> [pv1:cmdnode1.cmd911.com]
> action=create
> devices=sda
> ignore_pv_errors=no
>
> [pv1:cmdnode2.cmd911.com]
> action=create
> devices=sdb
> ignore_pv_errors=no
>
> [pv1:cmdnode3.cmd911.com]
> action=create
> devices=sdb
> ignore_pv_errors=no
>
> [vg1:cmdnode1.cmd911.com]
> action=create
> vgname=gluster_vg_sda
> pvname=sda
> ignore_vg_errors=no
>
> [vg1:cmdnode2.cmd911.com]
> action=create
> vgname=gluster_vg_sdb
> pvname=sdb
> ignore_vg_errors=no
>
> [vg1:cmdnode3.cmd911.com]
> action=create
> vgname=gluster_vg_sdb
> pvname=sdb
> ignore_vg_errors=no
>
> [lv1:cmdnode1.cmd911.com]
> action=create
> poolname=gluster_thinpool_sda
> ignore_lv_errors=no
> vgname=gluster_vg_sda
> lvtype=thinpool
> size=1005GB
> poolmetadatasize=5GB
>
> [lv2:cmdnode2.cmd911.com]
> action=create
> poolname=gluster_thinpool_sdb
> ignore_lv_errors=no
> vgname=gluster_vg_sdb
> lvtype=thinpool
> size=1005GB
> poolmetadatasize=5GB
>
> [lv3:cmdnode3.cmd911.com]
> action=create
> poolname=gluster_thinpool_sdb
> ignore_lv_errors=no
> vgname=gluster_vg_sdb
> lvtype=thinpool
> size=41GB
> poolmetadatasize=1GB
>
> [lv4:cmdnode1.cmd911.com]
> action=create
> lvname=gluster_lv_engine
> ignore_lv_errors=no
> vgname=gluster_vg_sda
> mount=/gluster_bricks/engine
> size=100GB
> lvtype=thick
>
> [lv5:cmdnode1.cmd911.com]
> action=create
> lvname=gluster_lv_data
> ignore_lv_errors=no
> vgname=gluster_vg_sda
> mount=/gluster_bricks/data
> lvtype=thinlv
> poolname=gluster_thinpool_sda
> virtualsize=500GB
>
> [lv6:cmdnode1.cmd911.com]
> action=create
> lvname=gluster_lv_vmstore
> ignore_lv_errors=no
> vgname=gluster_vg_sda
> mount=/gluster_bricks/vmstore
> lvtype=thinlv
> poolname=gluster_thinpool_sda
> virtualsize=500GB
>
> [lv7:cmdnode2.cmd911.com]
> action=create
> lvname=gluster_lv_engine
> ignore_lv_errors=no
> vgname=gluster_vg_sdb
> mount=/gluster_bricks/engine
> size=100GB
> lvtype=thick
>
> [lv8:cmdnode2.cmd911.com]
> action=create
> lvname=gluster_lv_data
> ignore_lv_errors=no
> vgname=gluster_vg_sdb
> mount=/gluster_bricks/data
> lvtype=thinlv
> poolname=gluster_thinpool_sdb
> virtualsize=500GB
>
> [lv9:cmdnode2.cmd911.com]
> action=create
> lvname=gluster_lv_vmstore
> ignore_lv_errors=no
> vgname=gluster_vg_sdb
> mount=/gluster_bricks/vmstore
> lvtype=thinlv
> poolname=gluster_thinpool_sdb
> virtualsize=500GB
>
> [lv10:cmdnode3.cmd911.com]
> action=create
> lvname=gluster_lv_engine
> ignore_lv_errors=no
> vgname=gluster_vg_sdb
> mount=/gluster_bricks/engine
> size=20GB
> lvtype=thick
>
> [lv11:cmdnode3.cmd911.com]
> action=create
> lvname=gluster_lv_data
> ignore_lv_errors=no
> vgname=gluster_vg_sdb
> mount=/gluster_bricks/data
> lvtype=thinlv
> poolname=gluster_thinpool_sdb
> virtualsize=20GB
>
> [lv12:cmdnode3.cmd911.com]
> action=create
> lvname=gluster_lv_vmstore
> ignore_lv_errors=no
> vgname=gluster_vg_sdb
> mount=/gluster_bricks/vmstore
> lvtype=thinlv
> poolname=gluster_thinpool_sdb
> virtualsize=20GB
>
> [selinux]
> yes
>
> [service3]
> action=restart
> service=glusterd
> slice_setup=yes
>
> [firewalld]
> action=add
> ports=111/tcp,2049/tcp,54321/tcp,5900/tcp,5900-6923/tcp,5666/tcp,16514/tcp,54322/tcp
> services=glusterfs
>
> [script2]
> action=execute
> file=/usr/share/gdeploy/scripts/disable-gluster-hooks.sh
>
> [shell3]
> action=execute
> command=usermod -a -G gluster qemu
>
> [volume1]
> action=create
> volname=engine
> transport=tcp
> replica=yes
> 

[ovirt-users] Re: Ovirt Node 4.3 Gluster Install adding bricks

[Sahina Bose]

On Thu, Feb 21, 2019 at 7:47 PM  wrote:
>
> Sorry if this seems simple, but trial and error is how I learn. So the 
> basics. I installed Node 4.3 on 3 hosts, and was following the setup for 
> self-hosted engine. The setup fails when detecting peers and indicates that 
> they are already part of a cluster. So i restart the install and choose the 
> install engine on single node with Gluster. I now have all three nodes 
> connected to ovirt engine, however my trouble is I am not understanding how 
> to add the disk of the two nodes to the glusterFS. I also have some extra 
> disks on my primary node I want to add. I believe it is as follows but I dont 
> want to mess this up.
>
> Under Compute >> Hosts >> $HOSTNAME
> Select Storage Devices
> Select Disk in my case sde
> Then create brick?
>  If this is the case Do I add it to a LV if so which one 
> engine,data or vmstore?
>  Do I repeat this for each hosts?
>
> I can duplicate the engine, data and vmstore on each one, but that will still 
> leave me with two disks on each node without assignment
> If anyone can help that would be great.

Using the engine UI to create a brick maps 1 disk -> 1 brick. So if
you want to use sde to create multiple bricks, that is not possible
currently via the UI.
Once you create bricks on the 2 hosts - you need to expand the gluster
volume and add the bricks from the 2 nodes.

Can you provide a bit more detail on the error you ran into while
installing on 3 hosts. Was gluster setup prior to the install?

>
>
> Thank you.
> Pollard
>
> ___
> 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/NRAIDCNL5UETBSR6RMXDEHUPU4D26AHG/
___
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/JU44JOAMZ747M634BPZTRRKDB7WCGRI6/

[ovirt-users] Re: Ovirt Glusterfs

[Sahina Bose]

The options set on the gluster volume are tuned for data consistency and
reliability.

Some of the changes that you can try
1. use gfapi - however this will not provide you HA if the server used to
access the gluster volume is down. (the backup-volfile-servers are not used
in case of gfapi). You can change this using the engine-config tool for
your cluster level.
2. Change the remote-dio:enable to turn on client side brick caching.
Ensure that you have a power backup in place, so that you don't end up with
data loss in case server goes down before data is flushed.

If you're seeing issues with a particular version of glusterfs, please
provide gluster profile output for us to help identify bottleneck.  (check
https://docs.gluster.org/en/latest/Administrator%20Guide/Monitoring%20Workload/
on how to do this)

On Fri, Feb 22, 2019 at 1:39 PM Sandro Bonazzola 
wrote:

> Adding Sahina
>
> Il giorno ven 22 feb 2019 alle ore 06:51 Strahil 
> ha scritto:
>
>> I have done some testing and it seems that storhaug + ctdb + nfs-ganesha
>> is showing decent performance in a 3 node  hyperconverged setup.
>> Fuse mounts are hitting some kind of limit when mounting gluster
>> -3.12.15  volumes.
>>
>> 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/7U5J4KYDJJS4W3BE2KEIR67NU3532XGY/
>>
>
>
> --
>
> SANDRO BONAZZOLA
>
> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>
> Red Hat EMEA 
>
> sbona...@redhat.com
> 
>
___
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/QL7Z56UFMWTGQ7F22JWNCYI6OHZHEI24/

[ovirt-users] Re: Problem deploying self-hosted engine on ovirt 4.3.0

[Sahina Bose]

You can interrupt and continue from hosted engine setup the next time.
Please download the ovirt-engine-appliance rpm prior to install to
speeden things up.

On Mon, Feb 25, 2019 at 4:56 AM matteo fedeli  wrote:
>
> after several attempts I managed to install and deploying the ovel gluster 
> but during the self-hosted engine deploy stuck on [INFO] TASK 
> ["oVirt.engine-setup: Install oVirt Engine package"] for 30 minutes ... How 
> to safely interrupt ? I let it go on while I look at some logs?
> ___
> 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/FOLFFYVCDBFNPDZ7TKETX7QFTUEUQ3I7/
___
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/4GS7IULDHCNA3Z424LGOJHUO5TIQ5ROQ/

[ovirt-users] Re: Ovirt Cluster completely unstable

[Sahina Bose]

On Thu, Feb 14, 2019 at 8:24 PM Jayme  wrote:

> https://bugzilla.redhat.com/show_bug.cgi?id=1677160 doesn't seem relevant
> to me?  Is that the correct link?
>
> Like I mentioned in a previous email I'm also having problems with Gluster
> bricks going offline since upgrading to oVirt 4.3 yesterday (previously
> I've never had a single issue with gluster nor have had a brick ever go
> down).  I suspect this will continue to happen daily as some other users on
> this group have suggested.  I was able to pull some logs from engine and
> gluster from around the time the brick dropped.  My setup is 3 node HCI and
> I was previously running the latest 4.2 updates (before upgrading to 4.3).
> My hardware is has a lot of overhead and I'm on 10Gbe gluster backend (the
> servers were certainly not under any significant amount of load when the
> brick went offline).  To recover I had to place the host in maintenance
> mode and reboot (although I suspect I could have simply unmounted and
> remounted gluster mounts).
>

Anything in the brick logs..the below logs only indicate that engine
detected that brick was down. To get to why the brick was marked down, the
bricks logs would help


> grep "2019-02-14" engine.log-20190214 | grep "GLUSTER_BRICK_STATUS_CHANGED"
> 2019-02-14 02:41:48,018-04 WARN
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (DefaultQuartzScheduler1) [5ff5b093] EVENT_ID:
> GLUSTER_BRICK_STATUS_CHANGED(4,086), Detected change in status of brick
> host2.replaced.domain.com:/gluster_bricks/non_prod_b/non_prod_b of volume
> non_prod_b of cluster Default from UP to DOWN via cli.
> 2019-02-14 03:20:11,189-04 WARN
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (DefaultQuartzScheduler3) [760f7851] EVENT_ID:
> GLUSTER_BRICK_STATUS_CHANGED(4,086), Detected change in status of brick
> host2.replaced.domain.com:/gluster_bricks/engine/engine of volume engine
> of cluster Default from DOWN to UP via cli.
> 2019-02-14 03:20:14,819-04 WARN
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (DefaultQuartzScheduler3) [760f7851] EVENT_ID:
> GLUSTER_BRICK_STATUS_CHANGED(4,086), Detected change in status of brick
> host2.replaced.domain.com:/gluster_bricks/prod_b/prod_b of volume prod_b
> of cluster Default from DOWN to UP via cli.
> 2019-02-14 03:20:19,692-04 WARN
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (DefaultQuartzScheduler3) [760f7851] EVENT_ID:
> GLUSTER_BRICK_STATUS_CHANGED(4,086), Detected change in status of brick
> host2.replaced.domain.com:/gluster_bricks/isos/isos of volume isos of
> cluster Default from DOWN to UP via cli.
> 2019-02-14 03:20:25,022-04 WARN
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (DefaultQuartzScheduler3) [760f7851] EVENT_ID:
> GLUSTER_BRICK_STATUS_CHANGED(4,086), Detected change in status of brick
> host2.replaced.domain.com:/gluster_bricks/prod_a/prod_a of volume prod_a
> of cluster Default from DOWN to UP via cli.
> 2019-02-14 03:20:29,088-04 WARN
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (DefaultQuartzScheduler3) [760f7851] EVENT_ID:
> GLUSTER_BRICK_STATUS_CHANGED(4,086), Detected change in status of brick
> host2.replaced.domain.com:/gluster_bricks/non_prod_b/non_prod_b of volume
> non_prod_b of cluster Default from DOWN to UP via cli.
> 2019-02-14 03:20:34,099-04 WARN
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (DefaultQuartzScheduler3) [760f7851] EVENT_ID:
> GLUSTER_BRICK_STATUS_CHANGED(4,086), Detected change in status of brick
> host2.replaced.domain.com:/gluster_bricks/non_prod_a/non_prod_a of volume
> non_prod_a of cluster Default from DOWN to UP via cli
>
> glusterd.log
>
> # grep -B20 -A20 "2019-02-14 02:41" glusterd.log
> [2019-02-14 02:36:49.585034] I [MSGID: 106499]
> [glusterd-handler.c:4389:__glusterd_handle_status_volume] 0-management:
> Received status volume req for volume non_prod_b
> [2019-02-14 02:36:49.597788] E [MSGID: 101191]
> [event-epoll.c:671:event_dispatch_epoll_worker] 0-epoll: Failed to dispatch
> handler
> The message "E [MSGID: 101191]
> [event-epoll.c:671:event_dispatch_epoll_worker] 0-epoll: Failed to dispatch
> handler" repeated 2 times between [2019-02-14 02:36:49.597788] and
> [2019-02-14 02:36:49.900505]
> [2019-02-14 02:36:53.437539] I [MSGID: 106499]
> [glusterd-handler.c:4389:__glusterd_handle_status_volume] 0-management:
> Received status volume req for volume non_prod_a
> [2019-02-14 02:36:53.452816] E [MSGID: 101191]
> [event-epoll.c:671:event_dispatch_epoll_worker] 0-epoll: Failed to dispatch
> handler
> [2019-02-14 02:36:53.864153] I [MSGID: 106499]
> [glusterd-handler.c:4389:__glusterd_handle_status_volume] 0-management:
> Received status volume req for volume non_prod_a
> [2019-02-14 02:36:53.875835] E [MSGID: 101191]
> [event-epoll.c:671:event_dispatch_epoll_worker] 0-epoll: Failed to dispatch
> handler
> [2019-02-14 

[ovirt-users] Re: Problem installing hyperconverged setup

[Sahina Bose]

You can edit per host in the cockpit UI if you have non-uniform hosts.
If you still run into issues, please paste the generated gdeploy
config file to check

On Wed, Feb 13, 2019 at 8:54 PM Edward Berger  wrote:
>
> I don't believe the wizard followed your wishes if it comes up with 1005gb 
> for the thinpool.
> 500gb data + 500gb vmstore +5gb metadata = 1005gb
>
> The wizard tries to do the same setup on all three gluster hosts.
> So if you change anything, you have to "check and edit" the config file it 
> generates in all three locations
> before deploy..
>
> With only 450gb min-size-disk, I'd start over again, delete the data and 
> vmstore domains during the wizard setup
> and bump up engine size to fill up the available space on the smallest disk 
> (400gb or so).
>
> The other domains aren't necessary and you might want to give them their own 
> larger disks later.
>
> On Wed, Feb 13, 2019 at 8:41 AM  wrote:
>>
>> Hi,
>>
>> I am currently setting up an Ovirt cluster in a test environment and cannot 
>> get the hyperconverged setup to run properly.  I have installed 3 nodes on 
>> version 4.2.8.
>>
>> I keep getting the following error -
>>
>> TASK [Create LVs with specified size for the VGs] 
>> **
>> failed: [node01.ovirt.local] (item={u'lv': u'gluster_thinpool_sdb', u'size': 
>> u'1005GB', u'extent': u'100%FREE', u'vg': u'gluster_vg_sdb'}) => {"changed": 
>> false, "item": {"extent": "100%FREE", "lv": "gluster_thinpool_sdb", "size": 
>> "1005GB", "vg": "gluster_vg_sdb"}, "msg": "  WARNING: Pool zeroing and 3.00 
>> MiB large chunk size slows down thin provisioning.\n  WARNING: Consider 
>> disabling zeroing (-Zn) or using smaller chunk size (<512.00 KiB).\n  Volume 
>> group \"gluster_vg_sdb\" has insufficient free space (157261 extents): 
>> 343040 required.\n", "rc": 5}
>> to retry, use: --limit @/tmp/tmpbXqHhw/lvcreate.retry
>>
>> All 3 nodes have an /sdb installed which are different sizes but all in 
>> excess of 450Gb.  I have specified JBOD in the setup.
>>
>> I have tried reducing the size of the engine, data and vmstore bricks to 
>> 50Gb each instead of the default but the installation still fails.
>>
>> I think it has something to do with the thin provisioning but not sure what.
>>
>> Any help would be much appreciated.
>>
>> Thanks
>> Paul.
>> ___
>> 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/BXNOIJCQHCOZCHEH4MLVB4F4AURGHBIZ/
>
> ___
> 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/4LQUWXCPNVTJWGH4UMO7WOVZRCGTBOPO/
___
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/KH5O35MZO72SVYIKY2ROPZNQHODILGXR/

[ovirt-users] Re: Ovirt Cluster completely unstable

[Sahina Bose]

On Thu, Feb 14, 2019 at 4:56 AM  wrote:
>
> I'm abandoning my production ovirt cluster due to instability.   I have a 7 
> host cluster running about 300 vms and have been for over a year.  It has 
> become unstable over the past three days.  I have random hosts both, compute 
> and storage disconnecting.  AND many vms disconnecting and becoming unusable.
>
> 7 host are 4 compute hosts running Ovirt 4.2.8 and three glusterfs hosts 
> running 3.12.5.  I submitted a bugzilla bug and they immediately assigned it 
> to the storage people but have not responded with any meaningful information. 
>  I have submitted several logs.

Can you point to the bug filed?
+Krutika Dhananjay to look at it

>
> I have found some discussion on problems with instability with gluster 
> 3.12.5.  I would be willing to upgrade my gluster to a more stable version if 
> that's the culprit.  I installed gluster using the ovirt gui and this is the 
> version the ovirt gui installed.
>
> Is there an ovirt health monitor available?  Where should I be looking to get 
> a resolution the problems I'm facing.
> ___
> 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/BL4M3JQA3IEXCQUY4IGQXOAALRUQ7TVB/
___
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/NFFMACCICXTDNEFKRDATHQ44MX44YDVX/

[ovirt-users] Re: Stuck completing last step of 4.3 upgrade

[Sahina Bose]

On Thu, Feb 14, 2019 at 2:39 AM Ron Jerome  wrote:
>
>
> >
> > Can you be more specific? What things did you see, and did you report bugs?
>
> I've got this one: https://bugzilla.redhat.com/show_bug.cgi?id=1649054
> and this one: https://bugzilla.redhat.com/show_bug.cgi?id=1651246
> and I've got bricks randomly going offline and getting out of sync with the 
> others at which point I've had to manually stop and start the volume to get 
> things back in sync.

Thanks for reporting these. Will follow up on the bugs to ensure
they're addressed.
Regarding brciks going offline - are the brick processes crashing? Can
you provide logs of glusterd and bricks. Or is this to do with
ovirt-engine and brick status not being in sync?

> ___
> 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/3RVMLCRK4BWCSBTWVXU2JTIDBWU7WEOP/
___
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/4PKJSVDIH3V4H7Q2RKS2C4ZUMWDODQY6/

[ovirt-users] Re: ovirt-4.3 hyperconverged deployment - no option for "disc count" for JBOD

[Sahina Bose]

On Mon, Feb 11, 2019 at 9:57 PM feral  wrote:

> No. I gave up on ovirt 4.2 (node iso and centos) and moved over to the
> node 4.3 iso, and that's where I found the problem with the JBOD. I then
> moved back to centos and installed 4.3 there, which comes with 
> gdeploy-2.0.8-1.el7.noarch
> . I don't know if this version had the issue or not, as I assumed that
> given I'm using the same ovirt/gluster repos, it'd probably have had the
> same problem.
>
> I've since wiped out the cluster and have been testing a single ovirt-4.3
> node (from centos) to try to rule out a few issues. Found that for some
> reason, while my bare metal raid array gives me about 1GBps r/w (XFS on top
> of LVM), as soon as I mount a brick and try to r/w to it, that performance
> drops to between 5 and 55MBps depending on block size. The native XFS and
> gluster XFS configs are identical. 1000MBps o the native XFS with 4k
> blocks, and 5MBps on gluster with 4k blocks. I can get up to 55MBps on
> gluster with 64k blocks. So something else isn't right, but I haven't had
> any luck in asking around, as everyone seems to feel this is just an issue
> of incrimental performance tweaks. I of course argue that all of the
> recommended tweaks only gained 1-2% performance, and that we'd need about
> 800 of them to get decent performance.
>
> So at this point I'm not really sure what to do next. When I've used
> gluster in the past (configured manually), I've never had a problem getting
> at least 80-90% native performance. I've also noticed that for some reason,
> ovirt runs my guests like complete garbage and I have no idea why. I get
> about 1/20th to 1/50th the performance from ovirt, as I get on the same
> hardware with boring qemu/kvm.
> I'm just bringing up a single host (centos with 4.3) now, and trying local
> storage instead of gluster, to see if there's any major change in overall
> VM performance. Just uploading an ISO to the local storage though, is
> already about 80x faster than uploading it to a gluster volume.
>

And the gluster volume options are the standard? Set by cockpit deployment?

The gluster volume created via cockpit uses network.remote-dio: disable and
performance.strict-o-direct:on to ensure that every write is written to
disk. This is to ensure consistency and prevent loss of data
You can turn on client side brick caching by using network.remote-dio:
enable - but be sure to have a power backup to ensure yours hosts do not
power off and lose data before the cache is flushed


> And... somewhat confirmed. Using local storage (just a plain XFS file
> system) showed major improvement to guest VM performance overall. The disc
> throughput is still very slow (160MBps vs the 1000MBps of the host), but
> overall, the entire VM is much more responsive.
> Meanwhile, testing a clone of the same VM on my 7 year old laptop, which
> pushes around 300MBps, the VM is pushing 280MBps average. Both using XFS.
>
> So why is ovirt's guest disc performance (native and gluster) so poor? Why
> is it consistently giving me about 1/10th to 1/80th of the hosts disc
> throughput?
>
>
>
>
> On Mon, Feb 11, 2019 at 5:01 AM Sahina Bose  wrote:
>
>>
>>
>> On Wed, Feb 6, 2019 at 10:45 PM feral  wrote:
>>
>>> On that note, this was already reported several times a few months back,
>>> but apparently was fixed in gdeploy-2.0.2-29.el7rhgs.noarch. I'm
>>> guessing ovirt-node-4.3 just hasn't updated to that version yet?
>>>
>>
>> +Niels de Vos  +Sachidananda URS 
>> Any update on the gdeploy package update in CentOS ?
>>
>>
>>> On Wed, Feb 6, 2019 at 8:51 AM feral  wrote:
>>>
>>>> Bugzilla must have lost my account. Requesting password reset on an
>>>> account that doesn't exist, results in 500 :p.
>>>> Created a new one.
>>>>
>>>> However, my options for gdeploy version do not match the version 2.0.2
>>>> installed. They only list 0.xx.x.
>>>>
>>>> On Wed, Feb 6, 2019 at 8:44 AM Greg Sheremeta 
>>>> wrote:
>>>>
>>>>>
>>>>> On Wed, Feb 6, 2019 at 11:31 AM feral  wrote:
>>>>>
>>>>>> Sorry, I tried opening a bug, but RH's Bugzilla is having issues and
>>>>>> 500's out when I try to request password reset.
>>>>>>
>>>>>
>>>>> Sorry to hear that. I hate to ask, but could you try after clearing
>>>>> cookies for *redhat.com, or try in an incognito tab? It's done that
>>>>> to me before and clearing cookies worked for me. If it still doesn't work,
>>>>> I'll open th

[ovirt-users] Re: Error starting hosted engine

[Sahina Bose]

On Tue, Feb 12, 2019 at 10:51 AM Endre Karlson 
wrote:

> It's a upgrade from 4.2.x < latest version of 4.2 series. I upgraded by
> adding the 4.3 repo and doing the steps on the upgrade guide page
> https://www.ovirt.org/release/4.3.0/#centos--rhel
>

Seems like you're running into
https://bugzilla.redhat.com/show_bug.cgi?id=1666795


>
> Den man. 11. feb. 2019 kl. 23:35 skrev Greg Sheremeta  >:
>
>> Hi,
>>
>> Is this an upgrade or a fresh installation? What version? What
>> installation or upgrade commands / methods did you use?
>>
>> Best wishes,
>> Greg
>>
>>
>>
>> On Mon, Feb 11, 2019 at 5:11 PM Endre Karlson 
>> wrote:
>>
>>> https://paste.ubuntu.com/p/BrmPYRKmzT/
>>> https://paste.fedoraproject.org/paste/MjfioF9-Pzk02541abKyOw
>>>
>>> Seems like it's a error with vdsmd and glusterfs ?
>>>
>>> // Endre
>>> ___
>>> 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/OWKVL6PWBCPYPKD6QWQJERZDDRYRIUKU/
>>>
>>
>>
>> --
>>
>> GREG SHEREMETA
>>
>> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
>>
>> Red Hat NA
>>
>> 
>>
>> gsher...@redhat.comIRC: gshereme
>> 
>>
> ___
> 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/LYXZVYVJAJFEBITTNQBNNF6WVTPNZJMJ/
>
___
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/SEB75SN6YLZHRIV3MN72JLUSOTU7BKSE/

[ovirt-users] Re: ovirt-4.3 hyperconverged deployment - no option for "disc count" for JBOD

[Sahina Bose]

On Wed, Feb 6, 2019 at 10:45 PM feral  wrote:

> On that note, this was already reported several times a few months back,
> but apparently was fixed in gdeploy-2.0.2-29.el7rhgs.noarch. I'm guessing
> ovirt-node-4.3 just hasn't updated to that version yet?
>

+Niels de Vos  +Sachidananda URS 
Any update on the gdeploy package update in CentOS ?


> On Wed, Feb 6, 2019 at 8:51 AM feral  wrote:
>
>> Bugzilla must have lost my account. Requesting password reset on an
>> account that doesn't exist, results in 500 :p.
>> Created a new one.
>>
>> However, my options for gdeploy version do not match the version 2.0.2
>> installed. They only list 0.xx.x.
>>
>> On Wed, Feb 6, 2019 at 8:44 AM Greg Sheremeta 
>> wrote:
>>
>>>
>>> On Wed, Feb 6, 2019 at 11:31 AM feral  wrote:
>>>
 Sorry, I tried opening a bug, but RH's Bugzilla is having issues and
 500's out when I try to request password reset.

>>>
>>> Sorry to hear that. I hate to ask, but could you try after clearing
>>> cookies for *redhat.com, or try in an incognito tab? It's done that to
>>> me before and clearing cookies worked for me. If it still doesn't work,
>>> I'll open the bug. Thanks!
>>>
>>>


 ---
 PLAY [gluster_servers]
 *

 TASK [Run a shell script]
 **
 changed: [ovirt-431.localdomain] =>
 (item=/usr/share/gdeploy/scripts/grafton-sanity-check.sh -d vdb -h
 ovirt-431.localdomain, ovirt-432.localdomain, ovirt-433.localdomain)

 PLAY RECAP
 *
 ovirt-431.localdomain  : ok=1changed=1unreachable=0
 failed=0


 PLAY [gluster_servers]
 *

 TASK [Run a shell script]
 **
 changed: [ovirt-432.localdomain] =>
 (item=/usr/share/gdeploy/scripts/grafton-sanity-check.sh -d vdb -h
 ovirt-431.localdomain, ovirt-432.localdomain, ovirt-433.localdomain)

 PLAY RECAP
 *
 ovirt-432.localdomain  : ok=1changed=1unreachable=0
 failed=0


 PLAY [gluster_servers]
 *

 TASK [Run a shell script]
 **
 changed: [ovirt-433.localdomain] =>
 (item=/usr/share/gdeploy/scripts/grafton-sanity-check.sh -d vdb -h
 ovirt-431.localdomain, ovirt-432.localdomain, ovirt-433.localdomain)

 PLAY RECAP
 *
 ovirt-433.localdomain  : ok=1changed=1unreachable=0
 failed=0


 PLAY [gluster_servers]
 *

 TASK [Create VDO with specified size]
 **
 changed: [ovirt-431.localdomain] => (item={u'disk': u'/dev/vdb',
 u'logicalsize': u'11000G', u'name': u'vdo_vdb'})

 PLAY RECAP
 *
 ovirt-431.localdomain  : ok=1changed=1unreachable=0
 failed=0


 PLAY [gluster_servers]
 *

 TASK [Create VDO with specified size]
 **
 changed: [ovirt-432.localdomain] => (item={u'disk': u'/dev/vdb',
 u'logicalsize': u'11000G', u'name': u'vdo_vdb'})

 PLAY RECAP
 *
 ovirt-432.localdomain  : ok=1changed=1unreachable=0
 failed=0


 PLAY [gluster_servers]
 *

 TASK [Create VDO with specified size]
 **
 changed: [ovirt-433.localdomain] => (item={u'disk': u'/dev/vdb',
 u'logicalsize': u'11000G', u'name': u'vdo_vdb'})

 PLAY RECAP
 *
 ovirt-433.localdomain  : ok=1changed=1unreachable=0
 failed=0


 PLAY [gluster_servers]
 *

 TASK [Enable or disable services]
 **
 ok: [ovirt-432.localdomain] => (item=chronyd)
 ok: [ovirt-431.localdomain] => (item=chronyd)
 ok: [ovirt-433.localdomain] => (item=chronyd)

 PLAY RECAP
 *
 ovirt-431.localdomain  : ok=1changed=0unreachable=0
 failed=0
 

[ovirt-users] Re: glusterevents daemon fails after upgrade from 4.2.8 to 4.3

[Sahina Bose]

On Fri, Feb 8, 2019 at 11:31 AM Aravinda  wrote:
>
> Looks like Python 3 porting issue. I will work on the fix soon. Thanks

Do we have a bug in gluster to track this?

>
>
> On Thu, 2019-02-07 at 13:27 +0530, Sahina Bose wrote:
> > +Aravinda Vishwanathapura Krishna Murthy can you take a look? oVirt
> > 4.3 has Gluster 5
> >
> > On Wed, Feb 6, 2019 at 7:35 PM Edward Berger 
> > wrote:
> > > I upgraded some nodes from 4.28 to 4.3 and now when I look at the
> > > cockpit "services"
> > > tab I see a red failure for Gluster Events Notifier and clicking
> > > through I get these messages below.
> > >
> > > 14:00
> > > glustereventsd.service failed.
> > > systemd
> > > 14:00
> > > Unit glustereventsd.service entered failed state.
> > > systemd
> > > 14:00
> > > glustereventsd.service: main process exited, code=exited,
> > > status=1/FAILURE
> > > systemd
> > > 14:00
> > > ValueError: Attempted relative import in non-package
> > > glustereventsd
> > > 14:00
> > > from .eventsapiconf import (LOG_FILE,
> > > glustereventsd
> > > 14:00
> > > File "/usr/libexec/glusterfs/events/utils.py", line 29, in 
> > > glustereventsd
> > > 14:00
> > > import utils
> > > glustereventsd
> > > 14:00
> > > File "/usr/libexec/glusterfs/events/handlers.py", line 12, in
> > > 
> > > glustereventsd
> > > 14:00
> > > import handlers
> > > glustereventsd
> > > 14:00
> > > File "/usr/sbin/glustereventsd", line 24, in 
> > > glustereventsd
> > > ___
> > > 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/K6N5EWVRPYRAXBUON2XNJVT5OH42PDEN/
> --
> regards
> Aravinda
>
___
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/6EKAE54IAMA5ZF36Q2PD7GXNYIEQUD7R/

[ovirt-users] Re: "Volume Option cluster.granular-entry-heal=enable could not be set" when using "Optimize for Virt store"

[Sahina Bose]

On Wed, Feb 6, 2019 at 4:17 PM Jorick Astrego  wrote:

> Hi again,
>
> When using the option "Optimize for Virt store", I get the following error:
>
> 2019-02-06 10:25:02,353+01 ERROR
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (EE-ManagedThreadFactory-engine-Thread-15727)
> [051cfc8c-9efc-427c-9e2e-9127e3e0a86d] EVENT_ID:
> GLUSTER_VOLUME_OPTION_SET_FAILED(4,003), Volume Option
> cluster.granular-entry-heal=enable could not be set on ssd9 of cluster
> GlusterFS-storage.
>
> This looks like the same issue as
> https://bugzilla.redhat.com/show_bug.cgi?id=1635684
>
> Volume set option 'granular-entry-heal' is not longer set via gluster
> volume set option.
>
> Is this a known issue or should I open a bug for this?
>

Please open a bug.


>
>
>
> Met vriendelijke groet, With kind regards,
>
> Jorick Astrego
>
> *Netbulae Virtualization Experts *
> --
> Tel: 053 20 30 270 i...@netbulae.eu Staalsteden 4-3A KvK 08198180
> Fax: 053 20 30 271 www.netbulae.eu 7547 TA Enschede BTW NL821234584B01
> --
>
> ___
> 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/HYEJJPEJISYSQCQLPT45AUAHEOKWBKN5/
>
___
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/WF72OTQR2WHQPU7XQ5CJ4IJWJLTAO5II/

[ovirt-users] Re: glusterevents daemon fails after upgrade from 4.2.8 to 4.3

[Sahina Bose]

+Aravinda Vishwanathapura Krishna Murthy can you take a look? oVirt
4.3 has Gluster 5

On Wed, Feb 6, 2019 at 7:35 PM Edward Berger  wrote:
>
> I upgraded some nodes from 4.28 to 4.3 and now when I look at the cockpit 
> "services"
> tab I see a red failure for Gluster Events Notifier and clicking through I 
> get these messages below.
>
> 14:00
> glustereventsd.service failed.
> systemd
> 14:00
> Unit glustereventsd.service entered failed state.
> systemd
> 14:00
> glustereventsd.service: main process exited, code=exited, status=1/FAILURE
> systemd
> 14:00
> ValueError: Attempted relative import in non-package
> glustereventsd
> 14:00
> from .eventsapiconf import (LOG_FILE,
> glustereventsd
> 14:00
> File "/usr/libexec/glusterfs/events/utils.py", line 29, in 
> glustereventsd
> 14:00
> import utils
> glustereventsd
> 14:00
> File "/usr/libexec/glusterfs/events/handlers.py", line 12, in 
> glustereventsd
> 14:00
> import handlers
> glustereventsd
> 14:00
> File "/usr/sbin/glustereventsd", line 24, in 
> glustereventsd
> ___
> 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/K6N5EWVRPYRAXBUON2XNJVT5OH42PDEN/
___
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/OR5RSKJI7VHWAAWVZZI27AXHGDKTWNVM/

[ovirt-users] Re: unable to migrate hosted-engine to oVirt 4.3 updated nodes

[Sahina Bose]

On Thu, Feb 7, 2019 at 8:57 AM Edward Berger  wrote:
>
> I'm seeing migration failures for the hosted-engine VM from a 4.28 node to a 
> 4.30 node so I can complete the node upgrades.

You may be running into
https://bugzilla.redhat.com/show_bug.cgi?id=1641798. Can you check the
version of libvirt used on the nodes?
>
> In one case I tried to force an update on the last node and now have a 
> cluster where the hosted-engine VM fails to start properly.   Sometimes 
> something thinks the VM is running, but clicking for details it seems to have 
> no disk.  I was so close to putting that one into production with working 
> LDAP user logins and custom SSL cert and then Oops! with the upgrade.
>
> In both cases the hosted VM storage is on gluster.  One hyperconverged oVirt 
> nodes, the other two nodes with an external gluster 5 server cluster
>
> I will note that I had set the engines previously (while at 4.2.8) to use the 
> gluster direct method enabling (libgfapi disk access level 4.2) instead of 
> the default fuse client for improved performance.
>
> Other details  Engine was updated first.
> Nodes were updated with
>
> yum install 
> https://resources.ovirt.org/pub/ovirt-4.3/rpm/el7/noarch/ovirt-node-ng-image-update-4.3.0-1.el7.noarch.rpm
>
> I forgot to mention another symptom.
> On the hyperconverged cluster, the "gluster volume heal engine" command 
> errors out on 4.3, but other gluster volumes accepted it.

+Ravishankar Narayanankutty to check the heal failures

>
> rolling back to 4.28 allows the heal command to succeed (nothing to do 
> actually) on engine, but I'm still unable to start a working engine VM with 
> hosted-engine --vm-start
>
>
> ___
> 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/HFHLP473CFIMINFBUO4NH6WO3GPIQSVU/
___
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/X2IQYD3HK367RWAY5VMFDXZPPT4G33KF/

[ovirt-users] Re: ovirt-node 4.2 iso - hyperconverged wizard doesn't write gdeployConfig settings

[Sahina Bose]

+Sachidananda URS to review user request about systemd mount files

On Tue, Feb 5, 2019 at 10:22 PM feral  wrote:
>
> Using SystemD makes way more sense to me. I was just trying to use ovirt-node 
> as it was ... intended? Mainly because I have no idea how it all works yet, 
> so I've been trying to do the most stockish deployment possible, following 
> deployment instructions and not thinking I'm smarter than the software :p.
> I've given up on 4.2 for now, as 4.3 was just released, so giving that a try 
> now. Will report back. Hopefully 4.3 enlists systemd for stuff?
>
> On Tue, Feb 5, 2019 at 4:33 AM Strahil Nikolov  wrote:
>>
>> Dear Feral,
>>
>> >On that note, have you also had issues with gluster not restarting on 
>> >reboot, as well as >all of the HA stuff failing on reboot after power loss? 
>> >Thus far, the only way I've got the >cluster to come back to life, is to 
>> >manually restart glusterd on all nodes, then put the >cluster back into 
>> >"not mainentance" mode, and then manually starting the hosted-engine vm. 
>> >>This also fails after 2 or 3 power losses, even though the entire cluster 
>> >is happy through >the first 2.
>>
>>
>> About the gluster not starting - use systemd.mount unit files.
>> here is my setup and for now works:
>>
>> [root@ovirt2 yum.repos.d]# systemctl cat gluster_bricks-engine.mount
>> # /etc/systemd/system/gluster_bricks-engine.mount
>> [Unit]
>> Description=Mount glusterfs brick - ENGINE
>> Requires = vdo.service
>> After = vdo.service
>> Before = glusterd.service
>> Conflicts = umount.target
>>
>> [Mount]
>> What=/dev/mapper/gluster_vg_md0-gluster_lv_engine
>> Where=/gluster_bricks/engine
>> Type=xfs
>> Options=inode64,noatime,nodiratime
>>
>> [Install]
>> WantedBy=glusterd.service
>> [root@ovirt2 yum.repos.d]# systemctl cat gluster_bricks-engine.automount
>> # /etc/systemd/system/gluster_bricks-engine.automount
>> [Unit]
>> Description=automount for gluster brick ENGINE
>>
>> [Automount]
>> Where=/gluster_bricks/engine
>>
>> [Install]
>> WantedBy=multi-user.target
>> [root@ovirt2 yum.repos.d]# systemctl cat glusterd
>> # /etc/systemd/system/glusterd.service
>> [Unit]
>> Description=GlusterFS, a clustered file-system server
>> Requires=rpcbind.service gluster_bricks-engine.mount 
>> gluster_bricks-data.mount gluster_bricks-isos.mount
>> After=network.target rpcbind.service gluster_bricks-engine.mount 
>> gluster_bricks-data.mount gluster_bricks-isos.mount
>> Before=network-online.target
>>
>> [Service]
>> Type=forking
>> PIDFile=/var/run/glusterd.pid
>> LimitNOFILE=65536
>> Environment="LOG_LEVEL=INFO"
>> EnvironmentFile=-/etc/sysconfig/glusterd
>> ExecStart=/usr/sbin/glusterd -p /var/run/glusterd.pid  --log-level 
>> $LOG_LEVEL $GLUSTERD_OPTIONS
>> KillMode=process
>> SuccessExitStatus=15
>>
>> [Install]
>> WantedBy=multi-user.target
>>
>> # /etc/systemd/system/glusterd.service.d/99-cpu.conf
>> [Service]
>> CPUAccounting=yes
>> Slice=glusterfs.slice
>>
>>
>> Best Regards,
>> Strahil Nikolov
>
>
>
> --
> _
> Fact:
> 1. Ninjas are mammals.
> 2. Ninjas fight ALL the time.
> 3. The purpose of the ninja is to flip out and kill people.
> ___
> 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/G4AE6YQHYL7XBTYNCLQPFQY6CY6C7YGX/
___
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/OU3HJYDT5P4ZQ2WJT7AS6URPEVTC4LRJ/