[ovirt-users] Re: ovirt 4.4 on Fedora 30

[Strahil Nikolov via Users]

On May 9, 2020 1:14:38 AM GMT+03:00, kelley bryan  
wrote:
>Hello everyone new test of 4.4 on Fedora 30:
>Prepare Vm fails with 
>{"attempts": 10, "changed": false, "cmd": "dnf install -y
>python2-dnf", "msg": "Could not import the dnf python module using
>/usr/bin/python (2.7.18 (default, Apr 21 2020, 18:49:31) [GCC 9.3.1
>20200408 (Red Hat 9.3.1-2)]). Please install `python2-dnf` package or
>ensure you have specified the correct ansible_python_interpreter.",
>"rc": 1, "results": [], "stderr": "Error: Unable to find a match:
>python2-dnf\n", "stderr_lines": ["Error: Unable to find a match:
>python2-dnf"], "stdout": "Last metadata expiration check: 2:38:48 ago
>on
> Fri 08 May 2020 12:16:25 PM MST.\nNo match for argument:
>python2-dnf\n", "stdout_lines": ["Last metadata expiration check:
>2:38:48 ago on Fri 08 May 2020 12:16:25 PM MST.", "No match for
>argument: python2-dnf"]}
>Is this due to Fedora 30 being based on RH7?
>___
>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/URZCTP6N3RE4TVQBRAQKO3E5TU36HYHM/

Which is the default python version ?
Most probably ansible is  looking for python 3.X while the default is 2.7.

Have you tried to specify ansible_python_interpreter ?

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/NGBCOLX6OZFN4VLONHPWK3J2GMWSRJ5W/

[ovirt-users] Re: Can't add freshly installed node.. host has no default route

[Strahil Nikolov via Users]

On May 12, 2020 6:56:45 PM GMT+03:00, Giorgio Biacchi  
wrote:
>Il 12/05/2020 17:07, Dominik Holler ha scritto:
>> 
>> 
>> On Tue, May 12, 2020 at 4:25 PM Giorgio Biacchi > > wrote:
>> 
>> On 5/12/20 12:28 PM, Dominik Holler wrote:
>>  >
>>  >
>>  > On Tue, May 12, 2020 at 8:49 AM Giorgio Biacchi
>> mailto:gior...@di.unimi.it>
>>  > >>
>wrote:
>>  >
>>  >     On 5/11/20 5:53 PM, Dominik Holler wrote:
>>  >     >
>>  >     >
>>  >     > On Mon, May 11, 2020 at 12:31 PM Giorgio Biacchi
>>  >     mailto:gior...@di.unimi.it>
>> >
>>  >     > 
>> wrote:
>>  >     >
>>  >     >     Hi list,
>>  >     >     I've spent a couple of days trying to understand why
>> this was
>>  >     >     happening...
>>  >     >
>>  >     >     For the installation I have a well tested
>installation
>> server
>>  >     with a
>>  >     >     custom kickstart file to setup ssh keys and custom
>> hooks for
>>  >     infiniband
>>  >     >     and I'm installing Ovirt Node 4.3.9 via pxe, this is
>> particularly
>>  >     >     useful
>>  >     >     when I have to install a bunch of blades at once..
>In
>> the past
>>  >     I had no
>>  >     >     issues and all was working like a charm until now
>when some
>>  >     hardware
>>  >     >     failed and I had to replace it.
>>  >     >
>>  >     >     As expected I have no issues in the node
>installation
>>  >     process.. the
>>  >     >     troubles begins when I try to add the node,
>> installation fails
>>  >     and in
>>  >     >     the UI I have an exclamation mark with the message
>> "Host has
>>  >     no default
>>  >     >     route." but I can ping and do ssh to the host from
>the
>>  >     manager.. the
>>  >     >     problem is somewhere else in the communication
>between the
>>  >     engine and
>>  >     >     vdsmd preventing the engine to refresh the host
>> capabilities.
>>  >     >
>>  >     >     So from the engine I tried:
>>  >     >
>>  >     >     [root@manager ~]# openssl s_client -connect
>> 172.20.22.78:54321 
>>  >     
>>  >     >     
>>  >     >     CONNECTED(0003)
>>  >     >     ---
>>  >     >     Certificate chain
>>  >     >       0 s:/CN=cn128.lagrange.di.unimi.it/O=VDSM
>> 
>>  >     
>>  >     >     
>Certificate
>>  >     >         i:/CN=VDSM Certificate Authority
>>  >     >       1 s:/CN=VDSM Certificate Authority
>>  >     >         i:/CN=VDSM Certificate Authority
>>  >     >     ---
>>  >     >
>>  >     >     The host has still the self signed vdsm
>certificate..
>> and on the
>>  >     >     host in
>>  >     >     vdsm.log I find:
>>  >     >
>>  >     >     2020-05-11 09:52:25,433+ ERROR (Reactor thread)
>>  >     >     [ProtocolDetector.SSLHandshakeDispatcher] ssl
>> handshake: SSLError,
>>  >     >     address: :::159.149.129.220 (sslutils:264)
>>  >     >
>>  >     >     So I tried to enroll the certificate from the UI and
>> from the
>>  >     events
>>  >     >     tab
>>  >     >     I sow the enrolling was successful but:
>>  >     >
>>  >     >     [root@manager ~]# openssl s_client -connect
>> 172.20.22.78:54321 
>>  >     
>>  >     >     
>>  >     >
>>  >     >     140084336994192:error:140790E5:SSL
>routines:ssl23_write:ssl
>>  >     handshake
>>  >     >     failure:s23_lib.c:177:
>>  >     >     CONNECTED(0003)
>>  >     >     ---
>>  >     >     no peer certificate available
>>  >     >     ---
>>  >     >
>>  >     >     there's still some issue with the certificates.. so
>on the
>>  >     host again:
>>  >     >
>>  >     >     [root@cn128 vdsm]# find /etc/pki/vdsm/ -type f -cmin
>-10|
>>  >     xargs ls -l
>>  >     >     -rw---. 1 root kvm  1424 May 11 09:56
>>  >     /etc/pki/vdsm/certs/cacert.pem
>>  >     >     -rw---. 1 root kvm  5108 May 11 09:57
>>  >     >     /etc/pki/vdsm/certs/vdsmcert.pem
>>  >     >     -r--r-. 1 root kvm  1704 May 11 09:56
>>  >     /etc/pki/vdsm/keys/vdsmkey.pem
>>  >     >     -rw-r--r--. 1 root root 1424 May 11 09:57
>>  >     >     /etc/pki/vdsm/libvirt-spice/ca-cert.pem
>>  

[ovirt-users] Re: Any official support list of SAS RAID controller?

[Strahil Nikolov via Users]

On May 13, 2020 4:52:18 AM GMT+03:00, hkexdong--- via Users  
wrote:
>I am not going to use those servers from HP, IBM, etc.
>
>My computer is desktop level and plan to insert a PCI-E SAS RAID
>controller card, that use to connect to an external SAN storage
>(https://www.areca.com.tw/products/storage-8042.html)
>
>I afraid I might buy the wrong RAID card that oVirt can't recognize. Is
>there any official support list of SAS RAID controller?
>___
>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/EAXOUEFNGO5SXDL4BI3GZGNDZRQEJ6VN/

Ovirt is a Layer above that - it manages the Virtualization and anything 
related to that (host kernel parameters ,etc).

As it  runs on CentOS & RHEL - you just need  to be sure that the OS has a 
module for that.
Keep in mind that oVirt 4.4 is moving to CentOS/ RHEL 8, so you have to check 
if the RAID card you plan to use  is supported, or you can consider if software 
raid is an option.

You always have the option to get your own kernel, but there is no guarantee 
that everything will be working flawlessly.

Just ask in the CentOS user list about the raid cards the others are using ( 
CentOS 8).

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/43TAZ56BGLCM5ZCP3FYWTQ5M7BMNYNWO/

[ovirt-users] Re: Unable to connect to cockpit

[Strahil Nikolov via Users]

On May 14, 2020 9:47:26 AM GMT+03:00, Yedidyah Bar David  
wrote:
>On Thu, May 14, 2020 at 9:29 AM Gobinda Das  wrote:
>>
>> Even with firefox latest in Fedora also the issue persists
>>
>> On Thu, May 14, 2020 at 10:11 AM Parth Dhanjal 
>wrote:
>>>
>>> No! I'm not using any proxy.
>>>
>>> On Wed, May 13, 2020 at 2:49 PM Garrett LeSage 
>wrote:

 Are you using a proxy, such as nginx?

 On Tue, May 12, 2020 at 1:09 PM Parth Dhanjal 
>wrote:
>
> Nope, using Chrome on Fedora.
>
> On Tue, May 12, 2020 at 3:14 PM Sandro Bonazzola
> wrote:
>>
>> Are you connecting with Safari browser?
>>
>> Il giorno lun 11 mag 2020 alle ore 09:58 Parth Dhanjal
> ha scritto:
>>>
>>> Hey!
>>>
>>> I have a remote machine on which I have installed RHVH4.4
>>> I'm unable to access the cockpit-plugin.
>>> journalctl -u cockpit returns this error
>>>
 cockpit-tls: gnutls_handshake failed: A TLS fatal alert has
>been received.
>>>
>>>
>>> Screenshot while trying to reach cockpit through the browser
>attached.
>>>
>>> Is anyone else facing this issue as well?
>
>Many people, it seems to me, after searching the net for:
>"gnutls_handshake failed: A TLS fatal alert has been received".
>
>Tried now again to connect to my CentOS8 host, with:
>
>cockpit-196.3-1.el8.x86_64
>gnutls-3.6.8-8.el8.x86_64
>
>from both firefox 68.8.0esr (part of my OS, RHEL8) and 76.0.1,
>and didn't reproduce - both worked as expected (warning page about
>self-signed cert etc., accepted the risk, got main screen).
>
>Please provide more details. Versions of relevant packages, more
>relevant lines from the log (e.g. 'journalctl -g cockpit'), did you
>change its default cert, perhaps details about this cert (when was
>it created, how, etc.), etc.
>
>Best regards,
>
>>> And does anyone has a solution/workaround to this?
>>> ___
>>> 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/POYO4WEFLTSHLMDZ5WNQGAJ3SE245I3S/
>>
>>
>>
>> --
>>
>> Sandro Bonazzola
>>
>> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
>>
>> Red Hat EMEA
>>
>> sbona...@redhat.com
>>
>> Red Hat respects your work life balance. Therefore there is no
>need to answer this email out of your office hours.
>
> ___
> cockpit-devel mailing list -- cockpit-de...@lists.fedorahosted.org
> To unsubscribe send an email to
>cockpit-devel-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
>https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
>https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
>https://lists.fedorahosted.org/archives/list/cockpit-de...@lists.fedorahosted.org

 ___
 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/LZGC4NTE7LTM2B7SZFXTVQP3DKMGIWQZ/
>>>
>>> ___
>>> 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/XPZ75NTFK5K3YJS2NSWRRYX5QGFQORTW/
>>
>>
>>
>> --
>>
>>
>> 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/MDMCWS6PF5HIOWZO7UJ3WNOY6EV5SKH5/

Also verify with rpm/yum all cockpit packages .

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/XGDN4HHAREAOMHQGDOC72WTM6J5AAVAQ/

[ovirt-users] Re: Bridge not forwarding frames on node.

[Strahil Nikolov via Users]

On May 14, 2020 6:16:06 PM GMT+03:00, Stefano Danzi  wrote:
>
>
>Il 14/05/2020 12:50, Dominik Holler ha scritto:
>>
>>
>> On Wed, May 13, 2020 at 9:44 PM s.danzi > > wrote:
>>
>> Hi to all!
>>
>> I'm having an issue with networks bridges on ovirt node.
>>
>> It's look like this bug:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1279161
>>
>> On VM I have a bridge between a tap device and network
>interface. 
>> On node side the interface is bridged with bond0 vlan 128
>> (bond0.128 lacp).
>>
>> When I ping an host on the other side of tap device I can see
>this:
>>
>> Arp request goes from my lan to the tap device on vm. Arp reply
>> return from tap vm and bridge forward this to vm networks
>> interface. Using tcpdump on vm interface on node I can see the
>arp
>> reply, using tcpdump on bond0.128 or on bridge I can't see the
>arp
>> reply.  Arp request is forwarded from bond0.128 to vm net but arp
>> reply isn't forwarded from vm net to bond0.128.
>>
>>
>>
>> Any chance that there is network filtering involved?
>> Please check if the related vNIC profile has No Network Filter.
>> If there is a Network Filter set, please shutdown the VM, set to No 
>> Network Filter in the vNIC profile, and start the VM again and check 
>> if the issue is gone.
>
>Hi! No Network filter It was my first check.

Have you checked the MTU ?
You need to keep it a little bit lower on the VM, as you have vlan on the 
hypervisor.

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/6L2THM5W6SYQXESBKZ2ITAKDK35QIJWE/

[ovirt-users] Re: HostedEngine add more RAM

[Strahil Nikolov via Users]

On May 14, 2020 12:41:13 AM GMT+03:00, Joseph Goldman  
wrote:
>Hi List,
>
>  I'm having troubles adding more RAM to my HostedEngine VM. When the 
>cluster first got up and running I only had a little bit of RAM so I 
>only gave the HE 4GB, but i'm constantly getting BadHealth alerts so I 
>want to up it to 8GB.
>
> I have tried multiple ways - mostly any time i edit the HE VM through 
>the UI it simply reverts back to 4096MB RAM, never upgrades to 8192MB.
>I 
>have tried with global HA maintenance on as well but no luck. No
>errors, 
>it saves as if it has completed the action but when I re-open the VM
>(or 
>even after a fresh boot) it has simply reverted back to 4096MB.
>
>  Any help appreciated.
>
>Thanks,
>Joe
>___
>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/QFUBQT3QUXIWLFNNODQRBONKGKVFMIWN/

Have you tried  to add  more  RAM via UI and leave the VM for a day /even 2/ 
for the OVF to be updated ?

I know that there  is an option to force  faster OVF updates , but it's still  
slower than the defined frequency.

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/UK6MAUKC6DTMDJLKDKLFJP3VOHSVCHZY/

[ovirt-users] Re: Convert unmanaged Gluster to managed one

[Strahil Nikolov via Users]

On May 13, 2020 10:33:39 PM GMT+03:00, "Николаев Алексей" 
 wrote:
>___
>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/C62KLIJCDIPHIX3E7NUHBYQK2T5GSVNA/

Hi Alex,

As far as I know, you can add it as long as the storage domain is not attached 
to another oVirt Engine.

FUSE client tools have a backward compatibility, but there could be issues when 
a v6 gluster fuse client has to connect to v3 storage pool.

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/G4MQN3MJ3DXM4TB7S6EGWXQOLSYIBQFU/

[ovirt-users] Re: HostedEngine add more RAM

[Strahil Nikolov via Users]

On May 17, 2020 1:09:18 PM GMT+03:00, Asaf Rachmani  wrote:
>Which oVirt version are you using?
>From 4.2 you don't need to wait, you should be able to update the HE
>memory
>via UI:
>1. Enable global maintenance
>2. Change HE VM memory via UI
>3. On the HE, run: # hosted-engine --vm-shutdown
>4. Wait for HE VM to be down: # hosted-engine --vm-status
>5. Start HE VM: # hosted-engine --vm-start
>6. Disable global maintenance
>
>On Sat, May 16, 2020 at 1:46 PM Strahil Nikolov via Users
>
>wrote:
>
>> On May 14, 2020 12:41:13 AM GMT+03:00, Joseph Goldman <
>> jos...@goldman.id.au> wrote:
>> >Hi List,
>> >
>> >  I'm having troubles adding more RAM to my HostedEngine VM. When
>the
>> >cluster first got up and running I only had a little bit of RAM so I
>> >only gave the HE 4GB, but i'm constantly getting BadHealth alerts so
>I
>> >want to up it to 8GB.
>> >
>> > I have tried multiple ways - mostly any time i edit the HE VM
>through
>> >the UI it simply reverts back to 4096MB RAM, never upgrades to
>8192MB.
>> >I
>> >have tried with global HA maintenance on as well but no luck. No
>> >errors,
>> >it saves as if it has completed the action but when I re-open the VM
>> >(or
>> >even after a fresh boot) it has simply reverted back to 4096MB.
>> >
>> >  Any help appreciated.
>> >
>> >Thanks,
>> >Joe
>> >___
>> >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/QFUBQT3QUXIWLFNNODQRBONKGKVFMIWN/
>>
>> Have you tried  to add  more  RAM via UI and leave the VM for a day
>/even
>> 2/ for the OVF to be updated ?
>>
>> I know that there  is an option to force  faster OVF updates , but
>it's
>> still  slower than the defined frequency.
>>
>> 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/UK6MAUKC6DTMDJLKDKLFJP3VOHSVCHZY/
>>

I'm using 4.3.9 .
Let's see the author's output.

Beest 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/UEOCWJB5BYOMY5EXSL5HHKBCZHDSCBTY/

[ovirt-users] Re: HostedEngine add more RAM

[Strahil Nikolov via Users]

On May 19, 2020 2:07:52 AM GMT+03:00, Joseph Goldman  
wrote:
>Using oVirt 4.3.7  - testing on 2 diff environments.
>
>So editing via UI and waiting some days, or using the below process
>both 
>still don't work.
>
>What seems to happen is it does update the running HE with the new RAM 
>amount while booted, but the OVF is not updating because as soon as the
>
>VM reboots its back to original value of 4GB, so the increase is only 
>applicable for that current running session.
>
>When editing in the UI it seems it does not save, I can go straight
>back 
>into the VM info or edit screen and it has instantly reverted back to 
>4096mb even though the VM itself now has 8 (trying to change from
>4->8).
>
>When saving, even the log says "Hotset memory: changed the amount of 
>memory on VM HostedEngine from 4096 to 4096" so it seems the system is 
>actively limiting my ability to update the HE - this happens both in 
>global maintenance mode and no maintenance mode.
>
>On a customers cluster - I am getting a lot of EngineBadHealth and the 
>HA agent is constantly moving it around on me, I fear because of RAM,
>so 
>I'd like the OVF to update so on fresh boot it can keep a new RAM
>config.
>
>Any help appreciated.
>
>Joe
>
>On 17/5/20 8:09 pm, Asaf Rachmani wrote:
>> Which oVirt version are you using?
>> From 4.2 you don't need to wait, you should be able to update the HE 
>> memory via UI:
>> 1. Enable global maintenance
>> 2. Change HE VM memory via UI
>> 3. On the HE, run: # hosted-engine --vm-shutdown
>> 4. Wait for HE VM to be down: # hosted-engine --vm-status
>> 5. Start HE VM: # hosted-engine --vm-start
>> 6. Disable global maintenance
>>
>> On Sat, May 16, 2020 at 1:46 PM Strahil Nikolov via Users 
>> mailto:users@ovirt.org>> wrote:
>>
>> On May 14, 2020 12:41:13 AM GMT+03:00, Joseph Goldman
>> mailto:jos...@goldman.id.au>> wrote:
>> >Hi List,
>> >
>> >  I'm having troubles adding more RAM to my HostedEngine VM.
>When
>> the
>> >cluster first got up and running I only had a little bit of RAM
>so I
>> >only gave the HE 4GB, but i'm constantly getting BadHealth
>alerts
>> so I
>> >want to up it to 8GB.
>> >
>> > I have tried multiple ways - mostly any time i edit the HE VM
>> through
>> >the UI it simply reverts back to 4096MB RAM, never upgrades to
>> 8192MB.
>> >I
>> >have tried with global HA maintenance on as well but no luck. No
>> >errors,
>> >it saves as if it has completed the action but when I re-open
>the VM
>> >(or
>> >even after a fresh boot) it has simply reverted back to 4096MB.
>> >
>> >  Any help appreciated.
>> >
>> >Thanks,
>> >Joe
>> >___
>> >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/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/QFUBQT3QUXIWLFNNODQRBONKGKVFMIWN/
>>
>> Have you tried  to add  more  RAM via UI and leave the VM for a
>> day /even 2/ for the OVF to be updated ?
>>
>> I know that there  is an option to force  faster OVF updates ,
>but
>> it's still  slower than the defined frequency.
>>
>> Best Regards,
>> Strahil Nikolov
>> ___
>> 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/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/UK6MAUKC6DTMDJLKDKLFJP3VOHSVCHZY/
>>
>>
>> ___
>> 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 

[ovirt-users] Re: Upgrade Memory of oVirt Nodes

[Strahil Nikolov via Users]

On May 19, 2020 11:16:35 AM GMT+03:00, souvaliotima...@mail.com wrote:
>Hello everyone, 
>
>I have an oVirt 4.3.2.5 hyperconverged 3 node production environment
>and we want to add some RAM to it. 
>
>Can I upgrade the RAM without my users noticing any disruptions and
>keep the VMs running?
>
>The way I thought I should do it was to migrate any running VMs to the
>other nodes, then set one node in maintenance mode, shut it down, place
>the new memory, bring it back up, remove it from maintenance mode and
>see how the installation reacts and repeat for the other two nodes. Is
>this correct or should I follow another way?
>
>Will there be a problem during the time when the nodes will not be
>identical in their resources?
>
>Thank you for your time,
>Souvalioti Maria 
>___
>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/F4E6DMLL23QU6KGMUVUNRGNR3IUYCT5W/

There is no requirement that your nodes should have the same ammount of RAM.
At least my setup doesn't have the same RAM on each node.

The problem with nonequal nodes is the scheduling policy, which reminds me to 
ask if there are any guides for seting a scheduling policy based on memory 
usage ?

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/WHPEVNYCE2BXEVVKTBIQDOO5D7LG5VYO/

[ovirt-users] Re: Upgrade Memory of oVirt Nodes

[Strahil Nikolov via Users]

On May 20, 2020 2:48:24 AM GMT+03:00, tho...@hoberg.net wrote:
>Just like Strahil, I would expect this to work just fine. RAM
>differences are actually the smallest concern, unless you run out of it
>in the mean-time. And there you may want to be careful and perhaps move
>VMs around manually with such a small HCI setup.
>
>oVirt will properly optimize the VMs and the hosts to fit, but I don't
>know what it will do when there simply isn't enough RAM to run the live
>VMs. Under the best of circumstances it should refuse to shut down the
>node you want to upgrade. Under less advantagious circumstances some
>VMs might get paused, or shut down (or killed?). I'd be interested to
>hear your experiences, somewhat less inclinded to try myself ;-)
>
>I'd play it safe and reduce the number of running VMs to relieve the
>RAM pressure. I assume there is a reason you want more RAM but the only
>way to get there is to reduce it first and that doesn't imply
>"unnoticeable".
>___
>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/BFCUPGDOSC3NLHULH6QW6EBCXR5DJIVN/

Actually,
If gou set a host into maintenance and there is no space to move - oVirt fails 
to migrate the VM and the node cannot be put into maintenance.
In such case I usually power off  the non-important VMs and then the node goes 
into the maintenance mode (I guess I was fast enough, as there is some timeout 
setting for going into that mode).

From there, you will be able to power off, upgrade and return the node in the 
cluster.

If a node reaches the 90% of memory usage, the ksm service kicks in and starts 
merging the same memory pages in order to save memory. Of course this is a 
trade of cpu cycles for extra memory - but I haven't seen a hypervisor that is 
running out of cpu (if you host HPC VMs could change that).Don't expect  magic  
from KSM, but in my case (32GB) it gained 5-6 GB from my linux VMs, but this 
depends on the software in the VMs.

Best Rregards,
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/HI4ZYLLVQ6AWMXM42Z7RJZLU6ZTYQDDQ/

[ovirt-users] Re: Non storage nodes erronously included in quota calculations for HCI?

[Strahil Nikolov via Users]

On May 20, 2020 2:37:32 AM GMT+03:00, tho...@hoberg.net wrote:
>For my home-lab I operate a 3 node HCI cluster on 100% passive Atoms,
>mostly to run light infrastructure services such as LDAP and NextCloud.
>
>I then add workstations or even laptops as pure compute hosts to the
>cluster for bigger but temporary things, that might actually run a
>different OS most of the time or just be shut off. From oVirt's point
>of view, these are just first put into maintenance and then shut down
>until needed again. No fencing or power management, all manual.
>
>All nodes, even the HCI ones, run CentOS7 with more of a workstation
>configuration, so updates pile up pretty quickly.
>
>After I recently upgraded one of these extra compute nodes, I found my
>three node HCI cluster not just faltering, but indeed very hard to
>reactivate at all.
>
>The faltering is a distinct issue: I have the impression that reboots
>of oVirt nodes cause broadcast storms on my rather simplistic 10Gibt L2
>switch, which a normal CentOS instance (or any other OS)  doesn't, but
>that's for another post.
>
>No what struck me, was that the gluster daemons on the three HCI nodes
>kept complaining about a lack of quorum long after the network was all
>back to normal, even if all three of them were there, saw each other
>perfectly on "gluster show status all", ready and without any healing
>issues pending at all.
>Glusterd would complain on all three nodes that there was no quota for
>the bricks and stop them.
>
>That went away as soon as I started one additional compute node, a node
>that was a gluster peer (because an oVirt host added to a HCI cluster
>always gets put into the Gluster, even if it's not contributing
>storage) but had no bricks. Immediately the gluster daemon on the three
>nodes with contributing bricks would report back good quota and launch
>the volumes (and thus all the rest of oVirt), even if in terms of
>*storage bricks* nothing had changed.
>
>I am afraid that downing the extra compute-only oVirtNode will bring
>down the HCI: Clearly not the type of redundancy it's designed to
>deliver.
>
>Evidently such compute-only hosts (and gluster members) get included
>into some quorum deliberations even if they hold not a single brick,
>neither storage nor arbitration.
>
>To me that seems like a bug, if that is indeed what happens: There I
>need your advice and suggestions.
>
>AFAIK HCI is a late addition to oVirt/RHEV as storage and compute were
>orginally designed to be completely distinct. In fact there are still
>remnants of documentation which seem to prohibit using a node for both
>compute and storage... what HCI is all about.
>
>And I have seen compute nodes with "matching" storage (parts of a
>distinct HCI setup, that was taken down but still had all the storage
>and Gluster elements operable), being happliy absorbed into a HCI
>cluster with all Gluster storage appearing in the GUI etc., without any
>manual creation or inclusion of bricks: Fully automatic (and
>undocumented)!
>
>In that case it makes sense to widen the scope of quota calculations
>when additional nodes are hyperconverged elements with contributing
>bricks. It also seems the only way to turn a 3 node HCI into 6 or 9
>node one.
>
>But if you really just want to add compute nodes without bricks, those
>can't get "quota votes" without storage to play a role in the
>redundancy.
>
>I can easily imagine the missing "if then else" in the code here, but I
>was actually very surprised to see those failure and success messages
>coming from glusterd itself, which to my understanding is pretty
>unrelated to oVirt on top. Not from the management engine (wasn't
>running anyway), not from VDSM.
>
>Re-creating the scenario is very scary even if I have gone through this
>three times already, trying to just bring my HCI back up. And then
>there is so verbose logs all over the place that I'd like some advice
>which ones I should post.
>
>But simply speaking: Gluster peers should get no quota voting rights on
>volumes unless they contribute bricks. That rule seems broken.
>
>Those in the know, please let me know if am on a goose chase or if
>there is a real issue here that deserves a bug report.
>___
>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/IBHZ674FMWFDSZYLTOMVAJU2JNM4K6OL/

I have skipped a huge  part of your e-mail cause it was too long (don't get 
offended).

Can you summarize in one (or 2  ) sentences what exactly is the problem ?
Is the UI not detecting the Gluster status, quota is preventing you to start 
VMs  or something else ?

Best Rergards,
Strahil Nikolov
___
Users mailing list -- users@ovirt.org
To unsubscrib

[ovirt-users] Re: Non storage nodes erronously included in quota calculations for HCI?

[Strahil Nikolov via Users]

On May 20, 2020 5:12:05 PM GMT+03:00, tho...@hoberg.net wrote:
>OK ;-)
>
>3 node HCI 2+1 data/arbiter
>added 3 compute-only nodes via host install without HE support which
>add no storage to the gluster (install still adds them as peers).
>
>With 2 compute-only nodes inactive/down I updated the third compute
>node (no contributing bricks) and saw all VMs pausing and glusterd on
>the HCI nodes "lost quorum on brick engine/vmstore/data" when it
>rebooted to activate the new kernel.
>
>Had to launch additional compute-only node to let glusterd on HCI nodes
>recover quorum.
>Seems glusterd computes quorum based on total peers (6) not on
>redundancy (2+1).
>
>With the gluster volumes down, running VMs remain paused according th
>virsh, HE and UI aren't there, hosted-engine --vm-status reports "not
>retrieved from storage"
>___
>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/F6QOGNZVPMCRAW4KP3MSMHOXSSRA4IMY/

Hi Thomas,

Quite  strange.
Get to  one of the gluster tsp nodes and provide  some data:

gluster volume list
gluster pool list
for i in $(gluster  volume list); do gluster  volume status $i;echo; gluster 
volume status $i; echo;echo;echo; done

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/DPXTHW6WMAYKWJHPA2VPUF3BIUC7OKTE/

[ovirt-users] Re: Non storage nodes erronously included in quota calculations for HCI?

[Strahil Nikolov via Users]

On May 21, 2020 12:29:24 PM GMT+03:00, Strahil Nikolov via Users 
 wrote:
>On May 20, 2020 5:12:05 PM GMT+03:00, tho...@hoberg.net wrote:
>>OK ;-)
>>
>>3 node HCI 2+1 data/arbiter
>>added 3 compute-only nodes via host install without HE support which
>>add no storage to the gluster (install still adds them as peers).
>>
>>With 2 compute-only nodes inactive/down I updated the third compute
>>node (no contributing bricks) and saw all VMs pausing and glusterd on
>>the HCI nodes "lost quorum on brick engine/vmstore/data" when it
>>rebooted to activate the new kernel.
>>
>>Had to launch additional compute-only node to let glusterd on HCI
>nodes
>>recover quorum.
>>Seems glusterd computes quorum based on total peers (6) not on
>>redundancy (2+1).
>>
>>With the gluster volumes down, running VMs remain paused according th
>>virsh, HE and UI aren't there, hosted-engine --vm-status reports "not
>>retrieved from storage"
>>___
>>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/F6QOGNZVPMCRAW4KP3MSMHOXSSRA4IMY/
>
>Hi Thomas,
>
>Quite  strange.
>Get to  one of the gluster tsp nodes and provide  some data:
>
>gluster volume list
>gluster pool list
>for i in $(gluster  volume list); do gluster  volume status $i;echo;
>gluster volume status $i; echo;echo;echo; done
>
>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/DPXTHW6WMAYKWJHPA2VPUF3BIUC7OKTE/

Yeah...
The for loop should  use  'status' and 'info' , so it should be somwthing like:

gluster volume list
gluster pool list
for i in $(gluster  volume list); do gluster  volume status $i;echo; gluster 
volume info $i; echo;echo;echo; done

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/AVROC45QWHFDVRX7YSHHTWL2TCBPTL7X/

[ovirt-users] Ovirt 4.4 Migration assistance needed.

[Strahil Nikolov via Users]

Hello All,

I  would like to ask  for some  assistance  with  the planing  of the upgrade 
to 4.4 .

