- Users - oVirt List Archives

Re: UX team is looking for feedback and your thoughts around user settings!
by Strahil 02 Oct '19

02 Oct '19

Hi Laura, Sadly I didn't have the time to take the survey on a PC, as on Android chrome - the survey cannot be completed. I hope next one is smartphone friendly. I will try to take the survey as soon as possible. Best Regards, Strahil NikolovOn Oct 2, 2019 20:33, Laura Wright <lwright(a)redhat.com> wrote: > > Hi all, > > We're still looking for some more responses so if you haven't taken the survey yet we would really appreciate it! Thank you! > > On Thu, Sep 26, 2019 at 3:47 AM Sandro Bonazzola <sbonazzo(a)redhat.com> wrote: >> >> oVirt UX team at Red Hat is currently looking for feedback and thoughts on the area of user settings within oVirt, both the VM and Administrator portal. >> >> If you have any ideas around user settings, we would love to hear from you! >> >> Please follow the link below[1] which will take you to a short survey that will ask some questions around proposed settings and give you the opportunity to suggest settings you would want to use. >> >> Thank you! >> >> [1] https://redhatdg.co1.qualtrics.com/jfe/form/SV_a9uTOLlQ41lV7KJ >> >> >> -- >> >> Sandro Bonazzola >> >> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV >> >> Red Hat EMEA >> >> sbonazzo(a)redhat.com >> >> Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours. >> _______________________________________________ >> Users mailing list -- users(a)ovirt.org >> To unsubscribe se

1 0

UX team is looking for feedback and your thoughts around user settings!
by Sandro Bonazzola 02 Oct '19

02 Oct '19

oVirt UX team at Red Hat is currently looking for feedback and thoughts on the area of user settings within oVirt, both the VM and Administrator portal. If you have any ideas around user settings, we would love to hear from you! Please follow the link below[1] which will take you to a short survey that will ask some questions around proposed settings and give you the opportunity to suggest settings you would want to use. Thank you! [1] https://redhatdg.co1.qualtrics.com/jfe/form/SV_a9uTOLlQ41lV7KJ -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/>*Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.*

2 1

Re: Ovirt 4.2.7 won't start and drops to emergency console
by Strahil 02 Oct '19

02 Oct '19

> >>>"Try to get all data in advance (before deactivating the VG)". > > Can you clarify? What do you mean by this? Get all necessary info before disabling the VG. For example: pvs vgs lvs -a lvdisplay -m /dev/gluster_vg1/lvthinpool lvdisplay -m /dev/gluster_vg1/lvthinpool_tmeta lvdisplay -m /dev/gluster_vg1/lvthinpool_tdata > >>>"You got 15GiB of metadata, so create your new metadata LV at least 30 GiB." > > My presumption is that 15 GB is the max size the was specified when it was initially built but not the actual size right now, but yes, making it larger does make sense. I was curious to know what the present size is. Also, lvconvert man page specifies a supported value between 2M and 16G I will create a larger metadata volume assuming I can get the procedure to work properly I am having some difficulty with the procedure, see below. If you don't manually create the meta and data LVs (which will create the pool with another command) the size is created by the following formula: (Pool_LV_size / Pool_LV_chunk_size * 64). For details check: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/ht… > > My most important question was here: > I am trying to follow the procedure from https://access.redhat.com/solutions/3251681 I am on step #2. Step 2a and 2b work without issue. Step 2c gives me an error. > > Here are the values I am using: > > # lvcreate -L 2G gluster_vg3 --name tmpLV > (created with no issues) > > # lvchange -ay gluster_vg3/tmpLV > (command completed with no issues) > > # lvconvert --thinpool gluster_vg1/lvthinpool --poolmetadata gluster_vg3/tmpLV > Error: > VG name mismatch from position arg (gluster_vg1) and option arg (gluster_vg3) > > Do I need to create the LV on the same disk that failed? (gluster_vg1) According to the error yes - logic shows that you need to be working in the same VG.If you don't have free space on the thin pool, you can add additional PV and extend the pool and then create your thin meta LV. You can also merge the 2 VGs to get the necessary space. Check 'man 8 vgmerge'. Best Regards, Strahil Nikolov

