- Users - oVirt List Archives

CLUSTER_CANNOT_DISABLE_GLUSTER_WHEN_CLUSTER_CONTAINS_VOLUMES
by Arsène Gschwind 29 Mar '19

29 Mar '19

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 xxxx@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

3 13

Migrate HE beetwen hosts failed.
by kiv＠intercom.pro 29 Mar '19

29 Mar '19

Hi all. I have oVirt 4.3.1 and 3 node hosts. All VM migrate beetwen all hosts successfully. VM with HE - does not migrate. vdsm.log: libvirtError: operation failed: guest CPU doesn't match specification: missing features: xsave,avx,xsaveopt Nodes: 1. Intel Westmere IBRS SSBD Family 2. Intel Westmere IBRS SSBD Family 3. Intel SandyBridge IBRS SSBD Family <----- HE now here Cluster CPU Type: Intel Westmere Family Info from VM with HE: Guest CPU Type: Intel Westmere Family Does anyone know what needs to be done to make migration work?

3 6

virsh edit vm not saving after reboot
by Dev Ops 29 Mar '19

29 Mar '19

I am trying to get Cisco ISE installed into Ovirt. I was told I needed to do a virsh edit on the vm and change a line in the smbios settings. This is all simple enough. After a reboot or shutdown/restart the settings revert back to what they were before. A dump of the XML in fact shows the original settings that I had changed. Since I can't edit the file while the VM is off I am not sure how to save this config change. My issue is similar to this: https://access.redhat.com/discussions/2720821 I have been reading and digging around with no luck. I just can't seem to make this change static. Thanks!

2 2

[ANN] oVirt 4.3.3 First Release Candidate is now available
by Sandro Bonazzola 28 Mar '19

28 Mar '19

The oVirt Project is pleased to announce the availability of the oVirt 4.3.3 First Release Candidate, as of March 28th, 2019. This update is a release candidate of the third 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.6 or later * CentOS Linux (or similar) 7.6 or later This release supports Hypervisor Hosts on x86_64 and ppc64le architectures for: * Red Hat Enterprise Linux 7.6 or later * CentOS Linux (or similar) 7.6 or later * oVirt Node 4.3 (available for x86_64 only) Experimental tech preview for x86_64 and s390x architectures for Fedora 28 is also included. See the release notes [1] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: - oVirt Appliance is already available - oVirt Node is already available[2] Additional Resources: * Read more about the oVirt 4.3.3 release highlights: http://www.ovirt.org/release/4.3.3/ * 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.3/ [2] http://resources.ovirt.org/pub/ovirt-4.3-pre/iso/ -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

1 0

Re: Gluster VM image Resync Time
by Strahil 28 Mar '19

28 Mar '19

Hi Krutika, I have noticed some performance penalties (10%-15%) when using sharing in v3.12 . What is the situation now with 5.5 ? Best Regards, Strahil NikolovOn Mar 28, 2019 08:56, Krutika Dhananjay <kdhananj(a)redhat.com> wrote: > > Right. So Gluster stores what are called "indices" for each modified file (or shard) > under a special hidden directory of the "good" bricks at $BRICK_PATH/.glusterfs/indices/xattrop. > When the offline brick comes back up, the file corresponding to each index is healed, and then the index deleted > to mark the fact that the file has been healed. > > You can try this and see it for yourself. Just create a 1x3 plain replicate volume, and enable shard on it. > Create a big file (big enough to have multiple shards). Check that the shards are created under $BRICK_PATH/.shard. > Now kill a brick. Modify a small portion of the file. Hit `ls` on $BRICK_PATH/.glusterfs/indices/xattrop of the online bricks. > You'll notice there will be entries named after the gfid (unique identifier in gluster for each file) of the shards. > And only for those shards that the write modified, and not ALL shards of this really big file. > And then when you bring the brick back up using `gluster volume start $VOL force`, the > shards get healed and the directory eventually becomes empty. > > -Krutika > > > On Thu, Mar 28, 2019 at 12:14 PM Indivar Nair <indivar.nair(a)techterra.in> wrote: >> >> Hi Krutika, >> >> So how does the Gluster node know which shards were modified after it went down? >> Do the other Gluster nodes keep track of it? >> >> Regards, >> >> >> Indivar Nair >> >> >> On Thu, Mar 28, 2019 at 9:45 AM Krutika Dhananjay <kdhananj(a)redhat.com> wrote: >>> >>> Each shard is a separate file of size equal to value of "features.shard-block-size". >>> So when a brick/node was down, only those shards belonging to the VM that were modified will be sync'd later when the brick's back up. >>> Does that answer your question? >>> >>> -Krutika >>> >>> On Wed, Mar 27, 2019 at 7:48 PM Sahina Bose <sabose(a)redhat.com> wrote: >>>> >>>> On Wed, Mar 27, 2019 at 7:40 PM Indivar Nair <indivar.nair(a)techterra.in> 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 <hunter86_bg(a)yahoo.com> 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 <indivar.nair(a)techterra.in> wrote: >>>> >> >>>> >> Hi All, >>>> >> >>>> >> We are planning a 2 + 1 arbitrated mirrored Gluster setup. >>>> >> We would have around 50 - 60 VMs, with an average 500GB disk size. >>>> >> >>>> >> Now in case one of the Gluster Nodes go completely out of sync, roughly, how long would it take to resync? (as per your experience) >>>> >> Will it impact the working of VMs in any way? >>>> >> Is there anything to be taken care of, in advance, to prepare for such a situation? >>>> >> >>>> >> Regards, >>>> >> >>>> >> >>>> >> Indivar Nair >>>> >> >>>> > ______________