I have  issues with the  OVN (doesn't work at all),  thus  I would like to 
start fresh with the HE.

The plan so far (downtime is not an issue) :

1. Reinstall  the nodes one by 1 and  rejoin them in the Gluster  TSP
2. Wipe  the HostedEngine's gluster  volume
3. Deploy a fresh hosted  engine
4. Import the storage  domains (gluster) back to the  engine and import the VMs

Do you see any issues  with the plan ?
Any problems expected  if the VMs do have snapshots?  What about the storage  
domain version ?

Thanks  in Advance.

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/QNPOH55AAAYOX5GX3EN5H5ZMOZHKYELI/

[ovirt-users] Re: oVirt 4.4.0 Release is now generally available

[Strahil Nikolov via Users]

On May 21, 2020 6:08:19 PM GMT+03:00, Derek Atkins  wrote:
>Nir,
>
>Nir Soffer  writes:
>
>> Why not open RFE to add the feature you need?
>
>I did -- about 3-4 years ago.  SOME of them have been implemented, some
>have been partially implemented, but I am still waiting for ovirt to
>support the full VM startup functionality that I had in vmware-server
>from like 2007 (or earlier).
>
>Part of the issue here is that I suspect most ovirt users have multiple
>hosts and therefore rarely have to worry about how host-system
>maintenance affects the VMs, and probably live in data centers with
>redundant power supplies, UPSes, and backup generators.
>
>I, on the other hand, I've got a single system so when I need to
>perform any maintenance I need to take down everything, or if I have a
>power outage that outlasts my UPS, or...  I want the VMs to come back
>up
>automatically -- and in a particular order (e.g., I need my DNS and KDC
>servers to come up before others).
>
>I filed these RFEs during the 4.0 days, which is when I first started
>using ovirt and put it into deployment.
>
>> You can use the python SDK to do anything supported by oVirt API.
>> Did you look here?
>> https://github.com/oVirt/ovirt-engine-sdk/tree/master/sdk/examples
>
>I have looked there, but I stopped reading after seeing "python".  ;)
>Frankly I detest python.  I think it's an abomination.  There are so
>many other, better languages out there and I don't understand why so
>many people like it (and worse, force it down everyone else's throats).
>But I'll step off my soap-box (and get off my lawn!)  lol.
>
>Honestly, I already spent the time to build a tool to do what I need. 
>I
>even had to update the tool going from 4.1 to 4.3 because some startup
>assumptions changed.  I really don't want to spend the time again, time
>I frankly don't have right now, to re-implement what I've already got.
>It's easier for me to just stay put on 4.3.x.
>
>Yes, I realize that in about 2 years or so I will need to do so.  I'll
>worry about that then.
>
>Of course, since the (partial?) functionality is only in 4.4, I really
>have no way to test it to make sure it does what I need, so see what
>I'm
>missing.  I don't have a testbed to play with it, just my one system.
>
>Thanks,
>
>-derek

Actually,
You can use Ansible and 'uri' module to communicate wwith the engine via the 
API. Most probably the 'uri' module was written in python - but  you don't have 
to deal with python code - just ansible.
Also, it's worth checking the ansible Ovirt modules , as they are kept up to 
date evwn when the API endpoint changes.

I think it won't be too hard to get a list of the VMs and then create some 
logic how to order them for the 'ignition'.

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/DQAGPB64SN33OOGYO3MBG4NS4ZBEUNSU/

[ovirt-users] Re: Ovirt 4.4 Migration assistance needed.

[Strahil Nikolov via Users]

On May 22, 2020 12:01:04 AM GMT+03:00, "Vinícius Ferrão via Users" 
 wrote:
>I think OVN is broken due to this:
>
>Some of the features included in the oVirt 4.4.0 release require
>content that will be available in CentOS Linux 8.2 but cannot be tested
>on RHEL 8.2 yet due to some incompatibility in the openvswitch package
>that is shipped in CentOS Virt SIG, which requires rebuilding
>openvswitch on top of CentOS 8.2. The cluster switch type OVS is not
>implemented for CentOS 8 hosts.
>
>https://blogs.ovirt.org/2020/05/ovirt-44-available/
>
>But I may be wrong.
>
>On 21 May 2020, at 12:06, Strahil Nikolov via Users
>mailto:users@ovirt.org>> wrote:
>
>Hello All,
>
>I  would like to ask  for some  assistance  with  the planing  of the
>upgrade to 4.4 .
>
>I have  issues with the  OVN (doesn't work at all),  thus  I would like
>to start fresh with the HE.
>
>The plan so far (downtime is not an issue) :
>
>1. Reinstall  the nodes one by 1 and  rejoin them in the Gluster  TSP
>2. Wipe  the HostedEngine's gluster  volume
>3. Deploy a fresh hosted  engine
>4. Import the storage  domains (gluster) back to the  engine and import
>the VMs
>
>Do you see any issues  with the plan ?
>Any problems expected  if the VMs do have snapshots?  What about the
>storage  domain version ?
>
>Thanks  in Advance.
>
>Best Regards,
>Strahil Nikolov
>___
>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/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/QNPOH55AAAYOX5GX3EN5H5ZMOZHKYELI/

I was  talking that my current OVN is broken (4.3.9) , not after the update. 
I'm sorry I didn't clariify that in a more clear way.

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/JC6BMZR23XY7AMB5ZTIOALFJLIIRHJE6/

[ovirt-users]Re: What's mean about this "ETL service sampling has encountered an error. Please consult the service log for more details.‘’

[Strahil Nikolov via Users]

On May 22, 2020 8:30:34 AM GMT+03:00, "zhou...@vip.friendtimes.net" 
 wrote:
>
>Dear  all:
>After I restart the server, the log will appear every 15 minutes,But 
>all nodes and vms are worrking normally. Is anyone knows what it means?
>
>
>
>
>zhou...@vip.friendtimes.net

According to https://access.redhat.com/solutions/3251541 (you can view it with 
a free red hat developer subscription) it could be  duplicate  entries  in 
'dwh_history_timekeeping' table.

What is the output of:
/usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "SELECT * FROM 
dwh_history_timekeeping;"

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/ZXEUXTGUT2IKSLA57OM6QPYSDA4U3FGX/

[ovirt-users] Re: storage domain cross data center status

[Strahil Nikolov via Users]

On May 20, 2020 5:34:30 PM GMT+03:00, "Николай Чаплинский"  
wrote:
>Hello!
>Wich table in ovirt database contains column with "cross data center
>status" оf Storage Domains?

Usually when I search something , I just dump the DB and then run a grep (or  
2).

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/EZIPVRCFEAK6N45CCJL7FIZRNVV6ZQVT/

[ovirt-users] Re: oVirt 4.4.0 Release is now generally available

[Strahil Nikolov via Users]

On May 22, 2020 6:48:43 PM GMT+03:00, Gianluca Cecchi 
 wrote:
>On Fri, May 22, 2020 at 4:17 PM Derek Atkins  wrote:
>
>>
>>
>> FTR: I don't think I need to check that the datacenter status is up;
>I
>> added that in not really understanding the changes between 4.1 and
>4.3.
>> The issue is that the storage domain status isn't initialized to
>'down'
>> when the engine first comes up so my script was testing that and
>seeing
>> all domains up when they really weren't.
>>
>>
>Actually  at least one time last week I had a situation where after a
>crash
>of a single host environment with 4.3.9 and gluster on host itself, all
>3
>gluster storage domains resulted active but actually only the engine
>rhev
>mount point was up and not the other 3 configured
>Something like this:
>/rhev/data-center/mnt/glusterSD/ovirtst.mydomai.storage:_engine
>
>While for the other 3 storage domains I only had the gluster brick
>active
>but not the filesystem mounted.
>In web admin gui all the storage domains was marked as active and
>as
>soon as I powered on the first VM the operation went into error of
>course
>and only at that time the 3 storage domains were marked as down...
>From the web admin gui I was able to then activate them and start VMs.
>I had no time to investigate more and so opening a bug for that...
>The problem is that in my opinion the datacenter was marked as up too,
>so
>your check would not be of great meaning.
>In my opinion you could crosscheck also storage domains number with
>expected mount points of type /rhev/data-center/mnt/...
>
>Gianluca

In order  to have a  full operational environment  you  will  need (they depend 
on each other):
1.  Engine is up and healthy
2.  Master  storage domain is up
3.  Datacenter is up
4.  A host  is  selected  for SPM
5.  The storage  domains for the VM are up
6. At least one  Host in the cluster  is up and running (usually that's  the  
node  in step 4)

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/OHEHUWMMY7ZHLA3BV4Q3JZ2IW2HRDGWT/

[ovirt-users] Re: oVirt 4.4.0 Release is now generally available

[Strahil Nikolov via Users]

On May 22, 2020 7:23:45 PM GMT+03:00, Gianluca Cecchi 
 wrote:
>On Fri, May 22, 2020 at 6:18 PM Strahil Nikolov 
>wrote:
>
>>
>> 5.  The storage  domains for the VM are up
>>
>
>As I wrote, it happens sometime that the storage domains are marked as
>up,
>but actually they are not (the related /rhev/data-center/mnt/...
>filesystem
>not mounted)
>
>It happened to me several times, only when restarting from a crash (not
>always though) and only in single host configurations.
>Both in NFS config (not supported actually) and in Gluster config
>(supposed
>to be supported).
>
>Gianluca

Usually,

There should be some  indicator why this  has happened.
Can you check the engine's log when this happens ?

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/A2J5ANIIFMWK3HO6LJDT7CVUJBTERUWV/

[ovirt-users] Re: where is ovirt-iso-uploader in 4.4?

[Strahil Nikolov via Users]

On May 23, 2020 2:14:26 AM GMT+03:00, dan.cr...@thecreeds.net wrote:
>Can't seem to find this, maybe I'm old school but in 4.4 how do I
>upload ISO's I want to boot as CD's on my virtual machine? 
>___
>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/P2TDK2XK5BTRM4CLYLXZDII47CHSYWZV/

Upload them as regular VM disks to a data fomain.
The iso domain should be depracated.

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/VNQY2PMNTQZPJ4KHSU7PPIBM2W6U3YKS/

[ovirt-users] Re: How to change IP range of node and hosted engine without break anything ?

[Strahil Nikolov via Users]

Hosts' ip can be  safely changed only before deployment.

In your case , it would be better if you start from scratch and reinstall the 
host with a new image, set the IP and then redeploy the HostedEngine  (both 
with correct VLANs).

What kind of data domain do you use. Maybe it will be easier to change that 
than a redeploy.

Best Regards,
Strahil Nikolov

На 23 май 2020 г. 15:56:09 GMT+03:00, "Stéphane Paillet" 
 написа:
>Hello,
>
>I installed an ovirt node and its hosted engine in a lab. After several
>
>difficulties to install the engine (I don't know why, I didn't have any
>
>problem in the past), I would like to change IPs of both to put them on
>
>another vlan.
>
>How can I do that without break anything ? My main fear is that the
>data 
>domain used by the hosted engine use the IP of the node rather than its
>
>FQDN. I change other data domains paths, but don't find how to change 
>this one, 'cause I can't modify it, and I can't detach / delete it to 
>recreate another one. I didn't find how to move the engine on another 
>data domain using the node's FQDN in its path. For now, I don't use
>DNS, 
>I just updated /etc/hosts defs on both servers.
>
>If someone could help me, telling me step by step how to change IPs on 
>each element in good order, I would be grateful.
>
>Thank you.
>Cheers,
>Stephane
>___
>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/CMVWT44HRX56JCQDP3C4XZ6CTOI3VXWT/

-- 
Изпратено от моето Андроид у-во чрез K-9 Mail. Моля да ме извините за краткият 
ми изказ.___
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/3TQXYLMVLWU6EKS6EE7JW26K25TFENXV/

[ovirt-users] Re: OVirt Upgrade from 4.3 to 4.4 - Hosted engine

[Strahil Nikolov via Users]

Hi Carlos,

where do you see a refference to standalone engine only ? I don't  see such 
thing.

Best Regards,
Strahil  Nikolov

На 23 май 2020 г. 16:54:20 GMT+03:00, ccesa...@blueit.com.br написа:
>Hello,
>Could someone please inform if Upgrade from OVirt 4.3 to 4.4 when using
>Hosted engine is it supported !? According the documentation
>https://www.ovirt.org/documentation/upgrade_guide/#Upgrading_from_4-3
>the upgrade procedure make reference only  to "standalone engine".
>If it is supported, what is correct steps to do it?
>
>Best regards
>Carlos
>___
>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/NQEU72S3WNIAYF4WECDAFDPEOUE4HXMN/

-- 
Изпратено от моето Андроид у-во чрез K-9 Mail. Моля да ме извините за краткият 
ми изказ.___
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/CRQKH4RZNMVMLNQYAV6KJTYH3QOC5MSP/

[ovirt-users] Re: 4.4 regression: engine-setup fails if admin password in answerfile contains a "%"

[Strahil Nikolov via Users]

Hi Stephen,

I think it's a regression. Could you open an issue/bug .

Best Regards,
Strahil Nikolov

На 24 май 2020 г. 2:28:41 GMT+03:00, Stephen Panicho  
написа:
>I encountered this error when deploying the Hosted Engine via Cockpit:
>
>[ INFO ] TASK [ovirt.engine-setup : Run engine-setup with answerfile]
>[ ERROR ] fatal: [localhost -> engine.ovirt.trashnet.xyz]: FAILED! =>
>{"changed": true, "cmd": ["engine-setup", "--accept-defaults",
>"--config-append=/root/ovirt-engine-answers"], "delta":
>"0:00:01.396490",
>"end": "2020-05-22 18:32:41.965984", "msg": "non-zero return code",
>"rc":
>1, "start": "2020-05-22 18:32:40.569494", "stderr": "", "stderr_lines":
>[],
>"stdout": "[ INFO ] Stage: Initializing\n[ ERROR ] Failed to execute
>stage
>'Initializing': '%' must be followed by '%' or '(', found: '%JUUj'\n[
>INFO
>] Stage: Clean up\n Log file is located at
>/var/log/ovirt-engine/setup/ovirt-engine-setup-20200522183241-c7d1kh.log\n[
>ERROR ] Failed to execute stage 'Clean up': 'NoneType' object has no
>attribute 'cleanup'\n[ INFO ] Generating answer file
>'/var/lib/ovirt-engine/setup/answers/20200522183241-setup.conf'\n[ INFO
>]
>Stage: Pre-termination\n[ INFO ] Stage: Termination\n[ ERROR ]
>Execution of
>setup failed", "stdout_lines": ["[ INFO ] Stage: Initializing", "[
>ERROR ]
>Failed to execute stage 'Initializing': '%' must be followed by '%' or
>'(',
>found: '%JUUj'", "[ INFO ] Stage: Clean up", " Log file is located at
>/var/log/ovirt-engine/setup/ovirt-engine-setup-20200522183241-c7d1kh.log",
>"[ ERROR ] Failed to execute stage 'Clean up': 'NoneType' object has no
>attribute 'cleanup'", "[ INFO ] Generating answer file
>'/var/lib/ovirt-engine/setup/answers/20200522183241-setup.conf'", "[
>INFO ]
>Stage: Pre-termination", "[ INFO ] Stage: Termination", "[ ERROR ]
>Execution of setup failed"]}
>
>The important bit is this: Failed to execute stage 'Initializing': '%'
>must
>be followed by '%' or '(', found: '%JUUj'"
>
>Hey! Those are the last few characters of the admin password. Note that
>I
>don't mean the root password to the VM, but the one for the "admin"
>user of
>the web interface. I added some debug lines to the Ansible play to see
>the
>answerfile that was being generated.
>
>OVESETUP_CONFIG/adminPassword=str:&6&yGfcWf#b%JUUj
>
>Apparently engine-setup can no longer handle an answerfile with a "%"
>character in it. This same password worked in 4.3.
>
>Once I changed the admin password, installation progressed normally.

-- 
Изпратено от моето Андроид у-во чрез K-9 Mail. Моля да ме извините за краткият 
ми изказ.___
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/OHDBPINYMOJVS3PYBNF2IVW72QZOSRTV/

[ovirt-users] Re: How to change IP range of node and hosted engine without break anything ?

[Strahil Nikolov via Users]

I  would  recommend you to keep all Vm configs on a separate location, so you  
will be able to use virsh to start the VMs all by yourself (until you recover 
yoour Hosted Engine in a hypothetical  failiure).
Libvirt  has ( in one  of it's  dirs  ) all running VMs' configs  -  so just 
back them up.

Also, virsh requires a pass  in order to be able  to execute  commands.
I use this alias  on all my hosts:
virsh='virsh -c 
qemu:///system?authfile=/etc/ovirt-hosted-engine/virsh_auth.conf'

Then you can test with 'virsh list' (don't forget to "source" your .bashrc).

Best Regards,
Strahil Nikolov

На 25 май 2020 г. 1:36:48 GMT+03:00, "Stéphane Paillet"  
написа:
>Thank you for this answer and for your help.
>
>After testing several operations without successfully change the IP
>range, I decided to reinstall the host and the hosted engine. I was
>afraid that I could not reinstall the engine correctly because I had
>trouble installing it 3 days ago.
>But this time the installation went well.
>
>I must be more autonomous with this virtualization solution to be able
>to save / restore elements by the command line from the host, because
>for the moment, if I break the engine, I'm like an idiot :) And as I
>can't export it as an ova or take a snapshot when it's up, I don't feel
>comfortable to test.
>
>Regards,
>Stephane
>
>Le 24/05/2020 à 08:34, Strahil Nikolov a écrit :
>> Hosts' ip can be safely changed only before deployment.
>>
>> In your case , it would be better if you start from scratch and
>> reinstall the host with a new image, set the IP and then redeploy the
>> HostedEngine (both with correct VLANs).
>>
>> What kind of data domain do you use. Maybe it will be easier to
>change
>> that than a redeploy.
>>
>> Best Regards,
>> Strahil Nikolov
>>
>> На 23 май 2020 г. 15:56:09 GMT+03:00, "Stéphane Paillet"
>>  написа:
>>
>> Hello,
>>
>> I installed an ovirt node and its hosted engine in a lab. After
>several 
>> difficulties to install the engine (I don't know why, I didn't
>have any 
>> problem in the past), I would like to change IPs of both to put
>them on 
>> another vlan.
>>
>> How can I do that without break anything ? My main fear is that
>the data 
>> domain used by the hosted engine use the IP of the node rather
>than its 
>> FQDN. I change other data domains paths, but don't find how to
>change 
>> this one, 'cause I can't modify it, and I can't detach / delete
>it to 
>> recreate another one. I didn't find how to move the engine on
>another 
>> data domain using the node's FQDN in its path. For now, I don't
>use DNS, 
>> I just updated /etc/hosts defs on both servers.
>>
>> If someone could help me, telling me step by step how to change
>IPs on 
>> each element in good order, I would be grateful.
>>
>> Thank you.
>> Cheers,
>> Stephane
>>
>
>> 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/CMVWT44HRX56JCQDP3C4XZ6CTOI3VXWT/
>>
>>
>> -- 
>> Изпратено от моето Андроид у-во чрез K-9 Mail. Моля да ме извините за
>> краткият ми изказ. 
___
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/WDBWRE7CEDXFPWELXJ4RNUOTDZT6JOV2/

[ovirt-users] Re: Terraform - Ovirt - seting or get some parameters

[Strahil Nikolov via Users]

I want to mention that you don't need  the ovirt guest agent,  but the qemu 
guest agent from the OS  repos.

Have  you  checked  the cloudinit functionality  ?
I think that you can use cloudinit script  to cover most (maybe all)  of your 
needs.

Best Regards,
Strahil Nikolov

На 25 май 2020 г. 8:12:57 GMT+03:00, Michal Obeslo  
написа:
>Hi all, we need a help,
>
>
>we have problem to set and get IP Address when we created virtual
>machine
>when we use terraform.
>
>
>step by step: what we created
>
>
>1) we created virtual machine Debian 9
>
>- installed the software ovirt-guest-agent) [systemctl status
>ovirt-guest
>agent = OK
>
>- we created private and public key to connectivity from another
>computer
>by .ssh ) /Jenkins Slave/
>
>
>2) we created template from virtual machine Debian 9
>
>- set this parameter in template initial Run > user, set static IP in
>Ovirt
>Managemet
>
>
>3) downloaded project from GitHub - create virtual machine from
>template
>
>- terraform main file = OK ?
>
>- terraform init = OK
>
>- terraform apply = OK
>
>: yes
>
>create new virtual machine = OK
>
>start automatically virtual machine = OK
>
>- when I check IP Address > IP address not set
>
>- when I check settings in Ovirt management > network > NOT SET
>
>- virtual machine not has IP addres > not working
>
>- when I change settings in Ovirt management in template Debian from
>Static
>IP dhcp > to DHCP
>
>- when I check settings in Ovirt management > network >
>
>IP in Ovit have DHCP, Virtual machine have dhcp OK
>
>
>But wee need set static IP to Virtual machine and get this IP from
>terraform.
>
>Thank you all.
>
>Best regard Michal
>
>
>--- This is the file main.tf:
>
>provider "ovirt" {
>
>url = "${var.ovirt_url}"
>
>username = "${var.ovirt_username}"
>
>password = "${var.ovirt_password}"
>
>}
>
>
>terraform {
>
>backend "local" {
>
>path = "terraform.tfstate"
>
>}
>
>}
>
>
># Create VM call temp02
>
>module "temp01-pipeline" {
>
>source = "../modules/vms"
>
>vm_authorized_ssh_key =
>"${file(pathexpand("c:/cygwin64/home/Administrator/.ssh/id_rsa.pub"))}"
>
>vm_custom_script = "
>${file(pathexpand("c:/Jenkins/workspace/AT_PipelineVM/config/basic/terraform/ovirt/init_script.yml"))}"
>
>cluster_id = "aa583cf2-a07a-11e8-aa92-525400491e5b"
>
>vm_name = "cd-pipeline-1.0.0"
>
>vm_memory = "4096"
>
>vm_cpu_cores = "1"
>
>vm_template_id = "876a260b-26c7-482e-bc19-19b10b9c48bb"
>
>
>
>vm_hostname = "temp01.example.com"
>
>vm_user_name = "root"
>
>vm_dns_servers = "8.8.8.8"
>
>vm_dns_search = "example.com"
>
>vm_timezone = "Africa/Nairobi"
>
>vm_nic_device = "env3"
>
>vm_nic_ip_address = "192.168.26.36"
>
>vm_nic_gateway = "192.168.26.2"
>
>vm_nic_netmask = "255.255.255.0"
>
>}
___
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/VTGYVFKIUXEWSAABKOEFD2WQQETYLIX7/

[ovirt-users] Re: 4.4 regression: engine-setup fails if admin password in answerfile contains a "%"

[Strahil Nikolov via Users]

Hey Didi,

usually  I fill in the bugzilla template . If it's possible ,  maybe we can 
change the oVirt bugzilla template to cover everything necessary ?

Best Regards,
Strahil Nikolov

На 25 май 2020 г. 9:50:11 GMT+03:00, Yedidyah Bar David  
написа:
>On Sun, May 24, 2020 at 9:36 PM Gianluca Cecchi
> wrote:
>>
>> On Sun, May 24, 2020 at 11:47 AM Yedidyah Bar David 
>wrote:
>>>
>>>
>>>
>>> Hi, Gianluca. Replying to your email on "4.4 HCI Install Failure -
>>> Missing /etc/pki/CA/cacert.pem":
>>>
>>> On Sun, May 24, 2020 at 12:28 PM Gianluca Cecchi
>>>  wrote:
>>> >
>>> > I I remember correctly it happened to me during the beta cycle and
>the only "strange" character I used for the admin password was the @
>>> > Donna if it related with what you reported for the % character
>>>
>>> Did you open a bug?
>>>
>>> In any case, my above patch is not supposed to fix '@', only '%' (I
>think).
>>>
>>> Thanks and best regards,
>>>
>>
>> No, I didn't open a bug, because I scratched the system and installed
>again this time without the error, but I don't remember if I used the
>same password with the @ character or not
>> I will put attention in case of future 4.4 new installations
>
>Very well, thanks :-)
___
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/GVN2I677TJ4V3IDMGNL7QZGPD35X6CA5/

[ovirt-users] Re: 4.4 regression: engine-setup fails if admin password in answerfile contains a "%"

[Strahil Nikolov via Users]

Hey Didi,

yes  this  one.
The user has spent some time to fill in the template,  so we shouldn't expect 
that this user should also dedicate extra time to search for articles :)

Best Regards,
Strahil Nikolov

На 26 май 2020 г. 14:29:57 GMT+03:00, Yedidyah Bar David  
написа:
>On Tue, May 26, 2020 at 2:05 PM Strahil Nikolov 
>wrote:
>>
>> Hey Didi,
>>
>> usually  I fill in the bugzilla template . If it's possible ,  maybe
>we can change the oVirt bugzilla template to cover everything necessary
>?
>
>Do you refer to this:
>
>Description of problem:
>Version-Release number of selected component (if applicable):
>How reproducible:
>Steps to Reproduce:
>1.
>2.
>3.
>Actual results:
>Expected results:
>Additional info:
>
>?
>
>I think we can change it, no idea about details.
>
>That said, I think it's already detailed enough. You have in the form
>also a way to upload logs, etc.
>
>I think it's enough for every open-source-software-user to spend at
>least one time in his career the time needed to read one of the "how
>to report bugs" howtos on the net, no need to repeat it in the form.
>
>Also, like everything else, some experience in doing this helps a
>lot...
>
>Best regards,
>
>>
>> Best Regards,
>> Strahil Nikolov
>>
>> На 25 май 2020 г. 9:50:11 GMT+03:00, Yedidyah Bar David
> написа:
>> >On Sun, May 24, 2020 at 9:36 PM Gianluca Cecchi
>> > wrote:
>> >>
>> >> On Sun, May 24, 2020 at 11:47 AM Yedidyah Bar David
>
>> >wrote:
>> >>>
>> >>>
>> >>>
>> >>> Hi, Gianluca. Replying to your email on "4.4 HCI Install Failure
>-
>> >>> Missing /etc/pki/CA/cacert.pem":
>> >>>
>> >>> On Sun, May 24, 2020 at 12:28 PM Gianluca Cecchi
>> >>>  wrote:
>> >>> >
>> >>> > I I remember correctly it happened to me during the beta cycle
>and
>> >the only "strange" character I used for the admin password was the @
>> >>> > Donna if it related with what you reported for the % character
>> >>>
>> >>> Did you open a bug?
>> >>>
>> >>> In any case, my above patch is not supposed to fix '@', only '%'
>(I
>> >think).
>> >>>
>> >>> Thanks and best regards,
>> >>>
>> >>
>> >> No, I didn't open a bug, because I scratched the system and
>installed
>> >again this time without the error, but I don't remember if I used
>the
>> >same password with the @ character or not
>> >> I will put attention in case of future 4.4 new installations
>> >
>> >Very well, thanks :-)
>>
___
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/ZZAO5I3W7AEDYVF3A43NIHYTC4B2T74B/

[ovirt-users] Re: Tasks stuck waiting on another after failed storage migration (yet not visible on SPM)

[Strahil Nikolov via Users]

I used  to have a similar issue and when I live migrated  (from 1  host to 
another)  it  automatically completed.

Best Regards,
Strahil Nikolov

На 27 май 2020 г. 17:39:36 GMT+03:00, Benny Zlotnik  
написа:
>Sorry, by overloaded I meant in terms of I/O, because this is an
>active layer merge, the active layer
>(aabf3788-8e47-4f8b-84ad-a7eb311659fa) is merged into the base image
>(a78c7505-a949-43f3-b3d0-9d17bdb41af5), before the VM switches to use
>it as the active layer. So if there is constantly additional data
>written to the current active layer, vdsm may have trouble finishing
>the synchronization
>
>
>On Wed, May 27, 2020 at 4:55 PM David Sekne 
>wrote:
>>
>> Hello,
>>
>> Yes, no problem. XML is attached (I ommited the hostname and IP).
>>
>> Server is quite big (8 CPU / 32 Gb RAM / 1 Tb disk) yet not
>overloaded. We have multiple servers with the same specs with no
>issues.
>>
>> Regards,
>>
>> On Wed, May 27, 2020 at 2:28 PM Benny Zlotnik 
>wrote:
>>>
>>> Can you share the VM's xml?
>>> Can be obtained with `virsh -r dumpxml `
>>> Is the VM overloaded? I suspect it has trouble converging
>>>
>>> taskcleaner only cleans up the database, I don't think it will help
>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/HX4QZDIKXH7ETWPDNI3SKZ535WHBXE2V/
___
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/6X5PAZG7RC4KEQZJIRKHXMBK7256Q2C7/

[ovirt-users] Re: oVirt not using local GlusterFS bricks

[Strahil Nikolov via Users]

If you don't have  pending heals  constantly  - the FUSE clients are  using  
all 3  bricks.

What is your storage  domain mount  options  ?

My guess is that if you set a host in maintenance (and mark it to stop the 
gluster) and then start gluster (you can also run gluster volume start with the 
force option) and activate the host - it will fix everything.

Why do  you think that ovirt1/3  use  only ovirt2  for storage ?

I  am using the following bash function (you can add it to .bashrc and source 
.bashrc)  to find if any client is disconnected. You  will need to run it on 
all gluster nodes:

gluster-check-connection(){
VOLUME=$(gluster volume list | grep -v gluster_shared_storage )
for i in $VOLUME
do
VOLUME_PATH=$(echo $i | sed 's/_/__/')
grep -i connected 
/rhev/data-center/mnt/glusterSD/gluster1\:_$VOLUME_PATH/.meta/graphs/active/${i}-client-*/private
done
}