1 0

Re: Ovirt 4.2.7 won't start and drops to emergency console
by Strahil 02 Oct '19

02 Oct '19

Is this an oVirt Node or a regular CentOS/RHEL ?On Oct 2, 2019 05:06, jeremy_tourville(a)hotmail.com wrote: > > Here is my fstab file: > # /etc/fstab > # Created by anaconda on Fri Dec 21 22:26:32 2018 > # > # Accessible filesystems, by reference, are maintained under '/dev/disk' > # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info > # > /dev/onn_vmh/ovirt-node-ng-4.2.7.1-0.20181216.0+1 / ext4 defaults,discard 1 1 > UUID=9b9546f9-25d2-42a6-835b-303f32aee4b1 /boot ext4 defaults 1 2 > /dev/mapper/onn_vmh-home /home ext4 defaults,discard 1 2 > /dev/mapper/onn_vmh-tmp /tmp ext4 defaults,discard 1 2 > /dev/mapper/onn_vmh-var /var ext4 defaults,discard 1 2 > /dev/mapper/onn_vmh-var_log /var/log ext4 defaults,discard 1 2 > /dev/mapper/onn_vmh-var_log_audit /var/log/audit ext4 defaults,discard 1 2 > /dev/mapper/onn_vmh-swap swap swap defaults 0 0 > /dev/gluster_vg1/engine_lv /gluster_bricks/engine xfs inode64,noatime,nodiratime 0 0 > /dev/gluster_vg1/lv_vmdisks /gluster_bricks/vmstore xfs inode64,noatime,nodiratime 0 0 > /dev/gluster_vg1/lv_datadisks /gluster_bricks/data xfs inode64,noatime,nodiratime 0 0 > #/dev/sdd1 /gluster_bricks/iso xfs inode64,noatime,nodiratime 0 0 > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ > List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/VYQ22EFSGRYDE…

1 0

Re: Ovirt 4.2.7 won't start and drops to emergency console
by Strahil 02 Oct '19

02 Oct '19

