[ovirt-users] How to config ovirt-engine to Https ?
The https web access is ok,but I cant login the ovirt-engine,how to config a https web? zhou...@vip.friendtimes.net ___ 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/43UGIBIJ23HSADJ5XYPRH57MCYPOIFS4/
[ovirt-users] Re: Host has time-drift of xxx seconds
Thanks Eli for your reply.
Bug is opened: https://bugzilla.redhat.com/show_bug.cgi?id=1848353
Best Regards,
Strahil Nikolov
На 16 юни 2020 г. 0:20:45 GMT+03:00, Eli Mesika написа:
>Hi
>
>Looking at the code I realized that the date/time retrieved from the
>host
>is cached and not refreshed again until the RHV manager engine is
>restarted
>Please open a bug on that, we should be able to notice that the problem
>was
>fixed
>
>Thanks
>Eli
>
>On Thu, Jun 11, 2020 at 6:02 AM Strahil Nikolov via Users
>
>wrote:
>
>> Hello All,
>>
>> I have a strange error that should be fixed but the event log is
>still
>> filling with the following after the latest patching (4.3.10):
>>
>> Host ovirt2.localdomain has time-drift of 2909848 seconds while
>maximum
>> configured value is 300 seconds.
>> Host ovirt3.localdomain has time-drift of 2909848 seconds while
>maximum
>> configured value is 300 seconds.
>>
>> As it blamed only 2 out of 3 systems, I checked what has happened
>on
>> ovirt1 and that one was far behind the other servers.
>>
>> Once I fixed the issue, I kept receiving those errors despite tthe
>fact
>> that I fixed the time drift on ovirt1 several days ago.
>> Currently the hosts and the engine are OK, but I got no idea how to
>'fix'
>> the issue.
>>
>> I have also noticed that the 2 errors had a date of 2 PM which is
>not
>> possible with my current timezone.
>>
>> Here is a one-shot query from all nodes:
>>
>> [root@ovirt1 ~]# for i in ovirt{1..3}; do ssh $i "ntpdate -q
>> office.ipacct.com"; done
>> server 195.85.215.8, stratum 1, offset 0.001233, delay 0.03105
>> 11 Jun 05:48:16 ntpdate[5224]: adjust time server 195.85.215.8 offset
>> 0.001233 sec
>> server 195.85.215.8, stratum 1, offset -0.000200, delay 0.02821
>> 11 Jun 05:48:23 ntpdate[6637]: adjust time server 195.85.215.8 offset
>> -0.000200 sec
>> server 195.85.215.8, stratum 1, offset 0.000243, delay 0.02914
>> 11 Jun 05:48:30 ntpdate[14215]: adjust time server 195.85.215.8
>offset
>> 0.000243 sec
>> [root@ovirt1 ~]# ssh engine 'ntpdate -q office.ipacct.com'
>> root@engine's password:
>> server 195.85.215.8, stratum 1, offset 0.000291, delay 0.02888
>> 11 Jun 05:49:15 ntpdate[13911]: adjust time server 195.85.215.8
>offset
>> 0.000291 sec
>>
>> Any ideas ?
>>
>> 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/B2IGFLACF66RX2SUWBTAX66GZTJJ4T4L/
>>
___
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/YFLXMGBRILSU4ER347SX7Z4EXQ6ZCMSE/
[ovirt-users] Re: Fwd: Fwd: Issues with Gluster Domain
Check on the hosts tab , which is your current SPM (last column in Admin UI). Then open the /var/log/vdsm/vdsm.log and repeat the operation. Then provide the log from that host and the engine's log (on the HostedEngine VM or on your standalone engine). Best Regards, Strahil Nikolov На 18 юни 2020 г. 23:59:36 GMT+03:00, C Williams написа: >Resending to eliminate email issues > >-- Forwarded message - >From: C Williams >Date: Thu, Jun 18, 2020 at 4:01 PM >Subject: Re: [ovirt-users] Fwd: Issues with Gluster Domain >To: Strahil Nikolov > > >Here is output from mount > >192.168.24.12:/stor/import0 on >/rhev/data-center/mnt/192.168.24.12:_stor_import0 >type nfs4 >(rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,soft,nosharecache,proto=tcp,timeo=600,retrans=6,sec=sys,clientaddr=192.168.24.18,local_lock=none,addr=192.168.24.12) >192.168.24.13:/stor/import1 on >/rhev/data-center/mnt/192.168.24.13:_stor_import1 >type nfs4 >(rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,soft,nosharecache,proto=tcp,timeo=600,retrans=6,sec=sys,clientaddr=192.168.24.18,local_lock=none,addr=192.168.24.13) >192.168.24.13:/stor/iso1 on >/rhev/data-center/mnt/192.168.24.13:_stor_iso1 >type nfs4 >(rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,soft,nosharecache,proto=tcp,timeo=600,retrans=6,sec=sys,clientaddr=192.168.24.18,local_lock=none,addr=192.168.24.13) >192.168.24.13:/stor/export0 on >/rhev/data-center/mnt/192.168.24.13:_stor_export0 >type nfs4 >(rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,soft,nosharecache,proto=tcp,timeo=600,retrans=6,sec=sys,clientaddr=192.168.24.18,local_lock=none,addr=192.168.24.13) >192.168.24.15:/images on >/rhev/data-center/mnt/glusterSD/192.168.24.15:_images >type fuse.glusterfs >(rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072) >192.168.24.18:/images3 on >/rhev/data-center/mnt/glusterSD/192.168.24.18:_images3 >type fuse.glusterfs >(rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072) >tmpfs on /run/user/0 type tmpfs >(rw,nosuid,nodev,relatime,seclabel,size=13198392k,mode=700) >[root@ov06 glusterfs]# > >Also here is a screenshot of the console > >[image: image.png] >The other domains are up > >Import0 and Import1 are NFS . GLCL0 is gluster. They all are running >VMs > >Thank You For Your Help ! > >On Thu, Jun 18, 2020 at 3:51 PM Strahil Nikolov >wrote: > >> I don't see '/rhev/data-center/mnt/192.168.24.13:_stor_import1' >mounted >> at all . >> What is the status of all storage domains ? >> >> Best Regards, >> Strahil Nikolov >> >> На 18 юни 2020 г. 21:43:44 GMT+03:00, C Williams > >> написа: >> > Resending to deal with possible email issues >> > >> >-- Forwarded message - >> >From: C Williams >> >Date: Thu, Jun 18, 2020 at 2:07 PM >> >Subject: Re: [ovirt-users] Issues with Gluster Domain >> >To: Strahil Nikolov >> > >> > >> >More >> > >> >[root@ov06 ~]# for i in $(gluster volume list); do echo $i;echo; >> >gluster >> >volume info $i; echo;echo;gluster volume status >$i;echo;echo;echo;done >> >images3 >> > >> > >> >Volume Name: images3 >> >Type: Replicate >> >Volume ID: 0243d439-1b29-47d0-ab39-d61c2f15ae8b >> >Status: Started >> >Snapshot Count: 0 >> >Number of Bricks: 1 x 3 = 3 >> >Transport-type: tcp >> >Bricks: >> >Brick1: 192.168.24.18:/bricks/brick04/images3 >> >Brick2: 192.168.24.19:/bricks/brick05/images3 >> >Brick3: 192.168.24.20:/bricks/brick06/images3 >> >Options Reconfigured: >> >performance.client-io-threads: on >> >nfs.disable: on >> >transport.address-family: inet >> >user.cifs: off >> >auth.allow: * >> >performance.quick-read: off >> >performance.read-ahead: off >> >performance.io-cache: off >> >performance.low-prio-threads: 32 >> >network.remote-dio: off >> >cluster.eager-lock: enable >> >cluster.quorum-type: auto >> >cluster.server-quorum-type: server >> >cluster.data-self-heal-algorithm: full >> >cluster.locking-scheme: granular >> >cluster.shd-max-threads: 8 >> >cluster.shd-wait-qlength: 1 >> >features.shard: on >> >cluster.choose-local: off >> >client.event-threads: 4 >> >server.event-threads: 4 >> >storage.owner-uid: 36 >> >storage.owner-gid: 36 >> >performance.strict-o-direct: on >> >network.ping-timeout: 30 >> >cluster.granular-entry-heal: enable >> > >> > >> >Status of volume: images3 >> >Gluster process TCP Port RDMA Port >Online >> > Pid >> >> >>-- >> >Brick 192.168.24.18:/bricks/brick04/images3 49152 0 Y >> > >> >Brick 192.168.24.19:/bricks/brick05/images3 49152 0 Y >> >6779 >> >Brick 192.168.24.20:/bricks/brick06/images3 49152 0 Y >> >7227 >> >Self-heal Daemon on localhost N/A N/AY >> >6689 >> >Self-heal Daemon on ov07.ntc.srcle.com N/A N/AY >> >6802 >> >Self-heal Daemon on ov08.ntc.srcle.com N/A N/AY
[ovirt-users] Re: Fwd: Issues with Gluster Domain
I don't see '/rhev/data-center/mnt/192.168.24.13:_stor_import1' mounted at all . What is the status of all storage domains ? Best Regards, Strahil Nikolov На 18 юни 2020 г. 21:43:44 GMT+03:00, C Williams написа: > Resending to deal with possible email issues > >-- Forwarded message - >From: C Williams >Date: Thu, Jun 18, 2020 at 2:07 PM >Subject: Re: [ovirt-users] Issues with Gluster Domain >To: Strahil Nikolov > > >More > >[root@ov06 ~]# for i in $(gluster volume list); do echo $i;echo; >gluster >volume info $i; echo;echo;gluster volume status $i;echo;echo;echo;done >images3 > > >Volume Name: images3 >Type: Replicate >Volume ID: 0243d439-1b29-47d0-ab39-d61c2f15ae8b >Status: Started >Snapshot Count: 0 >Number of Bricks: 1 x 3 = 3 >Transport-type: tcp >Bricks: >Brick1: 192.168.24.18:/bricks/brick04/images3 >Brick2: 192.168.24.19:/bricks/brick05/images3 >Brick3: 192.168.24.20:/bricks/brick06/images3 >Options Reconfigured: >performance.client-io-threads: on >nfs.disable: on >transport.address-family: inet >user.cifs: off >auth.allow: * >performance.quick-read: off >performance.read-ahead: off >performance.io-cache: off >performance.low-prio-threads: 32 >network.remote-dio: off >cluster.eager-lock: enable >cluster.quorum-type: auto >cluster.server-quorum-type: server >cluster.data-self-heal-algorithm: full >cluster.locking-scheme: granular >cluster.shd-max-threads: 8 >cluster.shd-wait-qlength: 1 >features.shard: on >cluster.choose-local: off >client.event-threads: 4 >server.event-threads: 4 >storage.owner-uid: 36 >storage.owner-gid: 36 >performance.strict-o-direct: on >network.ping-timeout: 30 >cluster.granular-entry-heal: enable > > >Status of volume: images3 >Gluster process TCP Port RDMA Port Online > Pid >-- >Brick 192.168.24.18:/bricks/brick04/images3 49152 0 Y > >Brick 192.168.24.19:/bricks/brick05/images3 49152 0 Y >6779 >Brick 192.168.24.20:/bricks/brick06/images3 49152 0 Y >7227 >Self-heal Daemon on localhost N/A N/AY >6689 >Self-heal Daemon on ov07.ntc.srcle.com N/A N/AY >6802 >Self-heal Daemon on ov08.ntc.srcle.com N/A N/AY >7250 > >Task Status of Volume images3 >-- >There are no active volume tasks > > > > >[root@ov06 ~]# ls -l /rhev/data-center/mnt/glusterSD/ >total 16 >drwxr-xr-x. 5 vdsm kvm 8192 Jun 18 14:04 192.168.24.15:_images >drwxr-xr-x. 5 vdsm kvm 8192 Jun 18 14:05 192.168.24.18:_images3 >[root@ov06 ~]# > >On Thu, Jun 18, 2020 at 2:03 PM C Williams >wrote: > >> Strahil, >> >> Here you go -- Thank You For Your Help ! >> >> BTW -- I can write a test file to gluster and it replicates properly. >> Thinking something about the oVirt Storage Domain ? >> >> [root@ov08 ~]# gluster pool list >> UUIDHostnameState >> 5b40c659-d9ab-43c3-9af8-18b074ea0b83ov06 >Connected >> 36ce5a00-6f65-4926-8438-696944ebadb5ov07.ntc.srcle.com >Connected >> c7e7abdb-a8f4-4842-924c-e227f0db1b29localhost >Connected >> [root@ov08 ~]# gluster volume list >> images3 >> >> On Thu, Jun 18, 2020 at 1:13 PM Strahil Nikolov > >> wrote: >> >>> Log to the oVirt cluster and provide the output of: >>> gluster pool list >>> gluster volume list >>> for i in $(gluster volume list); do echo $i;echo; gluster volume >info >>> $i; echo;echo;gluster volume status $i;echo;echo;echo;done >>> >>> ls -l /rhev/data-center/mnt/glusterSD/ >>> >>> Best Regards, >>> Strahil Nikolov >>> >>> >>> На 18 юни 2020 г. 19:17:46 GMT+03:00, C Williams > >>> написа: >>> >Hello, >>> > >>> >I recently added 6 hosts to an existing oVirt compute/gluster >cluster. >>> > >>> >Prior to this attempted addition, my cluster had 3 Hypervisor hosts >and >>> >3 >>> >gluster bricks which made up a single gluster volume (replica 3 >volume) >>> >. I >>> >added the additional hosts and made a brick on 3 of the new hosts >and >>> >attempted to make a new replica 3 volume. I had difficulty >creating >>> >the >>> >new volume. So, I decided that I would make a new compute/gluster >>> >cluster >>> >for each set of 3 new hosts. >>> > >>> >I removed the 6 new hosts from the existing oVirt Compute/Gluster >>> >Cluster >>> >leaving the 3 original hosts in place with their bricks. At that >point >>> >my >>> >original bricks went down and came back up . The volume showed >entries >>> >that >>> >needed healing. At that point I ran gluster volume heal images3 >full, >>> >etc. >>> >The volume shows no unhealed entries. I also corrected some peer >>> >errors. >>> > >>> >However, I am unable to copy disks, move disks to another domain, >>> >export >>> >disks, etc. It appears that the engine cannot locate disks properly >and >>> >I >>> >get storage I/O errors. >>>
[ovirt-users] Fwd: Issues with Gluster Domain
Resending to deal with possible email issues
-- Forwarded message -
From: C Williams
Date: Thu, Jun 18, 2020 at 2:07 PM
Subject: Re: [ovirt-users] Issues with Gluster Domain
To: Strahil Nikolov
More
[root@ov06 ~]# for i in $(gluster volume list); do echo $i;echo; gluster
volume info $i; echo;echo;gluster volume status $i;echo;echo;echo;done
images3
Volume Name: images3
Type: Replicate
Volume ID: 0243d439-1b29-47d0-ab39-d61c2f15ae8b
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
Brick1: 192.168.24.18:/bricks/brick04/images3
Brick2: 192.168.24.19:/bricks/brick05/images3
Brick3: 192.168.24.20:/bricks/brick06/images3
Options Reconfigured:
performance.client-io-threads: on
nfs.disable: on
transport.address-family: inet
user.cifs: off
auth.allow: *
performance.quick-read: off
performance.read-ahead: off
performance.io-cache: off
performance.low-prio-threads: 32
network.remote-dio: off
cluster.eager-lock: enable
cluster.quorum-type: auto
cluster.server-quorum-type: server
cluster.data-self-heal-algorithm: full
cluster.locking-scheme: granular
cluster.shd-max-threads: 8
cluster.shd-wait-qlength: 1
features.shard: on
cluster.choose-local: off
client.event-threads: 4
server.event-threads: 4
storage.owner-uid: 36
storage.owner-gid: 36
performance.strict-o-direct: on
network.ping-timeout: 30
cluster.granular-entry-heal: enable
Status of volume: images3
Gluster process TCP Port RDMA Port Online Pid
--
Brick 192.168.24.18:/bricks/brick04/images3 49152 0 Y
Brick 192.168.24.19:/bricks/brick05/images3 49152 0 Y
6779
Brick 192.168.24.20:/bricks/brick06/images3 49152 0 Y
7227
Self-heal Daemon on localhost N/A N/AY
6689
Self-heal Daemon on ov07.ntc.srcle.com N/A N/AY
6802
Self-heal Daemon on ov08.ntc.srcle.com N/A N/AY
7250
Task Status of Volume images3
--
There are no active volume tasks
[root@ov06 ~]# ls -l /rhev/data-center/mnt/glusterSD/
total 16
drwxr-xr-x. 5 vdsm kvm 8192 Jun 18 14:04 192.168.24.15:_images
drwxr-xr-x. 5 vdsm kvm 8192 Jun 18 14:05 192.168.24.18:_images3
[root@ov06 ~]#
On Thu, Jun 18, 2020 at 2:03 PM C Williams wrote:
> Strahil,
>
> Here you go -- Thank You For Your Help !
>
> BTW -- I can write a test file to gluster and it replicates properly.
> Thinking something about the oVirt Storage Domain ?
>
> [root@ov08 ~]# gluster pool list
> UUIDHostnameState
> 5b40c659-d9ab-43c3-9af8-18b074ea0b83ov06Connected
> 36ce5a00-6f65-4926-8438-696944ebadb5ov07.ntc.srcle.com Connected
> c7e7abdb-a8f4-4842-924c-e227f0db1b29localhost Connected
> [root@ov08 ~]# gluster volume list
> images3
>
> On Thu, Jun 18, 2020 at 1:13 PM Strahil Nikolov
> wrote:
>
>> Log to the oVirt cluster and provide the output of:
>> gluster pool list
>> gluster volume list
>> for i in $(gluster volume list); do echo $i;echo; gluster volume info
>> $i; echo;echo;gluster volume status $i;echo;echo;echo;done
>>
>> ls -l /rhev/data-center/mnt/glusterSD/
>>
>> Best Regards,
>> Strahil Nikolov
>>
>>
>> На 18 юни 2020 г. 19:17:46 GMT+03:00, C Williams
>> написа:
>> >Hello,
>> >
>> >I recently added 6 hosts to an existing oVirt compute/gluster cluster.
>> >
>> >Prior to this attempted addition, my cluster had 3 Hypervisor hosts and
>> >3
>> >gluster bricks which made up a single gluster volume (replica 3 volume)
>> >. I
>> >added the additional hosts and made a brick on 3 of the new hosts and
>> >attempted to make a new replica 3 volume. I had difficulty creating
>> >the
>> >new volume. So, I decided that I would make a new compute/gluster
>> >cluster
>> >for each set of 3 new hosts.
>> >
>> >I removed the 6 new hosts from the existing oVirt Compute/Gluster
>> >Cluster
>> >leaving the 3 original hosts in place with their bricks. At that point
>> >my
>> >original bricks went down and came back up . The volume showed entries
>> >that
>> >needed healing. At that point I ran gluster volume heal images3 full,
>> >etc.
>> >The volume shows no unhealed entries. I also corrected some peer
>> >errors.
>> >
>> >However, I am unable to copy disks, move disks to another domain,
>> >export
>> >disks, etc. It appears that the engine cannot locate disks properly and
>> >I
>> >get storage I/O errors.
>> >
>> >I have detached and removed the oVirt Storage Domain. I reimported the
>> >domain and imported 2 VMs, But the VM disks exhibit the same behaviour
>> >and
>> >won't run from the hard disk.
>> >
>> >
>> >I get errors such as this
>> >
>> >VDSM ov05 command HSMGetAllTasksStatusesVDS failed: low level Image
>> >copy
>> >failed: ("Command ['/usr/bin/qemu-img', 'convert', '-p', '-t',
[ovirt-users] Fwd: Issues with Gluster Domain
Resending to deal with possible email issues
Thank You For Your Help !!
-- Forwarded message -
From: C Williams
Date: Thu, Jun 18, 2020 at 2:03 PM
Subject: Re: [ovirt-users] Issues with Gluster Domain
To: Strahil Nikolov
Strahil,
Here you go -- Thank You For Your Help !
BTW -- I can write a test file to gluster and it replicates properly.
Thinking something about the oVirt Storage Domain ?
[root@ov08 ~]# gluster pool list
UUIDHostnameState
5b40c659-d9ab-43c3-9af8-18b074ea0b83ov06Connected
36ce5a00-6f65-4926-8438-696944ebadb5ov07.ntc.srcle.com Connected
c7e7abdb-a8f4-4842-924c-e227f0db1b29localhost Connected
[root@ov08 ~]# gluster volume list
images3
On Thu, Jun 18, 2020 at 1:13 PM Strahil Nikolov
wrote:
> Log to the oVirt cluster and provide the output of:
> gluster pool list
> gluster volume list
> for i in $(gluster volume list); do echo $i;echo; gluster volume info
> $i; echo;echo;gluster volume status $i;echo;echo;echo;done
>
> ls -l /rhev/data-center/mnt/glusterSD/
>
> Best Regards,
> Strahil Nikolov
>
>
> На 18 юни 2020 г. 19:17:46 GMT+03:00, C Williams
> написа:
> >Hello,
> >
> >I recently added 6 hosts to an existing oVirt compute/gluster cluster.
> >
> >Prior to this attempted addition, my cluster had 3 Hypervisor hosts and
> >3
> >gluster bricks which made up a single gluster volume (replica 3 volume)
> >. I
> >added the additional hosts and made a brick on 3 of the new hosts and
> >attempted to make a new replica 3 volume. I had difficulty creating
> >the
> >new volume. So, I decided that I would make a new compute/gluster
> >cluster
> >for each set of 3 new hosts.
> >
> >I removed the 6 new hosts from the existing oVirt Compute/Gluster
> >Cluster
> >leaving the 3 original hosts in place with their bricks. At that point
> >my
> >original bricks went down and came back up . The volume showed entries
> >that
> >needed healing. At that point I ran gluster volume heal images3 full,
> >etc.
> >The volume shows no unhealed entries. I also corrected some peer
> >errors.
> >
> >However, I am unable to copy disks, move disks to another domain,
> >export
> >disks, etc. It appears that the engine cannot locate disks properly and
> >I
> >get storage I/O errors.
> >
> >I have detached and removed the oVirt Storage Domain. I reimported the
> >domain and imported 2 VMs, But the VM disks exhibit the same behaviour
> >and
> >won't run from the hard disk.
> >
> >
> >I get errors such as this
> >
> >VDSM ov05 command HSMGetAllTasksStatusesVDS failed: low level Image
> >copy
> >failed: ("Command ['/usr/bin/qemu-img', 'convert', '-p', '-t', 'none',
> >'-T', 'none', '-f', 'raw',
> >u'/rhev/data-center/mnt/glusterSD/192.168.24.18:
> _images3/5fe3ad3f-2d21-404c-832e-4dc7318ca10d/images/3ea5afbd-0fe0-4c09-8d39-e556c66a8b3d/fe6eab63-3b22-4815-bfe6-4a0ade292510',
> >'-O', 'raw',
> >u'/rhev/data-center/mnt/192.168.24.13:
> _stor_import1/1ab89386-a2ba-448b-90ab-bc816f55a328/images/f707a218-9db7-4e23-8bbd-9b12972012b6/d6591ec5-3ede-443d-bd40-93119ca7c7d5']
> >failed with rc=1 out='' err=bytearray(b'qemu-img: error while reading
> >sector 135168: Transport endpoint is not connected\\nqemu-img: error
> >while
> >reading sector 131072: Transport endpoint is not connected\\nqemu-img:
> >error while reading sector 139264: Transport endpoint is not
> >connected\\nqemu-img: error while reading sector 143360: Transport
> >endpoint
> >is not connected\\nqemu-img: error while reading sector 147456:
> >Transport
> >endpoint is not connected\\nqemu-img: error while reading sector
> >155648:
> >Transport endpoint is not connected\\nqemu-img: error while reading
> >sector
> >151552: Transport endpoint is not connected\\nqemu-img: error while
> >reading
> >sector 159744: Transport endpoint is not connected\\n')",)
> >
> >oVirt version is 4.3.82-1.el7
> >OS CentOS Linux release 7.7.1908 (Core)
> >
> >The Gluster Cluster has been working very well until this incident.
> >
> >Please help.
> >
> >Thank You
> >
> >Charles Williams
>
___
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/PAUURXLJE5NIPHOXLLXNZYEQ77JGHOH7/
[ovirt-users] Re: Change Hosted engine VM cluster compatibility version throws error
> On 18 Jun 2020, at 08:59, Ritesh Chikatwar wrote: > > Hello Team, > > > When i try to change Cluster compatible version HE it throws error As what exactly are you changing where? > > Error while executing action: > > HostedEngine: > There was an attempt to change Hosted Engine VM values that are locked. > I am trying to change the version to 4.4 it was showing blank. > > Any suggestions on how I can edit. > > The VM other than HE is able to editi. > > > > Ritesh > ___ > 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/3EBGCBFDUBHNI6G5E3NG4DCD7RQJLUNC/ ___ 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/EJDEDCQJ6DMCMMLDTQJCBUAO2TPSDG2C/
[ovirt-users] Re: Issues with Gluster Domain
Log to the oVirt cluster and provide the output of:
gluster pool list
gluster volume list
for i in $(gluster volume list); do echo $i;echo; gluster volume info $i;
echo;echo;gluster volume status $i;echo;echo;echo;done
ls -l /rhev/data-center/mnt/glusterSD/
Best Regards,
Strahil Nikolov
На 18 юни 2020 г. 19:17:46 GMT+03:00, C Williams
написа:
>Hello,
>
>I recently added 6 hosts to an existing oVirt compute/gluster cluster.
>
>Prior to this attempted addition, my cluster had 3 Hypervisor hosts and
>3
>gluster bricks which made up a single gluster volume (replica 3 volume)
>. I
>added the additional hosts and made a brick on 3 of the new hosts and
>attempted to make a new replica 3 volume. I had difficulty creating
>the
>new volume. So, I decided that I would make a new compute/gluster
>cluster
>for each set of 3 new hosts.
>
>I removed the 6 new hosts from the existing oVirt Compute/Gluster
>Cluster
>leaving the 3 original hosts in place with their bricks. At that point
>my
>original bricks went down and came back up . The volume showed entries
>that
>needed healing. At that point I ran gluster volume heal images3 full,
>etc.
>The volume shows no unhealed entries. I also corrected some peer
>errors.
>
>However, I am unable to copy disks, move disks to another domain,
>export
>disks, etc. It appears that the engine cannot locate disks properly and
>I
>get storage I/O errors.
>
>I have detached and removed the oVirt Storage Domain. I reimported the
>domain and imported 2 VMs, But the VM disks exhibit the same behaviour
>and
>won't run from the hard disk.
>
>
>I get errors such as this
>
>VDSM ov05 command HSMGetAllTasksStatusesVDS failed: low level Image
>copy
>failed: ("Command ['/usr/bin/qemu-img', 'convert', '-p', '-t', 'none',
>'-T', 'none', '-f', 'raw',
>u'/rhev/data-center/mnt/glusterSD/192.168.24.18:_images3/5fe3ad3f-2d21-404c-832e-4dc7318ca10d/images/3ea5afbd-0fe0-4c09-8d39-e556c66a8b3d/fe6eab63-3b22-4815-bfe6-4a0ade292510',
>'-O', 'raw',
>u'/rhev/data-center/mnt/192.168.24.13:_stor_import1/1ab89386-a2ba-448b-90ab-bc816f55a328/images/f707a218-9db7-4e23-8bbd-9b12972012b6/d6591ec5-3ede-443d-bd40-93119ca7c7d5']
>failed with rc=1 out='' err=bytearray(b'qemu-img: error while reading
>sector 135168: Transport endpoint is not connected\\nqemu-img: error
>while
>reading sector 131072: Transport endpoint is not connected\\nqemu-img:
>error while reading sector 139264: Transport endpoint is not
>connected\\nqemu-img: error while reading sector 143360: Transport
>endpoint
>is not connected\\nqemu-img: error while reading sector 147456:
>Transport
>endpoint is not connected\\nqemu-img: error while reading sector
>155648:
>Transport endpoint is not connected\\nqemu-img: error while reading
>sector
>151552: Transport endpoint is not connected\\nqemu-img: error while
>reading
>sector 159744: Transport endpoint is not connected\\n')",)
>
>oVirt version is 4.3.82-1.el7
>OS CentOS Linux release 7.7.1908 (Core)
>
>The Gluster Cluster has been working very well until this incident.
>
>Please help.
>
>Thank You
>
>Charles Williams
___
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/YFJNLAOSXBYFU7WF2JUYFZE6WPK77J6E/
[ovirt-users] Issues with Gluster Domain
Hello,
I recently added 6 hosts to an existing oVirt compute/gluster cluster.
Prior to this attempted addition, my cluster had 3 Hypervisor hosts and 3
gluster bricks which made up a single gluster volume (replica 3 volume) . I
added the additional hosts and made a brick on 3 of the new hosts and
attempted to make a new replica 3 volume. I had difficulty creating the
new volume. So, I decided that I would make a new compute/gluster cluster
for each set of 3 new hosts.
I removed the 6 new hosts from the existing oVirt Compute/Gluster Cluster
leaving the 3 original hosts in place with their bricks. At that point my
original bricks went down and came back up . The volume showed entries that
needed healing. At that point I ran gluster volume heal images3 full, etc.
The volume shows no unhealed entries. I also corrected some peer errors.
However, I am unable to copy disks, move disks to another domain, export
disks, etc. It appears that the engine cannot locate disks properly and I
get storage I/O errors.
I have detached and removed the oVirt Storage Domain. I reimported the
domain and imported 2 VMs, But the VM disks exhibit the same behaviour and
won't run from the hard disk.
I get errors such as this
VDSM ov05 command HSMGetAllTasksStatusesVDS failed: low level Image copy
failed: ("Command ['/usr/bin/qemu-img', 'convert', '-p', '-t', 'none',
'-T', 'none', '-f', 'raw',
u'/rhev/data-center/mnt/glusterSD/192.168.24.18:_images3/5fe3ad3f-2d21-404c-832e-4dc7318ca10d/images/3ea5afbd-0fe0-4c09-8d39-e556c66a8b3d/fe6eab63-3b22-4815-bfe6-4a0ade292510',
'-O', 'raw',
u'/rhev/data-center/mnt/192.168.24.13:_stor_import1/1ab89386-a2ba-448b-90ab-bc816f55a328/images/f707a218-9db7-4e23-8bbd-9b12972012b6/d6591ec5-3ede-443d-bd40-93119ca7c7d5']
failed with rc=1 out='' err=bytearray(b'qemu-img: error while reading
sector 135168: Transport endpoint is not connected\\nqemu-img: error while
reading sector 131072: Transport endpoint is not connected\\nqemu-img:
error while reading sector 139264: Transport endpoint is not
connected\\nqemu-img: error while reading sector 143360: Transport endpoint
is not connected\\nqemu-img: error while reading sector 147456: Transport
endpoint is not connected\\nqemu-img: error while reading sector 155648:
Transport endpoint is not connected\\nqemu-img: error while reading sector
151552: Transport endpoint is not connected\\nqemu-img: error while reading
sector 159744: Transport endpoint is not connected\\n')",)
oVirt version is 4.3.82-1.el7
OS CentOS Linux release 7.7.1908 (Core)
The Gluster Cluster has been working very well until this incident.
Please help.
Thank You
Charles Williams
___
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/5JTOGVLEOI3M4LD7H3GRD2HXSN2W2CBK/
[ovirt-users] Re: cloud-init: reverts on reboot
On Fri, Jun 12, 2020 at 9:23 AM Florian Schmid via Users
wrote:
> Hi,
>
> we are using cloud-init for several years now and it looks like, that
> cloud-init needs a config for every boot, otherwise, it will use the
> default network config, which is DHCP.
>
> We come around this issue by adding this file:
> cat /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
> network: {config: disabled}
>
> by cloud-init itself on the first run.
>
> With this, cloud-init creates only once the network config and never
> touches it again.
> I would not completely disable cloud-init, because this could also have
> some drawbacks, like not being able to create a root/user password anymore,
> if on worst case, ssh is not working anymore...
>
> What we also fix on the first boot is the datasource_list
> -> datasource_list: ["NoCloud", "ConfigDrive"]
>
> Otherwise, we have an extremely long boot process (up to 5 minutes or so),
> because cloud-init tries to reach several cloud-config URLs.
>
> BR Florian
>
> - Ursprüngliche Mail -
> Von: "Jp"
> An: "users"
> Gesendet: Donnerstag, 11. Juni 2020 16:54:31
> Betreff: [ovirt-users] Re: cloud-init: reverts on reboot
>
> I re-read the docs on creating VMs.
>
> What is the difference between the Run Once w/ it's pop-up form vs the
> Initial Run with it's embedded form?
>
>From an engine point of view it's quite a difference, run once creates a
one-time configuration to start the VM with and then roll back to the
existing.
As for cloud-init, when you set it in the Edit VM, initial run (without
run-once), on the first time you will run the VM in your environment(first
boot for that VM in your environment), cloud-init will use it.
While, on run-once, it will use the configuration again.
>
> If an (updated) doc were to have a sequential workflow for using
> cloud-init in oVirt for a new VM's setup, would it look like this:
>
> * assume cloud-init already installed, ex. Glance image; so
> SysPre/Cloud-Init process already done*
>
> Glance Image Method
>
> 1. Import Image + Create Template
> 2. Create VM (_don't_ use Run; and _don't_ populate Initial Run tab)
> 3. start VM with Run Once (_not_ Run)
> 4. fill out Run Once pop-up form
> 5. VM boots as usual
> 6. remote Console/shell into VM to verify setting
> 7. Reboot or Shutdown/Run
> 8. use cloud-init'd VM like any other non-cloud-init'd VM
>
> That ^ look right?
>
I don't really understand point 8. But from at 5 the VM should consume the
cloud-init configuration and it should stay in the VM.
You may try and reconfigure if you use run-once again, setting cloud-init
configuration again.
It looks OK.
> Is CentOS8.2 out? I checked blog.centos.org but it looks like they had
build issues to still resolve as of last week ...
I'm not sure about centos8.2, adding +Sandro Bonazzola
.
> ___
> 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/LXA4TCGENOQ3PPNGTCRPZQQJYXSR52QI/
> ___
> 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/CE7MMZEETR3E5CQUGQ3RBI6KXFVOLUMD/
>
___
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/KO4JDDJ33RMXWY3B6VWIDGJDXARQVP2Z/
[ovirt-users] Re: Ovirt fails to retrieve iSCSI targets during installation
I didn't even change the value. Used the default value for it. ___ 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/6JUGKGH7ARR4KNVHI555ZA7I45PTATDM/
[ovirt-users] Re: Ovirt fails to retrieve iSCSI targets during installation
> "port\": \"3260,3260\" this looks strange. Did you specify port correctly? signature.asc Description: This is a digitally signed message part. ___ 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/RHGFZ5J5HK7DBVD5NONCCJZFFMDTFD6Y/
[ovirt-users] Re: Cannot authenticate user Invalid scopes: ovirt-app-api
So I think I have narrowed it down to the OVN settings. The only problem now
is, is that when I want to update the OVN settings, it fails with “Failed to
communicate with External Provider. See logs for details”
When checking the logs, I see an error stating the “root hostname does not
match” (In the OVN settings via the WebUI, I see that it also points to the old
hostname)
A bit of background on this, when the engine was initially built, it was
configured with a different hostname, which was then changed, but somehow it is
still referencing the old hostname. When I run the change hostname scripts
(/usr/share/ovirt-engine/setup/bin/ovirt-engine-rename) it runs through
everything, until it needs to modify the certs. (I have attached the screenshot)
I am really not sure where to go from here, and I believe that most of this has
to do with the certs (And I am just grasping at straws here)
I am starting to think that it would just be easier to deploy everything from
scratch, but if anybody has any ideas, I would appreciate it.
Thank you
Anton Louw
Cloud Engineer: Storage and Virtualization
__
D: 087 805 1572 | M: N/A
A: Rutherford Estate, 1 Scott Street, Waverley, Johannesburg
anton.l...@voxtelecom.co.za
www.vox.co.za
From: Anton Louw via Users
Sent: 18 June 2020 12:39
To: users@ovirt.org
Subject: [ovirt-users] Cannot authenticate user Invalid scopes: ovirt-app-api
Hi All,
A new issue
We have configured oVirt to use KeyCloak for authentication. This all works, I
can log into the WebUI etc, but as soon as I need to talk to the API, it gives
me the “invalid scopes” error. I have double checked KeyCloak, and the scopes
are added. I went through the logs, but there is nothing telling me exactly
what the actual cause is.
I get the below when trying to get a token from the engine:
“{"error_code":"access_denied","error":"Cannot authenticate user Invalid
scopes: ovirt-app-api ovirt-ext=token-info:authz-search
ovirt-ext=token-info:public-authz-search ovirt-ext=token-info:validate
ovirt-ext=token:password-access."}”
Does anybody have any idea where this is going wrong?
Thanks
Anton Louw
Cloud Engineer: Storage and Virtualization at Vox
T: 087 805 | D: 087 805 1572
M: N/A
E: anton.l...@voxtelecom.co.za
A: Rutherford Estate, 1 Scott Street, Waverley, Johannesburg
www.vox.co.za
[F]
[T]
[I]
[L]
[Y]
[#VoxBrand]
Disclaimer
The contents of this email are confidential to the sender and the intended
recipient. Unless the contents are clearly and entirely of a personal nature,
they are subject to copyright in favour of the holding company of the Vox group
of companies. Any recipient who receives this email in error should immediately
report the error to the sender and permanently delete this email from all
storage devices.
This email has been scanned for viruses and malware, and may have been
automatically archived by Mimecast Ltd, an innovator in Software as a Service
(SaaS) for business. Providing a safer and more useful place for your human
generated data. Specializing in; Security, archiving and compliance. To find
out more Click
Here.
___
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/VLKF3BWJJ2TQJDT5EGA2VU2WFNDZHBAW/
[ovirt-users] Re: oVirt 4.4.0 Release is now generally available
May be we need to check for VDO version. Will check and update. @Prajith Kesava Prasad Can please take a look? On Wed, Jun 17, 2020 at 7:43 PM Yedidyah Bar David wrote: > On Wed, Jun 17, 2020 at 4:57 PM wrote: > > > > Ciao Sandro, > > > > just tried to re-install a Centos7 based HCI cluster because it had > moved to another network. > > > > And from what I can tell it fails because Gobinda Das introduced a > hot-fix into > 'gluster-ansible-infra/roles/backend_setup/tasks/vdo_create.yml' that adds > a '--maxDiscardSize 16M' option statically on April 13th. > > > > Only problem, the vdo 6.1 that is part of the CentOS7/oVirt 4.3.10 stack > doesn't know that option at all, it seems to have been introduced for VDO > 6.2 which is COS 8 based. > > > > Questions: > > Should this not be caught by automated testing? > > Where and how do I need to fill a bug report in such a way that it gets > to Gobinda or his team? > > Adding Gobinda. > -- > Didi > > -- Thanks, Gobinda ___ 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/KBVAZCJUKMLUFGWRT7W46SJ4TWXIUOKY/
[ovirt-users] Re: Hosted engine deployment fails consistently when trying to download files.
On Thu, Jun 18, 2020 at 2:37 PM Gilboa Davara wrote: > > On Wed, Jun 17, 2020 at 12:35 PM Yedidyah Bar David wrote: > > > However, when trying to install 4.4 on the test CentOS 8.x (now 8.2 > > > after yesterday release), either manually (via hosted-engine --deploy) > > > or by using cockpit, fails when trying to download packages (see > > > attached logs) during the hosted engine deployment phase. > > > > Right. Didn't check them - I guess it's the same, no? > > Most likely you are correct. That said, the console version is more verbose. > > > > > Just to be clear, it is the hosted engine VM (during the deployment > > > process) that fails to automatically download packages, _not_ the > > > host. > > > > Exactly. That's why I asked you (because the logs do not reveal that) > > to manually login there and try to install (update) the package, and > > see what happens, why it failes, etc. Can you please try that? Thanks. > > Sadly enough, the failure comes early in the hosted engine deployment > process, making the VM completely inaccessible. > While I see qemu-kvm briefly start, it usually dies before I have any > chance to access it. > > Can I somehow prevent hosted-engine --deploy from destroying the > hosted engine VM, when the deployment fails, giving me access to it? This is how it should behave normally, it does not kill the VM. Perhaps check logs, try to find who/what killed it. Anyway: Earlier today I pushed this patch: https://gerrit.ovirt.org/109730 Didn't yet get to try verifying it. Would you like to try? You can get an RPM from the CI build linked there, or download the patch and apply it manually (in the "gitweb" link [1]). Then, you can do: hosted-engine --deploy --ansible-extra-vars=he_offline_deployment=true If you try this, please share the results. Thanks! [1] https://gerrit.ovirt.org/gitweb?p=ovirt-hosted-engine-setup.git;a=commitdiff_plain;h=f77fa8b84ed6d8a74cbe56b95accb1e8131afbb5 Best regards, -- Didi ___ 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/MEKTS2TFIPZSA7H225ZA6YQLVOJSTCFV/
[ovirt-users] Re: Hosted engine deployment fails consistently when trying to download files.
On Wed, Jun 17, 2020 at 12:35 PM Yedidyah Bar David wrote: > > However, when trying to install 4.4 on the test CentOS 8.x (now 8.2 > > after yesterday release), either manually (via hosted-engine --deploy) > > or by using cockpit, fails when trying to download packages (see > > attached logs) during the hosted engine deployment phase. > > Right. Didn't check them - I guess it's the same, no? Most likely you are correct. That said, the console version is more verbose. > > Just to be clear, it is the hosted engine VM (during the deployment > > process) that fails to automatically download packages, _not_ the > > host. > > Exactly. That's why I asked you (because the logs do not reveal that) > to manually login there and try to install (update) the package, and > see what happens, why it failes, etc. Can you please try that? Thanks. Sadly enough, the failure comes early in the hosted engine deployment process, making the VM completely inaccessible. While I see qemu-kvm briefly start, it usually dies before I have any chance to access it. Can I somehow prevent hosted-engine --deploy from destroying the hosted engine VM, when the deployment fails, giving me access to it? - Gilboa ___ 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/JTVDXZL2DC7SEZ6YWE66IYSSCPFFMFOH/
[ovirt-users] Cannot authenticate user Invalid scopes: ovirt-app-api
Hi All,
A new issue
We have configured oVirt to use KeyCloak for authentication. This all works, I
can log into the WebUI etc, but as soon as I need to talk to the API, it gives
me the “invalid scopes” error. I have double checked KeyCloak, and the scopes
are added. I went through the logs, but there is nothing telling me exactly
what the actual cause is.
I get the below when trying to get a token from the engine:
“{"error_code":"access_denied","error":"Cannot authenticate user Invalid
scopes: ovirt-app-api ovirt-ext=token-info:authz-search
ovirt-ext=token-info:public-authz-search ovirt-ext=token-info:validate
ovirt-ext=token:password-access."}”
Does anybody have any idea where this is going wrong?
Thanks
Anton Louw
Cloud Engineer: Storage and Virtualization
__
D: 087 805 1572 | M: N/A
A: Rutherford Estate, 1 Scott Street, Waverley, Johannesburg
anton.l...@voxtelecom.co.za
www.vox.co.za
___
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/X4BKE3EO44J3RNOH3YF6OEJFDIX3BULQ/
[ovirt-users] Re: Ovirt fails to retrieve iSCSI targets during installation
There's no proxy. This is during the installation using cockpit. Switching to the command line install, the problem doesn't appear. ___ 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/3TC2X3D5243E7IOZLHRMQNJZ4XFTYSLV/
[ovirt-users] Re: Shutting be down kvm host does what to VMs
On Thu, Jun 18, 2020 at 12:33 AM Louis Bohm wrote: > > I have a single ovirt host running 2 VMs. If I do a shutdown -h now on the > kvm host will ovirt do a similar shutdown command on the VMs? And wait for > them to shutdown before finishing it's shutdown? No. To shut down a host you should do: In oVirt UI (or via the API): 1. Shut down vms running on host 2. Put host to maintenance 3. Shut down the host If you have more than one host, you can simply do: 1. Put host to maintenance 2. Shut down the host oVirt will migrate the VMs to other hosts. > Please do not tell me I should have 2 physical hosts. I know but it's not in > the clients budget. More hosts are useful but not required. You can automate this using the oVirt API, SDK, or ansible, and add a service that runs at shutdown and does what you want. 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/RH7JFARIQ5JI3JWY2C2PXHH3J6XKZN5L/
[ovirt-users] Change Hosted engine VM cluster compatibility version throws error
Hello Team, When i try to change Cluster compatible version HE it throws error As Error while executing action: HostedEngine: - There was an attempt to change Hosted Engine VM values that are locked. I am trying to change the version to 4.4 it was showing blank. Any suggestions on how I can edit. The VM other than HE is able to editi. *Ritesh* ___ 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/3EBGCBFDUBHNI6G5E3NG4DCD7RQJLUNC/