Here  is a sample output (you should see similar:

[root@ovirt1 ~]# gluster-check-connection
/rhev/data-center/mnt/glusterSD/gluster1:_data/.meta/graphs/active/data-client-0/private:connected
 = 1
/rhev/data-center/mnt/glusterSD/gluster1:_data/.meta/graphs/active/data-client-1/private:connected
 = 1
/rhev/data-center/mnt/glusterSD/gluster1:_data/.meta/graphs/active/data-client-2/private:connected
 = 1

/rhev/data-center/mnt/glusterSD/gluster1:_engine/.meta/graphs/active/engine-client-0/private:connected
 = 1
/rhev/data-center/mnt/glusterSD/gluster1:_engine/.meta/graphs/active/engine-client-1/private:connected
 = 1
/rhev/data-center/mnt/glusterSD/gluster1:_engine/.meta/graphs/active/engine-client-2/private:connected
 = 1


Best  Regards,
Strahil Nikolov

На 27 май 2020 г. 17:45:36 GMT+03:00, Randall Wood  
написа:
>I have a three node oVirt 4.3.7 cluster that is using GlusterFS as the
>underlying storage (each oVirt node is a GlusterFS node). The nodes are
>named ovirt1, ovirt2, and ovirt3. This has been working wonderfully
>until last week when ovirt2 crashed (it is *old* hardware; this was not
>entirely unexpected).
>
>Now I have this situation: all three oVirt nodes are acting as if the
>GlusterFS volumes only exist on ovirt2. The bricks on all three nodes
>appear to be in sync.
>
>I *think* this began happening after I restarted ovirt2 (once hard, and
>once soft) and then restarted glusterd (and only glusterd) on ovirt1
>and ovirt3 after `gluster-eventsapi status` on those two nodes showed
>inconsistent results (this had been used with success before).
>
>How can I make the oVirt nodes read and write from their local bricks?
>___
>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/KXTXBLHRUGQR7TLCJZF3QEI6AO4RJU24/
___
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/PGS5KKMSOW4X2ZPH72QYG6JQTEVKB2NG/

[ovirt-users] Re: ovirt-websocket-proxy errors when trying noVNC

[Strahil Nikolov via Users]

Are you in the same network segment as the Engine ?
Maybe there  is a firewall preventing you to reach port 6100/tcp .
What is the output from ncat  -v engine-FQDN 6100

Best Regards,
Strahil Nikolov

На 27 май 2020 г. 18:48:31 GMT+03:00, Louis Bohm  написа:
>I am running MAC OS X but I was able to import the CA Cert and I can
>see it in my Keychain.  However, when I try to bring up the console I
>get:
>Can't connect to websocket proxy server
>wss://lfg-kvm.corp.lfg.com:6100. Please check that:
>websocket proxy service is running,
>firewalls are properly set,
>websocket proxy certificate is trusted by your browser. Default CA
>certificate
>.
>
>
>Louis
>-<<—->>-
>Louis Bohm
>louisb...@gmail.com
>
>
>
>
>> On May 27, 2020, at 11:01 AM, Scott Dickerson 
>wrote:
>> 
>> 
>> On Wed, May 27, 2020 at 7:42 AM Louis Bohm > wrote:
>> OS: Oracle Linux 7.8 (unbreakable kernel)
>> Using Oracle Linux Virtualization Manager: Software
>Version:4.3.6.6-1.0.9.el7
>> 
>> Since I am running all of it on one physical machine I opted to
>install the ovirt-engine using the accept defaults option.
>> 
>> When I try to start a noVNC console I see this in the messages file:
>> May 26 16:49:12 lfg-kvm saslpasswd2: Could not find keytab file:
>/etc/qemu/krb5.tab: No such file or directory
>> May 26 16:49:12 lfg-kvm saslpasswd2: error deleting entry from
>sasldb: BDB0073 DB_NOTFOUND: No matching key/data pair found
>> May 26 16:49:12 lfg-kvm saslpasswd2: error deleting entry from
>sasldb: BDB0073 DB_NOTFOUND: No matching key/data pair found
>> May 26 16:49:12 lfg-kvm saslpasswd2: error deleting entry from
>sasldb: BDB0073 DB_NOTFOUND: No matching key/data pair found
>> May 26 16:49:12 lfg-kvm saslpasswd2: error deleting entry from
>sasldb: BDB0073 DB_NOTFOUND: No matching key/data pair found
>> May 26 16:49:14 lfg-kvm journal: 2020-05-26 16:49:14,704-0400
>ovirt-websocket-proxy: INFO msg:824 handler exception: [SSL:
>SSLV3_ALERT_CERTIFICATE_UNKNOWN] sslv3 alert certificate unknown
>(_ssl.c:618)
>> May 26 16:49:14 lfg-kvm ovirt-websocket-proxy.py:
>ovirt-websocket-proxy[14582] INFO msg:824 handler exception: [SSL:
>SSLV3_ALERT_CERTIFICATE_UNKNOWN] sslv3 alert certificate unknown
>(_ssl.c:618)
>> 
>> I have checked the following:
>> [root@lfg-kvm ~]#  engine-config -g WebSocketProxy
>> WebSocketProxy: lfg-kvm.corp.lfg.com:6100
> version: general
>> [root@lfg-kvm ~]# engine-config -g SpiceProxyDefault
>> SpiceProxyDefault: http://lfg-kvm.corp.lfg.com:6100
> version: general
>> 
>> This is a brand new install.
>> 
>> I also am unable to get a VNC console up and running.  I have tried
>with an Ubuntu VM running on my MAC where I installed virt-manager. 
>The viewer comes up for a second says it cannot connect and then
>shutsdown.
>> 
>> 
>> If you're only using noVNC, then you need to make sure you import the
>CA Cert and trust it in your browser.  There is no way to interactively
>accept the self-signed cert from the engine when noVNC connects via the
>websocket proxy.
>>  
>> Anyone have any clue?
>> -<<—->>-
>> Louis Bohm
>> louisb...@gmail.com 
>> 
>
>
>> ___
>> 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/U66GSTI4QJSGPM6LUVF2WC2UW5JQCNCX/
>
>> 
>> 
>> -- 
>> Scott Dickerson
>> Senior Software Engineer
>> RHV-M Engineering - UX Team
>> Red Hat, Inc
___
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/TUCHAHFZYDPWKRUEV64XFWTTGBPOHUBO/

[ovirt-users] Re: PKIX path error

[Strahil Nikolov via Users]

Can you check 
https://www.ovirt.org/documentation/admin-guide/appe-oVirt_and_SSL.html  just  
in case you  missed  a  step ?

Best  Regards,
Strahil  Nikolov

На 27 май 2020 г. 23:10:53 GMT+03:00, Stack Korora  
написа:
>Greetings,
>I have a running oVirt install that's been working for almost 2 years.
>I'm building a _completely_ new install. I mention it because it is
>useful for me to compare configurations when I run into issues like
>this
>one.
>
>Right now there are three physical hosts:
>1x management where I run the engine and db
>2x hypervisor nodes.
>
>I had it up and installed and running smooth this morning on
>4.3.9.4-1.el7 on Scientific Linux 7.8 (fully patched).
>
>I copied over our 3rd party certs from the running system and restarted
>httpd. Perfect. SSL is running!
>/etc/pki/ovirt-engine/apache-ca.pem
>/etc/pki/ovirt-engine/certs/apache.cer
>/etc/pki/ovirt-engine/keys/apache.key.nopass
>
>Next I used ovirt-engine-extension-aaa-ldap-setup to point to our ldap
>server. I did the login and search test and both passed on the command
>line! Horray!
>
>Then I went to the web interface...
>
>sun.security.validator.ValidatorException: PKIX path building failed:
>sun.security.provider.certpath.SunCertPathBuilderException: unable to
>find valid certification path to requested target
>
>I'm digging through logs and I don't see anything close to this error
>except nearly the identical message in engine.log.
>
>ERROR [org.ovirt.engine.core.aaa.servlet.SslPostLoginServlet] (default
>task-2) [] server_error: sun.security.validator.ValidatorException:
>PKIX
>path building failed:
>sun.security.provider.certpath.SunCertPathBuilderException: unable to
>find valid certification path to requested target
>
>I can't log in via the web at all, I only get that message (so I can't
>even test out the local admin). The aaa ldap configuration it generated
>is darn near perfectly identical (just a name change). The certs are
>the
>same. Even when I look in the keystore, the sha1 hashes are the same
>between the two environments!
>
>After over an hour poking at this, I'm completely stumped.
>
>Can someone please give me a pointer on what I should try next?
>
>Thanks!
>~Stack~
>___
>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/YOR3ATLII3LYIBEYVOKTEE4RIYZGJR76/
___
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/23P3SRYRF2JXPLMSRRR3H5EED4427DCG/

[ovirt-users] Re: Engine expands CPU and memory

[Strahil Nikolov via Users]

Have you tried  to edit the HostedEngine VM in the  UI  ?

Best  Regards,
Strahil Nikolov

На 28 май 2020 г. 4:48:34 GMT+03:00, xil...@126.com написа:
>Hi, everyone. When I use the ovirt cluster, there are multiple virtual
>machines in the cluster.Engine controller shows excessive CPU load
>during administration, I would like to ask if there is a way to extend
>engine controller CPU and memory online, I would be very grateful.thank
>you
>___
>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/4AVO5RT5DOSJSI4WIULFCTQ5UITW62U3/
___
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/K6BI64MCFYKFSJFE47WIVM4WQ2WPNGV3/

[ovirt-users] Re: AutoStart VMs (was Re: Re: oVirt 4.4.0 Release is now generally available)

[Strahil Nikolov via Users]

Hi Derek,

I also  don't like  Python  (and I prefer Salt  instead of Ansible), but 
Ansible is the wiser option /personal opinion/ .
My reasons  - API change , so your  code will eventually will die.
With Ansible -  a  lot  of people use it and there  is a  high  chance that  
some updates the Ansible module that  will do the job even after the API 
changes.

Also,  Ansible is declarative ,  while  python will need more  effort.

Best  Regards,
Strahil Nikolov

На 28 май 2020 г. 4:59:16 GMT+03:00, Derek Atkins  написа:
>Hi,
>
>On Wed, May 27, 2020 5:38 pm, Gianluca Cecchi wrote:
>[snip]
>> But you hated Python, didn't you? ;-)
>
>I do.  Can't stand it.  Doesn't mean I can't read it and/or write it,
>but
>I have to hold my nose doing it.  Syntactic white space?  Eww.  But
>Python
>is already installed and used and, apparently, supported..  And when I
>looked at the examples I found that 90% of what I needed to do was
>already
>implemented, so it turned out to be much easier than expected.
>
>> I downloaded your files, even if I'm far from knowing python
>
>It's pretty much a direct translation of my bash script around
>ovirt-shell.  It does have one feature that the old code didn't, which
>is
>the ability to wait for ovirt to declare that a vm is actually "up".
>
>> try the ansible playbook that gives you more flexibility in my
>opinion
>
>I've never even installed ansible, let alone tried to use it.  I don't
>need flexibility, I need the job to get done.  But I'll take a look
>when I
>get the chance.  Thanks!
>
>> Gianluca
>
>-derek
>
>PS: you (meaning whomever is "in charge" is welcome to add my script(s)
>to
>the examples repo if you feel other people would benefit from seeing it
>there.
___
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/FUFNIKLAPLPLBGHSSZNMYYBMSVENWXQL/

[ovirt-users] Re: oVirt 4.4 and installer problem on Dell M620

[Strahil Nikolov via Users]

Have you tried  installing in text mode ?

На 28 май 2020 г. 18:53:05 GMT+03:00, Gianluca Cecchi 
 написа:
>Hello,
>I'm trying to install what in subject but it seems the graphical part
>fails...
>In fact the console remains black and if I switch  witch Ctrl+Alt+ F1 I
>see
>this screen
>
>https://drive.google.com/file/d/1mt9ipxNLpe1xadbkXsU-Avh_GnFafNek/view?usp=sharing
>
>Anyone tried on this kind of hardware? Can I try to give any particular
>boot option?
>Thanks,
>Gianluca
___
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/ET5WPY62YPGJ4CXI3DW2XK4QS5ZELXJW/

[ovirt-users] Re: ovirt-websocket-proxy errors when trying noVNC

[Strahil Nikolov via Users]

Hi Louis,

can you install a fresh browser and try to open the Engine's web interface.
Do you see a certificate  warning or it just opens.
I'm asking for a fresh browser because some browsers can accept certificates 
that while the other apps  on the system do not accept (certificate is  not in 
the windows cert store).

Also,  how did you configure the noVNC ?

Best Regards,
Strahil Nikolov

На 28 май 2020 г. 19:17:09 GMT+03:00, Louis Bohm  написа:
>Do not have Ncat on my windows vm but I can telnet to port 6100 on the
>engine from both my windows vm and my MAC.
>
>Louis
>-<<—->>-
>Louis Bohm
>louisb...@gmail.com
>
>
>
>
>> On May 28, 2020, at 12:03 PM, Strahil Nikolov 
>wrote:
>> 
>> Are you in the same network segment as the Engine ?
>> Maybe there  is a firewall preventing you to reach port 6100/tcp .
>> What is the output from ncat  -v engine-FQDN 6100
>> 
>> Best Regards,
>> Strahil Nikolov
>> 
>> На 27 май 2020 г. 18:48:31 GMT+03:00, Louis Bohm > написа:
>>> I am running MAC OS X but I was able to import the CA Cert and I can
>>> see it in my Keychain.  However, when I try to bring up the console
>I
>>> get:
>>> Can't connect to websocket proxy server
>>> wss://lfg-kvm.corp.lfg.com:6100 .
>Please check that:
>>> websocket proxy service is running,
>>> firewalls are properly set,
>>> websocket proxy certificate is trusted by your browser. Default CA
>>> certificate
>>>
>>.
>>> 
>>> 
>>> Louis
>>> -<<—->>-
>>> Louis Bohm
>>> louisb...@gmail.com 
>>> 
>>>
>>
>>>
>>
>>> 
 On May 27, 2020, at 11:01 AM, Scott Dickerson >
>>> wrote:
 
 
 On Wed, May 27, 2020 at 7:42 AM Louis Bohm 
>>> >> wrote:
 OS: Oracle Linux 7.8 (unbreakable kernel)
 Using Oracle Linux Virtualization Manager: Software
>>> Version:4.3.6.6-1.0.9.el7
 
 Since I am running all of it on one physical machine I opted to
>>> install the ovirt-engine using the accept defaults option.
 
 When I try to start a noVNC console I see this in the messages
>file:
 May 26 16:49:12 lfg-kvm saslpasswd2: Could not find keytab file:
>>> /etc/qemu/krb5.tab: No such file or directory
 May 26 16:49:12 lfg-kvm saslpasswd2: error deleting entry from
>>> sasldb: BDB0073 DB_NOTFOUND: No matching key/data pair found
 May 26 16:49:12 lfg-kvm saslpasswd2: error deleting entry from
>>> sasldb: BDB0073 DB_NOTFOUND: No matching key/data pair found
 May 26 16:49:12 lfg-kvm saslpasswd2: error deleting entry from
>>> sasldb: BDB0073 DB_NOTFOUND: No matching key/data pair found
 May 26 16:49:12 lfg-kvm saslpasswd2: error deleting entry from
>>> sasldb: BDB0073 DB_NOTFOUND: No matching key/data pair found
 May 26 16:49:14 lfg-kvm journal: 2020-05-26 16:49:14,704-0400
>>> ovirt-websocket-proxy: INFO msg:824 handler exception: [SSL:
>>> SSLV3_ALERT_CERTIFICATE_UNKNOWN] sslv3 alert certificate unknown
>>> (_ssl.c:618)
 May 26 16:49:14 lfg-kvm ovirt-websocket-proxy.py:
>>> ovirt-websocket-proxy[14582] INFO msg:824 handler exception: [SSL:
>>> SSLV3_ALERT_CERTIFICATE_UNKNOWN] sslv3 alert certificate unknown
>>> (_ssl.c:618)
 
 I have checked the following:
 [root@lfg-kvm ~]#  engine-config -g WebSocketProxy
 WebSocketProxy: lfg-kvm.corp.lfg.com:6100
>
>>> > version: general
 [root@lfg-kvm ~]# engine-config -g SpiceProxyDefault
 SpiceProxyDefault: http://lfg-kvm.corp.lfg.com:6100
>
>>> > version: general
 
 This is a brand new install.
 
 I also am unable to get a VNC console up and running.  I have tried
>>> with an Ubuntu VM running on my MAC where I installed virt-manager. 
>>> The viewer comes up for a second says it cannot connect and then
>>> shutsdown.
 
 
 If you're only using noVNC, then you need to make sure you import
>the
>>> CA Cert and trust it in your browser.  There is no way to
>interactively
>>> accept the self-signed cert from the engine when noVNC co

[ovirt-users] Re: oVirt 4.3.9 Standalone Engine local DB install documentation

[Strahil Nikolov via Users]

Hi Marc,

4.3.X will not have a long life  and the upgrade will be a  p**n in the *** .
I know that 4.4 will be hard to install untill all the bugs are polished, but I 
highly advise you to try to deploy 4.4 first.

Best Regards,
Strahil Nikolov

На 28 май 2020 г. 19:46:57 GMT+03:00, msantoro--- via Users  
написа:
>Hello,
>
>I am new to oVirt and installing our first dev deployment.  The 4.4
>documentation is RHEL 8.1 specific (i.e. "yum module "), and I
>cannot seem to easily find similar install documentation for the
>Standalone local DB case for 4.3.x.  I am using RHEL 7.x for the time
>being.  Can someone point me to install docs 4.3.x?
>
>Thanks,
>Marc
>___
>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/M665BM5LJVJAC6G2J3PNY5RNIH5LXLMK/
___
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/NODKROPPHUDOYY75NMA2CFU2P3XWZ37U/

[ovirt-users] Re: Issues deploying 4.4 with HE on new EPYC hosts

[Strahil Nikolov via Users]

Based on my vague memories from Dec 2018,  I think I got a similar situation 
where I had to delete that external Engine.

Of  course that was  on 4.2.7 and the story here can be different. If you use 
gluster, you can power off the engine (Global Maintenance) and then create a 
gluster snapshot before wiping the remnants.

Best Regards,
Strahil Nikolov

На 29 май 2020 г. 0:52:46 GMT+03:00, Gianluca Cecchi 
 написа:
>On Thu, May 28, 2020 at 3:09 PM Gianluca Cecchi
>
>wrote:
>
>[snip]
>
>>
>>
>> for the cluster type in the mean time I was able to change it to
>"Intel
>> Cascadelake Server Family" from web admin gui and now I have to try
>these
>> steps and see if engine starts automatically without manual
>operations
>>
>> 1) set global maintenance
>> 2) shutdown engine
>> 3) exit maintenance
>> 4) see if the engine vm starts without the cpu flag
>>
>>
>I confirm that point 4) was successful and engine vm was able to
>autostart,
>after changing cluster type.
>I'm also able to connect to its console from web admin gui
>
>The command line generated now is:
>
>qemu 29450 1 43 23:38 ?00:03:09 /usr/libexec/qemu-kvm
>-name
>guest=HostedEngine,debug-threads=on -S -object
>secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-10-HostedEngine/master-key.aes
>-machine pc-q35-rhel8.1.0,accel=kvm,usb=off,dump-guest-core=off -cpu
>Cascadelake-Server,hle=off,rtm=off,arch-capabilities=on -m
>size=16777216k,slots=16,maxmem=67108864k -overcommit mem-lock=off -smp
>2,maxcpus=32,sockets=16,cores=2,threads=1 -object iothread,id=iothread1
>-numa node,nodeid=0,cpus=0-31,mem=16384 -uuid
>b572d924-b278-41c7-a9da-52c4f590aac1 -smbios
>type=1,manufacturer=oVirt,product=RHEL,version=8-1.1911.0.9.el8,serial=d584e962-5461-4fa5-affa-db413e17590c,uuid=b572d924-b278-41c7-a9da-52c4f590aac1,family=oVirt
>-no-user-config -nodefaults -device sga -chardev
>socket,id=charmonitor,fd=40,server,nowait -mon
>chardev=charmonitor,id=monitor,mode=control -rtc
>base=2020-05-28T21:38:21,driftfix=slew -global
>kvm-pit.lost_tick_policy=delay -no-hpet -no-reboot -global
>ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on
>-device
>pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2
>-device
>pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1
>-device
>pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2
>-device
>pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3
>-device
>pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4
>-device
>pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5
>-device
>pcie-root-port,port=0x16,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x6
>-device
>pcie-root-port,port=0x17,chassis=8,id=pci.8,bus=pcie.0,addr=0x2.0x7
>-device
>pcie-root-port,port=0x18,chassis=9,id=pci.9,bus=pcie.0,multifunction=on,addr=0x3
>-device
>pcie-root-port,port=0x19,chassis=10,id=pci.10,bus=pcie.0,addr=0x3.0x1
>-device
>pcie-root-port,port=0x1a,chassis=11,id=pci.11,bus=pcie.0,addr=0x3.0x2
>-device
>pcie-root-port,port=0x1b,chassis=12,id=pci.12,bus=pcie.0,addr=0x3.0x3
>-device
>pcie-root-port,port=0x1c,chassis=13,id=pci.13,bus=pcie.0,addr=0x3.0x4
>-device
>pcie-root-port,port=0x1d,chassis=14,id=pci.14,bus=pcie.0,addr=0x3.0x5
>-device
>pcie-root-port,port=0x1e,chassis=15,id=pci.15,bus=pcie.0,addr=0x3.0x6
>-device
>pcie-root-port,port=0x1f,chassis=16,id=pci.16,bus=pcie.0,addr=0x3.0x7
>-device
>pcie-root-port,port=0x20,chassis=17,id=pci.17,bus=pcie.0,addr=0x4
>-device pcie-pci-bridge,id=pci.18,bus=pci.1,addr=0x0 -device
>qemu-xhci,p2=8,p3=8,id=ua-b630a65c-8156-4542-b8e8-98b4d2c48f67,bus=pci.4,addr=0x0
>-device
>virtio-scsi-pci,iothread=iothread1,id=ua-b7696ce2-fd8c-4856-8c38-197fc520271b,bus=pci.5,addr=0x0
>-device
>virtio-serial-pci,id=ua-608f9599-30b2-4ee6-a0d3-d5fb588583ad,max_ports=16,bus=pci.3,addr=0x0
>-drive
>if=none,id=drive-ua-fa671f6c-dc42-4c59-a66d-ccfa3d5d422b,readonly=on
>-device
>ide-cd,bus=ide.2,drive=drive-ua-fa671f6c-dc42-4c59-a66d-ccfa3d5d422b,id=ua-fa671f6c-dc42-4c59-a66d-ccfa3d5d422b,werror=report,rerror=report
>-drive
>file=/var/run/vdsm/storage/3df8f6d4-d572-4d2b-9ab2-8abc456a396f/df02bff9-2c4b-4e14-a0a3-591a84ccaed9/bf435645-2999-4fb2-8d0e-5becab5cf389,format=raw,if=none,id=drive-ua-df02bff9-2c4b-4e14-a0a3-591a84ccaed9,cache=none,aio=threads
>-device
>virtio-blk-pci,iothread=iothread1,scsi=off,bus=pci.6,addr=0x0,drive=drive-ua-df02bff9-2c4b-4e14-a0a3-591a84ccaed9,id=ua-df02bff9-2c4b-4e14-a0a3-591a84ccaed9,bootindex=1,write-cache=on,serial=df02bff9-2c4b-4e14-a0a3-591a84ccaed9,werror=stop,rerror=stop
>-netdev
>tap,fds=43:44,id=hostua-b29ca99f-a53e-4de7-8655-b65ef4ba5dc4,vhost=on,vhostfds=45:46
>-device
>virtio-net-pci,mq=on,vectors=6,host_mtu=1500,netdev=hostua-b29ca99f-a53e-4de7-8655-b65ef4ba5dc4,id=ua-b29ca99f-a53e-4de7-8655-b65ef4ba5dc4,mac=00:16:3e:0a:96:80,bus=pci.2,addr=0x0
>-chardev socket,id=charserial0,fd=47,server,nowait -device
>isa-serial,chardev=charserial0,id=serial0 -charde

[ovirt-users] Re: PKIX path error

[Strahil Nikolov via Users]

You mentioned that  your certificates were different. Did you try converting 
them to the type  used  in the example ?

Best Regards,
Strahil Nikolov

На 29 май 2020 г. 1:29:51 GMT+03:00, Stack Korora  
написа:
>On 2020-05-28 16:07, Strahil Nikolov wrote:
>> Can you check
>https://www.ovirt.org/documentation/admin-guide/appe-oVirt_and_SSL.html
> just  in case you  missed  a  step ?
>>
>> Best  Regards,
>> Strahil  Nikolov
>
>Greetings,
>
>Thanks for replying.
>
>I was going to argue a bit since the way my certs come are in different
>formats so my commands are a bit different then the directions. But I
>went through step by step. Got to the end, and the internal
>authentication was working with the right SSL cert! My LDAP
>authentication was missing though...it looks correct.
>
>So I redid all the steps for adding LDAP. At the end of the
>ovirt-engine-extension-aaa-ldap-setup script, I can test accounts and
>search so I know that is correct. My cert is in the right .jks file.
>Still nothing I do shows anything but internal.
>
>So I scrapped the changes and started over. Round three on a fresh
>reboot (just in case I missed a service) with the SSL certs and
>configuring LDAP. SSL works, internal works, ldap doesn't show up as a
>drop-down option for the profile.
>
>Grr...Reboot just in case I missed a service again...nope. SSL and
>internal work, ldap still not shown in the profile. Tried a different
>browser, same thing. Double Grr...
>
>Any suggestions on where I might be going wrong?
>
>Thanks!
>
>
>
>___
>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/A4BKWITWPNPYYVLDVRN4XOSDTN4LPNB3/
___
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/5ANRX472AJLRXMZBEDPF2QH5UG23GWQP/

[ovirt-users] Re: Q: Fixing SELinux Permissions on oVirt node

[Strahil Nikolov via Users]

I can give you another tip -  use  'sealert'.

yum install  setroubleshoot-server
sealert -a /var/log/audit/audit.log

It  will provide  you with guidance.

Actually  selinux  hast  'allow' rules  based on process type (last part  after 
 ':') with the file type.
ps aux -Z
ls  -lZ file

Sometimes you need  to tell selinux that a file should have another  label :
semanage -a -t var_log_t somefile
restorecon -v somefile

SELINUX  is quite  benefitial  for  VMs/Containers  because even if one of them 
is hacked,  it will still not be able  to reach another  one (even  if 
ownership is  the same).

Best  Regards,
Strahil  Nikolov

На 29 май 2020 г. 17:26:37 GMT+03:00, Andrei Verovski  
написа:
>Hi,
>
>OK, Michael, thanks a LOT, these commands fixed problem.
>
>cat /var/log/audit/audit.log | grep snmpd | grep sed | audit2allow -M
>my_module_for_snmpd
>semodule -i my_module_for_snmpd.pp
>
>
>
>
>> On 29 May 2020, at 16:31, Michaël Couren  wrote:
>> 
>> Hi, 
>> you coul'd start with :
>> 
>> cat /var/log/audit/audit.log | grep denied | audit2why 
>> 
>> The messages are quite clear.
>> 
>> After you coul'd also refine a little bit more :
>> 
>> cat /var/log/audit/audit.log |grep snmpd |  audit2allow -M
>my_module_for_snmpd
>> 
>> Remember to renew audit.log sometimes, in order to filter errors more
>preciselly
>> -- 
>> Cordialement / Best regards, Michaël Couren,
>> ABES, Montpellier, France.
>> 
>> 
>> 
>> - Le 29 Mai 20, à 15:14, Andrei Verovski andre...@starlett.lv a
>écrit :
>> 
>>> Hi,
>>> 
>>> SELinux is quite cumbersome for someone which not used it before.
>>> 
>>> stat /var/log/anvraidcheck.log
>>> #  File: ‘/var/log/anvraidcheck.log’
>>> #  Size: 75  Blocks: 8  IO Block: 4096   regular
>file
>>> # Device: fd08h/64776dInode: 138 Links: 1
>>> # Access: (0666/-rw-rw-rw-)  Uid: (0/root)   Gid: (0/   
>root)
>>> # Context: system_u:object_r:cron_log_t:s0
>>> 
>>> ps -eZ | grep snmpd
>>> # system_u:system_r:snmpd_t:s0 1835 ?00:02:00 snmpd
>>> 
>>> 
>>> How to enforce this policy (if its correct of course)?
>>> 
>>> allow snmpd_t cron_log_t:file { read };
>>> 
>>> 
>>> 
 On 29 May 2020, at 12:31, Alan  wrote:
 
 When running from the terminal you are unconfined, hence it runs
>without error.
 
 Probably your only option is to create custom policy to allow this.
>Although I
 would question why the log file you are reading is cron_log_t and
>not
 var_log_t.
 
 
  On Fri, 29 May 2020 09:25:41 +0100 Andrei Verovski
>
 wrote 
 
 Hi !
 
 I’m struggling with SELinux blocking SNMP script from reading log
>file (oVirt
 node manually installed on CentOS 7).
 Log file is readable by all (chmod ugo+r).
 
 Scripts working fine when executed from terminal.
 
 I did not dig deep into CentOS internals, I’m mostly use Debian and
>SuSE. As far
 as I know, SELinux can’t be turned off on oVirt node.
 
 Thanks in advance for any suggestion(s).
 
 
 **
 
 option in snmpd.conf
 
 extend .1.3.6.1.4.1.2021.7890.5 checkraid /opt/4anvcheckraid_hp.sh
 
 
 **
 script 4anvcheckraid_hp.sh
 
 #!/bin/bash
 
 LOGFILE='/var/log/anvraidcheck.log'
 
 if [ ! -f $LOGFILE ]; then
 exit 0
 fi
 
 # Variant 1 with sed
 sed '/^[ \t]*$/d' $LOGFILE | while read line; do
 echo "$line"
 exit 1
 done
 
 # Variant 2 without sed
 while read line
 do
 if [[ "$line" =~ [^[:space:]] ]]; then
 echo "$line"
 exit 1
 fi
 done < $LOGFILE
 
 
 **
 
 SELinux audit log:
 
 type=AVC msg=audit(1590673970.198:469304): avc: denied { read } for
>pid=12142
 comm="sed" name="anvraidcheck.log" dev="dm-8" ino=138
 scontext=system_u:system_r:snmpd_t:s0
>tcontext=system_u:object_r:cron_log_t:s0
 tclass=file permissive=0
 
 type=AVC msg=audit(1590673970.197:469303): avc: denied { read } for
>pid=12141
 comm="4anvcheckraid_h" name="anvraidcheck.log" dev="dm-8" ino=138
 scontext=system_u:system_r:snmpd_t:s0
>tcontext=system_u:object_r:cron_log_t:s0
 tclass=file permissive=0
 
 ___
 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/MYWS2S57UP5GISJ7APXVJO6NVCVEFM22/

>

[ovirt-users] Re: basic infra and glusterfs sizing question

[Strahil Nikolov via Users]

Last time I used oVirt to deploy my gluster, cockpit was  using thick LVs 
instead of thin LVM.
I think that thin LVM is  way more  suitable for the task. Then you can set the 
size  to anything needed.

Best Regards,
Strahil Nikolov

На 29 май 2020 г. 18:27:59 GMT+03:00, Jayme  написа:
>Also, I can't think of the limit off the top of my head. I believe it's
>either 75 or 100Gb. If the engine volume is set any lower the
>installation
>will fail. There is a minimum size requirement.
>
>On Fri, May 29, 2020 at 12:09 PM Jayme  wrote:
>
>> Regarding Gluster question. The volumes would be provisioned with LVM
>on
>> the same block device. I believe 100Gb is recommended for the engine
>> volume. The other volumes such as data would be created on another
>logical
>> volume and you can use up the rest of the available space there. Ex.
>100gb
>> engine, 500Gb data and 400Gb vmstore.
>>
>> Data domains are basically the same now, in the past there used to be
>> different domain types such as ISO domains which are deprecated. You
>don't
>> really need any more than engine volume and data volume.  You could
>have a
>> volume for storing ISOs if you wanted to. You could have a separate
>volume
>> for OS disks and another volume for data disks which would give you
>more
>> flexibility for backups (so that you could backup data disks but not
>OS for
>> example).
>>
>> On Fri, May 29, 2020 at 10:29 AM Jiří Sléžka 
>wrote:
>>
>>> Hello,
>>>
>>> I am just curious if basic gluster HCI layout which is suggested in
>>> cockpit has some deeper meaning.
>>>
>>> There are suggested 3 volumes
>>>
>>> * engine - it is clear, it is the volume where engine vm is running.
>>> When this vm is 51GB big how small could this volume be? I have 1TB
>SSD
>>> storage and I would like utilize it as much as possible. Could I
>create
>>> this volume as small as this vm is? Is it safe for example for
>future
>>> upgrades?
>>>
>>> * vmstore - it make sense it is a space for all other vms running in
>>> oVirt. Right?
>>>
>>> * data - which purpose has this volume? other data like for example
>>> ISOs? Direct disks?
>>>
>>> Another infra question... or maybe request for comment
>>>
>>> I have small amount of public ipv4 addresses in my housing (but I
>have
>>> own switches there so I can create vlans and separate internal
>traffic).
>>> I can access only these public ipv4 addresses directly. I would like
>to
>>> conserve these addressess as much as possible so what is the best
>>> approach in your opinion?
>>>
>>> * Install all hosts and HE with management network on private
>addressess
>>>
>>>   * have small router (hw appliance with for example LEDE) which
>will
>>> utilize one ipv4 address and will do NAT and vpn for accessing my
>>> internals vlans.
>>> + looks like simple approach to me
>>> - single point of failure in this router (not really - just in
>case
>>> oVirt is badly broken and I need to access internal vlans to recover
>it)
>>>
>>>   * have this router as virtual appliance inside oVirt (something
>like
>>> pfSense for example)
>>> + no need hw router
>>> + not sure but I could probably configure vrrp redundancy
>>> - still single point of failure like in first case
>>>
>>>   * any other approach? Could ovn help here somehow?
>>>
>>> * Install all hosts and HE with public addresses :-)
>>>   + access to all hosts directly
>>>   - 3 node HCI cluster uses 4 public ip addressess
>>>
>>> Thanks for your opinions
>>>
>>> Cheers,
>>>
>>> Jiri
>>>
>>> ___
>>> 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/LIFQQHTFVTS6KICR5MTRPGO5CH7QDLK7/
>>>
>>
___
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/UZU3JPWVPFWD7SCOUHZXLGYRLGYNOA3J/