2 2

Re: ovirt data domain with multi luns, any best practice
by Strahil 28 Mar '19

28 Mar '19

In my opinion it's best to have 2 data domains. Best Regards, Strahil NikolovOn Mar 28, 2019 05:32, adam_xu(a)adagene.com.cn wrote: > > Hello, everyone. I had a question on how to create a data domain in the best way. > for example, I have a FCP device and there's a lot of hdds and ssds in that device. I ceate 2 luns. one consisting of HDDs and the other consisting of SSDs. I want to make some normal vms run in the lun with hdd and some vms (such as DB) run in the lun with ssd. > so, shoud I create one data domain with the 2 luns. or shoud I create 2 difference data domains, and every data domain with a single lun in it? > thanks. > ________________________________ > yours Adam

1 0

ovirt data domain with multi luns, any best practice
by adam_xu＠adagene.com.cn 28 Mar '19

28 Mar '19

Hello, everyone. I had a question on how to create a data domain in the best way. for example, I have a FCP device and there's a lot of hdds and ssds in that device. I ceate 2 luns. one consisting of HDDs and the other consisting of SSDs. I want to make some normal vms run in the lun with hdd and some vms (such as DB) run in the lun with ssd. so, shoud I create one data domain with the 2 luns. or shoud I create 2 difference data domains, and every data domain with a single lun in it? thanks. yours Adam

1 0

User permissions needed to clone template disk
by Wood Peter 27 Mar '19

27 Mar '19

Hi, Users have PowerUserRole permissions on the cluster and the storage objects. Also TemplateCreator role on the Datacenter. When users create VMs from templates there is no option to clone the disk and create independent VM disk. The resource allocation section is not visible at all. What permissions should I give users so they can clone the disk when creating a VM from a template? Using oVirt 4.2.8.2-1.el7 Thank you, -- Peter

2 4

Bad Volume Specification
by Bryan Sockel 27 Mar '19

27 Mar '19

Having an issue with starting one of my VM's. Looks like there was a problem with an auto generated snapshot on the VM. The snapshot file is missing: VDSM-Tool Output: image: 52f31c3a-25ac-4930-8e67-105945dd42b5 - 461e1747-3a59-4abc-ac6a-2013ec7858d3 status: OK, voltype: INTERNAL, format: RAW, legality: LEGAL, type: PREALLOCATED, capacity: 53687091200, truesize: 53687091200 - fe5fb4a4-8b3a-4bad-8f03-9dd179ac8397 status: OK, voltype: INTERNAL, format: COW, legality: LEGAL, type: SPARSE, capacity: 53687091200, truesize: 6576668672 - a01d662f-cf33-4c86-b0ba-8bddc6d25dfd status: ILLEGAL, voltype: LEAF, format: COW, legality: ILLEGAL, type: SPARSE, capacity: 53687091200, truesize: 3221225472 lvs -o+lv_tags |grep 52f31c3a-25ac-4930-8e67-105945dd42b5 Couldn't find device with uuid 5UNXpR-SmSR-KqA2-swpe-kcQi-X7tt-7B5wRz. 461e1747-3a59-4abc-ac6a-2013ec7858d3 8dfaac42-32fc-4e23-b5cb-e5c2c3c56c9d -wi-a----- 50.00g IU_52f31c3a-25ac-4930-8e67-105945dd42b5,MD_43,PU_00000000-0000-0000-0000-000000000000 a01d662f-cf33-4c86-b0ba-8bddc6d25dfd 8dfaac42-32fc-4e23-b5cb-e5c2c3c56c9d -wi------- 3.00g IU_52f31c3a-25ac-4930-8e67-105945dd42b5,MD_46,PU_fe5fb4a4-8b3a-4bad-8f03-9dd179ac8397 fe5fb4a4-8b3a-4bad-8f03-9dd179ac8397 8dfaac42-32fc-4e23-b5cb-e5c2c3c56c9d -wi-a----- 6.12g IU_52f31c3a-25ac-4930-8e67-105945dd42b5,MD_45,PU_461e1747-3a59-4abc-ac6a-2013ec7858d3 qemu-img info /dev/8dfaac42-32fc-4e23-b5cb-e5c2c3c56c9d/a01d662f-cf33-4c86-b0ba-8bddc6d25dfd qemu-img: Could not open '/dev/8dfaac42-32fc-4e23-b5cb-e5c2c3c56c9d/a01d662f-cf33-4c86-b0ba-8bddc6d25dfd': Could not open '/dev/8dfaac42-32fc-4e23-b5cb-e5c2c3c56c9d/a01d662f-cf33-4c86-b0ba-8bddc6d25dfd': No such file or directory What is the best way to remove the snapshot from the vm (PSQL statement to delete the entry from the database)? Thank You, Bryan Sockel

1 0

VM disk corruption with LSM on Gluster
by Sander Hoentjen 27 Mar '19

27 Mar '19

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-threads 16 32 performance.strict-o-direct off on network.ping-timeout 42 30 network.remote-dio enable off transport.address-family - inet performance.stat-prefetch off on features.shard-block-size 512MB 64MB cluster.shd-max-threads 1 8 cluster.shd-wait-qlength 1024 10000 cluster.locking-scheme full granular cluster.granular-entry-heal no enable 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. Kind regards, Sander Hoentjen

4 6