Hm... It's strage it doesn't detect the VG , but could be related to the issue. Accordi g to this: lvthinpool_tmeta { id = "WBut10-rAOP-FzA7-bJvr-ZdxL-lB70-jzz1Tv" status = ["READ", "WRITE"] flags = [] creation_time = 1545495487 # 2018-12-22 10:18:07 -0600 creation_host = "vmh.cyber-range.lan" segment_count = 1 segment1 { start_extent = 0 extent_count = 16192 # 15.8125 Gigabytes You got 15GiB of metadata, so create your new metadata LV at least 30 GiB. Best Regards, Strahil NikolovOn Oct 2, 2019 04:49, jeremy_tourville(a)hotmail.com wrote: > > I don't know why I didn't think to get some more info regarding my storage environment and post it here earlier. My gluster_vg1 volume is on /dev/sda1. I can access the engine storage directory but I think that is because it is not thin provisioned. I guess I was too bogged down in solving the problem when I'm stuck in emergency mode. I had to sneaker net my USB drive to my system so I could capture some info. Anyhow here it is: > > # lsblk > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT > sda 8:0 0 5.5T 0 disk > └─sda1 8:1 0 5.5T 0 part > sdb 8:16 0 223.6G 0 disk > ├─sdb1 8:17 0 1G 0 part /boot > └─sdb2 8:18 0 222.6G 0 part > └─md127 9:127 0 222.5G 0 raid1 > ├─onn_vmh-swap 253:0 0 4G 0 lvm [SWAP] > ├─onn_vmh-pool00_tmeta 253:1 0 1G 0 lvm > │ └─onn_vmh-pool00-tpool 253:3 0 173.6G 0 lvm > │ ├─onn_vmh-ovirt--node--ng--4.2.7.1--0.20181216.0+1 253:4 0 146.6G 0 lvm / > │ ├─onn_vmh-pool00 253:5 0 173.6G 0 lvm > │ ├─onn_vmh-root 253:6 0 146.6G 0 lvm > │ ├─onn_vmh-home 253:7 0 1G 0 lvm /home > │ ├─onn_vmh-tmp 253:8 0 1G 0 lvm /tmp > │ ├─onn_vmh-var 253:9 0 15G 0 lvm /var > │ ├─onn_vmh-var_log 253:10 0 8G 0 lvm /var/log > │ ├─onn_vmh-var_log_audit 253:11 0 2G 0 lvm /var/log/audit > │ └─onn_vmh-var_crash 253:12 0 10G 0 lvm /var/crash > └─onn_vmh-pool00_tdata 253:2 0 173.6G 0 lvm > └─onn_vmh-pool00-tpool 253:3 0 173.6G 0 lvm > ├─onn_vmh-ovirt--node--ng--4.2.7.1--0.20181216.0+1 253:4 0 146.6G 0 lvm / > ├─onn_vmh-pool00 253:5 0 173.6G 0 lvm > ├─onn_vmh-root 253:6 0 146.6G 0 lvm > ├─onn_vmh-home 253:7 0 1G 0 lvm /home > ├─onn_vmh-tmp 253:8 0 1G 0 lvm /tmp > ├─onn_vmh-var 253:9 0 15G 0 lvm /var > ├─onn_vmh-var_log 253:10 0 8G 0 lvm /var/log > ├─onn_vmh-var_log_audit 253:11 0 2G 0 lvm /var/log/audit > └─onn_vmh-var_crash 253:12 0 10G 0 lvm /var/crash > sdc 8:32 0 223.6G 0 disk > └─sdc1 8:33 0 222.6G 0 part > └─md127 9:127 0 222.5G 0 raid1 > ├─onn_vmh-swap 253:0 0 4G 0 lvm [SWAP] > ├─onn_vmh-pool00_tmeta 253:1 0 1G 0 lvm > │ └─onn_vmh-pool00-tpool 253:3 0 173.6G 0 lvm > │ ├─onn_vmh-ovirt--node--ng--4.2.7.1--0.20181216.0+1 253:4 0 146.6G 0 lvm / > │ ├─onn_vmh-pool00 253:5 0 173.6G 0 lvm > │ ├─onn_vmh-root 253:6 0 146.6G 0 lvm > │ ├─onn_vmh-home 253:7 0 1G 0 lvm /home > │ ├─onn_vmh-tmp 253:8 0 1G 0 lvm /tmp > │ ├─onn_vmh-var 253:9 0 15G 0 lvm /var > │ ├─onn_vmh-var_log 253:10 0 8G 0 lvm /var/log > │ ├─onn_vmh-var_log_audit 253:11 0 2G 0 lvm /var/log/audit > │ └─onn_vmh-var_crash 253:12 0 10G 0 lvm /var/crash > └─onn_vmh-pool00_tdata 253:2 0 173.6G 0 lvm > └─onn_vmh-pool00-tpool 253:3 0 173.6G 0 lvm > ├─onn_vmh-ovirt--node--ng--4.2.7.1--0.20181216.0+1 253:4 0 146.6G 0 lvm / > ├─onn_vmh-pool00 253:5 0 173.6G 0 lvm > ├─onn_vmh-root 253:6 0 146.6G 0 lvm > ├─onn_vmh-home 253:7 0 1G 0 lvm /home > ├─onn_vmh-tmp 253:8 0 1G 0 lvm /tmp > ├─onn_vmh-var 253:9 0 15G 0 lvm /var > ├─onn_vmh-var_log 253:10 0 8G 0 lvm /var/log > ├─onn_vmh-var_log_audit 253:11 0 2G 0 lvm /var/log/audit > └─onn_vmh-var_crash 253:12 0 10G 0 lvm /var/crash > sdd 8:48 0 596.2G 0 disk > └─sdd1 8:49 0 4G 0 part > └─gluster_vg3-tmpLV 253:13 0 2G 0 lvm > sde 8:64 1 7.5G 0 disk > └─sde1 8:65 1 7.5G 0 part /mnt > > # blkid > /dev/sda1: UUID="f026a2dc-201a-4b43-974e-2419a8783bce" TYPE="xfs" PARTLABEL="Linux filesystem" PARTUUID="4bca8a3a-42f0-4877-aa60-f544bf1fdce7" > /dev/sdc1: UUID="e5f4acf5-a4bc-6470-7b6f-415e3f4077ff" UUID_SUB="a895900e-5585-8f31-7515-1ff7534e39d7" LABEL="vmh.cyber-range.lan:pv00" TYPE="linux_raid_member" > /dev/sdb1: UUID="9b9546f9-25d2-42a6-835b-303f32aee4b1" TYPE="ext4" > /dev/sdb2: UUID="e5f4acf5-a4bc-6470-7b6f-415e3f4077ff" UUID_SUB="6e20b5dd-0152-7f42-22a7-c17133fbce45" LABEL="vmh.cyber-range.lan:pv00" TYPE="linux_raid_member" > /dev/sdd1: UUID="2nLjVF-sh3N-0qkm-aUQ1-jnls-3e8W-tUkBw5" TYPE="LVM2_member" > /dev/md127: UUID="Mq1chn-6XhF-WCwF-LYhl-tZEz-Y8lq-8R2Ifq" TYPE="LVM2_member" > /dev/mapper/onn_vmh-swap: UUID="1b0b9c91-22ed-41d1-aebf-e22fd9aa05d9" TYPE="swap" > /dev/mapper/onn_vmh-ovirt--node--ng--4.2.7.1--0.20181216.0+1: UUID="b0e1c479-9696-4e19-b799-7f81236026b7" TYPE="ext4" > /dev/mapper/onn_vmh-root: UUID="60905f5d-ed91-4ca9-9729-9a72a4678ddd" TYPE="ext4" > /dev/mapper/onn_vmh-home: UUID="82a1d567-f8af-4b96-bfbf-5f79dff7384f" TYPE="ext4" > /dev/mapper/onn_vmh-tmp: UUID="7dd9d3ae-3af7-4763-9683-19f583d8d15b" TYPE="ext4" > /dev/mapper/onn_vmh-var: UUID="f206e030-876b-45a9-8a90-a0e54005b85c" TYPE="ext4" > /dev/mapper/onn_vmh-var_log: UUID="b8a12f56-0818-416c-9fb7-33b48ef29eed" TYPE="ext4" > /dev/mapper/onn_vmh-var_log_audit: UUID="bc78ad0c-9ab6-4f57-a69f-5b1ddf898552" TYPE="ext4" > /dev/mapper/onn_vmh-var_crash: UUID="a941d416-4d7d-41ae-bcd4-8c1ec9d0f744" TYPE="ext4" > /dev/sde1: UUID="44aa40d0-6c82-4e8e-8218-177e5c8474f4" TYPE="ext4" > > # pvscan > PV /dev/md127 VG onn_vmh lvm2 [222.44 GiB / 43.66 GiB free] > PV /dev/sdd1 VG gluster_vg3 lvm2 [<4.00 GiB / <2.00 GiB free] > Total: 2 [<226.44 GiB] / in use: 2 [<226.44 GiB] / in no VG: 0 [0 ] > Reading all physical volumes. This may take a while... > Found volume group "onn_vmh" using metadata type lvm2 > Found volume group "gluster_vg3" using metadata type lvm2 > > # lvscan > ACTIVE '/dev/onn_vmh/pool00' [173.60 GiB] inherit > ACTIVE '/dev/onn_vmh/root' [146.60 GiB] inherit > ACTIVE '/dev/onn_vmh/home' [1.00 GiB] inherit > ACTIVE '/dev/onn_vmh/tmp' [1.00 GiB] inherit > ACTIVE '/dev/onn_vmh/var' [15.00 GiB] inherit > ACTIVE '/dev/onn_vmh/var_log' [8.00 GiB] inherit > ACTIVE '/dev/onn_vmh/var_log_audit' [2.00 GiB] inherit > ACTIVE '/dev/onn_vmh/swap' [4.00 GiB] inherit > inactive '/dev/onn_vmh/ovirt-node-ng-4.2.7.1-0.20181216.0' [146.60 GiB] inherit > ACTIVE '/dev/onn_vmh/ovirt-node-ng-4.2.7.1-0.20181216.0+1' [146.60 GiB] inherit > ACTIVE '/dev/onn_vmh/var_crash' [10.00 GiB] inherit > ACTIVE '/dev/gluster_vg3/tmpLV' [2.00 GiB] inherit > > [/etc/lvm/backup/gluster_vg1] > # Generated by LVM2 version 2.02.180(2)-RHEL7 (2018-07-20): Sat Dec 22 10:18:46 2018 > > contents = "Text Format Volume Group" > version = 1 > > description = "Created *after* executing '/usr/sbin/lvcreate --virtualsize 500GB --name lv_datadisks -T gluster_vg1/lvthinpool'" > > creation_host = "vmh.cyber-range.lan" # Linux vmh.cyber-range.lan 3.10.0-957.1.3.el7.x86_64 #1 SMP Thu Nov 29 14:49:43 UTC 2018 x86_64 > creation_time = 1545495526 # Sat Dec 22 10:18:46 2018 > > gluster_vg1 { > id = "TfNqtn-2eX6-i5gC-w4ye-h29n-5Zfy-UFHSvU" > seqno = 9 > format = "lvm2" # informational > status = ["RESIZEABLE", "READ", "WRITE"] > flags = [] > extent_size = 2048 # 1024 Kilobytes > max_lv = 0 > max_pv = 0 > metadata_copies = 0 > > physical_volumes { > > pv0 { > id = "DRfoKl-TUhb-cirx-Oz9P-mZEY-XoiB-mdLy6v" > device = "/dev/sda" # Hint only > > status = ["ALLOCATABLE"] > flags = [] > dev_size = 11718885376 # 5.45703 Terabytes > pe_start = 2048 > pe_count = 5722111 # 5.45703 Terabytes > } > } > > logical_volumes { > > engine_lv { > id = "P2ScEB-ws3V-iqVv-XTWh-Y2Jh-pg0c-6KnJXC" > status = ["READ", "WRITE", "VISIBLE"] > flags = [] > creation_time = 1545495460 # 2018-12-22 10:17:40 -0600 > creation_host = "vmh.cyber-range.lan" > segment_count = 1 > > segment1 { > start_extent = 0 > extent_count = 102400 # 100 Gigabytes > > type = "striped" > stripe_count = 1 # linear > > stripes = [ > "pv0", 0 > ] > } > } > > lvthinpool { > id = "c0yaNn-DcaB-cYjj-9ZRv-M2Em-rzLW-qY9WpI" > status = ["READ", "WRITE", "VISIBLE"] > flags = [] > creation_time = 1545495487 # 2018-12-22 10:18:07 -0600 > creation_host = "vmh.cyber-range.lan" > segment_count = 1 > > segment1 { > start_extent = 0 > extent_count = 512000 # 500 Gigabytes > > type = "thin-pool" > metadata = "lvthinpool_tmeta" > pool = "lvthinpool_tdata" > transaction_id = 2 > chunk_size = 2048 # 1024 Kilobytes > discards = "passdown" > zero_new_blocks = 1 > } > } > > lv_vmdisks { > id = "erpXRi-nPUq-mCf2-ga2J-3a0l-OWiC-i0xr8M" > status = ["READ", "WRITE", "VISIBLE"] > flags = [] > creation_time = 1545495493 # 2018-12-22 10:18:13 -0600 > creation_host = "vmh.cyber-range.lan" > segment_count = 1 > > segment1 { > start_extent = 0 > extent_count = 4613735 # 4.4 Terabytes > > type = "thin" > thin_pool = "lvthinpool" > transaction_id = 0 > device_id = 1 > } > } > > lv_datadisks { > id = "hKim3z-1QCh-dwhU-st2O-t4tG-wIss-UpLMZw" > status = ["READ", "WRITE", "VISIBLE"] > flags = [] > creation_time = 1545495526 # 2018-12-22 10:18:46 -0600 > creation_host = "vmh.cyber-range.lan" > segment_count = 1 > > segment1 { > start_extent = 0 > extent_count = 512000 # 500 Gigabytes > > type = "thin" > thin_pool = "lvthinpool" > transaction_id = 1 > device_id = 2 > } > } > > lvol0_pmspare { > id = "bHc0eC-Z4Ed-mV47-QTU4-SCvo-FWbE-L8NV7Q" > status = ["READ", "WRITE"] > flags = [] > creation_time = 1545495487 # 2018-12-22 10:18:07 -0600 > creation_host = "vmh.cyber-range.lan" > segment_count = 1 > > segment1 { > start_extent = 0 > extent_count = 16192 # 15.8125 Gigabytes > > type = "striped" > stripe_count = 1 # linear > > stripes = [ > "pv0", 102400 > ] > } > } > > lvthinpool_tmeta { > id = "WBut10-rAOP-FzA7-bJvr-ZdxL-lB70-jzz1Tv" > status = ["READ", "WRITE"] > flags = [] > creation_time = 1545495487 # 2018-12-22 10:18:07 -0600 > creation_host = "vmh.cyber-range.lan" > segment_count = 1 > > segment1 { > start_extent = 0 > extent_count = 16192 # 15.8125 Gigabytes > > type = "striped" > stripe_count = 1 # linear > > stripes = [ > "pv0", 630592 > ] > } > } > > lvthinpool_tdata { > id = "rwNZux-1fz1-dv8J-yN2j-LcES-f6ml-231td5" > status = ["READ", "WRITE"] > flags = [] > creation_time = 1545495487 # 2018-12-22 10:18:07 -0600 > creation_host = "vmh.cyber-range.lan" > segment_count = 1 > > segment1 { > start_extent = 0 > extent_count = 512000 # 500 Gigabytes > > type = "striped" > stripe_count = 1 # linear > > stripes = [ > "pv0", 118592 > ] > } > } > } > > } > > > # cd /var/log > # grep -ri gluster_vg1-lvthinpool-tpool > messages-20190922:Sep 15 03:58:15 vmh lvm[14072]: Failed command for gluster_vg1-lvthinpool-tpool. > messages:Sep 22 03:44:05 vmh lvm[14072]: Failed command for gluster_vg1-lvthinpool-tpool. > messages-20190908:Sep 1 21:27:14 vmh lvm[14062]: Monitoring thin pool gluster_vg1-lvthinpool-tpool. > messages-20190908:Sep 1 21:27:24 vmh lvm[14062]: WARNING: Thin pool gluster_vg1-lvthinpool-tpool data is now 100.00% full. > messages-20190908:Sep 2 00:19:05 vmh lvm[14072]: Monitoring thin pool gluster_vg1-lvthinpool-tpool. > messages-20190908:Sep 2 00:19:15 vmh lvm[14072]: WARNING: Thin pool gluster_vg1-lvthinpool-tpool data is now 100.00% full. > messages-20190908:Sep 2 20:16:34 vmh lvm[14072]: Failed command for gluster_vg1-lvthinpool-tpool. > > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ > List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/PPTNPPD3SQL3I…

1 0

Re: Ovirt 4.2.7 won't start and drops to emergency console
by Strahil 02 Oct '19

02 Oct '19

Try to get all data in advance (before deactivating the VG). I still can't imagine why the VG will disappear. Try with 'pvscan --cache' to redetect the PV. Afrer all , all VG info is in the PVs' headers and should be visible no matter the VG is deactivated or not. Best Regards, Strahil NikolovOn Oct 2, 2019 02:08, jeremy_tourville(a)hotmail.com wrote: > > "lvs -a" does not list the logical volume I am missing. > "lvdisplay -m /dev/gluster_vg1-lvthinpool-tpool_tmeta" does not work either. Error message is: Volume Group xxx not found. Cannot process volume group xxx." > > I am trying to follow the procedure from https://access.redhat.com/solutions/3251681 > I am on step #2 Step 2a and 2b work without issue. Step 2c give me an error. Here are the values I am using: > # lvcreate -L 2G gluster_vg3 --name tmpLV > # lvchange -ay gluster_vg3/tmpLV > # lvconvert --thinpool gluster_vg1/lvthinpool --poolmetadata gluster_vg3/tmpLV > > VG name mismatch from position arg (gluster_vg1) and option arg (gluster_vg3) > > Do I need to create the LV on the same disk that failed? (gluster_vg1) > Is creating a new LV on (gluster_vg3) ok for this situation? > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ > List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/OJN6VVEMQY743…

1 0

how to put or conditions in filters in web admin gui
by Gianluca Cecchi 02 Oct '19

02 Oct '19

Hello, environment tin 4.3.6. Suppose I'm in Web Admin GUI in Storage --> Disks and I want to get displayed only the disks with "pattern1" together with the disks with "string2" ("or" condition), limiting output to these two conditions, how can I do it? I tried some combinations without success BTW: also the "and" condition seems not to work Thanks, Gianluca

3 4

oVirt Hyperconverged disaster recovery questions
by wodel youchi 02 Oct '19

02 Oct '19

Hi, oVirt Hyperconverged disaster recovery uses georeplication to replicate the volume containing the VMs. What I know about georeplication is that it is an asynchronous replication. My questions are : - How the replication of the VMs is done, are only the changes synchronized? - What is the interval of this replication? can this interval be configured taking into consideration the bandwidth of the replication link. - How can the RPO be measured in the case of a georeplication? Regards.

1 0

Re: Cannot enable maintenance mode
by Bruno Martins 02 Oct '19

02 Oct '19

Hello guys, No ideas for this issue? Thanks for your cooperation! Kind regards, -----Original Message----- From: Bruno Martins <bruno.o.martins(a)gfi.world> Sent: 29 de setembro de 2019 16:16 To: users(a)ovirt.org Subject: [ovirt-users] Cannot enable maintenance mode Hello guys, I am being unable to put a host from a two nodes cluster into maintenance mode in order to remove it from the cluster afterwards. This is what I see in engine.log: 2019-09-27 16:20:58,364 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-6-thread-45) [4cc251c9] Correlation ID: 4cc251c9, Job ID: 65731fbb-db34-49a9-ab56-9fba59bc0ee0, Call Stack: null, Custom Event ID: -1, Message: Host CentOS-H1 cannot change into maintenance mode - not all Vms have been migrated successfully. Consider manual intervention: stopping/migrating Vms: Non interactive user (User: admin). Host has been rebooted multiple times. vdsClient shows no VM's running. What else can I do? Kind regards, Bruno Martins _______________________________________________ Users mailing list -- users(a)ovirt.org To unsubscribe send an email to users-leave(a)ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/X5FJWFW7GXNW6…

1 0

Incremental backup using ovirt api
by smidhunraj＠gmail.com 02 Oct '19

02 Oct '19

Hi, I tried to take incremental backup of a vm using this script. public function downloadDiskIncremental(){ $data=array(); $xmlStr = "<disk_attachment> <disk id='1371afdd-91d4-4bc7-9792-0efbf6bbd1c9'> <backup>incremental</backup> </disk> </disk_attachment>"; $curlParam=array( "url" => "vms/4044e014-7e20-4dbc-abe5-64690ec45f63/diskattachments", "method" => "POST", "data" =>$xmlStr, ); } But it is throwing me error as Array ( [status] => error [message] => For correct usage, see: https://ovirt.bobcares.com/ovirt-engine/api/v4/model#services/disk-attachme… Please help me with this issue....

2 1