[ovirt-users] Re: ovirt imageio problem...

[Strahil Nikolov via Users]

And what  about https://bugzilla.redhat.com/show_bug.cgi?id=1787906
Do we  have any validation of the checksum via the python script ?


Best Regards,
Strahil Nikolov

На 31 май 2020 г. 0:18:43 GMT+03:00, Carlos C  написа:
>Hi,
>
>You can try upload using the python as described here
>https://lists.ovirt.org/archives/list/users@ovirt.org/message/GWYRK6LUNHU6FELP7QYSDIPF5SR6YPCK/
>
>
>Carlos
>___
>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/A2JW27WDLI5X2KWWZ47T7TNZCUOJMD32/
___
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/DN3QCX3LOCSUWXPL7X64OHUC6UAQADI4/

[ovirt-users] Re: Problem with Ovirt Machines

[Strahil Nikolov via Users]

На 31 май 2020 г. 15:52:14 GMT+03:00, aigin...@gmail.com написа:
>Hi,
>
>Our company uses Ovirt to host some of its virtual machines. The
>version used is 4.2.6.4-1.el7. There are about 36 virtual hosts in it.
>The specifications used for the host machine is 30G RAM and 6 CPUs.
>Some of the VMs in the ovirt host run with 4 CPUs. Some with 2 CPUs. 
>
>The problem I face now is that recently there was a need for high CPU
>and memory specs to setup a VM for DR. I created a VM with 16G RAM and
>6 CPUs, without checking the CPUs available in the host first. After
>DR, the VM was brought down already. Then later another person in the
>team brought the VM back up for a different DR use, for a much larger
>DB restoration purpose.
>
>This caused the VM to pause due to storage error. And then worse things
>happened, whereby 2 other VMs inadvertently went down. Although I
>assumed that this was caused by storage errors/problems, the senior
>admins in the team concluded that the problem was due to fencing
>because of the max allotted CPU for the host being used for the VM.

 Check the libvirt logs  on the host where the VM was  running. In the engine, 
you can check the logs  for any fencing, but I have never seen such thing as 
"excessive CPU allocation" to cause fencing.
Either the VM passes the checks (overcommit rules,  scheduling,etc)  and gets 
up and running  or the engine will refuse  to power  it up.
Also  check via  journalctl  for any messages  at that time  for the 
'sanlock.service' .  Any issues  (storage  unavailable or high lattency 
detected)  will be reported  via the sanlock service  on the affected node.
If you use multipath  -  check if it also reported  any paths failing.


>Now what I need to know is how to properly allocate CPU resources to a
>host to run multiple virtual machines in it like the situation above. 
The  best way is to start with less  CPUs  as possible.
Here is a  short (or maybe not)  example:
Hoypervisor has  8 CPUs/8 Threads. First VM has 1  CPU. Second has 6 CPUs 
allocated and a third VM has  8 CPUs allocated.
For the hypervisor to allocate CPU time for the third  (beefy) VM,  it needs to 
have all 8 CPUs  available. As the host itself has 8 cores and usually some  OS 
stuff is going on - the third  VM  will receive  far less  CPU time than 
first/second VM.

>I even tried to look for errors in vdsm.log, but this log was not
>available in the host machine nor in the affected VM. My colleague
>asked me to check "Events" section of the ovirt management interface to
>see past the past events. However, I don't find much details about the
>fencing activity or how the fencing occurred or what caused the
>fencing. 
>
>And how did they conclude that the CPU count caused the fencing and not
>the storage?

Interesting question... I think they just assumed. In worst case  scenario (CPU 
 starvation), the vdsmd service  might not respond to the engine, but then a 
'soft' reboot will happen where the engine will restart  this service over ssh.
>___
>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/QX7NAZQ67VBA3KLPYIOXYSTPNU46XOBO/


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/SRD5TUJNKF32H2L6C47HEV4SQDILKLRV/

[ovirt-users] Re: Problems creating bricks for new Gluster storage 4.4

[Strahil Nikolov via Users]

I think that feature  didn't work for  me  on 4.2.7 , so  I doubt  it ever  
worked.
It's  worth opening a  bugzilla.


Best Regards,
Strahil  Nikolov

На 2 юни 2020 г. 2:29:50 GMT+03:00, Jaret Garcia via Users  
написа:
>
>Hi guys I'm trying to deploy a new ovirt environmet based in version
>4.4 so I set up the following: 
>
>1 engine sever (stand alone) Version : 4.4.0.3 
>
>3 host servers (32 GB RAM, 2CPUs 8 core Xeon 5160, 500GB OS drive, 1
>storage 8TB drive and 1 SSD 256GB (I'm trying to create a brick with
>SSD cache with no success) 
>
>Detail of versions running on servers 
>[ 
>OS Version: 
>RHEL - 8 - 1.1911.0.9.el8 
>OS Description: 
>oVirt Node 4.4.0 
>Kernel Version: 
>4.18.0 - 147.8.1.el8_1.x86_64 
>KVM Version: 
>4.1.0 - 23.el8.1 
>LIBVIRT Version: 
>libvirt-5.6.0-10.el8 
>VDSM Version: 
>vdsm-4.40.16-1.el8 
>SPICE Version: 
>0.14.2 - 1.el8 
>GlusterFS Version: 
>glusterfs-7.5-1.el8 
>CEPH Version: 
>librbd1-12.2.7-9.el8 
>Open vSwitch Version: 
>openvswitch-2.11.1-5.el8 
>Nmstate Version: 
>nmstate-0.2.10-1.el8 
>] 
>
>Engine server working fine, all 3 host servers already part of the
>default cluster as hypervisors, then when I try to create a brick in
>any of the servers, using the 8TB HHDD and SSD as cache the process
>fails, in the GUI it just says "failed to creat brick on host" 
>
>However in engine log as well as in brick-setup log I see: "err" : "
>Physical volume \"/dev/sdc\" still in use\n" "failed" : true,, (sdc in
>this case is the 8TB HHDD) 
>
>Attached files of both logs. 
>
>Thanks in advance, 
>
>
>Jaret Garcia 
>
>PACKET 
>Next Generation IT & Telecom 
>Tel. [ callto:+52%20%2855%29%2059898707 | +52 (55) 59898707 ] 
>Of. [ callto:+52%20%2855%29%2047441200 | +52 (55) 47441200 ] Ext. 1210 
>email: [ mailto:jaret.gar...@packet.mx | jaret.gar...@packet.mx ] 
>
>[ http://www.packet.mx/ | www.packet.mx ] 
___
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/IZTKM76VVO6SWUEJCEGU3JKK5VRJ65CT/

[ovirt-users] Re: Ovirt 4.4 HC gluster issues on new CentOS 8 node (cluster still in 4.3 compatibility level)

[Strahil Nikolov via Users]

Maybe  you miss  a rpm.
Do you have vdsm-gluster  package installed  ?

Best  Regards,
Strahil Nikolov

На 2 юни 2020 г. 19:18:43 GMT+03:00, jillian.mor...@primordial.ca написа:
>I've successfully migrated to a new 4.4 engine, now managing the older
>4.3 (CentOS 7) nodes. So far so good there.
>
>I installed a new CentOS 8 node w/ 4.4, joined it to the Gluster peer
>group, and it can see all of the volumes, but the node won't go into
>Online state in the engine because of apparent gluster-related VDSM
>errors:
>   
>Status of host butter was set to NonOperational.
>Gluster command [] failed on server .
>VDSM butter command ManageGlusterServiceVDS failed: The method does not
>exist or is not available: {'method': 'GlusterService.action'}
>
>I haven't been able to find anything in the VDSM or Engine logs that
>give me any hint as to what's going on (besides just repeating that the
>"GlusterSerice.action" method doesn't exist). Anybody know what I'm
>missing, or have hints on where to dig to debug further?
>___
>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/KERTWSZE5I5WMIWYXRXG4UVZZ2X4HZBE/
___
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/BR4V63F56TB7VLNYV3HHINQODCTRAOQN/

[ovirt-users] Re: VM login info

[Strahil Nikolov via Users]

When you click on the console button in the UI,  a  file with necessary info 
(inclusing auth)  is provided. That file can be  used  with many remote 
connection apps.
Keep in mind that  auth info is valid for a very short  term (a minute,  maybe 
2) so you need  to open it without waiting too much.

Best  Regards,
Strahil Nikolov

На 3 юни 2020 г. 11:28:50 GMT+03:00, fa...@kdsplumbing.com написа:
>Hi guys,
>
>After a lot of attempts, i was finally able to open a VM (centos8-cld)
>using virt-viewer on  my mac (catalina).  but i am faced with a login
>screen.  So,  where do i get this information from?
>or should i be using a different method to log into a vm?
>
>This goes for all of the VMs available by default.
>
>can someone please help me with this?
>
>thanks
>___
>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/UVCGYBB3XAVYKMLAOGK4V45QWFSPQZJ2/
___
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/NB7Z47TIERO5X6N3EDSRF52NS4BKARJB/

[ovirt-users] Re: Ovirt 4.4 HC gluster issues on new CentOS 8 node (cluster still in 4.3 compatibility level)

[Strahil Nikolov via Users]

Please  open a  bug  for that  issue with the relevant logs.
4.4  HCI should  depend  on that one.

Thanks  in advance.

Best Regards,
Strahil Nikolov

На 3 юни 2020 г. 18:31:18 GMT+03:00, Jillian Morgan 
 написа:
>Thank you, Strahil.
>
>That was exactly the problem. I had already figured out other missing
>gluster-related packages (ansible roles, gluster-server, etc), but
>didn't think about the VDSM sub-package. Sigh.
>So that problem's solved. Now I have another, but I'll debug that a
>while before bugging the list again.
___
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/HHRJUEHJOKQ7BGUZCSLH6HZEQGRA3XW3/

[ovirt-users] Re: Weird problem starting VMs in oVirt-4.4

[Strahil Nikolov via Users]

Is  it UEFI based  or the lagacy bios ?

Best Regards,
Strahil Nikolov

На 3 юни 2020 г. 19:00:48 GMT+03:00, Marco Fais  написа:
>Hi Joop
>
>I am having the same problem -- thought initially was due to the VM
>import
>but it is now happening even on newly created VMs.
>Rebooting (e.g. ctrl-alt-del) the machine a couple of times solves the
>issue, but a power off / power on might cause it again...
>
>Not sure how best to capture this behaviour in the logs yet...
>
>Regards,
>Marco
>
>On Wed, 3 Jun 2020 at 14:00, Joop  wrote:
>
>> Hi All,
>>
>> Just had a rather new experience in that starting a VM worked but the
>> kernel entered grub2 rescue console due to the fact that something
>was
>> wrong with its virtio-scsi disk.
>> The message is Booting from Hard Disk 
>> error: ../../grub-core/kern/dl.c:266:invalid arch-independent ELF
>maginc.
>> entering rescue mode...
>>
>> Doing a CTRL-ALT-Del through the spice console let the VM boot
>> correctly. Shutting it down and repeating the procedure I get a disk
>> problem everytime. Weird thing is if I activate the BootMenu and then
>> straight away start the VM all is OK.
>> I don't see any ERROR messages in either vdsm.log, engine.log
>>
>> If I would have to guess it looks like the disk image isn't connected
>> yet when the VM boots but thats weird isn't it?
>>
>> Regards,
>>
>> Joop
>>
>> ___
>> 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/TA6BJ2A4XUGKU7P47OGM42TT26GXZJXP/
>>
___
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/UIY4SM23H7DWEGBB33KJMQL3D3S2NESS/

[ovirt-users] Re: clean of .shard files if changing volume settings

[Strahil Nikolov via Users]

You should  disable  sharding  prior  using the volume  as  a  storage domain.
Disabling  sharding  while  you have data on the volume will  fause havoc.

Can you try disabling before  creating  the storage domain  ?

Best Regards,
Strahil Nikolov

На 3 юни 2020 г. 20:35:13 GMT+03:00, Gianluca Cecchi 
 написа:
>Hello,
>I have a single host in 4.4 with HCI and Gluster.
>I have only one brick for the volume and I disabled sharding:
>
>[root@ovirt01 /root]# gluster volume set data features.shard off
>volume set: success
>[root@ovirt01 /root]#
>
>In events of web admin I see it registered and updating db:
>
>Detected change in value of option features.shard from on to off on
>volume
>data of cluster Default, and updated it to engine DB.
>6/3/206:46:52 PM
>
>Then I delete a VM with a 65Gb disk, that I created while sharding was
>enabled (I enabled the check box to remove disks) but it seems that
>files
>under .shard are not removed.
>[root@ovirt01 ~]# du -sh
>/rhev/data-center/mnt/glusterSD/ovirt01st.lutwyn.storage\:_data/.shard/
>62G
>/rhev/data-center/mnt/glusterSD/ovirt01st.lutwyn.storage:_data/.shard/
>[root@ovirt01 ~]#
>
>Is there any special command I have to run? Or can I simply remove the
>.shard directory now?
>I only had that VM in that storage domain before disabling sharding.
>
>The files are all of type:
>-rw-rw. 1 root root 67100672 Jun  3 18:18
>23f0c94c-cf2a-42c1-8e2e-a21c4e542774.1
>-rw-rw. 1 root root 67108864 Jun  3 18:18
>23f0c94c-cf2a-42c1-8e2e-a21c4e542774.2
>...
>-rw-rw. 1 root root 67108864 Jun  3 18:44
>23f0c94c-cf2a-42c1-8e2e-a21c4e542774.1008
>-rw-rw. 1 root root 39845888 Jun  3 18:44
>23f0c94c-cf2a-42c1-8e2e-a21c4e542774.1009
>-rw-rw. 1 root root 56643584 Jun  3 18:44
>23f0c94c-cf2a-42c1-8e2e-a21c4e542774.1031
>
>Thanks in advance,
>Gianluca
___
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/NQALKNKYKH4BAKSLKVU4R4SJQO66WYFT/

[ovirt-users] Re: CentOS Stream support

[Strahil Nikolov via Users]

Hi Michael,

Thanks for raising that topic.
I personally believe that the CentOS Stream will be something between Fedora 
and RHEL and thus it won't be as stable as I wish.
Yet on the other side , if this speeds up bug fixing - I am OK for that.

P.S.: I'm still on 4.3, but I was planing to switch to regular CentOS instead 
of Stream.


Best Regards,
Strahil Nikolov






В петък, 5 юни 2020 г., 11:37:16 Гринуич+3, Michal Skrivanek 
 написа: 





Hi all,
we would like to ask about interest in community about oVirt moving to CentOS 
Stream.
There were some requests before but it’s hard to see how many people would 
really like to see that.

With CentOS releases lagging behind RHEL for months it’s interesting to 
consider moving to CentOS Stream as it is much more up to date and allows us to 
fix bugs faster, with less workarounds and overhead for maintaining old code. 
E.g. our current integration tests do not really pass on CentOS 8.1 and we 
can’t really do much about that other than wait for more up to date packages. 
It would also bring us closer to make oVirt run smoothly on RHEL as that is 
also much closer to Stream than it is to outdated CentOS.

So..would you like us to support CentOS Stream?
We don’t really have capacity to run 3 different platforms, would you still 
want oVirt to support CentOS Stream if it means “less support” for regular 
CentOS? 
There are some concerns about Stream being a bit less stable, do you share 
those concerns?

Thank you for your comments,
michal
___
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/3B5MJKO7BS2DMQL3XOXPNO4BU3YDL52T/
___
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/XDUHBY43TCKRRLKFQYDB4BNSJOEGOY2L/

[ovirt-users] Re: Gluster error in server log.

[Strahil Nikolov via Users]

Have you tried restarting the engine ?


Best Regards,
Strahil Nikolov

В петък, 5 юни 2020 г., 11:56:37 Гринуич+3, Krist van Besien 
 написа: 





  


Hello all,

On my ovirt HC cluster I constantly get the following kinds of errors:

From /var/log/ovirt-engine/engine.log

2020-06-05 10:38:36,652+02 WARN 
[org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturn] 
(EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-15) [] 
Could not associate brick 'on1.ws.kri.st:/gluster_bricks/vmstore/vmstore' of 
volume 'dab47af2-16fc-461d-956e-daab00c8489e' with correct network as no 
gluster network found in cluster 'a8a38ffe-a499-11ea-9471-00163e5ffe63'

Normally you get these errors if you forgot to define and assign a storage 
network. However I do have a storage network, have assigned it to the interface 
used by gluster on each host, and have set it as the “gluster” network in the 
default cluster.
So why am I still getting this error?

Krist




  
Vriendelijke Groet | Best Regards | Freundliche Grüße | Cordialement





Krist van Besien


krist.vanbes...@gmail.com





___
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/WGKRR6TZCJCZB4GB23JWS4QPIX6Q34T4/
___
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/45QG4KD5SWWJH6Y5UBF3G33BYQKOUXXF/

[ovirt-users] Re: Ovirt 4.4 Migration assistance needed.

[Strahil Nikolov via Users]

Hello Tal, Michal,

What do you think about the plan ?
Anything I have to be careful for ?


Best Regards,
Strahil Nikolov






В петък, 22 май 2020 г., 19:01:42 Гринуич+3, Sandro Bonazzola 
 написа: 







Il giorno gio 21 mag 2020 alle ore 17:08 Strahil Nikolov via Users 
 ha scritto:
> Hello All,
> 
> I  would like to ask  for some  assistance  with  the planing  of the upgrade 
> to 4.4 .
> 
> I have  issues with the  OVN (doesn't work at all),  thus  I would like to 
> start fresh with the HE.
> 
> The plan so far (downtime is not an issue) :
> 
> 1. Reinstall  the nodes one by 1 and  rejoin them in the Gluster  TSP
> 2. Wipe  the HostedEngine's gluster  volume
> 3. Deploy a fresh hosted  engine
> 4. Import the storage  domains (gluster) back to the  engine and import the 
> VMs

+Tal Nisan , +Michal Skrivanek any thoughts on this flow?


 
>  
> Do you see any issues  with the plan ?
> Any problems expected  if the VMs do have snapshots?  What about the storage  
> domain version ?
> 
> Thanks  in Advance.
> 
> 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/QNPOH55AAAYOX5GX3EN5H5ZMOZHKYELI/
> 


-- 
Sandro Bonazzola
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA

sbona...@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@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/JKLAFKFNI4XZVLWJBXVZTOWFRGKUHNHL/
___
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/2J64WKCACCYVJX2QT6E6LUSGMYD24GDN/

[ovirt-users] Re: Slow disk upload via WebGUI

[Strahil Nikolov via Users]

Hi Magnus,


there  are several ways  to upload a disk.

For details, check 
https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html/administration_guide/sect-Virtual_Disk_Tasks#Uploading_a_Disk_Image_to_a_Storage_Domain

Best Regards,
Strahil Nikolov

На 6 юни 2020 г. 12:15:36 GMT+03:00, Magnus Isaksson  написа:
>A note to this is that we are migrating a couple of customers from a
>vmware enviroment that we have no control over, we get the vmdk files
>on a NFS share. its a bit over 130 VM:s and if every disk will go at
>100mbit/s its quite a painful process.
>
>Is there a faster way to import these disk images other then via
>WebGUI? (of course after convert)
>
>//Magnus
>
>From: Magnus Isaksson 
>Sent: 06 June 2020 10:58
>To: users 
>Subject: [ovirt-users] Slow disk upload via WebGUI
>
>Hello
>
>I'm running Engine 4.3.9 and have fibre channel SSD storage and 4
>nodes.
>
>When uploading disk images i get around 100mbit/s per disk, if im
>running 3 uploads at the same time i get about 300mbit/s combined.
>Everything is connected via 10G and 16G to FC storage.
>
>Why is it so slow? and what can i do to speed things up?
>
>Regards
> Magnus
___
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/TZ2W4WOIEYDQ6BHQRM43JJTX4DAEIJFU/

[ovirt-users] Re: Slow disk upload via WebGUI

[Strahil Nikolov via Users]

There  is also the API  and I think there was a  python script for ISO upload.

You can also import from OVA.

As you have multiple VMDKs, why don't you just upload  in parallel (20-30 disk 
in batch).

Best Regards,
Strahil Nikolov

На 6 юни 2020 г. 13:39:44 GMT+03:00, Magnus Isaksson  написа:
>Hi
>
>From what i can tell from that link is that there is only one way for
>my scenario, or have i missed something?
>
>"Procedure 11.8. Uploading a Disk Image to a Storage Domain"
>
>//Magnus
>
>From: Strahil Nikolov 
>Sent: 06 June 2020 12:26
>To: users@ovirt.org ; Magnus Isaksson 
>Subject: Re: [ovirt-users] Re: Slow disk upload via WebGUI
>
>Hi Magnus,
>
>
>there  are several ways  to upload a disk.
>
>For details, check
>https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html/administration_guide/sect-Virtual_Disk_Tasks#Uploading_a_Disk_Image_to_a_Storage_Domain
>
>Best Regards,
>Strahil Nikolov
>
>На 6 юни 2020 г. 12:15:36 GMT+03:00, Magnus Isaksson 
>написа:
>>A note to this is that we are migrating a couple of customers from a
>>vmware enviroment that we have no control over, we get the vmdk files
>>on a NFS share. its a bit over 130 VM:s and if every disk will go at
>>100mbit/s its quite a painful process.
>>
>>Is there a faster way to import these disk images other then via
>>WebGUI? (of course after convert)
>>
>>//Magnus
>>
>>From: Magnus Isaksson 
>>Sent: 06 June 2020 10:58
>>To: users 
>>Subject: [ovirt-users] Slow disk upload via WebGUI
>>
>>Hello
>>
>>I'm running Engine 4.3.9 and have fibre channel SSD storage and 4
>>nodes.
>>
>>When uploading disk images i get around 100mbit/s per disk, if im
>>running 3 uploads at the same time i get about 300mbit/s combined.
>>Everything is connected via 10G and 16G to FC storage.
>>
>>Why is it so slow? and what can i do to speed things up?
>>
>>Regards
>> Magnus
___
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/VCI43CDVHFJ7T77MHHXASWP7BYYNWCRS/

[ovirt-users] Re: migration

[Strahil Nikolov via Users]

Hi ,

I know that you won't receive this e-mail directly, but you might see it in the 
web (kitty).

I updated my  4.3 this friday and  I never experienced  any hiccups.
Can you provide your 'rpm -qa'?

Best  Regards,
Strahil Nikolov

На 6 юни 2020 г. 18:12:44 GMT+03:00, eev...@digitaldatatechs.com написа:
>I am running Ovirt 4.310. When I update the engine server it updates
>the user extensions to
>ovirt-engine-ui-extensions.noarch 0:1.0.13-1.20200303git3b594b8.el7 and
>migration fails. I have to downgrade to
>ovirt-engine-ui-extensions-1.0.10-1.el7.noarch.rpm inorder to get
>migration to work again. 
>This needs to be passed on to the developers to correct the updated
>version.
>Also, I had to download
>ovirt-engine-ui-extensions-1.0.10-1.el7.noarch.rpm and run yum
>downgrade ovirt-engine-ui-extensions-1.0.10-1.el7.noarch.rpm for the
>downgrade to complete successfully.
>After the downgrade, migration works.
>___
>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/6Q3SOHGYO63NSIWMQM3QDVM47KR73JIE/
___
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/FDBSTHLP7JSR6VWDWTSBC53MZRZXYUGE/

[ovirt-users] Re: What happens when shared storage is down?

[Strahil Nikolov via Users]

На 7 юни 2020 г. 1:58:27 GMT+03:00, "Vinícius Ferrão via Users" 
 написа:
>Hello,
>
>This is a pretty vague and difficult question to answer. But what
>happens if the shared storage holding the VMs is down or unavailable
>for a period of time?
Once  a  pending I/O is blocked, libvirt will pause the VM .

>I’m aware that a longer timeout may put the VMs on pause state, but how
>this is handled? Is it a time limit? Requests limit? Who manages this?
You got sanlock.service that notifies the engine when a storage domain is 
unaccessible for  mode than 60s.

Libvirt also will pause  a  VM when a pending I/O cannot be done.

>In an event of self recovery of the storage backend what happens next?
Usually the engine should resume the VM,  and from application perspective 
nothing has happened.

>Manual intervention is required? The VMs may be down or they just
>continue to run? It depends on the guest OS running like in XenServer
>where different scenarios may happen?
>
>I’ve looked here:
>https://www.ovirt.org/documentation/admin-guide/chap-Storage.html but
>there’s nothing that goes about this question.
>
>Thanks,
>
>Sent from my iPhone
___
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/RQMM35T4LVYSLD3WWIFN25ME3ENKAB73/

[ovirt-users] Re: First ovirt 4.4 installation failing

[Strahil Nikolov via Users]

On top of that Ansible is  also using ssh, so  you need to 'override' the 
settings for the engine.

Best  Regards,
Strahil Nikolov

На 7 юни 2020 г. 13:01:08 GMT+03:00, Yedidyah Bar David  
написа:
>On Sat, Jun 6, 2020 at 8:42 PM Michael Thomas  wrote:
>>
>> After a week of iterations, I finally found the problem.  I was
>setting 'PermitRootLogin no' in the global section of the bare metal OS
>sshd_config, as we do on all of our servers.  Instead, PermitRootLogin
>is set to 'without-password' in a match block to allow root logins only
>from a well-known set of hosts.
>
>Thanks for the report!
>
>>
>> Can someone explain why setting 'PermitRootLogin no' in the
>sshd_config on the hypervisor OS would affect the hosted engine
>deployment?
>
>Because the engine (running inside a VM) uses ssh as root to connect
>to the host (in which the engine vm is running).
>
>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/ZOSVMS4LQFTKD7USTNJ5T73J6HWECRCV/
___
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/SBGU46FKWTF2ZN3Y45HP7NGPJAIUKWYP/

[ovirt-users] Re: Weird problem starting VMs in oVirt-4.4

[Strahil Nikolov via Users]

Are you using ECC ram ?

Best Regards,
Strahil Nikolov

На 8 юни 2020 г. 15:06:22 GMT+03:00, Joop  написа:
>On 3-6-2020 14:58, Joop wrote:
>> Hi All,
>>
>> Just had a rather new experience in that starting a VM worked but the
>> kernel entered grub2 rescue console due to the fact that something
>was
>> wrong with its virtio-scsi disk.
>> The message is Booting from Hard Disk 
>> error: ../../grub-core/kern/dl.c:266:invalid arch-independent ELF
>maginc.
>> entering rescue mode...
>>
>> Doing a CTRL-ALT-Del through the spice console let the VM boot
>> correctly. Shutting it down and repeating the procedure I get a disk
>> problem everytime. Weird thing is if I activate the BootMenu and then
>> straight away start the VM all is OK.
>> I don't see any ERROR messages in either vdsm.log, engine.log
>>
>> If I would have to guess it looks like the disk image isn't connected
>> yet when the VM boots but thats weird isn't it?
>>
>>
>As an update to this:
>Just had the same problem with a Windows VM but more importantly also
>with HostedEngine itself.
>On the host did:
>hosted-engine --set-maintenance --mode=global
>hosted-engine --vm-shutdown
>
>Stopped all oVirt related services, cleared all oVirt related logs from
>/var/log/..., restarted the host, ran hosted-engine --set-maintenance
>--mode=none
>Watched /var/spool/mail/root to see the engine coming up. It went to
>starting but never came into the Up status.
>Set a password and used vncviewer to see the console, see attached
>screenschot.
>hosted-engine --vm-poweroff, and tried again, same result
>hosted-engine --vm-start, works
>Let it startup and then shut it down after enabling maintenance mode.
>Copied, hopefully, all relevant logs and attached them.
>
>A sosreport is also available, size 12Mb. I can provide a download link
>if needed.
>
>Hopefully someone is able to spot what is going wrong.
>
>Regards,
>
>Joop
___
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/XASNIEZTZIMWAUIANSOPCX4ZBK6T7TZT/

[ovirt-users] Re: Deploy host engine error: The task includes an option with an undefined variable

[Strahil Nikolov via Users]

Can you put something like this before the 'Parse server cpu list'  :

-  name: Debug why parsing  fails
  debug:
msg:
- "Loop is done over  {{ 
server_cpu_list.json['values']['system_option_value'][0]['value'].split('; 
')|list|difference(['']) }}"
- "Actual value of server_cpu_dict before the set_fact is {{ 
server_cpu_dict }}"


Note: e-mail clients can distort code. Don't copy/paste , but type the example  
from above.

Best  Regards,
Strahil Nikolov

На 9 юни 2020 г. 19:34:07 GMT+03:00, "Angel R. Gonzalez" 
 написа:
>Hi all!
>
>I'm deploying a host engine in a host node with a 8x Intel(R) Xeon(R) 
>CPU E5410 @ 2.33GHz.
>
>The deploy proccess show the next message
>
>> [INFO]TASK [ovirt.hosted_engine_setup : Convert CPU model name]
>> [ERROR]fatal: [localhost]: FAILED! => {"msg": "The task includes an 
>> option with an undefined variable. The error was: 'dict object' has
>no 
>> attribute ''\n\nThe error appears to be in 
>>
>'/usr/share/ansible/roles/ovirt.hosted_engine_setup/tasks/create_target_vm/01_create_target_hosted_engine_vm.yml':
>
>> line 105, column 15, but may\nbe elsewhere in the file depending on 
>> the exact syntax problem.\n\nThe offending line appears to be:\n\n - 
>> debug: var=server_cpu_dict\n ^ here\n\nThere appears to be both 'k=v'
>
>> shorthand syntax and YAML in this task. Only one syntax may be
>used.\n"}
>
>The ansible deploy script in his 105 line show:
>
>> - name: Parse server CPU list
>>     set_fact:
>>  server_cpu_dict: "{{ server_cpu_dict | 
>> combine({item.split(':')[1]: item.split(':')[3]}) }}"
>>     with_items: >-
>>   {{ 
>>
>server_cpu_list.json['values']['system_option_value'][0]['value'].split(';
>
>> ')|list|difference(['']) }}
>>   - debug: var=server_cpu_dict
>
>I don´t know ansible and i don't how to resolve this issue. Any idea?
>
>Thanks in advance,
>
>Ángel González.
___
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/G5X3PHZRPR2VW2S576TALV4W4DU5EGAP/

[ovirt-users] Re: What happens when shared storage is down?

[Strahil Nikolov via Users]

Hi  Vinicius,

If you don't  have too much VMs and you have local storage (like a  raid 
controller) or NFS/iSCSI - you can also move the VMs there temporarily (live 
storage  migration) without any interruption.

Best Regards,
Strahil Nikolov

На 10 юни 2020 г. 12:14:38 GMT+03:00, Jayme  написа:
>This is of course not recommended but there has been times where I have
>lost network access to storage or storage sever while vms were running.
>They paused and came back up when storage was available again without
>causing any problems. This doesn’t mean it’s 100% safe but from my
>experience it has not caused any issue.
>
>Personally I would shutdown vms or live migrate the disk to secondary
>storage then migrate it back after the updates are performed.
>
>On Wed, Jun 10, 2020 at 2:22 AM Vinícius Ferrão via Users
>
>wrote:
>
>>
>>
>> > On 7 Jun 2020, at 08:34, Strahil Nikolov 
>wrote:
>> >
>> >
>> >
>> > На 7 юни 2020 г. 1:58:27 GMT+03:00, "Vinícius Ferrão via Users" <
>> users@ovirt.org> написа:
>> >> Hello,
>> >>
>> >> This is a pretty vague and difficult question to answer. But what
>> >> happens if the shared storage holding the VMs is down or
>unavailable
>> >> for a period of time?
>> > Once  a  pending I/O is blocked, libvirt will pause the VM .
>> >
>> >> I’m aware that a longer timeout may put the VMs on pause state,
>but how
>> >> this is handled? Is it a time limit? Requests limit? Who manages
>this?
>> > You got sanlock.service that notifies the engine when a storage
>domain
>> is unaccessible for  mode than 60s.
>> >
>> > Libvirt also will pause  a  VM when a pending I/O cannot be done.
>> >
>> >> In an event of self recovery of the storage backend what happens
>next?
>> > Usually the engine should resume the VM,  and from application
>> perspective nothing has happened.
>>
>> Hmm thanks Strahil. I was thinking to upgrade the storage backend of
>one
>> of my oVirt clusters without powering off the VM’s, just to be lazy.
>>
>> The storage does not have dual controllers, so downtime is needed.
>I’m
>> trying to understand what happens so I can evaluate this update
>without
>> turning off the VMs.
>>
>> >> Manual intervention is required? The VMs may be down or they just
>> >> continue to run? It depends on the guest OS running like in
>XenServer
>> >> where different scenarios may happen?
>> >>
>> >> I’ve looked here:
>> >> https://www.ovirt.org/documentation/admin-guide/chap-Storage.html
>but
>> >> there’s nothing that goes about this question.
>> >>
>> >> Thanks,
>> >>
>> >> Sent from my iPhone
>>
>> ___
>> 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/BVZAG2V3KBB364U5VBRCBIU42LJNGCI6/
>>
___
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/FH7XKNDBVD7CETKM4KN5BSO7IRTOCNYF/

[ovirt-users] Re: Advise Needed - Hosted Engine Minor Update

[Strahil Nikolov via Users]

I use  Gluster  snapshots before patching the engine.
Usually the flow is:
1. Global Maintenance
2. Power off the HostedEngine VM
3. Gluster snapshot
4. Power on HE
5. Upgrade  of the setup packages
6. Run the hosted-engine upgrade  script
7. Patch the OS of HE
8. Reboot
9. Remove Global Maintenance


If you need to revert a snapshot, you need to stop the gluster volume , so you 
need to follow the rule and keep the engine on a separate gluster volume.


Best Regards,
Strahil Nikolov

На 10 юни 2020 г. 13:21:08 GMT+03:00, Yedidyah Bar David  
написа:
>On Wed, Jun 10, 2020 at 1:05 PM  wrote:
>>
>> Hi Guys!
>>
>> How do you usually backup your hosted engine prior minor updates?
>>
>> I’ve tried to perform a minor update from 4.3.8 to 4.3.9 recently.
>I’ve used engine-backup before updating and for restore. However, the
>problem I’m encountering now is that, it looks like the hosted-engine
>settings are only being restored. The version is still 4.3.9 when I’m
>trying to revert it to 4.3.8.
>>
>> Am I missing some steps aside from engine-backup —restore? I saw on
>old posts that snapshots of hosted engine is not a recommended step
>before upgrade/update.
>
>engine-backup --mode=restore only restores the data. If you want 4.3.8
>packages, you have to install them. For rolling back packages on an
>existing machine, you can usually find the relevant yum transactions
>and 'yum history undo $ID' on them.
>
>If you installed and set up e.g. 4.3.8, and take a backup, then try to
>restore this backup on 4.3.9, the next engine-setup you run (which is
>a required step after restore) will upgrade your database
>schema/content to 4.3.9.
>
>Hope this helps,
___
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/SZ4NSSMKDBQIK6VJX7YMZBFDB7SKOPDC/

[ovirt-users] Host has time-drift of xxx seconds

[Strahil Nikolov via Users]

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/

[ovirt-users] Re: Host has time-drift of xxx seconds

[Strahil Nikolov via Users]

I just found entries in the db pointing to 11 July (1  month ahead) and I 
rebooted the engine.It seems that time-drift is somehow related to all the 
issues I have observed after patching from 4.3.9  to 4.3.10:
1. ovirt1  started  to slow down - solved by stopping chrony, wiping 
/var/lib/chrony/drift and a reboot
2. HE stopped  logging in the dwh tables and spamming me with ETL service 
stopped ...
I hope I fixed it by using:
https://bugzilla.redhat.com/show_bug.cgi?id=1277591#c5

(note I have typed the link,  so it might have a typo)
3. Constantly being spammed about host has been activated - most probably that 
one is also 1  month ahead  in the DB :)

Not fixed yet.

Best Regards,
Strahil Nikolov

At least the events now show real time.

Best Regards

На 11 юни 2020 г. 6:00:52 GMT+03:00, Strahil Nikolov  
написа:
>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/QN7VIVOZFOTUQY3GFUWWW6CJZUQDN4ES/

[ovirt-users] Re: oVirt 4.4.0 HE deployment on GlusterFS fails during health check

[Strahil Nikolov via Users]

Your gluster mount option is not correct.
You need 'backup-volfile-servers=storagehost2:storagehost3' (without the volume 
name as they all have thaylt volume) .

Best Regards,
Strahil  Nikolov

На 13 юни 2020 г. 10:47:28 GMT+03:00, Oliver Leinfelder 
 написа:
>Hi,
>
>I have the following two components:
>
>1.) A freshly installed VM host (oVirt Node 4.4.0 release ISO)
>2.) 3 storage hosts, also freshly installed from oVirt Node 4.4.0 
>release ISO
>
>The storage hosts have been successfully installed with Gluster
>(through 
>Cockpit). They have two volumes, both of which I can mount and 
>read/write from a client.
>
>On the VM host, I ran "hosted-engine --deploy" (no backups imported).
>
>When prompted for storage, I answered "glusterfs" and specified 
>"storagehost1:/engine" as storage for the HE deployment. For mount 
>options, I specified 
>"backup-volfile-servers=storagehost2:/engine:storagehost3:/engine"
>
>(Not the real hostnames, but all of them are resolvable via internal
>DNS)
>
>Everything seems to works fine, I also see the "engine" volume become 
>populated with data. At some point I could ping and SSH login to the
>HE.
>
>When the setup proceed to health check, it failed and the whole process
>
>was aborted :-(
>
>"hosted-engine --vm-status" reported "failed liveliness check" when it 
>was reachable via SSH. At some point the engine went down and, to my 
>surprise, shows a grub prompt after the restart when doing a 
>"hosted-engine --console".
>
>[ INFO  ] TASK [ovirt.hosted_engine_setup : Check engine VM health]
>[ ERROR ] fatal: [localhost]: FAILED! => {"attempts": 180, "changed": 
>true, "cmd": ["hosted-engine", "--vm-status", "--json"], "delta": 
>"0:00:00.160595", "end": "2020-06-12 17:50:05.675774", "rc": 0,
>"start": 
>"2020-06-12 17:50:05.515179", "stderr": "", "stderr_lines": [],
>"stdout": "{\"1\": {\"host-id\": 1, \"host-ts\": 11528, \"score\":
>3400, 
>\"engine-status\": {\"vm\": \"up\", \"health\": \"bad\", \"detail\": 
>\"Powering down\", \"reason\": \"failed liveliness check\"}, 
>\"hostname\": \"vmhost\", \"maintenance\": false, \"stopped\": false, 
>\"crc32\": \"2c447835\", \"conf_on_shared_storage\": true, 
>\"local_conf_timestamp\": 11528, \"extra\": 
>\"metadata_parse_version=1\\nmetadata_feature_version=1\\ntimestamp=11528
>
>(Fri Jun 12 17:49:57 
>2020)\\nhost-id=1\\nscore=3400\\nvm_conf_refresh_time=11528 (Fri Jun 12
>
>17:49:57 
>2020)\\nconf_on_shared_storage=True\\nmaintenance=False\\nstate=EngineStop\\nstopped=False\\ntimeout=Thu
>
>Jan  1 04:12:48 1970\\n\", \"live-data\": true},
>\"global_maintenance\": 
>false}", "stdout_lines": ["{\"1\": {\"host-id\": 1, \"host-ts\": 11528,
>
>\"score\": 3400, \"engine-status\": {\"vm\": \"up\", \"health\": 
>\"bad\", \"detail\": \"Powering down\", \"reason\": \"failed liveliness
>
>check\"}, \"hostname\": \"vmhost\", \"maintenance\": false,
>\"stopped\": 
>false, \"crc32\": \"2c447835\", \"conf_on_shared_storage\": true, 
>\"local_conf_timestamp\": 11528, \"extra\": 
>\"metadata_parse_version=1\\nmetadata_feature_version=1\\ntimestamp=11528
>
>(Fri Jun 12 17:49:57 
>2020)\\nhost-id=1\\nscore=3400\\nvm_conf_refresh_time=11528 (Fri Jun 12
>
>17:49:57 
>2020)\\nconf_on_shared_storage=True\\nmaintenance=False\\nstate=EngineStop\\nstopped=False\\ntimeout=Thu
>
>Jan  1 04:12:48 1970\\n\", \"live-data\": true},
>\"global_maintenance\": 
>false}"]}
>
>A second attempt failed at exactly the same stage.
>
>I can see the following in the setup log:
>
>ovirt-hosted-engine-setup-20200612151212-j9zwd2.log:
>2020-06-12 17:33:18,314+0200 DEBUG 
>otopi.ovirt_hosted_engine_setup.ansible_utils 
>ansible_utils._process_output:103 {'msg': 'non-zero return code',
>'cmd': 
>['hosted-engine', '--reinitialize-lockspace', '--force'], 'stdout': '',
>
>'stderr': 'Traceback (most recent call last):\n
>   File "/usr/lib64/python3.6/runpy.py", line 193, in 
>_run_module_as_main\n    "__main__", mod_spec)\n  File 
>"/usr/lib64/python3.6/runpy.py", line 85, in _run_code\n exec(code, 
>run_globals)\n  File 
>"/usr/lib/python3.6/site-packages/ovirt_hosted_engine_setup/reinitialize_
>lockspace.py", line 30, in \n ha_cli.reset_lockspace(force)\n  
>File 
>"/usr/lib/python3.6/site-packages/ovirt_hosted_engine_ha/client/client.py",
>
>line 286, in reset_lockspace\n    stats = 
>broker.get_stats_from_storage()\n  File
>"/usr/lib/python3.6/site-packages/ov
>irt_hosted_engine_ha/lib/brokerlink.py", line 148, in 
>get_stats_from_storage\n    result = self._proxy.get_stats()\n  File 
>"/usr/lib64/python3.6/xmlrpc/client.py", line 1112, in __call__\n
>return 
>self.__send(self.__name, args)\n  File
>"/usr/lib64/python3.6/xmlrpc/client
>.py", line 1452, in __request\n    verbose=self.__verbose\n  File 
>"/usr/lib64/python3.6/xmlrpc/client.py", line 1154, in request\n return
>
>self.single_request(host, handler, request_body, verbose)\n File 
>"/usr/lib64/python3.6/xmlrpc/client.py", line 1166, in single_requ
>est\n    http_conn = self.send_request(host, handler, request_bo

[ovirt-users] Re: Skype for Bussines

[Strahil Nikolov via Users]

You can check in 
https://lists.ovirt.org/archives/search?q=spice+youtube&page=1&sort=date-desc  
for 'spice  options  hooks'  . Maybe the discussed there could help.

Best Regards,
Strahil  Nikolov

На 11 юни 2020 г. 12:35:30 GMT+03:00, ozme...@hotmail.com написа:
>Hi,
>While using "skype for bussiness" on guest machine we've been getting
>sound and video problem.
>i've found a solution on
>https://docs.microsoft.com/en-us/skypeforbusiness/deploy/deploy-clients/deploy-the-lync-vdi-plug-in
>web page.
>But this is only for windows client and nor for spice connection
>
>Does anyone has a solution for this problem?
>
>Thanks
>___
>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/LPQXAD2YICVW2GRKUQCVJZGPDVI5FJ2M/
___
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/U3RRJXNLFU3L67Y64MLW7Q3XATLFCFIC/

[ovirt-users] Re: ovirt 4.3.10 Web UI constantly "finished activating host"

[Strahil Nikolov via Users]

Hey Didi,

it seems that there is still timeshift in the DB - lots of stuff was reporting 
ahead of time.

I had to update the table jobs with the correct month and now at least I have 
no more spam in the web ui.

Best Regards,
Strahil Nikolov






В четвъртък, 11 юни 2020 г., 9:39:45 ч. Гринуич+3, Yedidyah Bar David 
 написа: 





On Thu, Jun 11, 2020 at 6:55 AM Strahil Nikolov via Users

 wrote:
>
> I'm not sure if this one is related to "time shift" in the DB (as I found 
> that dwh_history_timekeeping had some entries 1 month ahead/ETL service 
> issues also/, but I keep getting spammed that the host has been activated.
>
>
> Any hint ?


I'd start with:

1. Check (in /var/log) if you had a case of time moving forward and
than backward for some weird reason

2. Dump the entire db (engine, perhaps also dwh if you want) and
search for future dates. If you only find a few, it might be easier to
handle them one-by-one (hopefully by updating the relevant entity from
the UI, not directly in the db). If it's many, it might require
something more significant.

In 4.4, that's just:

su - postgres -c 'pg_dump engine' | less

In 4.3:

su - postgres -c 'scl enable rh-postgresql10 "pg_dump engine"' | less

Then search e.g. '2020-07', or '2020-06-2', etc.

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/XREOMRKOGY54G64EUEDF6R35T324ZLN4/
___
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/OUM5YY2EBAU3EQDAYLSSEXJX5WBHKHGM/

[ovirt-users] Engine is one month ahead

[Strahil Nikolov via Users]

Hello All,

I have a problem which started after the latest patching 4.3.9 to 4.3.10 .

Symptoms so far:
1. Engine reports that Hypervisours are drifting too much
2. ETL service stopped working
3. Web UI constantly notifies me that the nodes are again active (fills the 
screen till the bottom)

So far I have found an issue with one of the Hypervisours and after removing 
chrony's drift file and reboot - no more issues are observed.
I found in the DB that DWH last update was one month (yes, that's July) ahead , 
so updating it to June has fixed the ETL issue.
The problem with the constant "Host has been activated" was fixed by updating 
the Engine database , table Job (July was changed with June).


The only problem I have now is that every event in the Web (and in the DB of 
course) is pointing to July.

Any ideas how the engine is taking the time ,cause a restart doesn't fix the 
issue?

As you can see both Hypervisours and HE VM are OK:

[root@engine ~]# ntpdate -q time.cloudflare.com
server 162.159.200.1, stratum 3, offset 0.000816, delay 0.02812
server 162.159.200.123, stratum 3, offset 0.000939, delay 0.02834
14 Jun 11:40:05 ntpdate[30135]: adjust time server 162.159.200.1 offset 
0.000816 sec
[root@engine ~]# logout
Connection to engine closed.
[root@ovirt1 ~]# for i in ovirt{1..3} ; do ntpdate -q time.cloudflare.com ; done
server 162.159.200.123, stratum 3, offset 0.002658, delay 0.02948
server 162.159.200.1, stratum 3, offset 0.001741, delay 0.02768
14 Jun 11:40:24 ntpdate[29562]: adjust time server 162.159.200.1 offset 
0.001741 sec
server 162.159.200.1, stratum 3, offset 0.002529, delay 0.02914
server 162.159.200.123, stratum 3, offset 0.001931, delay 0.02788
14 Jun 11:40:31 ntpdate[29597]: adjust time server 162.159.200.123 offset 
0.001931 sec
server 162.159.200.123, stratum 3, offset 0.001765, delay 0.02742
server 162.159.200.1, stratum 3, offset 0.002551, delay 0.02924
14 Jun 11:40:37 ntpdate[29618]: adjust time server 162.159.200.123 offset 
0.001765 sec


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/OJMYZRPDZM4WZMWEXEVCS2NG6ADQZ4C2/

[ovirt-users] Re: Engine is one month ahead

[Strahil Nikolov via Users]

It seems that the current events are OK and have today's date.
The issue is that the Dashboard is showing events with filter '> Today' which 
also catches those events logged in July 2020.

I guess If I fix those (or just wait till July), the Dashboard won't show them 
any more.

Best Regards,
Strahil Nikolov






В неделя, 14 юни 2020 г., 11:41:36 ч. Гринуич+3, Strahil Nikolov 
 написа: 





Hello All,

I have a problem which started after the latest patching 4.3.9 to 4.3.10 .

Symptoms so far:
1. Engine reports that Hypervisours are drifting too much
2. ETL service stopped working
3. Web UI constantly notifies me that the nodes are again active (fills the 
screen till the bottom)

So far I have found an issue with one of the Hypervisours and after removing 
chrony's drift file and reboot - no more issues are observed.
I found in the DB that DWH last update was one month (yes, that's July) ahead , 
so updating it to June has fixed the ETL issue.
The problem with the constant "Host has been activated" was fixed by updating 
the Engine database , table Job (July was changed with June).


The only problem I have now is that every event in the Web (and in the DB of 
course) is pointing to July.

Any ideas how the engine is taking the time ,cause a restart doesn't fix the 
issue?

As you can see both Hypervisours and HE VM are OK:

[root@engine ~]# ntpdate -q time.cloudflare.com
server 162.159.200.1, stratum 3, offset 0.000816, delay 0.02812
server 162.159.200.123, stratum 3, offset 0.000939, delay 0.02834
14 Jun 11:40:05 ntpdate[30135]: adjust time server 162.159.200.1 offset 
0.000816 sec
[root@engine ~]# logout
Connection to engine closed.
[root@ovirt1 ~]# for i in ovirt{1..3} ; do ntpdate -q time.cloudflare.com ; done
server 162.159.200.123, stratum 3, offset 0.002658, delay 0.02948
server 162.159.200.1, stratum 3, offset 0.001741, delay 0.02768
14 Jun 11:40:24 ntpdate[29562]: adjust time server 162.159.200.1 offset 
0.001741 sec
server 162.159.200.1, stratum 3, offset 0.002529, delay 0.02914
server 162.159.200.123, stratum 3, offset 0.001931, delay 0.02788
14 Jun 11:40:31 ntpdate[29597]: adjust time server 162.159.200.123 offset 
0.001931 sec
server 162.159.200.123, stratum 3, offset 0.001765, delay 0.02742
server 162.159.200.1, stratum 3, offset 0.002551, delay 0.02924
14 Jun 11:40:37 ntpdate[29618]: adjust time server 162.159.200.123 offset 
0.001765 sec


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/FVCODQVPYMQHTJNMGMKKYGT2E2QG4WKQ/

[ovirt-users] Re: Weird problem starting VMs in oVirt-4.4

[Strahil Nikolov via Users]

Hey Joop,

are you using fully allocated qcow2 images ?

Best Regards,
Strahil Nikolov



На 16 юни 2020 г. 20:23:17 GMT+03:00, Joop  написа:
>On 3-6-2020 14:58, Joop wrote:
>> Hi All,
>>
>> Just had a rather new experience in that starting a VM worked but the
>> kernel entered grub2 rescue console due to the fact that something
>was
>> wrong with its virtio-scsi disk.
>> The message is Booting from Hard Disk 
>> error: ../../grub-core/kern/dl.c:266:invalid arch-independent ELF
>maginc.
>> entering rescue mode...
>>
>> Doing a CTRL-ALT-Del through the spice console let the VM boot
>> correctly. Shutting it down and repeating the procedure I get a disk
>> problem everytime. Weird thing is if I activate the BootMenu and then
>> straight away start the VM all is OK.
>> I don't see any ERROR messages in either vdsm.log, engine.log
>>
>> If I would have to guess it looks like the disk image isn't connected
>> yet when the VM boots but thats weird isn't it?
>>
>As a follow up I tried a couple of other things:
>- installed CentOS-7 and oVirt 4.3.10 using HCI and same problem
>(the previous install of 4.3 was a upgraded version. Don't know the
>start versie)
>- did some testing with copying large files into the engine gluster
>volume through /rhev/datacenter using 'cp' and no problems
>- used qemu-img convert with the engine gluster volume as destination
>--> problems
>- had a good look through lots of logfiles and stumbled across an error
>about missing shard which aligned with qemu-img errors
>- turned features.shard off on the volume and restarted the volume
>- reran the tests with qemu-img --> no problems any more.
>- reinstalled Centos8.2 + oVirt-4.0, turned off sharding before
>starting
>the engine install
>--> no problems installing, no problems importing, no problems starting
>vms, sofar
>
>I need to install another server tomorrow, so I'll do that with
>sharding
>enabled and see if it crashes too and then get the logs some place
>safe.
>
>Regards,
>
>Joop
>
>___
>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/6TNJYNVBJWCB2NXDYMBYVNDQUWKBJJYU/
___
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/6P5RUFXZYGOQZBOQ6FNYMUNC6G727X77/

[ovirt-users] Re: Weird problem starting VMs in oVirt-4.4

[Strahil Nikolov via Users]

Hey Nir,

in ovirt  4.3.something  the default behaviour for Gluster changed  from thin 
to fully allocated.

My guess  is that the shard xlator cannot catch up with the I/O.

Do you think that I should file a RFE to change the shard size  ? 
As far as I know RedHat support only 512MB shard size,  while gluster's default 
is only 64MB.

Best Rregards,
Strahil Nikolov

На 16 юни 2020 г. 23:22:53 GMT+03:00, Nir Soffer  написа:
>On Tue, Jun 16, 2020 at 11:01 PM Joop  wrote:
>>
>> On 16-6-2020 19:44, Strahil Nikolov wrote:
>> > Hey Joop,
>> >
>> > are you using fully allocated qcow2 images ?
>> >
>> > Best Regards,
>> > Strahil Nikolov
>> >
>> I noticed that when I use import VM from an Export domain I see that
>it
>> sometimes uses preallocated and sometimes thin-provisioned for the
>disk(s).
>> Don't know why and I don't think there is a pattern.
>
>Maybe the system selects a different storage domain? On block storage
>the
>default is preallocated, but on file based storage the default is thin.
>
>> Old VMs from 3.3 or
>> new ones from 4.2/3, its mixed.
>> I almost always use thin-provisioned but one or two could have been
>> preallocated by accident.
>>
>> How do I check?
>
>If the question was about creating images with:
>
>qemu-img create -f qcow2 -o preallocation=metadata ...
>
>Then it is easy, ovirt does not create such images.
>
>> Joop
>>
>> >
>> > На 16 юни 2020 г. 20:23:17 GMT+03:00, Joop 
>написа:
>> >> On 3-6-2020 14:58, Joop wrote:
>> >>> Hi All,
>> >>>
>> >>> Just had a rather new experience in that starting a VM worked but
>the
>> >>> kernel entered grub2 rescue console due to the fact that
>something
>> >> was
>> >>> wrong with its virtio-scsi disk.
>> >>> The message is Booting from Hard Disk 
>> >>> error: ../../grub-core/kern/dl.c:266:invalid arch-independent ELF
>> >> maginc.
>> >>> entering rescue mode...
>> >>>
>> >>> Doing a CTRL-ALT-Del through the spice console let the VM boot
>> >>> correctly. Shutting it down and repeating the procedure I get a
>disk
>> >>> problem everytime. Weird thing is if I activate the BootMenu and
>then
>> >>> straight away start the VM all is OK.
>> >>> I don't see any ERROR messages in either vdsm.log, engine.log
>> >>>
>> >>> If I would have to guess it looks like the disk image isn't
>connected
>> >>> yet when the VM boots but thats weird isn't it?
>> >>>
>> >> As a follow up I tried a couple of other things:
>> >> - installed CentOS-7 and oVirt 4.3.10 using HCI and same problem
>> >> (the previous install of 4.3 was a upgraded version. Don't know
>the
>> >> start versie)
>> >> - did some testing with copying large files into the engine
>gluster
>> >> volume through /rhev/datacenter using 'cp' and no problems
>> >> - used qemu-img convert with the engine gluster volume as
>destination
>> >> --> problems
>> >> - had a good look through lots of logfiles and stumbled across an
>error
>> >> about missing shard which aligned with qemu-img errors
>> >> - turned features.shard off on the volume and restarted the volume
>> >> - reran the tests with qemu-img --> no problems any more.
>> >> - reinstalled Centos8.2 + oVirt-4.0, turned off sharding before
>> >> starting
>> >> the engine install
>> >> --> no problems installing, no problems importing, no problems
>starting
>> >> vms, sofar
>> >>
>> >> I need to install another server tomorrow, so I'll do that with
>> >> sharding
>> >> enabled and see if it crashes too and then get the logs some place
>> >> safe.
>> >>
>> >> Regards,
>> >>
>> >> Joop
>> >>
>> >> ___
>> >> 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/6TNJYNVBJWCB2NXDYMBYVNDQUWKBJJYU/
>> ___
>> 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/7BPONTX2FDDNBMUK3ZBU3ZFK5DTESGYF/
>___
>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/NARCCR7LYDFKLTQDSD27JNLQW3FML6S2/
___
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 Condu

[ovirt-users] Re: cant edit ISO domain in any way

[Strahil Nikolov via Users]

What do you want to change ?

На 17 юни 2020 г. 0:36:49 GMT+03:00, Philip  Brown  написа:
>oVirt 4.3:  Okay, I found documentation that I cant have more than one
>"ISO" type storage domain.
>I can kinda understand that.
>
>But, I cant even edit or delete the existing one?
>Even when logged in to the oVirt GUI as admin@internal?
>
>Is this some kind of bug or something?
>___
>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/DXSU32CVV6AQJNKUV7JL7TW2NRAZDMLG/
___
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/2KAGPHN3HKP4FMNSZNGOEY4GF6OKJNNF/

[ovirt-users] Re: Information requested on oVirt + RDO/OpenStack

[Strahil Nikolov via Users]

Hello Glenn,


sadly I can't answer your questions ,  but I think you will find this one 
interesting:

http://chrisj.cloud/?q=node/8

Best Regards,
Strahil Nikolov

На 17 юни 2020 г. 3:00:34 GMT+03:00, Glenn Marcy  написа:
>I am hoping to try out adding RDO to oVirt after things with CentOS 8.2
>settle down.  I've done deployments of RDO on KVM before without any
>issues (TripleO Quickstart), but this would be my first time trying it
>on oVirt.
>
>Since oVirt recently updated to the openstack-java 3.2.9 packages, is
>there a specific version of OpenStack (Train or Ussuri) that runs on
>CentOS 8.x that I need?  Are there any issues with the fact that oVirt
>already uses and/or provides some OpenStack services?  Does the fact
>that OpenStack deployments are now more "containerized" present any
>issues I should be aware of?
>
>Are there initiatives for further convergence between oVirt,
>RDO/OpenStack and OKD/OCP that are changing this space where it would
>make sense to follow and/or participate in those efforts?
>
>I'm starting out with oVirt to get an understanding of the capabilities
>that it brings to the table, but interested in the convergence of the
>other technologies that would benefit from having oVirt as, or a part
>of, the foundation.
>
>Best Regards,
>Glenn
>___
>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/5MPEU357TFRCJBM5U2VO4KXXCKCHJN56/
___
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/ODPWUYYO3Q3LSADNIOIBNPV3ULW3ZUIJ/

[ovirt-users] Re: Ovirt fails to retrieve iSCSI targets during installation

[Strahil Nikolov via Users]

Are you using proxy?
Check that all hosts can discover and login with the same parameters you set in 
oVirt.

Best Regards,
Strahil Nikolov

На 17 юни 2020 г. 11:32:49 GMT+03:00, Ricardo Alonso  
написа:
>Trying to connect to a an iSCSI target (no chap/secrets) is failing
>with the message: 
>
>2020-06-17 05:25:40,050-0300 ERROR ansible failed {
>"ansible_host": "localhost",
>"ansible_playbook":
>"/usr/share/ovirt-hosted-engine-setup/ansible/trigger_role.yml",
>"ansible_result": {
>"_ansible_no_log": false,
>"changed": false,
>"connection": "close",
>"content": "{\n  \"detail\" : \"For correct usage, see:
>https://ovirt./ovirt-engine/apidoc#services/host/methods/iscsi_discover\",\n
> \"reason\" : \"Request syntactically incorrect.\"\n}",
>"content_encoding": "identity",
>"content_type": "application/json",
>"correlation_id": "a5ba94a7-b22b-4ed6-9a47-87a87186c341",
>"date": "Wed, 17 Jun 2020 08:25:38 GMT",
>"elapsed": 0,
>"invocation": {
>"module_args": {
>"attributes": null,
>"backup": null,
>"body": "{\"iscsi\": {\"address\": \"192.168.6.1\", \"port\":
>\"3260,3260\", \"username\": null, \"password\": \"\"}}",
>"body_format": "json",
>"client_cert": null,
>"client_key": null,
>"content": null,
>"creates": null,
>"delimiter": null,
>"dest": null,
>"directory_mode": null,
>"follow": false,
>"follow_redirects": "safe",
>"force": false,
>"force_basic_auth": false,
>"group": null,
>"headers": {
>"Accept": "application/json",
> "Authorization": "Basic YWRtaW5AaW50ZXJuYWw6cGQyMDAx",
>"Content-Type": "application/json"
>},
>"http_agent": "ansible-httpget",
>"method": "POST",
>"mode": null,
>"owner": null,
>"regexp": null,
>"remote_src": null,
>"removes": null,
>"return_content": true,
>"selevel": null,
>"serole": null,
>"setype": null,
>"seuser": null,
>"src": null,
>"status_code": [
>"200"
>],
>"timeout": 30,
>"unix_socket": null,
>"unsafe_writes": null,
>"url":
>"https://ovirt./ovirt-engine/api/hosts/2c173b7f-9f9e-4046-890a-ab16d1babc35/iscsidiscover",
>"url_password": null,
>"url_username": null,
>"use_proxy": true,
>"validate_certs": false
>}
>},
>"json": {
>"detail": "For correct usage, see:
>https://ovirt./ovirt-engine/apidoc#services/host/methods/iscsi_discover",
>"reason": "Request syntactically incorrect."
>},
>"msg": "Status code was 400 and not [200]: HTTP Error 400: Bad
>Request",
>"redirected": false,
>"server": "Apache/2.4.37 (centos) OpenSSL/1.1.1c mod_wsgi/4.6.4
>Python/3.6",
>"status": 400,
>"transfer_encoding": "chunked",
>"url":
>"https://ovirt./ovirt-engine/api/hosts/2c173b7f-9f9e-4046-890a-ab16d1babc35/iscsidiscover"
>},
>"ansible_task": "iSCSI discover with REST API",
>"ansible_type": "task",
>"status": "FAILED",
>"task_duration": 4
>}
>
>I found this old bug, but doesn't seams to have a resolution. Any
>clue/tips? 
>___
>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/ONVH6LBKTXGCMIH3CKN6XQJSDM2M7HZZ/
___
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/ETYRWDYIPF7IB6GK7DLQXMW2KG7IEMDI/

[ovirt-users] Re: Issues with Gluster Domain

[Strahil Nikolov via Users]

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] Re: Fwd: Issues with Gluster Domain

[Strahil Nikolov via Users]

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] Re: Fwd: Fwd: Issues with Gluster Domain

[Strahil Nikolov via Users]

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: Host has time-drift of xxx seconds

[Strahil Nikolov via Users]

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

[Strahil Nikolov via Users]

Hey C Williams,

sorry for the delay,  but I couldn't get somw time to check your logs.  Will  
try a  little  bit later.

Best Regards,
Strahil  Nikolov

На 20 юни 2020 г. 2:37:22 GMT+03:00, C Williams  
написа:
>Hello,
>
>Was wanting to follow up on this issue. Users are impacted.
>
>Thank You
>
>On Fri, Jun 19, 2020 at 9:20 AM C Williams 
>wrote:
>
>> Hello,
>>
>> Here are the logs (some IPs are changed )
>>
>> ov05 is the SPM
>>
>> Thank You For Your Help !
>>
>> On Thu, Jun 18, 2020 at 11:31 PM Strahil Nikolov
>
>> wrote:
>>
>>> 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.lo

[ovirt-users] Re: Fwd: Fwd: Issues with Gluster Domain

[Strahil Nikolov via Users]

Hi ,


This one really looks like the ACL bug I was hit with when I updated from 
Gluster v6.5 to 6.6 and later from 7.0 to 7.2.

Did you update your setup recently ? Did you upgrade gluster also ?

You have to check the gluster logs in order to verify that, so you can try:

1. Set Gluster logs to trace level (for details check: 
https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3/html/administration_guide/configuring_the_log_level
 )
2. Power up a VM that was already off , or retry the procedure from the logs 
you sent.
3. Stop the trace level of the logs
4. Check libvirt logs on the host that was supposed to power up the VM (in case 
a VM was powered on)
5. Check the gluster brick logs on all nodes for ACL errors.
Here is a sample from my old logs:

gluster_bricks-data_fast4-data_fast4.log:[2020-03-18 13:19:41.489047] I [MSGID: 
139001] [posix-acl.c:262:posix_acl_log_permit_denied] 
0-data_fast4-access-control: client: CTX_ID:4a654305-d2e4-
4a10-bad9-58d670d99a97-GRAPH_ID:0-PID:32412-HOST:ovirt1.localdomain-PC_NAME:data_fast4-client-0-RECON_NO:-19,
 gfid: be318638-e8a0-4c6d-977d-7a937aa84806, req(uid:36,gid:36,perm:1,ngrps:3), 
ctx
(uid:0,gid:0,in-groups:0,perm:000,updated-fop:INVALID, acl:-) [Permission 
denied]
gluster_bricks-data_fast4-data_fast4.log:[2020-03-18 13:22:51.818796] I [MSGID: 
139001] [posix-acl.c:262:posix_acl_log_permit_denied] 
0-data_fast4-access-control: client: CTX_ID:4a654305-d2e4-
4a10-bad9-58d670d99a97-GRAPH_ID:0-PID:32412-HOST:ovirt1.localdomain-PC_NAME:data_fast4-client-0-RECON_NO:-19,
 gfid: be318638-e8a0-4c6d-977d-7a937aa84806, req(uid:36,gid:36,perm:1,ngrps:3), 
ctx
(uid:0,gid:0,in-groups:0,perm:000,updated-fop:INVALID, acl:-) [Permission 
denied]
gluster_bricks-data_fast4-data_fast4.log:[2020-03-18 13:24:43.732856] I [MSGID: 
139001] [posix-acl.c:262:posix_acl_log_permit_denied] 
0-data_fast4-access-control: client: CTX_ID:4a654305-d2e4-
4a10-bad9-58d670d99a97-GRAPH_ID:0-PID:32412-HOST:ovirt1.localdomain-PC_NAME:data_fast4-client-0-RECON_NO:-19,
 gfid: be318638-e8a0-4c6d-977d-7a937aa84806, req(uid:36,gid:36,perm:1,ngrps:3), 
ctx
(uid:0,gid:0,in-groups:0,perm:000,updated-fop:INVALID, acl:-) [Permission 
denied]
gluster_bricks-data_fast4-data_fast4.log:[2020-03-18 13:26:50.758178] I [MSGID: 
139001] [posix-acl.c:262:posix_acl_log_permit_denied] 
0-data_fast4-access-control: client: CTX_ID:4a654305-d2e4-
4a10-bad9-58d670d99a97-GRAPH_ID:0-PID:32412-HOST:ovirt1.localdomain-PC_NAME:data_fast4-client-0-RECON_NO:-19,
 gfid: be318638-e8a0-4c6d-977d-7a937aa84806, req(uid:36,gid:36,perm:1,ngrps:3), 
ctx
(uid:0,gid:0,in-groups:0,perm:000,updated-fop:INVALID, acl:-) [Permission 
denied]


In my case , the workaround was to downgrade the gluster packages on all nodes 
(and reboot each node 1 by 1 ) if the major version is the same, but if you 
upgraded to v7.X - then you can try the v7.0 .

Best Regards,
Strahil Nikolov






В събота, 20 юни 2020 г., 18:48:42 ч. Гринуич+3, C Williams 
 написа: 





Hello,

Here are additional log tiles as well as a tree of the problematic Gluster 
storage domain. During this time I attempted to copy a virtual disk to another 
domain, move a virtual disk to another domain and run a VM where the virtual 
hard disk would be used. 

The copies/moves failed and the VM went into pause mode when the virtual HDD 
was involved.

Please check these out.

Thank You For Your Help !

On Sat, Jun 20, 2020 at 9:54 AM C Williams  wrote:
> Strahil,
> 
> I understand. Please keep me posted.
> 
> Thanks For The Help ! 
> 
> On Sat, Jun 20, 2020 at 4:36 AM Strahil Nikolov  wrote:
>> Hey C Williams,
>> 
>> sorry for the delay,  but I couldn't get somw time to check your logs.  Will 
>>  try a  little  bit later.
>> 
>> Best Regards,
>> Strahil  Nikolov
>> 
>> На 20 юни 2020 г. 2:37:22 GMT+03:00, C Williams  
>> написа:
>>>Hello,
>>>
>>>Was wanting to follow up on this issue. Users are impacted.
>>>
>>>Thank You
>>>
>>>On Fri, Jun 19, 2020 at 9:20 AM C Williams 
>>>wrote:
>>>
 Hello,

 Here are the logs (some IPs are changed )

 ov05 is the SPM

 Thank You For Your Help !

 On Thu, Jun 18, 2020 at 11:31 PM Strahil Nikolov
>>>
 wrote:

> 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

[ovirt-users] Re: Fwd: Fwd: Issues with Gluster Domain

[Strahil Nikolov via Users]

Sorry to hear that.
I can say that  for  me 6.5 was  working,  while 6.6 didn't and I upgraded to 
7.0 .
In the ended ,  I have ended  with creating a  new fresh volume and physically 
copying the data there,  then I detached the storage domains and attached  to 
the  new ones  (which holded the old  data),  but I could afford  the downtime.
Also,  I can say that v7.0  (  but not 7.1  or anything later)  also worked  
without the ACL  issue,  but it causes some trouble  in oVirt - so avoid that 
unless  you have no other options.

Best Regards,
Strahil  Nikolov




На 21 юни 2020 г. 4:39:46 GMT+03:00, C Williams  
написа:
>Hello,
>
>Upgrading diidn't help
>
>Still acl errors trying to use a Virtual Disk from a VM
>
>[root@ov06 bricks]# tail bricks-brick04-images3.log | grep acl
>[2020-06-21 01:33:45.665888] I [MSGID: 139001]
>[posix-acl.c:263:posix_acl_log_permit_denied] 0-images3-access-control:
>client:
>CTX_ID:3697a7f1-44fb-4258-96b0-98cb4137d195-GRAPH_ID:0-PID:6706-HOST:ov06.ntc.srcle.com-PC_NAME:images3-client-0-RECON_NO:-0,
>gfid: be318638-e8a0-4c6d-977d-7a937aa84806,
>req(uid:107,gid:107,perm:1,ngrps:3),
>ctx(uid:0,gid:0,in-groups:0,perm:000,updated-fop:INVALID, acl:-)
>[Permission denied]
>The message "I [MSGID: 139001]
>[posix-acl.c:263:posix_acl_log_permit_denied] 0-images3-access-control:
>client:
>CTX_ID:3697a7f1-44fb-4258-96b0-98cb4137d195-GRAPH_ID:0-PID:6706-HOST:ov06.ntc.srcle.com-PC_NAME:images3-client-0-RECON_NO:-0,
>gfid: be318638-e8a0-4c6d-977d-7a937aa84806,
>req(uid:107,gid:107,perm:1,ngrps:3),
>ctx(uid:0,gid:0,in-groups:0,perm:000,updated-fop:INVALID, acl:-)
>[Permission denied]" repeated 2 times between [2020-06-21
>01:33:45.665888]
>and [2020-06-21 01:33:45.806779]
>
>Thank You For Your Help !
>
>On Sat, Jun 20, 2020 at 8:59 PM C Williams 
>wrote:
>
>> Hello,
>>
>> Based on the situation, I am planning to upgrade the 3 affected
>hosts.
>>
>> My reasoning is that the hosts/bricks were attached to 6.9 at one
>time.
>>
>> Thanks For Your Help !
>>
>> On Sat, Jun 20, 2020 at 8:38 PM C Williams 
>> wrote:
>>
>>> Strahil,
>>>
>>> The gluster version on the current 3 gluster hosts is  6.7 (last
>update
>>> 2/26). These 3 hosts provide 1 brick each for the replica 3 volume.
>>>
>>> Earlier I had tried to add 6 additional hosts to the cluster. Those
>new
>>> hosts were 6.9 gluster.
>>>
>>> I attempted to make a new separate volume with 3 bricks provided by
>the 3
>>> new gluster  6.9 hosts. After having many errors from the oVirt
>interface,
>>> I gave up and removed the 6 new hosts from the cluster. That is
>where the
>>> problems started. The intent was to expand the gluster cluster while
>making
>>> 2 new volumes for that cluster. The ovirt compute cluster would
>allow for
>>> efficient VM migration between 9 hosts -- while having separate
>gluster
>>> volumes for safety purposes.
>>>
>>> Looking at the brick logs, I see where there are acl errors starting
>from
>>> the time of the removal of the 6 new hosts.
>>>
>>> Please check out the attached brick log from 6/14-18. The events
>started
>>> on 6/17.
>>>
>>> I wish I had a downgrade path.
>>>
>>> Thank You For The Help !!
>>>
>>> On Sat, Jun 20, 2020 at 7:47 PM Strahil Nikolov
>
>>> wrote:
>>>
 Hi ,


 This one really looks like the ACL bug I was hit with when I
>updated
 from Gluster v6.5 to 6.6 and later from 7.0 to 7.2.

 Did you update your setup recently ? Did you upgrade gluster also ?

 You have to check the gluster logs in order to verify that, so you
>can
 try:

 1. Set Gluster logs to trace level (for details check:

>https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3/html/administration_guide/configuring_the_log_level
 )
 2. Power up a VM that was already off , or retry the procedure from
>the
 logs you sent.
 3. Stop the trace level of the logs
 4. Check libvirt logs on the host that was supposed to power up the
>VM
 (in case a VM was powered on)
 5. Check the gluster brick logs on all nodes for ACL errors.
 Here is a sample from my old logs:

 gluster_bricks-data_fast4-data_fast4.log:[2020-03-18
>13:19:41.489047] I
 [MSGID: 139001] [posix-acl.c:262:posix_acl_log_permit_denied]
 0-data_fast4-access-control: client: CTX_ID:4a654305-d2e4-

>4a10-bad9-58d670d99a97-GRAPH_ID:0-PID:32412-HOST:ovirt1.localdomain-PC_NAME:data_fast4-client-0-RECON_NO:-19,
 gfid: be318638-e8a0-4c6d-977d-7a937aa84806,
 req(uid:36,gid:36,perm:1,ngrps:3), ctx
 (uid:0,gid:0,in-groups:0,perm:000,updated-fop:INVALID, acl:-)
 [Permission denied]
 gluster_bricks-data_fast4-data_fast4.log:[2020-03-18
>13:22:51.818796] I
 [MSGID: 139001] [posix-acl.c:262:posix_acl_log_permit_denied]
 0-data_fast4-access-control: client: CTX_ID:4a654305-d2e4-

>4a10-bad9-58d670d99a97-GRAPH_ID:0-PID:32412-HOST:ovirt1.localdomain-PC_NAME:data_fast4-client-0-RECON_NO:-19,
 gfid: be318638-e8a0-4c6d-977d-7a937aa84806,
 req

[ovirt-users] Multiple Gluster ACL issues with oVirt

[Strahil Nikolov via Users]

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/7OTGSH25GAB4HTSMFEME3UZ6VC65MU2E/

[ovirt-users] Re: Fwd: Fwd: Issues with Gluster Domain

[Strahil Nikolov via Users]

I  created a fresh volume  (which is not an ovirt sgorage domain),  set  the  
original  storage  domain  in maintenance and detached  it.
Then I 'cp  -a ' the data from the old to the new volume. Next,  I just  added  
the  new  storage domain (the old  one  was  a  kind  of a 'backup')  - 
pointing to the  new  volume  name.

If  you  observe  issues ,  I would  recommend  you  to downgrade  gluster  
packages one node  at  a  time  . Then you might be able to restore  your  
oVirt operations.

Best  Regards,
Strahil  Nikolov

На 21 юни 2020 г. 18:01:31 GMT+03:00, C Williams  
написа:
>Strahil,
>
>Thanks for the follow up !
>
>How did you copy the data to another volume ?
>
>I have set up another storage domain GLCLNEW1 with a new volume imgnew1
>.
>How would you copy all of the data from the problematic domain GLCL3
>with
>volume images3 to GLCLNEW1 and volume imgnew1 and preserve all the VMs,
>VM
>disks, settings, etc. ?
>
>Remember all of the regular ovirt disk copy, disk move, VM export 
>tools
>are failing and my VMs and disks are trapped on domain GLCL3 and volume
>images3 right now.
>
>Please let me know
>
>Thank You For Your Help !
>
>
>
>
>
>On Sun, Jun 21, 2020 at 8:27 AM Strahil Nikolov 
>wrote:
>
>> Sorry to hear that.
>> I can say that  for  me 6.5 was  working,  while 6.6 didn't and I
>upgraded
>> to 7.0 .
>> In the ended ,  I have ended  with creating a  new fresh volume and
>> physically copying the data there,  then I detached the storage
>domains and
>> attached  to the  new ones  (which holded the old  data),  but I
>could
>> afford  the downtime.
>> Also,  I can say that v7.0  (  but not 7.1  or anything later)  also
>> worked  without the ACL  issue,  but it causes some trouble  in oVirt
>- so
>> avoid that unless  you have no other options.
>>
>> Best Regards,
>> Strahil  Nikolov
>>
>>
>>
>>
>> На 21 юни 2020 г. 4:39:46 GMT+03:00, C Williams
>
>> написа:
>> >Hello,
>> >
>> >Upgrading diidn't help
>> >
>> >Still acl errors trying to use a Virtual Disk from a VM
>> >
>> >[root@ov06 bricks]# tail bricks-brick04-images3.log | grep acl
>> >[2020-06-21 01:33:45.665888] I [MSGID: 139001]
>> >[posix-acl.c:263:posix_acl_log_permit_denied]
>0-images3-access-control:
>> >client:
>>
>>
>>CTX_ID:3697a7f1-44fb-4258-96b0-98cb4137d195-GRAPH_ID:0-PID:6706-HOST:ov06.ntc.srcle.com-PC_NAME:images3-client-0-RECON_NO:-0,
>> >gfid: be318638-e8a0-4c6d-977d-7a937aa84806,
>> >req(uid:107,gid:107,perm:1,ngrps:3),
>> >ctx(uid:0,gid:0,in-groups:0,perm:000,updated-fop:INVALID, acl:-)
>> >[Permission denied]
>> >The message "I [MSGID: 139001]
>> >[posix-acl.c:263:posix_acl_log_permit_denied]
>0-images3-access-control:
>> >client:
>>
>>
>>CTX_ID:3697a7f1-44fb-4258-96b0-98cb4137d195-GRAPH_ID:0-PID:6706-HOST:ov06.ntc.srcle.com-PC_NAME:images3-client-0-RECON_NO:-0,
>> >gfid: be318638-e8a0-4c6d-977d-7a937aa84806,
>> >req(uid:107,gid:107,perm:1,ngrps:3),
>> >ctx(uid:0,gid:0,in-groups:0,perm:000,updated-fop:INVALID, acl:-)
>> >[Permission denied]" repeated 2 times between [2020-06-21
>> >01:33:45.665888]
>> >and [2020-06-21 01:33:45.806779]
>> >
>> >Thank You For Your Help !
>> >
>> >On Sat, Jun 20, 2020 at 8:59 PM C Williams 
>> >wrote:
>> >
>> >> Hello,
>> >>
>> >> Based on the situation, I am planning to upgrade the 3 affected
>> >hosts.
>> >>
>> >> My reasoning is that the hosts/bricks were attached to 6.9 at one
>> >time.
>> >>
>> >> Thanks For Your Help !
>> >>
>> >> On Sat, Jun 20, 2020 at 8:38 PM C Williams
>
>> >> wrote:
>> >>
>> >>> Strahil,
>> >>>
>> >>> The gluster version on the current 3 gluster hosts is  6.7 (last
>> >update
>> >>> 2/26). These 3 hosts provide 1 brick each for the replica 3
>volume.
>> >>>
>> >>> Earlier I had tried to add 6 additional hosts to the cluster.
>Those
>> >new
>> >>> hosts were 6.9 gluster.
>> >>>
>> >>> I attempted to make a new separate volume with 3 bricks provided
>by
>> >the 3
>> >>> new gluster  6.9 hosts. After having many errors from the oVirt
>> >interface,
>> >>> I gave up and removed the 6 new hosts from the cluster. That is
>> >where the
>> >>> problems started. The intent was to expand the gluster cluster
>while
>> >making
>> >>> 2 new volumes for that cluster. The ovirt compute cluster would
>> >allow for
>> >>> efficient VM migration between 9 hosts -- while having separate
>> >gluster
>> >>> volumes for safety purposes.
>> >>>
>> >>> Looking at the brick logs, I see where there are acl errors
>starting
>> >from
>> >>> the time of the removal of the 6 new hosts.
>> >>>
>> >>> Please check out the attached brick log from 6/14-18. The events
>> >started
>> >>> on 6/17.
>> >>>
>> >>> I wish I had a downgrade path.
>> >>>
>> >>> Thank You For The Help !!
>> >>>
>> >>> On Sat, Jun 20, 2020 at 7:47 PM Strahil Nikolov
>> >
>> >>> wrote:
>> >>>
>>  Hi ,
>> 
>> 
>>  This one really looks like the ACL bug I was hit with when I
>> >updated
>>  from Gluster v6.5 to 6.6 and later from 7.0 to 7.2.
>> 
>>  Did you update your setup recently ? Did yo

[ovirt-users] Re: Fwd: Fwd: Issues with Gluster Domain

[Strahil Nikolov via Users]

In my situation I had  only the ovirt nodes.

На 21 юни 2020 г. 22:43:04 GMT+03:00, C Williams  
написа:
>Strahil,
>
>So should I make the target volume on 3 bricks which do not have ovirt
>--
>just gluster ? In other words (3) Centos 7 hosts ?
>
>Thank You For Your Help !
>
>On Sun, Jun 21, 2020 at 3:08 PM Strahil Nikolov 
>wrote:
>
>> I  created a fresh volume  (which is not an ovirt sgorage domain), 
>set
>> the  original  storage  domain  in maintenance and detached  it.
>> Then I 'cp  -a ' the data from the old to the new volume. Next,  I
>just
>> added  the  new  storage domain (the old  one  was  a  kind  of a
>> 'backup')  - pointing to the  new  volume  name.
>>
>> If  you  observe  issues ,  I would  recommend  you  to downgrade
>> gluster  packages one node  at  a  time  . Then you might be able to
>> restore  your  oVirt operations.
>>
>> Best  Regards,
>> Strahil  Nikolov
>>
>> На 21 юни 2020 г. 18:01:31 GMT+03:00, C Williams
>
>> написа:
>> >Strahil,
>> >
>> >Thanks for the follow up !
>> >
>> >How did you copy the data to another volume ?
>> >
>> >I have set up another storage domain GLCLNEW1 with a new volume
>imgnew1
>> >.
>> >How would you copy all of the data from the problematic domain GLCL3
>> >with
>> >volume images3 to GLCLNEW1 and volume imgnew1 and preserve all the
>VMs,
>> >VM
>> >disks, settings, etc. ?
>> >
>> >Remember all of the regular ovirt disk copy, disk move, VM export
>> >tools
>> >are failing and my VMs and disks are trapped on domain GLCL3 and
>volume
>> >images3 right now.
>> >
>> >Please let me know
>> >
>> >Thank You For Your Help !
>> >
>> >
>> >
>> >
>> >
>> >On Sun, Jun 21, 2020 at 8:27 AM Strahil Nikolov
>
>> >wrote:
>> >
>> >> Sorry to hear that.
>> >> I can say that  for  me 6.5 was  working,  while 6.6 didn't and I
>> >upgraded
>> >> to 7.0 .
>> >> In the ended ,  I have ended  with creating a  new fresh volume
>and
>> >> physically copying the data there,  then I detached the storage
>> >domains and
>> >> attached  to the  new ones  (which holded the old  data),  but I
>> >could
>> >> afford  the downtime.
>> >> Also,  I can say that v7.0  (  but not 7.1  or anything later) 
>also
>> >> worked  without the ACL  issue,  but it causes some trouble  in
>oVirt
>> >- so
>> >> avoid that unless  you have no other options.
>> >>
>> >> Best Regards,
>> >> Strahil  Nikolov
>> >>
>> >>
>> >>
>> >>
>> >> На 21 юни 2020 г. 4:39:46 GMT+03:00, C Williams
>> >
>> >> написа:
>> >> >Hello,
>> >> >
>> >> >Upgrading diidn't help
>> >> >
>> >> >Still acl errors trying to use a Virtual Disk from a VM
>> >> >
>> >> >[root@ov06 bricks]# tail bricks-brick04-images3.log | grep acl
>> >> >[2020-06-21 01:33:45.665888] I [MSGID: 139001]
>> >> >[posix-acl.c:263:posix_acl_log_permit_denied]
>> >0-images3-access-control:
>> >> >client:
>> >>
>> >>
>>
>>
>>>CTX_ID:3697a7f1-44fb-4258-96b0-98cb4137d195-GRAPH_ID:0-PID:6706-HOST:ov06.ntc.srcle.com-PC_NAME:images3-client-0-RECON_NO:-0,
>> >> >gfid: be318638-e8a0-4c6d-977d-7a937aa84806,
>> >> >req(uid:107,gid:107,perm:1,ngrps:3),
>> >> >ctx(uid:0,gid:0,in-groups:0,perm:000,updated-fop:INVALID, acl:-)
>> >> >[Permission denied]
>> >> >The message "I [MSGID: 139001]
>> >> >[posix-acl.c:263:posix_acl_log_permit_denied]
>> >0-images3-access-control:
>> >> >client:
>> >>
>> >>
>>
>>
>>>CTX_ID:3697a7f1-44fb-4258-96b0-98cb4137d195-GRAPH_ID:0-PID:6706-HOST:ov06.ntc.srcle.com-PC_NAME:images3-client-0-RECON_NO:-0,
>> >> >gfid: be318638-e8a0-4c6d-977d-7a937aa84806,
>> >> >req(uid:107,gid:107,perm:1,ngrps:3),
>> >> >ctx(uid:0,gid:0,in-groups:0,perm:000,updated-fop:INVALID, acl:-)
>> >> >[Permission denied]" repeated 2 times between [2020-06-21
>> >> >01:33:45.665888]
>> >> >and [2020-06-21 01:33:45.806779]
>> >> >
>> >> >Thank You For Your Help !
>> >> >
>> >> >On Sat, Jun 20, 2020 at 8:59 PM C Williams
>
>> >> >wrote:
>> >> >
>> >> >> Hello,
>> >> >>
>> >> >> Based on the situation, I am planning to upgrade the 3 affected
>> >> >hosts.
>> >> >>
>> >> >> My reasoning is that the hosts/bricks were attached to 6.9 at
>one
>> >> >time.
>> >> >>
>> >> >> Thanks For Your Help !
>> >> >>
>> >> >> On Sat, Jun 20, 2020 at 8:38 PM C Williams
>> >
>> >> >> wrote:
>> >> >>
>> >> >>> Strahil,
>> >> >>>
>> >> >>> The gluster version on the current 3 gluster hosts is  6.7
>(last
>> >> >update
>> >> >>> 2/26). These 3 hosts provide 1 brick each for the replica 3
>> >volume.
>> >> >>>
>> >> >>> Earlier I had tried to add 6 additional hosts to the cluster.
>> >Those
>> >> >new
>> >> >>> hosts were 6.9 gluster.
>> >> >>>
>> >> >>> I attempted to make a new separate volume with 3 bricks
>provided
>> >by
>> >> >the 3
>> >> >>> new gluster  6.9 hosts. After having many errors from the
>oVirt
>> >> >interface,
>> >> >>> I gave up and removed the 6 new hosts from the cluster. That
>is
>> >> >where the
>> >> >>> problems started. The intent was to expand the gluster cluster
>> >while
>> >> >making
>> >> >>> 2 new volumes for that cluster. The ovirt compute cluster
>would
>> >> >al

[ovirt-users] Re: oVirt install questions

[Strahil Nikolov via Users]

На 21 юни 2020 г. 23:26:32 GMT+03:00, David White via Users  
написа:
>I'm reading through all of the documentation at
>https://ovirt.org/documentation/, and am a bit overwhelmed with all of
>the different options for installing oVirt. 
>
>My particular use case is that I'm looking for a way to manage VMs on
>multiple physical servers from 1 interface, and be able to deploy new
>VMs (or delete VMs) as necessary. Ideally, it would be great if I could
>move a VM from 1 host to a different host as well, particularly in the
>event that 1 host becomes degraded (bad HDD, bad processor, etc...)
>
>I'm trying to figure out what the difference is between an oVirt Node
>and the oVirt Engine, and how the engine differs from the Manager.
>
>I get the feeling that `Engine` = `Manager`. Same thing. I further
>think I understand the Engine to be essentially synonymous with a
>vCenter VM for ESXi hosts. Is this correct?
Generally speaking they are  interchangeable, but usually the engine is the 
deamon that is running inside the manager.
Correct, just  like  in VMware  - you can have your Vcenter  in a VM on the 
esxi or  you can host it on a separate physical server.

>If so, then what's the difference between the `self-hosted` vs the
>`stand-alone` engines?
Self  hosted  -> the manager  is managing the host that is hosting it ,  while 
standalone is on a non-managed location - like  standalone  KVM VM,  VMware VM 
or physical server.
>oVirt Engine requirements look to be a minimum of 4GB RAM and 2CPUs.
>oVirt Nodes, on the other hand, require only 2GB RAM.
>Is this a requirement just for the physical host, or is that how much
>RAM that each oVirt node process requires? In other words, if I have a
>physical host with 12GB of physical RAM, will I only be able to
>allocate 10GB of that to guest VMs? How much of that should I dedicated
>to the oVirt node processes?

oVirt Node -> a  kind of  ready to go appliance  that  has  only 1  purpose  - 
Hosting VMs.  It has  an advantage that you can easily rollback updates. 
Drawback  - hard to customize  (for example custom  drivers).
It  will be nice to have  as much memory as  possible, but depends  on the 
ammount and type  of VMs you plan to host on it.

>Can you install the oVirt Engine as a VM onto an existing oVirt Node?
>And then connect that same node to the Engine, once the Engine is
>installed?
That's  what the Hosted-Engine deployment  is doing for you. The  easiest  way 
is to use the cockpit  method.

>Reading through the documentation, it also sounds like oVirt Engine and
>oVirt Node require different versions of RHEL or CentOS.
>I read that the Engine for oVirt 4.4.0 requires RHEL (or CentOS) 8.2,
>whereas each Node requires 7.x (although I'll plan to just use the
>oVirt Node ISO).
oVirt 4.3 (node, engine) are based on  CentOS/EL  7.X
oVirt 4.4 (node,  engine)  are based on CentOS/EL 8.
oVirt 4.4 still needs  some polishing,  but keep in mind that migration from 
4.3 to  4.4  requires  redeploy (real reinstall).

>I'm also wondering about storage.
>I don't really like the idea of using local storage, but a single NFS
>server would also be a single point of failure, and Gluster would be
>too expensive to deploy, so at this point, I'm leaning towards using
>local storage.

 It's up to you.

>Any advice or clarity would be greatly appreciated.
>
>Thanks,
>David
>
>Sent with ProtonMail Secure Email.
___
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/3MKFQLYYN4IJJ53XDMOJNV6JA4M3D6IL/

[ovirt-users] Re: Fwd: Fwd: Issues with Gluster Domain

[Strahil Nikolov via Users]

You are definitely reading it wrong.
1. I didn't create a new storage  domain ontop this new volume.
2. I used cli

Something like this  (in your case it should be 'replica 3'):
gluster volume create newvol replica 3 arbiter 1 ovirt1:/new/brick/path 
ovirt2:/new/brick/path ovirt3:/new/arbiter/brick/path
gluster volume start newvol

#Detach oldvol from ovirt

mount -t glusterfs  ovirt1:/oldvol /mnt/oldvol
mount -t glusterfs ovirt1:/newvol /mnt/newvol
cp -a /mnt/oldvol/* /mnt/newvol

#Add only newvol as a storage domain in oVirt
#Import VMs

I still think that you should downgrade your gluster packages!!!

Best Regards,
Strahil Nikolov

На 22 юни 2020 г. 0:43:46 GMT+03:00, C Williams  
написа:
>Strahil,
>
>It sounds like  you used a "System Managed Volume" for the new storage
>domain,is that correct?
>
>Thank You For Your Help !
>
>On Sun, Jun 21, 2020 at 5:40 PM C Williams 
>wrote:
>
>> Strahil,
>>
>> So you made another oVirt Storage Domain -- then copied the data with
>cp
>> -a from the failed volume to the new volume.
>>
>> At the root of the volume there will be the old domain folder id ex
>> 5fe3ad3f-2d21-404c-832e-4dc7318ca10d
>>  in my case. Did that cause issues with making the new domain since
>it is
>> the same folder id as the old one ?
>>
>> Thank You For Your Help !
>>
>> On Sun, Jun 21, 2020 at 5:18 PM Strahil Nikolov
>
>> wrote:
>>
>>> In my situation I had  only the ovirt nodes.
>>>
>>> На 21 юни 2020 г. 22:43:04 GMT+03:00, C Williams
>
>>> написа:
>>> >Strahil,
>>> >
>>> >So should I make the target volume on 3 bricks which do not have
>ovirt
>>> >--
>>> >just gluster ? In other words (3) Centos 7 hosts ?
>>> >
>>> >Thank You For Your Help !
>>> >
>>> >On Sun, Jun 21, 2020 at 3:08 PM Strahil Nikolov
>
>>> >wrote:
>>> >
>>> >> I  created a fresh volume  (which is not an ovirt sgorage
>domain),
>>> >set
>>> >> the  original  storage  domain  in maintenance and detached  it.
>>> >> Then I 'cp  -a ' the data from the old to the new volume. Next, 
>I
>>> >just
>>> >> added  the  new  storage domain (the old  one  was  a  kind  of a
>>> >> 'backup')  - pointing to the  new  volume  name.
>>> >>
>>> >> If  you  observe  issues ,  I would  recommend  you  to downgrade
>>> >> gluster  packages one node  at  a  time  . Then you might be able
>to
>>> >> restore  your  oVirt operations.
>>> >>
>>> >> Best  Regards,
>>> >> Strahil  Nikolov
>>> >>
>>> >> На 21 юни 2020 г. 18:01:31 GMT+03:00, C Williams
>>> >
>>> >> написа:
>>> >> >Strahil,
>>> >> >
>>> >> >Thanks for the follow up !
>>> >> >
>>> >> >How did you copy the data to another volume ?
>>> >> >
>>> >> >I have set up another storage domain GLCLNEW1 with a new volume
>>> >imgnew1
>>> >> >.
>>> >> >How would you copy all of the data from the problematic domain
>GLCL3
>>> >> >with
>>> >> >volume images3 to GLCLNEW1 and volume imgnew1 and preserve all
>the
>>> >VMs,
>>> >> >VM
>>> >> >disks, settings, etc. ?
>>> >> >
>>> >> >Remember all of the regular ovirt disk copy, disk move, VM
>export
>>> >> >tools
>>> >> >are failing and my VMs and disks are trapped on domain GLCL3 and
>>> >volume
>>> >> >images3 right now.
>>> >> >
>>> >> >Please let me know
>>> >> >
>>> >> >Thank You For Your Help !
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >On Sun, Jun 21, 2020 at 8:27 AM Strahil Nikolov
>>> >
>>> >> >wrote:
>>> >> >
>>> >> >> Sorry to hear that.
>>> >> >> I can say that  for  me 6.5 was  working,  while 6.6 didn't
>and I
>>> >> >upgraded
>>> >> >> to 7.0 .
>>> >> >> In the ended ,  I have ended  with creating a  new fresh
>volume
>>> >and
>>> >> >> physically copying the data there,  then I detached the
>storage
>>> >> >domains and
>>> >> >> attached  to the  new ones  (which holded the old  data),  but
>I
>>> >> >could
>>> >> >> afford  the downtime.
>>> >> >> Also,  I can say that v7.0  (  but not 7.1  or anything later)
>>> >also
>>> >> >> worked  without the ACL  issue,  but it causes some trouble 
>in
>>> >oVirt
>>> >> >- so
>>> >> >> avoid that unless  you have no other options.
>>> >> >>
>>> >> >> Best Regards,
>>> >> >> Strahil  Nikolov
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> На 21 юни 2020 г. 4:39:46 GMT+03:00, C Williams
>>> >> >
>>> >> >> написа:
>>> >> >> >Hello,
>>> >> >> >
>>> >> >> >Upgrading diidn't help
>>> >> >> >
>>> >> >> >Still acl errors trying to use a Virtual Disk from a VM
>>> >> >> >
>>> >> >> >[root@ov06 bricks]# tail bricks-brick04-images3.log | grep
>acl
>>> >> >> >[2020-06-21 01:33:45.665888] I [MSGID: 139001]
>>> >> >> >[posix-acl.c:263:posix_acl_log_permit_denied]
>>> >> >0-images3-access-control:
>>> >> >> >client:
>>> >> >>
>>> >> >>
>>> >>
>>> >>
>>>
>>>
CTX_ID:3697a7f1-44fb-4258-96b0-98cb4137d195-GRAPH_ID:0-PID:6706-HOST:ov06.ntc.srcle.com-PC_NAME:images3-client-0-RECON_NO:-0,
>>> >> >> >gfid: be318638-e8a0-4c6d-977d-7a937aa84806,
>>> >> >> >req(uid:107,gid:107,perm:1,ngrps:3),
>>> >> >> >ctx(uid:0,gid:0,in-groups:0,perm:000,updated-fop:INVALID,
>acl:-)
>>> >> >> >[Permission denied]
>>> >> >> >Th

[ovirt-users] Re: Fwd: Fwd: Issues with Gluster Domain

[Strahil Nikolov via Users]

You can't add the new volume as it contains the same data (UUID) as the old one 
, thus you need to detach the old one before adding the new one - of course 
this means downtime for all VMs on that storage.

As you see , downgrading is more simpler. For me v6.5 was working, while 
anything above (6.6+) was causing complete lockdown.  Also v7.0 was working, 
but it's supported  in oVirt 4.4.

Best Regards,
Strahil Nikolov

На 22 юни 2020 г. 7:21:15 GMT+03:00, C Williams  
написа:
>Another question
>
>What version could I downgrade to safely ? I am at 6.9 .
>
>Thank You For Your Help !!
>
>On Sun, Jun 21, 2020 at 11:38 PM Strahil Nikolov
>
>wrote:
>
>> You are definitely reading it wrong.
>> 1. I didn't create a new storage  domain ontop this new volume.
>> 2. I used cli
>>
>> Something like this  (in your case it should be 'replica 3'):
>> gluster volume create newvol replica 3 arbiter 1
>ovirt1:/new/brick/path
>> ovirt2:/new/brick/path ovirt3:/new/arbiter/brick/path
>> gluster volume start newvol
>>
>> #Detach oldvol from ovirt
>>
>> mount -t glusterfs  ovirt1:/oldvol /mnt/oldvol
>> mount -t glusterfs ovirt1:/newvol /mnt/newvol
>> cp -a /mnt/oldvol/* /mnt/newvol
>>
>> #Add only newvol as a storage domain in oVirt
>> #Import VMs
>>
>> I still think that you should downgrade your gluster packages!!!
>>
>> Best Regards,
>> Strahil Nikolov
>>
>> На 22 юни 2020 г. 0:43:46 GMT+03:00, C Williams
>
>> написа:
>> >Strahil,
>> >
>> >It sounds like  you used a "System Managed Volume" for the new
>storage
>> >domain,is that correct?
>> >
>> >Thank You For Your Help !
>> >
>> >On Sun, Jun 21, 2020 at 5:40 PM C Williams 
>> >wrote:
>> >
>> >> Strahil,
>> >>
>> >> So you made another oVirt Storage Domain -- then copied the data
>with
>> >cp
>> >> -a from the failed volume to the new volume.
>> >>
>> >> At the root of the volume there will be the old domain folder id
>ex
>> >> 5fe3ad3f-2d21-404c-832e-4dc7318ca10d
>> >>  in my case. Did that cause issues with making the new domain
>since
>> >it is
>> >> the same folder id as the old one ?
>> >>
>> >> Thank You For Your Help !
>> >>
>> >> On Sun, Jun 21, 2020 at 5:18 PM Strahil Nikolov
>> >
>> >> wrote:
>> >>
>> >>> In my situation I had  only the ovirt nodes.
>> >>>
>> >>> На 21 юни 2020 г. 22:43:04 GMT+03:00, C Williams
>> >
>> >>> написа:
>> >>> >Strahil,
>> >>> >
>> >>> >So should I make the target volume on 3 bricks which do not have
>> >ovirt
>> >>> >--
>> >>> >just gluster ? In other words (3) Centos 7 hosts ?
>> >>> >
>> >>> >Thank You For Your Help !
>> >>> >
>> >>> >On Sun, Jun 21, 2020 at 3:08 PM Strahil Nikolov
>> >
>> >>> >wrote:
>> >>> >
>> >>> >> I  created a fresh volume  (which is not an ovirt sgorage
>> >domain),
>> >>> >set
>> >>> >> the  original  storage  domain  in maintenance and detached 
>it.
>> >>> >> Then I 'cp  -a ' the data from the old to the new volume.
>Next,
>> >I
>> >>> >just
>> >>> >> added  the  new  storage domain (the old  one  was  a  kind 
>of a
>> >>> >> 'backup')  - pointing to the  new  volume  name.
>> >>> >>
>> >>> >> If  you  observe  issues ,  I would  recommend  you  to
>downgrade
>> >>> >> gluster  packages one node  at  a  time  . Then you might be
>able
>> >to
>> >>> >> restore  your  oVirt operations.
>> >>> >>
>> >>> >> Best  Regards,
>> >>> >> Strahil  Nikolov
>> >>> >>
>> >>> >> На 21 юни 2020 г. 18:01:31 GMT+03:00, C Williams
>> >>> >
>> >>> >> написа:
>> >>> >> >Strahil,
>> >>> >> >
>> >>> >> >Thanks for the follow up !
>> >>> >> >
>> >>> >> >How did you copy the data to another volume ?
>> >>> >> >
>> >>> >> >I have set up another storage domain GLCLNEW1 with a new
>volume
>> >>> >imgnew1
>> >>> >> >.
>> >>> >> >How would you copy all of the data from the problematic
>domain
>> >GLCL3
>> >>> >> >with
>> >>> >> >volume images3 to GLCLNEW1 and volume imgnew1 and preserve
>all
>> >the
>> >>> >VMs,
>> >>> >> >VM
>> >>> >> >disks, settings, etc. ?
>> >>> >> >
>> >>> >> >Remember all of the regular ovirt disk copy, disk move, VM
>> >export
>> >>> >> >tools
>> >>> >> >are failing and my VMs and disks are trapped on domain GLCL3
>and
>> >>> >volume
>> >>> >> >images3 right now.
>> >>> >> >
>> >>> >> >Please let me know
>> >>> >> >
>> >>> >> >Thank You For Your Help !
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> >>> >> >On Sun, Jun 21, 2020 at 8:27 AM Strahil Nikolov
>> >>> >
>> >>> >> >wrote:
>> >>> >> >
>> >>> >> >> Sorry to hear that.
>> >>> >> >> I can say that  for  me 6.5 was  working,  while 6.6 didn't
>> >and I
>> >>> >> >upgraded
>> >>> >> >> to 7.0 .
>> >>> >> >> In the ended ,  I have ended  with creating a  new fresh
>> >volume
>> >>> >and
>> >>> >> >> physically copying the data there,  then I detached the
>> >storage
>> >>> >> >domains and
>> >>> >> >> attached  to the  new ones  (which holded the old  data), 
>but
>> >I
>> >>> >> >could
>> >>> >> >> afford  the downtime.
>> >>> >> >> Also,  I can say that v7.0  (  but not 7.1  or anything
>later)
>> >>> >also
>> >>> >> >> worked  without the A

[ovirt-users] Re: oVirt install questions

[Strahil Nikolov via Users]

На 22 юни 2020 г. 11:06:16 GMT+03:00, David White via Users  
написа:
>Thank you and Strahil for your responses.
>They were both very helpful.
>
>> I think a hosted engine installation VM wants 16GB RAM configured
>though I've built older versions with 8GB RAM.
>> For modern VMs CentOS8 x86_64 recommends at least 2GB for a host.
>CentOS7 was OK with 1, CentOS6 maybe 512K.
>> The tendency is always increasing with updated OS versions.
>
>Ok, so to clarify my question a little bit, I'm trying to figure out
>how much RAM I would need to reserve for the host OS (or oVirt Node).
>
>I do recall that CentOS / RHEL 8 wants a minimum of 2GB, so perhaps
>that would suffice?
>And then as you noted, I would need to plan to give the engine 16GB.

I run my engine on 4Gb or RAM,  but i have no more than 20 VMs, the larger  the 
setup - the more ram for the engine is needed.

>> My minimum ovirt systems were mostly 48GB 16core, but most are now
>128GB 24core or more.
>
>But this is the total amount of physical RAM in your systems, correct?
>Not the amount that you've reserved for your host OS?I've spec'd out
>some hardware, and am probably looking at purchasing two PowerEdge
>R820's to start, each with 64GB RAM and 32 cores.
> 
>
>> While ovirt can do what you would like it to do concerning a single
>user interface, but with what you listed,
>> you're probably better off with just plain KVM/qemu and using
>virt-manager for the interface.
>
>
>Can you migrate VMs from 1 host to another with virt-manager, and can
>you take snapshots?
>If those two features aren't supported by virt-manager, then that would
>almost certainly be a deal breaker.

The engine is just a management layer. KVM/qemu has  that option a long time 
ago,  yet it's some manual work to do it.

>Come to think of it, if I decided to use local storage on each of the
>physical hosts, would I be able to migrate VMs? 
>Or do I *have* to use a Gluster or NFS store for that?
>
For  migration between hosts you need a shared storage. SAN,  Gluster,  CEPH,  
NFS, iSCSI  are  among the ones already supported (CEPH  is a little bit  
experimental).

>‐‐‐ Original Message ‐‐‐
>On Sunday, June 21, 2020 5:58 PM, Edward Berger 
>wrote:
>
>> While ovirt can do what you would like it to do concerning a single
>user interface, but with what you listed,
>> you're probably better off with just plain KVM/qemu and using
>virt-manager for the interface.
>> 
>
>> Those memory/cpu requirements you listed are really tiny and I
>wouldn't recommend even trying ovirt on such challenged systems.
>> I would specify at least 3 hosts for a gluster hyperconverged system,
>and a spare available that can take over if one of the hosts dies.
>> 
>
>> I think a hosted engine installation VM wants 16GB RAM configured
>though I've built older versions with 8GB RAM.
>> For modern VMs CentOS8 x86_64 recommends at least 2GB for a host.
>CentOS7 was OK with 1, CentOS6 maybe 512K.
>> The tendency is always increasing with updated OS versions.
>> 
>
>> My minimum ovirt systems were mostly 48GB 16core, but most are now
>128GB 24core or more.
>> 
>
>> ovirt node ng is a prepackaged installer for an oVirt
>hypervisor/gluster host, with its cockpit interface you can create and
>install the hosted-engine VM for the user and admin web interface.  Its
>very good on enterprise server hardware with lots of RAM,CPU, and
>DISKS. 
>> 
>
>> On Sun, Jun 21, 2020 at 4:34 PM David White via Users
> wrote:
>> 
>
>> > I'm reading through all of the documentation at
>https://ovirt.org/documentation/, and am a bit overwhelmed with all of
>the different options for installing oVirt. 
>> > 
>
>> > My particular use case is that I'm looking for a way to manage VMs
>on multiple physical servers from 1 interface, and be able to deploy
>new VMs (or delete VMs) as necessary. Ideally, it would be great if I
>could move a VM from 1 host to a different host as well, particularly
>in the event that 1 host becomes degraded (bad HDD, bad processor,
>etc...)
>> > 
>
>> > I'm trying to figure out what the difference is between an oVirt
>Node and the oVirt Engine, and how the engine differs from the Manager.
>> > 
>
>> > I get the feeling that `Engine` = `Manager`. Same thing. I further
>think I understand the Engine to be essentially synonymous with a
>vCenter VM for ESXi hosts. Is this correct?
>> > 
>
>> > If so, then what's the difference between the `self-hosted` vs the
>`stand-alone` engines?
>> > 
>
>> > oVirt Engine requirements look to be a minimum of 4GB RAM and
>2CPUs.
>> > oVirt Nodes, on the other hand, require only 2GB RAM.
>> > Is this a requirement just for the physical host, or is that how
>much RAM that each oVirt node process requires? In other words, if I
>have a physical host with 12GB of physical RAM, will I only be able to
>allocate 10GB of that to guest VMs? How much of that should I dedicated
>to the oVirt node processes?
>> > 
>
>> > Can you install the oVirt Engine as a VM onto an existing oVirt
>Node? 

[ovirt-users] Re: oVirt noVNC

[Strahil Nikolov via Users]

It's  the client's browser settings ,  but I think it's easier to either change 
the certificate to something that will be trusted,  or  to just import it.

Best Regards,
Strahil  Nikolov

На 22 юни 2020 г. 11:29:20 GMT+03:00, Anton Louw via Users  
написа:
>Hi All,
>
>So I managed to get the noVNC console to work. The last item I am still
>struggling with however is to open the console without importing the CA
>certificate from the below screen:
>
>[cid:image001.png@01D6487F.FC012BF0]
>
>Anybody have any idea what settings I can change for the console to
>display without first importing the CA cert?
>
>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
>
>
>
>From: Anton Louw via Users 
>Sent: 17 June 2020 06:58
>To: Staniforth, Paul ; users@ovirt.org
>Subject: [ovirt-users] Re: oVirt noVNC
>
>
>Hi Paul,
>
>Apologies for the late response.
>
>So we only have a cert bundle on the one that is currently not working.
>The env that is working still has all the default certs.
>
>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]
>
>
>From: Staniforth, Paul
>mailto:p.stanifo...@leedsbeckett.ac.uk>>
>Sent: 12 June 2020 13:13
>To: Anton Louw
>mailto:anton.l...@voxtelecom.co.za>>;
>users@ovirt.org
>Subject: Re: oVirt noVNC
>
>Sorry Anton,
>   I'm trying to get a lot of things sorted before the weekend.
>
>This seems the wrong way round, if you follow the documentation you
>shouldn't have the symbolic link on the working system unless you
>replaced the file it was pointing to.
>
>Do you have certificate bundles for both systems?
>
>Regards,
>Paul S.
>
>
>From: Anton Louw
>mailto:anton.l...@voxtelecom.co.za>>
>Sent: 12 June 2020 11:44
>To: Staniforth, Paul
>mailto:p.stanifo...@leedsbeckett.ac.uk>>;
>users@ovirt.org
>mailto:users@ovirt.org>>
>Subject: RE: oVirt noVNC
>
>
>Caution External Mail: Do not click any links or open any attachments
>unless you trust the sender and know that the content is safe.
>
>
>Thanks Paul,
>
>
>
>So the symbolic link has then been removed, as per the below. Not quite
>sure where to go from here.
>
>
>
>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]

[ovirt-users] Re: Fwd: Re: Fwd: Fwd: Issues with Gluster Domain

[Strahil Nikolov via Users]

You should ensure  that in the storage domain tab, the old  storage is not 
visible.

I  still wander why yoiu didn't try to downgrade first.

Best Regards,
Strahil Nikolov

На 22 юни 2020 г. 13:58:33 GMT+03:00, C Williams  
написа:
>Strahil,
>
>The GLCL3 storage domain was detached prior to attempting to add the
>new
>storage domain.
>
>Should I also "Remove" it ?
>
>Thank You For Your Help !
>
>-- Forwarded message -
>From: Strahil Nikolov 
>Date: Mon, Jun 22, 2020 at 12:50 AM
>Subject: Re: [ovirt-users] Re: Fwd: Fwd: Issues with Gluster Domain
>To: C Williams 
>Cc: users 
>
>
>You can't add the new volume as it contains the same data (UUID) as the
>old
>one , thus you need to detach the old one before adding the new one -
>of
>course this means downtime for all VMs on that storage.
>
>As you see , downgrading is more simpler. For me v6.5 was working,
>while
>anything above (6.6+) was causing complete lockdown.  Also v7.0 was
>working, but it's supported  in oVirt 4.4.
>
>Best Regards,
>Strahil Nikolov
>
>На 22 юни 2020 г. 7:21:15 GMT+03:00, C Williams
>
>написа:
>>Another question
>>
>>What version could I downgrade to safely ? I am at 6.9 .
>>
>>Thank You For Your Help !!
>>
>>On Sun, Jun 21, 2020 at 11:38 PM Strahil Nikolov
>>
>>wrote:
>>
>>> You are definitely reading it wrong.
>>> 1. I didn't create a new storage  domain ontop this new volume.
>>> 2. I used cli
>>>
>>> Something like this  (in your case it should be 'replica 3'):
>>> gluster volume create newvol replica 3 arbiter 1
>>ovirt1:/new/brick/path
>>> ovirt2:/new/brick/path ovirt3:/new/arbiter/brick/path
>>> gluster volume start newvol
>>>
>>> #Detach oldvol from ovirt
>>>
>>> mount -t glusterfs  ovirt1:/oldvol /mnt/oldvol
>>> mount -t glusterfs ovirt1:/newvol /mnt/newvol
>>> cp -a /mnt/oldvol/* /mnt/newvol
>>>
>>> #Add only newvol as a storage domain in oVirt
>>> #Import VMs
>>>
>>> I still think that you should downgrade your gluster packages!!!
>>>
>>> Best Regards,
>>> Strahil Nikolov
>>>
>>> На 22 юни 2020 г. 0:43:46 GMT+03:00, C Williams
>>
>>> написа:
>>> >Strahil,
>>> >
>>> >It sounds like  you used a "System Managed Volume" for the new
>>storage
>>> >domain,is that correct?
>>> >
>>> >Thank You For Your Help !
>>> >
>>> >On Sun, Jun 21, 2020 at 5:40 PM C Williams
>
>>> >wrote:
>>> >
>>> >> Strahil,
>>> >>
>>> >> So you made another oVirt Storage Domain -- then copied the data
>>with
>>> >cp
>>> >> -a from the failed volume to the new volume.
>>> >>
>>> >> At the root of the volume there will be the old domain folder id
>>ex
>>> >> 5fe3ad3f-2d21-404c-832e-4dc7318ca10d
>>> >>  in my case. Did that cause issues with making the new domain
>>since
>>> >it is
>>> >> the same folder id as the old one ?
>>> >>
>>> >> Thank You For Your Help !
>>> >>
>>> >> On Sun, Jun 21, 2020 at 5:18 PM Strahil Nikolov
>>> >
>>> >> wrote:
>>> >>
>>> >>> In my situation I had  only the ovirt nodes.
>>> >>>
>>> >>> На 21 юни 2020 г. 22:43:04 GMT+03:00, C Williams
>>> >
>>> >>> написа:
>>> >>> >Strahil,
>>> >>> >
>>> >>> >So should I make the target volume on 3 bricks which do not
>have
>>> >ovirt
>>> >>> >--
>>> >>> >just gluster ? In other words (3) Centos 7 hosts ?
>>> >>> >
>>> >>> >Thank You For Your Help !
>>> >>> >
>>> >>> >On Sun, Jun 21, 2020 at 3:08 PM Strahil Nikolov
>>> >
>>> >>> >wrote:
>>> >>> >
>>> >>> >> I  created a fresh volume  (which is not an ovirt sgorage
>>> >domain),
>>> >>> >set
>>> >>> >> the  original  storage  domain  in maintenance and detached
>>it.
>>> >>> >> Then I 'cp  -a ' the data from the old to the new volume.
>>Next,
>>> >I
>>> >>> >just
>>> >>> >> added  the  new  storage domain (the old  one  was  a  kind
>>of a
>>> >>> >> 'backup')  - pointing to the  new  volume  name.
>>> >>> >>
>>> >>> >> If  you  observe  issues ,  I would  recommend  you  to
>>downgrade
>>> >>> >> gluster  packages one node  at  a  time  . Then you might be
>>able
>>> >to
>>> >>> >> restore  your  oVirt operations.
>>> >>> >>
>>> >>> >> Best  Regards,
>>> >>> >> Strahil  Nikolov
>>> >>> >>
>>> >>> >> На 21 юни 2020 г. 18:01:31 GMT+03:00, C Williams
>>> >>> >
>>> >>> >> написа:
>>> >>> >> >Strahil,
>>> >>> >> >
>>> >>> >> >Thanks for the follow up !
>>> >>> >> >
>>> >>> >> >How did you copy the data to another volume ?
>>> >>> >> >
>>> >>> >> >I have set up another storage domain GLCLNEW1 with a new
>>volume
>>> >>> >imgnew1
>>> >>> >> >.
>>> >>> >> >How would you copy all of the data from the problematic
>>domain
>>> >GLCL3
>>> >>> >> >with
>>> >>> >> >volume images3 to GLCLNEW1 and volume imgnew1 and preserve
>>all
>>> >the
>>> >>> >VMs,
>>> >>> >> >VM
>>> >>> >> >disks, settings, etc. ?
>>> >>> >> >
>>> >>> >> >Remember all of the regular ovirt disk copy, disk move, VM
>>> >export
>>> >>> >> >tools
>>> >>> >> >are failing and my VMs and disks are trapped on domain GLCL3
>>and
>>> >>> >volume
>>> >>> >> >images3 right now.
>>> >>> >> >
>>> >>> >> >Please let me know
>>> >>> >> >
>>> >>> >> >Thank You For Your Help !
>>> >>> >> >

[ovirt-users] Re: oVirt install questions

[Strahil Nikolov via Users]

Hey David,

keep in mind that you  need some big NICs.
I started  my oVirt lab with 1 Gbit  NIC and later added 4 dual-port  1 Gbit  
NICs  and I had to create multiple  gluster volumes  and multiple storage 
domains.
Yet,  windows  VMs cannot use software  raid  for boot devices,  thus it's a  
pain in the @$$.
I think that optimal is to have several 10Gbit NICs (at least  1  for gluster 
and 1 for oVirt live migration).
Also,  NVMEs  can be used  as lvm cache for spinning disks.

Best Regards,
Strahil  Nikolov

На 22 юни 2020 г. 18:50:01 GMT+03:00, David White  
написа:
>> For migration between hosts you need a shared storage. SAN, Gluster,
>CEPH, NFS, iSCSI are among the ones already supported (CEPH is a little
>bit experimental).
>
>Sounds like I'll be using NFS or Gluster after all.
>Thank you.
>
>> The engine is just a management layer. KVM/qemu has that option a
>long time ago, yet it's some manual work to do it.
>Yeah, this environment that I'm building is expected to grow over time
>(although that growth could go slowly), so I'm trying to architect
>things properly now to make future growth easier to deal with. I'm also
>trying to balance availability concerns with budget constraints
>starting out.
>
>Given that NFS would also be a single point of failure, I'll probably
>go with Gluster, as long as I can fit the storage requirements into the
>overall budget.
>
>
>Sent with ProtonMail Secure Email.
>
>‐‐‐ Original Message ‐‐‐
>On Monday, June 22, 2020 6:31 AM, Strahil Nikolov via Users
> wrote:
>
>> На 22 юни 2020 г. 11:06:16 GMT+03:00, David White via
>usersus...@ovirt.org написа:
>> 
>
>> > Thank you and Strahil for your responses.
>> > They were both very helpful.
>> > 
>
>> > > I think a hosted engine installation VM wants 16GB RAM configured
>> > > though I've built older versions with 8GB RAM.
>> > > For modern VMs CentOS8 x86_64 recommends at least 2GB for a host.
>> > > CentOS7 was OK with 1, CentOS6 maybe 512K.
>> > > The tendency is always increasing with updated OS versions.
>> > 
>
>> > Ok, so to clarify my question a little bit, I'm trying to figure
>out
>> > how much RAM I would need to reserve for the host OS (or oVirt
>Node).
>> > I do recall that CentOS / RHEL 8 wants a minimum of 2GB, so perhaps
>> > that would suffice?
>> > And then as you noted, I would need to plan to give the engine
>16GB.
>> 
>
>> I run my engine on 4Gb or RAM, but i have no more than 20 VMs, the
>larger the setup - the more ram for the engine is needed.
>> 
>
>> > > My minimum ovirt systems were mostly 48GB 16core, but most are
>now
>> > > 128GB 24core or more.
>> > 
>
>> > But this is the total amount of physical RAM in your systems,
>correct?
>> > Not the amount that you've reserved for your host OS?I've spec'd
>out
>> > some hardware, and am probably looking at purchasing two PowerEdge
>> > R820's to start, each with 64GB RAM and 32 cores.
>> > 
>
>> > > While ovirt can do what you would like it to do concerning a
>single
>> > > user interface, but with what you listed,
>> > > you're probably better off with just plain KVM/qemu and using
>> > > virt-manager for the interface.
>> > 
>
>> > Can you migrate VMs from 1 host to another with virt-manager, and
>can
>> > you take snapshots?
>> > If those two features aren't supported by virt-manager, then that
>would
>> > almost certainly be a deal breaker.
>> 
>
>> The engine is just a management layer. KVM/qemu has that option a
>long time ago, yet it's some manual work to do it.
>> 
>
>> > Come to think of it, if I decided to use local storage on each of
>the
>> > physical hosts, would I be able to migrate VMs? 
>> > Or do I have to use a Gluster or NFS store for that?
>> 
>
>> For migration between hosts you need a shared storage. SAN, Gluster,
>CEPH, NFS, iSCSI are among the ones already supported (CEPH is a little
>bit experimental).
>> 
>
>> > ‐‐‐ Original Message ‐‐‐
>> > On Sunday, June 21, 2020 5:58 PM, Edward Berger edwber...@gmail.com
>> > wrote:
>> > 
>
>> > > While ovirt can do what you would like it to do concerning a
>single
>> > > user interface, but with what you listed,
>> > > you're probably better off with just plain KVM/qemu and using
>> > > virt-manager for the interface.
>> > 
>

[ovirt-users] Re: Fwd: Re: Fwd: Fwd: Issues with Gluster Domain

[Strahil Nikolov via Users]

As  I told you, you could just downgrade gluster on all nodes and later plan to 
live migrate the VM disks.
I had to copy my data to the new volume, so I can avoid the ACL bug , when I 
use newer versions of gluster.


Let's clarify some details:
1. Which version of oVirt and Gluster are you using ?
2. You now have your old  gluster volume attached  to oVirt and the new volume 
unused, right ?
3. Did you copy the contents of the old volume to the new one ?

Best Regards,
Strahil Nikolov

На 23 юни 2020 г. 4:34:19 GMT+03:00, C Williams  
написа:
>Strahil,
>
>Thank You For Help !
>
>Downgrading Gluster to 6.5 got the original storage domain working
>again !
>
>After, I finished my copy of the contents of the problematic volume to
>a
>new volume, I did the following
>
>Unmounted the mount points
>Stopped the original problematic Gluster volume
>On each problematic peer,
>I downgraded Gluster to 6.5
>(yum downgrade glusterfs-6.5-1.el7.x86_64
>vdsm-gluster-4.30.46-1.el7.x86_64
>python2-gluster-6.5-1.el7.x86_64 glusterfs-libs-6.5-1.el7.x86_64
>glusterfs-cli-6.5-1.el7.x86_64 glusterfs-fuse-6.5-1.el7.x86_64
>glusterfs-rdma-6.5-1.el7.x86_64 glusterfs-api-6.5-1.el7.x86_64
>glusterfs-server-6.5-1.el7.x86_64 glusterfs-events-6.5-1.el7.x86_64
>glusterfs-client-xlators-6.5-1.el7.x86_64
>glusterfs-geo-replication-6.5-1.el7.x86_64)
>Restarted glusterd (systemctl restart glusterd)
>Restarted the problematic Gluster  volume
>Reattached the problematic storage domain
>Started the problematic storage domain
>
>Things work now. I can now run VMs and write data, copy virtual disks,
>move
>virtual disks to other storage domains, etc.
>
>I am very thankful that the storage domain is working again !
>
>How can I safely perform upgrades on Gluster ! When will it be safe to
>do
>so ?
>
>Thank You Again For Your Help !
>
>On Mon, Jun 22, 2020 at 10:58 AM C Williams 
>wrote:
>
>> Strahil,
>>
>> I have downgraded the target. The copy from the problematic volume to
>the
>> target is going on now.
>> Once I have the data copied, I might downgrade the problematic
>volume's
>> Gluster to 6.5.
>> At that point I might reattach the original ovirt domain and see if
>it
>> will work again.
>> But the copy is going on right now.
>>
>> Thank You For Your Help !
>>
>> On Mon, Jun 22, 2020 at 10:52 AM Strahil Nikolov
>
>> wrote:
>>
>>> You should ensure  that in the storage domain tab, the old  storage
>is
>>> not visible.
>>>
>>> I  still wander why yoiu didn't try to downgrade first.
>>>
>>> Best Regards,
>>> Strahil Nikolov
>>>
>>> На 22 юни 2020 г. 13:58:33 GMT+03:00, C Williams
>
>>> написа:
>>> >Strahil,
>>> >
>>> >The GLCL3 storage domain was detached prior to attempting to add
>the
>>> >new
>>> >storage domain.
>>> >
>>> >Should I also "Remove" it ?
>>> >
>>> >Thank You For Your Help !
>>> >
>>> >-- Forwarded message -
>>> >From: Strahil Nikolov 
>>> >Date: Mon, Jun 22, 2020 at 12:50 AM
>>> >Subject: Re: [ovirt-users] Re: Fwd: Fwd: Issues with Gluster Domain
>>> >To: C Williams 
>>> >Cc: users 
>>> >
>>> >
>>> >You can't add the new volume as it contains the same data (UUID) as
>the
>>> >old
>>> >one , thus you need to detach the old one before adding the new one
>-
>>> >of
>>> >course this means downtime for all VMs on that storage.
>>> >
>>> >As you see , downgrading is more simpler. For me v6.5 was working,
>>> >while
>>> >anything above (6.6+) was causing complete lockdown.  Also v7.0 was
>>> >working, but it's supported  in oVirt 4.4.
>>> >
>>> >Best Regards,
>>> >Strahil Nikolov
>>> >
>>> >На 22 юни 2020 г. 7:21:15 GMT+03:00, C Williams
>>> >
>>> >написа:
>>> >>Another question
>>> >>
>>> >>What version could I downgrade to safely ? I am at 6.9 .
>>> >>
>>> >>Thank You For Your Help !!
>>> >>
>>> >>On Sun, Jun 21, 2020 at 11:38 PM Strahil Nikolov
>>> >>
>>> >>wrote:
>>> >>
>>> >>> You are definitely reading it wrong.
>>> >>> 1. I didn't create a new storage  domain ontop this new volume.
>>> >>> 2. I used cli
>>> >>>
>>> >>> Something like this  (in your case it should be 'replica 3'):
>>> >>> gluster volume create newvol replica 3 arbiter 1
>>> >>ovirt1:/new/brick/path
>>> >>> ovirt2:/new/brick/path ovirt3:/new/arbiter/brick/path
>>> >>> gluster volume start newvol
>>> >>>
>>> >>> #Detach oldvol from ovirt
>>> >>>
>>> >>> mount -t glusterfs  ovirt1:/oldvol /mnt/oldvol
>>> >>> mount -t glusterfs ovirt1:/newvol /mnt/newvol
>>> >>> cp -a /mnt/oldvol/* /mnt/newvol
>>> >>>
>>> >>> #Add only newvol as a storage domain in oVirt
>>> >>> #Import VMs
>>> >>>
>>> >>> I still think that you should downgrade your gluster packages!!!
>>> >>>
>>> >>> Best Regards,
>>> >>> Strahil Nikolov
>>> >>>
>>> >>> На 22 юни 2020 г. 0:43:46 GMT+03:00, C Williams
>>> >>
>>> >>> написа:
>>> >>> >Strahil,
>>> >>> >
>>> >>> >It sounds like  you used a "System Managed Volume" for the new
>>> >>storage
>>> >>> >domain,is that correct?
>>> >>> >
>>> >>> >Thank You For Your Help !
>>> >>> >
>>> >>> >On Sun, Jun 21, 2020 at 5:40 PM C Williams
>>> >
>>>

[ovirt-users] Re: Fwd: Re: Fwd: Fwd: Issues with Gluster Domain

[Strahil Nikolov via Users]

As  far as  I know, oVirt 4.4  uses gluster  v7.X , so you will eventually have 
to upgrade the version.

As  I mentioned, I have created my new volume  while I was running a higher  
version and copied the data to it, which prevented  the acl bug hitting me 
again.

I  can recommend you to:
1. Mount the new gluster  volume via FUSE
2. Wipe the data,  as  you don't need it
3. Attach the new gluster volume as  a fresh storage domain in  ovirt
4. Live migrate the VM disks  to the new  volume prior  to upgrading gluster

I cannot guarantee that the issue will be avoided ,  but it's worth trying .

Best Regards,
Strahil Nikolov

На 23 юни 2020 г. 23:42:13 GMT+03:00, C Williams  
написа:
>Strahil,
>
>Thanks for getting back with me !
>
>Sounds like it is best to evacuate VM disks to another storage domain 
>--
>if possible from a Gluster storage domain -- prior to an upgrade .
>
>Per your questions ...
>
>1. Which version of oVirt and Gluster are you using ?
>oVirt 4.3.8.2-1
>Gluster 6.5 , 6.7, 6.9 (depends on the cluster)
>
>2. You now have your old  gluster volume attached  to oVirt and the new
>volume unused, right ?
>Correct -- intending to dispose of data on the new volume since the old
>one is now working
>
>3. Did you copy the contents of the old volume to the new one ?
>I did prior to trying to downgrade the Gluster version on the hosts for
>the old volume. I am planning to delete the data now that the old
>volume is
>working.
>
>Thanks Again For Your Help !!
>
>On Mon, Jun 22, 2020 at 11:34 PM Strahil Nikolov
>
>wrote:
>
>> As  I told you, you could just downgrade gluster on all nodes and
>later
>> plan to live migrate the VM disks.
>> I had to copy my data to the new volume, so I can avoid the ACL bug ,
>when
>> I use newer versions of gluster.
>>
>>
>> Let's clarify some details:
>> 1. Which version of oVirt and Gluster are you using ?
>> 2. You now have your old  gluster volume attached  to oVirt and the
>new
>> volume unused, right ?
>> 3. Did you copy the contents of the old volume to the new one ?
>>
>> Best Regards,
>> Strahil Nikolov
>>
>> На 23 юни 2020 г. 4:34:19 GMT+03:00, C Williams
>
>> написа:
>> >Strahil,
>> >
>> >Thank You For Help !
>> >
>> >Downgrading Gluster to 6.5 got the original storage domain working
>> >again !
>> >
>> >After, I finished my copy of the contents of the problematic volume
>to
>> >a
>> >new volume, I did the following
>> >
>> >Unmounted the mount points
>> >Stopped the original problematic Gluster volume
>> >On each problematic peer,
>> >I downgraded Gluster to 6.5
>> >(yum downgrade glusterfs-6.5-1.el7.x86_64
>> >vdsm-gluster-4.30.46-1.el7.x86_64
>> >python2-gluster-6.5-1.el7.x86_64 glusterfs-libs-6.5-1.el7.x86_64
>> >glusterfs-cli-6.5-1.el7.x86_64 glusterfs-fuse-6.5-1.el7.x86_64
>> >glusterfs-rdma-6.5-1.el7.x86_64 glusterfs-api-6.5-1.el7.x86_64
>> >glusterfs-server-6.5-1.el7.x86_64 glusterfs-events-6.5-1.el7.x86_64
>> >glusterfs-client-xlators-6.5-1.el7.x86_64
>> >glusterfs-geo-replication-6.5-1.el7.x86_64)
>> >Restarted glusterd (systemctl restart glusterd)
>> >Restarted the problematic Gluster  volume
>> >Reattached the problematic storage domain
>> >Started the problematic storage domain
>> >
>> >Things work now. I can now run VMs and write data, copy virtual
>disks,
>> >move
>> >virtual disks to other storage domains, etc.
>> >
>> >I am very thankful that the storage domain is working again !
>> >
>> >How can I safely perform upgrades on Gluster ! When will it be safe
>to
>> >do
>> >so ?
>> >
>> >Thank You Again For Your Help !
>> >
>> >On Mon, Jun 22, 2020 at 10:58 AM C Williams
>
>> >wrote:
>> >
>> >> Strahil,
>> >>
>> >> I have downgraded the target. The copy from the problematic volume
>to
>> >the
>> >> target is going on now.
>> >> Once I have the data copied, I might downgrade the problematic
>> >volume's
>> >> Gluster to 6.5.
>> >> At that point I might reattach the original ovirt domain and see
>if
>> >it
>> >> will work again.
>> >> But the copy is going on right now.
>> >>
>> >> Thank You For Your Help !
>> >>
>> >> On Mon, Jun 22, 2020 at 10:52 AM Strahil Nikolov
>> >
>> >> wrote:
>> >>
>> >>> You should ensure  that in the storage domain tab, the old 
>storage
>> >is
>> >>> not visible.
>> >>>
>> >>> I  still wander why yoiu didn't try to downgrade first.
>> >>>
>> >>> Best Regards,
>> >>> Strahil Nikolov
>> >>>
>> >>> На 22 юни 2020 г. 13:58:33 GMT+03:00, C Williams
>> >
>> >>> написа:
>> >>> >Strahil,
>> >>> >
>> >>> >The GLCL3 storage domain was detached prior to attempting to add
>> >the
>> >>> >new
>> >>> >storage domain.
>> >>> >
>> >>> >Should I also "Remove" it ?
>> >>> >
>> >>> >Thank You For Your Help !
>> >>> >
>> >>> >-- Forwarded message -
>> >>> >From: Strahil Nikolov 
>> >>> >Date: Mon, Jun 22, 2020 at 12:50 AM
>> >>> >Subject: Re: [ovirt-users] Re: Fwd: Fwd: Issues with Gluster
>Domain
>> >>> >To: C Williams 
>> >>> >Cc: users 
>> >>> >
>> >>> >
>> >>> >You can't add the new volume as it contains the same d

[ovirt-users] Re: Clean old mount points in hosts VDSM

[Strahil Nikolov via Users]

Did you reinstall the node via the WEB UI ?

Best Regards,
Strahil  Nikolov

На 25 юни 2020 г. 3:23:15 GMT+03:00, "Vinícius Ferrão via Users" 
 написа:
>Hello,
>
>For reasons unknown one of my hosts is trying to mount an old storage
>point that’s been removed some time ago.
>
>/var/log/vdsm/vdsm.log:2020-06-24 19:57:35,958-0300 INFO 
>(tmap-65016/0) [IOProcessClient] (/192.168.10.6:_mnt_pool0_ovirt_he)
>Starting client (__init__:308)
>/var/log/vdsm/vdsm.log:2020-06-24 19:57:35,968-0300 INFO 
>(ioprocess/12115) [IOProcess] (/192.168.10.6:_mnt_pool0_ovirt_he)
>Starting ioprocess (__init__:434)
>/var/log/vdsm/vdsm.log:2020-06-24 19:57:42,167-0300 INFO  (jsonrpc/6)
>[vdsm.api] START connectStorageServer(domType=1,
>spUUID=u'----',
>conList=[{u'protocol_version': u'auto', u'connection':
>u'192.168.10.6:/mnt/pool0/ovirt/he', u'user': u'kvm', u'id':
>u'e29cf818-5ee5-46e1-85c1-8aeefa33e95d'}], options=None)
>from=::1,59090, task_id=5ea81925-ec92-4031-aa36-bb6f436321d5 (api:48)
>/var/log/vdsm/vdsm.log:2020-06-24 19:57:42,169-0300 INFO  (jsonrpc/6)
>[storage.StorageServer.MountConnection] Creating directory
>u'/rhev/data-center/mnt/192.168.10.6:_mnt_pool0_ovirt_he'
>(storageServer:168)
>/var/log/vdsm/vdsm.log:2020-06-24 19:57:42,169-0300 INFO  (jsonrpc/6)
>[storage.fileUtils] Creating directory:
>/rhev/data-center/mnt/192.168.10.6:_mnt_pool0ovirt_he mode: None
>(fileUtils:199)
>/var/log/vdsm/vdsm.log:2020-06-24 19:57:42,169-0300 INFO  (jsonrpc/6)
>[storage.Mount] mounting 192.168.10.6:/mnt/pool0/ovirt/he at
>/rhev/data-center/mnt/192.168.10.6:_mnt_pool0_ovirt_he (mount:204)
>/var/log/vdsm/vdsm.log:MountError: (32, ';mount.nfs: mounting
>192.168.10.6:/mnt/pool0/ovirt/he failed, reason given by server: No
>such file or directory\n')
>/var/log/vdsm/vdsm.log:2020-06-24 19:57:43,683-0300 INFO  (jsonrpc/5)
>[vdsm.api] START connectStorageServer(domType=1,
>spUUID=u'----',
>conList=[{u'protocol_version': u'auto', u'connection':
>u'192.168.10.6:/mnt/pool0/ovirt/he', u'user': u'kvm', u'id':
>u'e29cf818-5ee5-46e1-85c1-8aeefa33e95d'}], options=None)
>from=::1,59094, task_id=9ce61858-dea1-4059-b942-a52c8c82afdc (api:48)
>/var/log/vdsm/vdsm.log:2020-06-24 19:57:43,685-0300 INFO  (jsonrpc/5)
>[storage.StorageServer.MountConnection] Creating directory
>u'/rhev/data-center/mnt/192.168.10.6:_mnt_pool0_ovirt_he'
>(storageServer:168)
>/var/log/vdsm/vdsm.log:2020-06-24 19:57:43,685-0300 INFO  (jsonrpc/5)
>[storage.fileUtils] Creating directory:
>/rhev/data-center/mnt/192.168.10.6:_mnt_pool0ovirt_he mode: None
>(fileUtils:199)
>/var/log/vdsm/vdsm.log:2020-06-24 19:57:43,685-0300 INFO  (jsonrpc/5)
>[storage.Mount] mounting 192.168.10.6:/mnt/pool0/ovirt/he at
>/rhev/data-center/mnt/192.168.10.6:_mnt_pool0_ovirt_he (mount:204)
>/var/log/vdsm/vdsm.log:MountError: (32, ';mount.nfs: mounting
>192.168.10.6:/mnt/pool0/ovirt/he failed, reason given by server: No
>such file or directory\n’)
>
>This only happens in one host and it’s spamming /var/log/vdsm/vdsm.log.
>
>Any ideia on how to debug this and remove the entry?
>
>Thanks,
>
>___
>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/DS2ZIZVAXJVLPR6BFSZU63TU7KJWTZVA/
___
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/HVPSXS7SLNRFPEY7RPY7DAZ3UFBTDERP/

[ovirt-users] Re: How to suspend a stateless VM

[Strahil Nikolov via Users]

What is the status of the host?
Usially a VM is staless  ,  because  the engine cannot reach the VDSM on the 
Hypervisour.

Best Regards,
Strahil Nikolov

На 26 юни 2020 г. 22:23:15 GMT+03:00, pas...@butterflyit.com написа:
>Currently from the ovirt web interface it is not possible to suspend a
>stateless VM. However I have a need for it for example when I want to
>free idle VM (or migrate them to a different cluster) and still not
>lose the current status of the VM.
>
>Thanks
>___
>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/MP64LJLUCSJMW7KMDKEFISCTMOT6YC4W/
___
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/T7Y3YZON4XDBH6DNLTFLXABMLCWCL35T/

[ovirt-users] Re: update and engine-setup

[Strahil Nikolov via Users]

What  repos do you have  enabled  ?
It  seems you have  a  repo conflict.

Best Regards,
Strahil  Nikolov

На 26 юни 2020 г. 18:30:31 GMT+03:00, eev...@digitaldatatechs.com написа:
>I do not have a self hosted engine and did yum update whech update
>these files:
>Updated:
>  microcode_ctl.x86_64 2:2.1-61.10.el7_8
>  ovirt-engine-appliance.x86_64 0:4.3-20200625.1.el7
>ovirt-engine-extensions-api-impl.noarch
>0:4.3.11.1-0.0.master.20200625131236.git33fd414.el7
>ovirt-engine-extensions-api-impl-javadoc.noarch
>0:4.3.11.1-0.0.master.20200625131236.git33fd414.el7
>ovirt-engine-health-check-bundler.noarch
>0:4.3.11.1-0.0.master.20200625131236.git33fd414.el7
>ovirt-engine-setup.noarch
>0:4.3.11.1-0.0.master.20200625131236.git33fd414.el7
>ovirt-engine-setup-base.noarch
>0:4.3.11.1-0.0.master.20200625131236.git33fd414.el7
>ovirt-engine-setup-plugin-cinderlib.noarch
>0:4.3.11.1-0.0.master.20200625131236.git33fd414.el7
>ovirt-engine-setup-plugin-ovirt-engine.noarch
>0:4.3.11.1-0.0.master.20200625131236.git33fd414.el7
>ovirt-engine-setup-plugin-ovirt-engine-common.noarch
>0:4.3.11.1-0.0.master.20200625131236.git33fd414.el7
>ovirt-engine-setup-plugin-vmconsole-proxy-helper.noarch
>0:4.3.11.1-0.0.master.20200625131236.git33fd414.el7
>ovirt-engine-setup-plugin-websocket-proxy.noarch
>0:4.3.11.1-0.0.master.20200625131236.git33fd414.el7
>  ovirt-engine-ui-extensions.noarch 0:1.0.13-1.20200303git3b594b8.el7
>ovirt-engine-vmconsole-proxy-helper.noarch
>0:4.3.11.1-0.0.master.20200625131236.git33fd414.el7
>ovirt-engine-websocket-proxy.noarch
>0:4.3.11.1-0.0.master.20200625131236.git33fd414.el7
>ovirt-node-ng-image-update.noarch
>0:4.3.11-0.1.rc1.20200625025312.git243a031.el7
>  ovirt-release43.noarch 0:4.3.11-0.1.rc1.20200626025335.git243a031.el7
>ovirt-release43-snapshot.noarch
>0:4.3.11-0.1.rc1.20200626025335.git243a031.el7
>ovirt-release43-tested.noarch
>0:4.3.11-0.1.rc1.20200626025335.git243a031.el7
>python2-ovirt-engine-lib.noarch
>0:4.3.11.1-0.0.master.20200625131236.git33fd414.el7
>  python2-tracer.noarch 0:0.7.4-1.el7
>  tracer-common.noarch 0:0.7.4-1.el7
>
>It statedI needed to run engine-setup but is failed with these
>messages:
>
>engine-setup
>[ INFO  ] Stage: Initializing
>[ INFO  ] Stage: Environment setup
>Configuration files:
>['/etc/ovirt-engine-setup.conf.d/10-packaging-jboss.conf',
>'/etc/ovirt-engine-setup.conf.d/10-packaging.conf',
>'/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf']
>Log file:
>/var/log/ovirt-engine/setup/ovirt-engine-setup-20200626111946-5y1tda.log
>Version: otopi-1.8.5_master
>(otopi-1.8.5-0.0.master.20191017094324.git500b7f5.el7)
>[ INFO  ] Stage: Environment packages setup
>[ INFO  ] Stage: Programs detection
>[ INFO  ] Stage: Environment setup (late)
>[ INFO  ] Stage: Environment customization
>
>  --== PRODUCT OPTIONS ==--
>
>[ INFO  ] ovirt-provider-ovn already installed, skipping.
>
>  --== PACKAGES ==--
>
>[ INFO  ] Checking for product updates...
>[ ERROR ] Yum ['ovirt-engine conflicts with
>ovirt-engine-ui-extensions-1.0.13-1.20200303git3b594b8.el7.noarch']
>[ INFO  ] Yum Performing yum transaction rollback
>[ ERROR ] Failed to execute stage 'Environment customization':
>['ovirt-engine conflicts with
>ovirt-engine-ui-extensions-1.0.13-1.20200303git3b594b8.el7.noarch']
>[ INFO  ] Stage: Clean up
>Log file is located at
>/var/log/ovirt-engine/setup/ovirt-engine-setup-20200626111946-5y1tda.log
>[ INFO  ] Generating answer file
>'/var/lib/ovirt-engine/setup/answers/20200626112010-setup.conf'
>[ INFO  ] Stage: Pre-termination
>[ INFO  ] Stage: Termination
>[ ERROR ] Execution of setup failed
>
>I ran engine-setup --offline and it completed successfully. I'm not
>sure what the issue is with the UI extensions but it's been an issue
>for a while failing migrations, etc. Each time I update, I have to
>downgrade the UI-extensions as stated in a  previous post.
>
>I thought the developers should know about this so it can be addressed.
>___
>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/KZI3JAAQ3EAARANVIZBDXENCMI4DGHRN/
___
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/V42MPZWV3TJ3ZFBGSSY6V6MHP36WS62P/

[ovirt-users] Re: Does a slow Web proxy (can't run the update-check) ruin HA scores? (Solved, ...but really?)

[Strahil Nikolov via Users]

Most probably the hosts's ICMP echo requests to the gateway get lost. This 
leads  to enough penalty, so your engine is moved away from the host.

Which 'penalty' did you disable  to stabilize your environment ?

Best Regards,
Strahil Nikolov

На 27 юни 2020 г. 18:19:58 GMT+03:00, tho...@hoberg.net написа:
>Running a couple of oVirt clusters on left-over hardware in an R&D
>niche of the data center. Lots of switches/proxies still at 100Mbit and
>just checking for updates via 'yum update' can take awhile, even time
>out 2 times of out 3.
>
>The network between the nodes is 10Gbit though, faster than any other
>part of the hardware, including some SSDs and RAIDs: Cluster
>communication should be excellent, even if everything goes through a
>single port.
>
>After moving some servers to a new IP range, where there are even more
>hops to the proxy, I am shocked to see the three HCI nodes in one
>cluster almost permanently report bad HA scores, which of course
>becomes a real issue, when it hits all three. The entire cluster really
>starts to 'wobble'
>
>Trying to find the reason for that bad score and there is nothing
>obvious: Machines have been running just fine, very light loads, no
>downtimes, reboots etc.
>
>But looking at the events recorded on hosts, something like "Failed to
>check for available updates on host  with message 'Failed to run
>check-update of host ''. Error: null'." does come up pretty
>often. Moreover, when I then have all three servers run the update
>check on the GUI, I can find myself locked-out of the oVirt GUI and
>once I get back in, all non-active HostedEngine hosts are suddenly back
>in the 'low HS score' state.
>
>So I have this inkling impression, that the ability (or not) to run the
>update check is counting into the HA score, which ... IMHO would be
>quite mad. It would have production clusters go haywire, just because
>an external internet connection is interrupted...
>
>Any feedback on this?
>
>P.S.
>Only minutes later, after noticing the ha-scores reported by
>hosted-engine --vm-status were really in the low 2000s range overall, I
>did a quick Google and found this:
>
>ovirt-ha-agent - host score
>penaltieshttps://github.com/oVirt/ovirt-hosted-engine-ha/blob/master/ovirt_hosted_engine_ha/agent/agent.conf[score]#
>
>
>NOTE: These values must be the same for all hosts in the HA 
>cluster!base-score=3400
>gateway-score-penalty=1600
>not-uptodate-config-penalty=1000 //not 'knowing if there are updates'
>is not the same as 'knowing it missing critical patches'
>mgmt-bridge-score-penalty=600
>free-memory-score-penalty=400
>cpu-load-score-penalty=1000
>engine-retry-score-penalty=50
>cpu-load-penalty-min=0.4
>cpu-load-penalty-max=0.9
>
>So now I know how to fix it for me, but I'd consider this pretty much a
>bug: When the update check fails, that implies really only that the
>update check could not go through. It doesn't mean the cluster is
>fundamentally unhealthy.
>
>Now I understand how that negative feedback is next to impossible
>inside RedHat's network, where update servers are local.
>
>But having a cluster HA score being based on something 'just now
>happening' on the other far edges of the Internet... seems a very bad
>design decision.
>
>Please comment and/or tell me how and where I should file this as a
>bug.
>___
>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/ACY3NEU6NYM6ZJE3X2M3Y7PGY6QVOH6U/
___
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/SLXYKNCB4GLTBIEDCT4ZM2T3FBJQNIJO/

[ovirt-users] Re: Migration of self Hosted Engine from iSCSI to Gluster/NFS

[Strahil Nikolov via Users]

As you will migrate from block-based storage to file-based storage, I think 
that you should use the  backup & restore procedure.

Best Regards,
Strahil Nikolov

На 25 юни 2020 г. 7:31:55 GMT+03:00, Erez Zarum  написа:
>I was looking for a “complete” best practice to migrate a self-hosted
>engine running currently on an iSCSI LUN to a Gluster of NFS storage
>domain
>oVirt version 4.3.10
>
>Thanks!
___
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/T2RCLHYRXFLMHIH7VTNWWLU5OSH2IOJH/

[ovirt-users] Re: VDSM can't see StoragePool

[Strahil Nikolov via Users]

Can you set one of the Hypervisours into maintenance and use the "reinstall" 
option  from the UI ?

Best Regards,
Strahil Nikolov

На 25 юни 2020 г. 13:24:26 GMT+03:00, Erez Zarum  написа:
>I have a Self-hosted Engine running on iSCSI as well as couple of
>Storage domains using iSCSI, both the SE and those Storage Domains uses
>the same target portals (two).
>I can see the iSCSI sessions and multipath working well from the Host
>point of view.
>Yesterday after doing a restart for the “ovirt-engine” all the hosts
>besides the one that runs the SE and the SPM went into “Unassigned”
>mode with an error stating the ovirt-engine can’t communicate with the
>hosts.
>Network wise, everything is good, I can reach all the ports, all the
>network is well configured, so I ruled this.
>Looking at the VDSM logs on those “Unassigned” hosts it looks like the
>VDSM can’t find the Storage Pool.
>
>(vmrecovery) [vdsm.api] START
>getConnectedStoragePoolsList(options=None) from=internal,
>task_id=217ec32b-591c-4376-8dc0-8d62200557ee (api:48)
>(vmrecovery) [vdsm.api] FINISH getConnectedStoragePoolsList
>return={'poollist': []} from=internal,
>task_id=217ec32b-591c-4376-8dc0-8d62200557ee (api:54)
>(vmrecovery) [vds] recovery: waiting for storage pool to go up
>(clientIF:723)
>
>If I look at the VDSM logs on the host where the SE and SPM is running,
>no issues there and the node appears up (green) in the ovirt-engine UI.
>
>I managed to set the hosted-engine to maintenance, shut it down and
>then start it again on another Host, when it starts on that Host, the
>host goes “green” and if the SPM stays on the previous host, I have two
>hosts working and the rest remains “Unassigned”.
>
>All the “ovirt-ha-agent”/”ovirt-ha-broker” services seems ok, I
>restarted them, I also tried to restart the VDSM on the hosts with no
>luck.
>I have the VMs still running, I did shutdown one host (even used the
>“SSH restart” from the WebUI) to see if that helps, it came back and
>still went into “Unassigned”.
>
>It seems like the hosts can’t see the Storage pool.
>
>Where should I start to troubleshoot this?
>
>Thanks
___
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/UG23X42MKLAW6JYG23IQ757RS5OQ2R7G/

[ovirt-users] Re: Ovirt 4.3.10 Glusterfs SSD slow performance over 10GE

[Strahil Nikolov via Users]

Hello ,

Let me ask some questions:
1. What is the scheduler for your PV ?
2. Have you aligned your PV during the setup 'pvcreate --dataalignment 
alignment_value device'
3. What is your tuned profile ? Do you use rhgs-random-io from the 
ftp://ftp.redhat.com/redhat/linux/enterprise/7Server/en/RHS/SRPMS/redhat-storage-server-3.5.0.0-6.el7rhgs.src.rpm
 ?
4. What is the output of "xfs_info /path/to/your/gluster/brick" ?
5. Are you using Jumbo Frames ? Does your infra support them?
Usually MTU of 9k is standard, but some switches and NICs support up to 16k.

All the options for "optimize for virt" are located at 
/var/lib/glusterd/groups/virt on each gluster node.

Best Regards,
Strahil Nikolov




В неделя, 28 юни 2020 г., 22:13:09 Гринуич+3, jury cat  
написа: 





Hello all,

I am using Ovirt 4.3.10 on Centos 7.8 with glusterfs 6.9 .
My Gluster setup is of 3 hosts in replica 3 (2 hosts + 1 arbiter).
All the 3 hosts are Dell R720  with Perc Raid Controller H710 mini(that has 
maximim throughtout 6Gbs)  and  with 2×1TB samsumg SSD in RAID 0. The volume is 
partitioned using LVM thin provision and formated XFS.
The hosts have separate 10GE network cards for storage traffic.
The Gluster Network is connected to this 10GE network cards and is mounted 
using Fuse Glusterfs(NFS is disabled).Also Migration Network is activated on 
the same storage network.

 
The problem is that the 10GE network is not used at full potential by the 
Gluster.
If i do live Migration of Vms i can see speeds of 7GB/s ~ 9GB/s.
The same network tests using iperf3 reported 9.9GB/s ,  these exluding the 
network setup as a bottleneck(i will not paste all the iperf3 tests here for 
now).
I did not enable all the Volume options  from "Optimize for Virt Store", 
because of the bug that cant set volume  cluster.granural-heal to enable(this 
was fixed in vdsm-4
40, but that is working only on Centos 8 with ovirt 4.4 ) .
i whould be happy to know what are all these "Optimize for Virt Store" options, 
so i can set them manually.


The speed on the disk inside the host using dd is b etween 1GB/s to 700Mbs.


[root@host1 ~]# dd if=/dev/zero of=test bs=100M count=40 cou nt=80 
status=progress 8074035200 bytes (8.1 GB) copied, 11.059372 s, 730 MB/s 80+0 
records in 80+0 records out 8388608000 bytes (8.4 GB) copied, 11.9928 s, 699 
MB/s


The dd  write test on the gluster volme inside the host is poor only  ~ 120MB/s 
.
During the dd test, if i look at Networks->Gluster network ->Hosts at Tx and Rx 
the network speed barerly reaches over  1Gbs  (~1073 Mbs) out of maximum of 
1 Mbs. 


 dd if=/dev/zero of=/rhev/data-center/mnt/glu sterSD/gluster1.domain.local\: 
_data/test bs=100M count=80 status=progress 8283750400 bytes (8.3 GB) copied, 
71.297942 s, 116 MB/s 80+0 records in 80+0 records out 8388608000 bytes (8.4 
GB) copied, 71.9545 s, 117 MB/s


I have attached  my Gluster volume settings and mount options.

Thanks,
Emy


___
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/7BR6TZQ4EXS4SIEHTZN2WJUMBYZHP5GJ/
___
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/C6PCFUC5JXVWTN353FZPZF3BZQP35MY5/