[ovirt-users] Re: OvirtEngine Fails (any ideas?)

2021-03-15 Thread Strahil Nikolov via Users 
You have to verify the NFS share's ownership (user +group) and 
permissions.Usually, alot of users set 'anonuid' & 'anongid' to 36 and then use 
allsquash (check the man for exact spelling) to force all clients to be using 
36:36 .
Best Regards,Strahil Nikolov
 
 
  On Mon, Mar 15, 2021 at 22:43, Jason Alexander Hazen 
Valliant-Saunders 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/5IJTQIKCMO5XXDX5W4FE2OSQKMZ6TOY4/
  
___
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/3GOHANQUBII3BVHADL2YBXSWMEGNLJM5/

[ovirt-users] Re: OvirtEngine Fails (any ideas?)

2021-03-15 Thread Jason Alexander Hazen Valliant-Saunders 
Found it;

Default route was set to the NFS / SAN Network Gateway, not the Actual
gateway.

Now I seem to be hitting this bug:
[ ERROR ] Verify permission settings on the specified storage path.]". HTTP
response code is 400.
[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "Fault
reason is \"Operation Failed\". Fault detail is \"[Permission settings on
the specified path do not allow access to the storage.\nVerify permission
settings on the specified storage path.]\". HTTP response code is 400."}

However I can mount it manually just fine in the node.

e.g. NFS mount works and I can edit / touch manipulate files.

On Mon, Mar 15, 2021 at 4:25 PM Nir Soffer  wrote:

> On Mon, Mar 15, 2021 at 10:15 PM Nir Soffer  wrote:
>
>> On Mon, Mar 15, 2021 at 7:17 PM Jason Alexander Hazen Valliant-Saunders <
>> haze...@altignus.com> wrote:
>>
>>>
>>>   Loaded: loaded (/usr/lib/systemd/system/ovirt-imageio.service;
>>> disabled; vendor preset: disabled)
>>>Active: activating (start) since Mon 2021-03-15 13:06:24 EDT; 3ms ago
>>>  Main PID: 57738 ((-imageio))
>>> Tasks: 0 (limit: 616123)
>>>Memory: 0B
>>>CGroup: /system.slice/ovirt-imageio.service
>>>└─57738 (-imageio)
>>> tail
>>> ==> /var/log/ovirt-imageio/daemon.log <==
>>> self.remote_service = services.RemoteService(self.config, self.auth)
>>>   File
>>> "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/services.py",
>>> line 79, in __init__
>>> self._secure_server()
>>>   File
>>> "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/services.py",
>>> line 102, in _secure_server
>>> enable_tls1_1=self._config.tls.enable_tls1_1)
>>>   File
>>> "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/ssl.py", line
>>> 16, in server_context
>>> purpose=ssl.Purpose.CLIENT_AUTH, cafile=cafile)
>>>   File "/usr/lib64/python3.6/ssl.py", line 468, in create_default_context
>>> context.load_verify_locations(cafile, capath, cadata)
>>> FileNotFoundError: [Errno 2] No such file or directory
>>>
>>
>> This means that cafile does not exist.
>>
>> What do you see in /var/log/ovirt-imageio/daemon.log?
>>
>> Can you share the content of /etc/ovirt-imageio/ ?
>>
>> tar czf etc-ovirt-imageio.tar.gz /etc/ovirt-imageio
>>
>> Did you change engine certificates? Maybe you forgot to update imageio
>> configuration after the change?
>>
>> Note that you should not change /etc/ovirt-imageio/conf.d/50-engine.conf.
>> This file belongs to engine and will be replaced when updating engine.
>>
>> If you need to change configuration add you own file like:
>> /etc/ovirt-imageio/conf.d/99-local.conf
>>
>
> For reference, this is the default configuration taken from engine 4.4.5:
>
> # ovirt-imageio --show-config | jq .tls
> {
>   "ca_file": "/etc/pki/ovirt-engine/apache-ca.pem",
>   "cert_file": "/etc/pki/ovirt-engine/certs/apache.cer",
>   "enable": true,
>   "enable_tls1_1": false,
>   "key_file": "/etc/pki/ovirt-engine/keys/apache.key.nopass"
> }
>
> Nir
>>
>>
>>> Heres the error when set to started / Enabled.
>>> ovirt-imageio.service: Start request repeated too quickly.
>>> CODE_FILE ../src/core/unit.c
>>> CODE_FUNC unit_start_limit_test
>>> CODE_LINE 1669
>>> INVOCATION_ID 7d226e2e792c473c9d34725ec4b625ce
>>> PRIORITY 4
>>> SYSLOG_FACILITY 3
>>> SYSLOG_IDENTIFIER systemd
>>> UNIT ovirt-imageio.service
>>> _BOOT_ID 4bd6b8dcfcc04655bb96228bbc07e371
>>> _CAP_EFFECTIVE 3f
>>> _CMDLINE /usr/lib/systemd/systemd --switched-root --system
>>> --deserialize 17
>>> _COMM systemd
>>> _EXE /usr/lib/systemd/systemd
>>> _GID 0
>>> _HOSTNAME ovirt1.altignus.com
>>> _MACHINE_ID 0d2ee365ebc64b03982bae07fe190e25
>>> _PID 1
>>> _SELINUX_CONTEXT system_u:system_r:init_t:s0
>>> _SOURCE_REALTIME_TIMESTAMP 1615828262063499
>>> _SYSTEMD_CGROUP /init.scope
>>> _SYSTEMD_SLICE -.slice
>>> _SYSTEMD_UNIT init.scope
>>> _TRANSPORT journal
>>> _UID 0
>>> __CURSOR
>>> s=896394b4edaf41349024e42366d9e760;i=69e5;b=4bd6b8dcfcc04655bb96228bbc07e371;m=66f373e9;t=5bd9655940e25;x=94ca32742879524f
>>> __MONOTONIC_TIMESTAMP 1727230953
>>> __REALTIME_TIMESTAMP 1615828262063653Mar 15 13:06:24 ovirt1.altignus.com
>>> systemd[1]: Starting oVirt ImageIO Daemon...
>>>
>>> On Mon, Mar 15, 2021 at 1:06 PM Derek Atkins  wrote:
>>>
 I'm sure more knowledgeable people will reply, but from me:
 what does "systemctl status -l ovirt-imageio" give you?
 It should give a bit more log data about the failure.

 Is there any log data about the startup?  Anything in
 /var/log/ovirt-imageio-daemon/daemon.log?  Anything happen if you try to
 start it manually?

 -derek


 On Mon, March 15, 2021 12:56 pm, Jason Alexander Hazen Valliant-Saunders
 wrote:
 > Failed to start oVirt ImageIO Daemon.
 > CODE_FILE ../src/core/job.c
 > CODE_FUNC job_log_done_status_message
 > CODE_LINE 933
 > INVOCATION_ID 4c19d99e2caf48a39b4d3c79b290c214
 > JOB_RESULT failed
 > JOB_TYPE start
 >

[ovirt-users] Re: OvirtEngine Fails (any ideas?)

2021-03-15 Thread Nir Soffer 
On Mon, Mar 15, 2021 at 10:15 PM Nir Soffer  wrote:

> On Mon, Mar 15, 2021 at 7:17 PM Jason Alexander Hazen Valliant-Saunders <
> haze...@altignus.com> wrote:
>
>>
>>   Loaded: loaded (/usr/lib/systemd/system/ovirt-imageio.service;
>> disabled; vendor preset: disabled)
>>Active: activating (start) since Mon 2021-03-15 13:06:24 EDT; 3ms ago
>>  Main PID: 57738 ((-imageio))
>> Tasks: 0 (limit: 616123)
>>Memory: 0B
>>CGroup: /system.slice/ovirt-imageio.service
>>└─57738 (-imageio)
>> tail
>> ==> /var/log/ovirt-imageio/daemon.log <==
>> self.remote_service = services.RemoteService(self.config, self.auth)
>>   File
>> "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/services.py",
>> line 79, in __init__
>> self._secure_server()
>>   File
>> "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/services.py",
>> line 102, in _secure_server
>> enable_tls1_1=self._config.tls.enable_tls1_1)
>>   File
>> "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/ssl.py", line
>> 16, in server_context
>> purpose=ssl.Purpose.CLIENT_AUTH, cafile=cafile)
>>   File "/usr/lib64/python3.6/ssl.py", line 468, in create_default_context
>> context.load_verify_locations(cafile, capath, cadata)
>> FileNotFoundError: [Errno 2] No such file or directory
>>
>
> This means that cafile does not exist.
>
> What do you see in /var/log/ovirt-imageio/daemon.log?
>
> Can you share the content of /etc/ovirt-imageio/ ?
>
> tar czf etc-ovirt-imageio.tar.gz /etc/ovirt-imageio
>
> Did you change engine certificates? Maybe you forgot to update imageio
> configuration after the change?
>
> Note that you should not change /etc/ovirt-imageio/conf.d/50-engine.conf.
> This file belongs to engine and will be replaced when updating engine.
>
> If you need to change configuration add you own file like:
> /etc/ovirt-imageio/conf.d/99-local.conf
>

For reference, this is the default configuration taken from engine 4.4.5:

# ovirt-imageio --show-config | jq .tls
{
  "ca_file": "/etc/pki/ovirt-engine/apache-ca.pem",
  "cert_file": "/etc/pki/ovirt-engine/certs/apache.cer",
  "enable": true,
  "enable_tls1_1": false,
  "key_file": "/etc/pki/ovirt-engine/keys/apache.key.nopass"
}

Nir
>
>
>> Heres the error when set to started / Enabled.
>> ovirt-imageio.service: Start request repeated too quickly.
>> CODE_FILE ../src/core/unit.c
>> CODE_FUNC unit_start_limit_test
>> CODE_LINE 1669
>> INVOCATION_ID 7d226e2e792c473c9d34725ec4b625ce
>> PRIORITY 4
>> SYSLOG_FACILITY 3
>> SYSLOG_IDENTIFIER systemd
>> UNIT ovirt-imageio.service
>> _BOOT_ID 4bd6b8dcfcc04655bb96228bbc07e371
>> _CAP_EFFECTIVE 3f
>> _CMDLINE /usr/lib/systemd/systemd --switched-root --system --deserialize
>> 17
>> _COMM systemd
>> _EXE /usr/lib/systemd/systemd
>> _GID 0
>> _HOSTNAME ovirt1.altignus.com
>> _MACHINE_ID 0d2ee365ebc64b03982bae07fe190e25
>> _PID 1
>> _SELINUX_CONTEXT system_u:system_r:init_t:s0
>> _SOURCE_REALTIME_TIMESTAMP 1615828262063499
>> _SYSTEMD_CGROUP /init.scope
>> _SYSTEMD_SLICE -.slice
>> _SYSTEMD_UNIT init.scope
>> _TRANSPORT journal
>> _UID 0
>> __CURSOR
>> s=896394b4edaf41349024e42366d9e760;i=69e5;b=4bd6b8dcfcc04655bb96228bbc07e371;m=66f373e9;t=5bd9655940e25;x=94ca32742879524f
>> __MONOTONIC_TIMESTAMP 1727230953
>> __REALTIME_TIMESTAMP 1615828262063653Mar 15 13:06:24 ovirt1.altignus.com
>> systemd[1]: Starting oVirt ImageIO Daemon...
>>
>> On Mon, Mar 15, 2021 at 1:06 PM Derek Atkins  wrote:
>>
>>> I'm sure more knowledgeable people will reply, but from me:
>>> what does "systemctl status -l ovirt-imageio" give you?
>>> It should give a bit more log data about the failure.
>>>
>>> Is there any log data about the startup?  Anything in
>>> /var/log/ovirt-imageio-daemon/daemon.log?  Anything happen if you try to
>>> start it manually?
>>>
>>> -derek
>>>
>>>
>>> On Mon, March 15, 2021 12:56 pm, Jason Alexander Hazen Valliant-Saunders
>>> wrote:
>>> > Failed to start oVirt ImageIO Daemon.
>>> > CODE_FILE ../src/core/job.c
>>> > CODE_FUNC job_log_done_status_message
>>> > CODE_LINE 933
>>> > INVOCATION_ID 4c19d99e2caf48a39b4d3c79b290c214
>>> > JOB_RESULT failed
>>> > JOB_TYPE start
>>> > MESSAGE_ID be02cf6855d2428ba40df7e9d022f03d
>>> > PRIORITY 3
>>> > SYSLOG_FACILITY 3
>>> > SYSLOG_IDENTIFIER systemd
>>> > UNIT ovirt-imageio.service
>>> > _BOOT_ID 4bd6b8dcfcc04655bb96228bbc07e371
>>> > _CAP_EFFECTIVE 3f
>>> > _CMDLINE /usr/lib/systemd/systemd --switched-root --system
>>> --deserialize
>>> > 17
>>> > _COMM systemd
>>> > _EXE /usr/lib/systemd/systemd
>>> > _GID 0
>>> > _HOSTNAME ovirt1.altignus.com
>>> > _MACHINE_ID 0d2ee365ebc64b03982bae07fe190e25
>>> > _PID 1
>>> > _SELINUX_CONTEXT system_u:system_r:init_t:s0
>>> > _SOURCE_REALTIME_TIMESTAMP 1615827351504037
>>> > _SYSTEMD_CGROUP /init.scope
>>> > _SYSTEMD_SLICE -.slice
>>> > _SYSTEMD_UNIT init.scope
>>> > _TRANSPORT journal
>>> > _UID 0
>>> > __CURSOR
>>> >
>>>

[ovirt-users] Re: OvirtEngine Fails (any ideas?)

2021-03-15 Thread Nir Soffer 
On Mon, Mar 15, 2021 at 7:17 PM Jason Alexander Hazen Valliant-Saunders <
haze...@altignus.com> wrote:

>
>   Loaded: loaded (/usr/lib/systemd/system/ovirt-imageio.service; disabled;
> vendor preset: disabled)
>Active: activating (start) since Mon 2021-03-15 13:06:24 EDT; 3ms ago
>  Main PID: 57738 ((-imageio))
> Tasks: 0 (limit: 616123)
>Memory: 0B
>CGroup: /system.slice/ovirt-imageio.service
>└─57738 (-imageio)
> tail
> ==> /var/log/ovirt-imageio/daemon.log <==
> self.remote_service = services.RemoteService(self.config, self.auth)
>   File
> "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/services.py",
> line 79, in __init__
> self._secure_server()
>   File
> "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/services.py",
> line 102, in _secure_server
> enable_tls1_1=self._config.tls.enable_tls1_1)
>   File
> "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/ssl.py", line
> 16, in server_context
> purpose=ssl.Purpose.CLIENT_AUTH, cafile=cafile)
>   File "/usr/lib64/python3.6/ssl.py", line 468, in create_default_context
> context.load_verify_locations(cafile, capath, cadata)
> FileNotFoundError: [Errno 2] No such file or directory
>

This means that cafile does not exist.

What do you see in /var/log/ovirt-imageio/daemon.log?

Can you share the content of /etc/ovirt-imageio/ ?

tar czf etc-ovirt-imageio.tar.gz /etc/ovirt-imageio

Did you change engine certificates? Maybe you forgot to update imageio
configuration after the change?

Note that you should not change /etc/ovirt-imageio/conf.d/50-engine.conf.
This file belongs to engine and will be replaced when updating engine.

If you need to change configuration add you own file like:
/etc/ovirt-imageio/conf.d/99-local.conf

Nir


> Heres the error when set to started / Enabled.
> ovirt-imageio.service: Start request repeated too quickly.
> CODE_FILE ../src/core/unit.c
> CODE_FUNC unit_start_limit_test
> CODE_LINE 1669
> INVOCATION_ID 7d226e2e792c473c9d34725ec4b625ce
> PRIORITY 4
> SYSLOG_FACILITY 3
> SYSLOG_IDENTIFIER systemd
> UNIT ovirt-imageio.service
> _BOOT_ID 4bd6b8dcfcc04655bb96228bbc07e371
> _CAP_EFFECTIVE 3f
> _CMDLINE /usr/lib/systemd/systemd --switched-root --system --deserialize
> 17
> _COMM systemd
> _EXE /usr/lib/systemd/systemd
> _GID 0
> _HOSTNAME ovirt1.altignus.com
> _MACHINE_ID 0d2ee365ebc64b03982bae07fe190e25
> _PID 1
> _SELINUX_CONTEXT system_u:system_r:init_t:s0
> _SOURCE_REALTIME_TIMESTAMP 1615828262063499
> _SYSTEMD_CGROUP /init.scope
> _SYSTEMD_SLICE -.slice
> _SYSTEMD_UNIT init.scope
> _TRANSPORT journal
> _UID 0
> __CURSOR
> s=896394b4edaf41349024e42366d9e760;i=69e5;b=4bd6b8dcfcc04655bb96228bbc07e371;m=66f373e9;t=5bd9655940e25;x=94ca32742879524f
> __MONOTONIC_TIMESTAMP 1727230953
> __REALTIME_TIMESTAMP 1615828262063653Mar 15 13:06:24 ovirt1.altignus.com
> systemd[1]: Starting oVirt ImageIO Daemon...
>
> On Mon, Mar 15, 2021 at 1:06 PM Derek Atkins  wrote:
>
>> I'm sure more knowledgeable people will reply, but from me:
>> what does "systemctl status -l ovirt-imageio" give you?
>> It should give a bit more log data about the failure.
>>
>> Is there any log data about the startup?  Anything in
>> /var/log/ovirt-imageio-daemon/daemon.log?  Anything happen if you try to
>> start it manually?
>>
>> -derek
>>
>>
>> On Mon, March 15, 2021 12:56 pm, Jason Alexander Hazen Valliant-Saunders
>> wrote:
>> > Failed to start oVirt ImageIO Daemon.
>> > CODE_FILE ../src/core/job.c
>> > CODE_FUNC job_log_done_status_message
>> > CODE_LINE 933
>> > INVOCATION_ID 4c19d99e2caf48a39b4d3c79b290c214
>> > JOB_RESULT failed
>> > JOB_TYPE start
>> > MESSAGE_ID be02cf6855d2428ba40df7e9d022f03d
>> > PRIORITY 3
>> > SYSLOG_FACILITY 3
>> > SYSLOG_IDENTIFIER systemd
>> > UNIT ovirt-imageio.service
>> > _BOOT_ID 4bd6b8dcfcc04655bb96228bbc07e371
>> > _CAP_EFFECTIVE 3f
>> > _CMDLINE /usr/lib/systemd/systemd --switched-root --system --deserialize
>> > 17
>> > _COMM systemd
>> > _EXE /usr/lib/systemd/systemd
>> > _GID 0
>> > _HOSTNAME ovirt1.altignus.com
>> > _MACHINE_ID 0d2ee365ebc64b03982bae07fe190e25
>> > _PID 1
>> > _SELINUX_CONTEXT system_u:system_r:init_t:s0
>> > _SOURCE_REALTIME_TIMESTAMP 1615827351504037
>> > _SYSTEMD_CGROUP /init.scope
>> > _SYSTEMD_SLICE -.slice
>> > _SYSTEMD_UNIT init.scope
>> > _TRANSPORT journal
>> > _UID 0
>> > __CURSOR
>> >
>> s=896394b4edaf41349024e42366d9e760;i=3393;b=4bd6b8dcfcc04655bb96228bbc07e371;m=30ad6a7e;t=5bd961f4e04b9;x=b3fe6e1de39c7ab8
>> > __MONOTONIC_TIMESTAMP 816671358
>> > __REALTIME_TIMESTAMP 1615827351504057
>> > ___
>> > 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:
>> >
>>

[ovirt-users] Re: Reset NVRAM

2021-03-15 Thread Tomáš Golembiovský 
On Mon, Mar 15, 2021 at 04:12:51PM +, Shantur Rathore wrote:
> Thanks Tomáš,
> 
> Actually I hit "Send" too quickly. Are you experiencing the issue after
> > VM reboot or even after shutdown? Because NVRAM is kept between reboots
> > and is removed only after VM shutdown.
> 
> 
> It happens after shutdown and reboot. The VM just goes into a weird state
> with "Guest hasn't initialised the display (yet)" error.
> If I create another VM with the same configuration and use the same boot
> disk it works fine.
> 
> So, if it's not NVRAM, I am not sure what could it be which stays with VM
> but is not a disk.

Maybe something in domain XML. You can compare the domain XML of VM that
does not boot any longer with your newly created VM.

One way or another, you'll have to provide more information regarding
the steps that lead to the unbootable VM before we can provide any
usefull hints.

Tomas


> 
> Thanks,
> shantur
> 
> On Mon, Mar 15, 2021 at 3:47 PM Tomáš Golembiovský 
> wrote:
> 
> > On Mon, Mar 15, 2021 at 04:43:20PM +0100, Tomáš Golembiovský wrote:
> > > On Mon, Mar 15, 2021 at 01:13:10PM +, Shantur Rathore wrote:
> > > > Hi all,
> > > >
> > > > I am doing some testing with GPU passthrough to VMs and in some cases
> > the
> > > > OVMF stops booting after a GPU passthrough.
> > > > I have figured out that it's related to some state stored in NVRAM by
> > OVMF
> > > > and as soon as I create another VM with the same disks it starts
> > booting up.
> > > >
> > > > I believe oVirt saves the NVRAM state.
> > >
> > > No it isn't. Or, better said, it wasn't. Storing of NVRAM is a new
> > > feature in 4.4.5 and it will be enabled only for VMs with Secure Boot.
> > >
> > > So whatever you're experiencing is probably caused by something else.
> >
> > Actually I hit "Send" too quickly. Are you experiencing the issue after
> > VM reboot or even after shutdown? Because NVRAM is kept between reboots
> > and is removed only after VM shutdown.
> >
> > Tomas
> >
> > >
> > > >  Is there a way to clear NVRAM for a VM without deleting it?
> > >
> > > This is not part of the feature introduced in 4.4.5. But it would make
> > > sense to have it if we later extend the NVRAM storing to all VMs with
> > > UEFI. So despite what I wrote above it would be worth opening a feature
> > > request bug.
> > >
> > > Tomas
> > >
> > > >
> > > > Regards,
> > > > Shantur
> > >
> > > > ___
> > > > 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/GJ4AQHJ6SIAT7ML526SSO7IKRTY2BHCQ/
> > >
> > >
> > > --
> > > Tomáš Golembiovský 
> >
> > --
> > Tomáš Golembiovský 
> >
> >

-- 
Tomáš Golembiovský 
___
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/47KRWMTCNDHZ3V6SGMHMIQ5NZYN7QHZR/

[ovirt-users] Re: OvirtEngine Fails (any ideas?)

2021-03-15 Thread Jason Alexander Hazen Valliant-Saunders 
  Loaded: loaded (/usr/lib/systemd/system/ovirt-imageio.service; disabled;
vendor preset: disabled)
   Active: activating (start) since Mon 2021-03-15 13:06:24 EDT; 3ms ago
 Main PID: 57738 ((-imageio))
Tasks: 0 (limit: 616123)
   Memory: 0B
   CGroup: /system.slice/ovirt-imageio.service
   └─57738 (-imageio)
tail
==> /var/log/ovirt-imageio/daemon.log <==
self.remote_service = services.RemoteService(self.config, self.auth)
  File
"/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/services.py",
line 79, in __init__
self._secure_server()
  File
"/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/services.py",
line 102, in _secure_server
enable_tls1_1=self._config.tls.enable_tls1_1)
  File "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/ssl.py",
line 16, in server_context
purpose=ssl.Purpose.CLIENT_AUTH, cafile=cafile)
  File "/usr/lib64/python3.6/ssl.py", line 468, in create_default_context
context.load_verify_locations(cafile, capath, cadata)
FileNotFoundError: [Errno 2] No such file or directory

Heres the error when set to started / Enabled.
ovirt-imageio.service: Start request repeated too quickly.
CODE_FILE ../src/core/unit.c
CODE_FUNC unit_start_limit_test
CODE_LINE 1669
INVOCATION_ID 7d226e2e792c473c9d34725ec4b625ce
PRIORITY 4
SYSLOG_FACILITY 3
SYSLOG_IDENTIFIER systemd
UNIT ovirt-imageio.service
_BOOT_ID 4bd6b8dcfcc04655bb96228bbc07e371
_CAP_EFFECTIVE 3f
_CMDLINE /usr/lib/systemd/systemd --switched-root --system --deserialize 17
_COMM systemd
_EXE /usr/lib/systemd/systemd
_GID 0
_HOSTNAME ovirt1.altignus.com
_MACHINE_ID 0d2ee365ebc64b03982bae07fe190e25
_PID 1
_SELINUX_CONTEXT system_u:system_r:init_t:s0
_SOURCE_REALTIME_TIMESTAMP 1615828262063499
_SYSTEMD_CGROUP /init.scope
_SYSTEMD_SLICE -.slice
_SYSTEMD_UNIT init.scope
_TRANSPORT journal
_UID 0
__CURSOR
s=896394b4edaf41349024e42366d9e760;i=69e5;b=4bd6b8dcfcc04655bb96228bbc07e371;m=66f373e9;t=5bd9655940e25;x=94ca32742879524f
__MONOTONIC_TIMESTAMP 1727230953
__REALTIME_TIMESTAMP 1615828262063653Mar 15 13:06:24 ovirt1.altignus.com
systemd[1]: Starting oVirt ImageIO Daemon...

On Mon, Mar 15, 2021 at 1:06 PM Derek Atkins  wrote:

> I'm sure more knowledgeable people will reply, but from me:
> what does "systemctl status -l ovirt-imageio" give you?
> It should give a bit more log data about the failure.
>
> Is there any log data about the startup?  Anything in
> /var/log/ovirt-imageio-daemon/daemon.log?  Anything happen if you try to
> start it manually?
>
> -derek
>
>
> On Mon, March 15, 2021 12:56 pm, Jason Alexander Hazen Valliant-Saunders
> wrote:
> > Failed to start oVirt ImageIO Daemon.
> > CODE_FILE ../src/core/job.c
> > CODE_FUNC job_log_done_status_message
> > CODE_LINE 933
> > INVOCATION_ID 4c19d99e2caf48a39b4d3c79b290c214
> > JOB_RESULT failed
> > JOB_TYPE start
> > MESSAGE_ID be02cf6855d2428ba40df7e9d022f03d
> > PRIORITY 3
> > SYSLOG_FACILITY 3
> > SYSLOG_IDENTIFIER systemd
> > UNIT ovirt-imageio.service
> > _BOOT_ID 4bd6b8dcfcc04655bb96228bbc07e371
> > _CAP_EFFECTIVE 3f
> > _CMDLINE /usr/lib/systemd/systemd --switched-root --system --deserialize
> > 17
> > _COMM systemd
> > _EXE /usr/lib/systemd/systemd
> > _GID 0
> > _HOSTNAME ovirt1.altignus.com
> > _MACHINE_ID 0d2ee365ebc64b03982bae07fe190e25
> > _PID 1
> > _SELINUX_CONTEXT system_u:system_r:init_t:s0
> > _SOURCE_REALTIME_TIMESTAMP 1615827351504037
> > _SYSTEMD_CGROUP /init.scope
> > _SYSTEMD_SLICE -.slice
> > _SYSTEMD_UNIT init.scope
> > _TRANSPORT journal
> > _UID 0
> > __CURSOR
> >
> s=896394b4edaf41349024e42366d9e760;i=3393;b=4bd6b8dcfcc04655bb96228bbc07e371;m=30ad6a7e;t=5bd961f4e04b9;x=b3fe6e1de39c7ab8
> > __MONOTONIC_TIMESTAMP 816671358
> > __REALTIME_TIMESTAMP 1615827351504057
> > ___
> > 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/DNB73ZMUB5DIMV7UK74MTFYTE7SGZ5J7/
> >
>
>
> --
>Derek Atkins 617-623-3745
>de...@ihtfp.com www.ihtfp.com
>Computer and Internet Security Consultant
>
>
___
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/Y7HDZVJUVLNXD4PLVX7PADTHPYPB5DG4/

[ovirt-users] Re: OvirtEngine Fails (any ideas?)

2021-03-15 Thread Derek Atkins 
I'm sure more knowledgeable people will reply, but from me:
what does "systemctl status -l ovirt-imageio" give you?
It should give a bit more log data about the failure.

Is there any log data about the startup?  Anything in
/var/log/ovirt-imageio-daemon/daemon.log?  Anything happen if you try to
start it manually?

-derek


On Mon, March 15, 2021 12:56 pm, Jason Alexander Hazen Valliant-Saunders
wrote:
> Failed to start oVirt ImageIO Daemon.
> CODE_FILE ../src/core/job.c
> CODE_FUNC job_log_done_status_message
> CODE_LINE 933
> INVOCATION_ID 4c19d99e2caf48a39b4d3c79b290c214
> JOB_RESULT failed
> JOB_TYPE start
> MESSAGE_ID be02cf6855d2428ba40df7e9d022f03d
> PRIORITY 3
> SYSLOG_FACILITY 3
> SYSLOG_IDENTIFIER systemd
> UNIT ovirt-imageio.service
> _BOOT_ID 4bd6b8dcfcc04655bb96228bbc07e371
> _CAP_EFFECTIVE 3f
> _CMDLINE /usr/lib/systemd/systemd --switched-root --system --deserialize
> 17
> _COMM systemd
> _EXE /usr/lib/systemd/systemd
> _GID 0
> _HOSTNAME ovirt1.altignus.com
> _MACHINE_ID 0d2ee365ebc64b03982bae07fe190e25
> _PID 1
> _SELINUX_CONTEXT system_u:system_r:init_t:s0
> _SOURCE_REALTIME_TIMESTAMP 1615827351504037
> _SYSTEMD_CGROUP /init.scope
> _SYSTEMD_SLICE -.slice
> _SYSTEMD_UNIT init.scope
> _TRANSPORT journal
> _UID 0
> __CURSOR
> s=896394b4edaf41349024e42366d9e760;i=3393;b=4bd6b8dcfcc04655bb96228bbc07e371;m=30ad6a7e;t=5bd961f4e04b9;x=b3fe6e1de39c7ab8
> __MONOTONIC_TIMESTAMP 816671358
> __REALTIME_TIMESTAMP 1615827351504057
> ___
> 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/DNB73ZMUB5DIMV7UK74MTFYTE7SGZ5J7/
>


-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant
___
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/HX4TCAOLFIDKVCVPSXMH2CHBU6JLNX3Z/

[ovirt-users] OvirtEngine Fails (any ideas?)

2021-03-15 Thread Jason Alexander Hazen Valliant-Saunders 
Failed to start oVirt ImageIO Daemon.
CODE_FILE ../src/core/job.c
CODE_FUNC job_log_done_status_message
CODE_LINE 933
INVOCATION_ID 4c19d99e2caf48a39b4d3c79b290c214
JOB_RESULT failed
JOB_TYPE start
MESSAGE_ID be02cf6855d2428ba40df7e9d022f03d
PRIORITY 3
SYSLOG_FACILITY 3
SYSLOG_IDENTIFIER systemd
UNIT ovirt-imageio.service
_BOOT_ID 4bd6b8dcfcc04655bb96228bbc07e371
_CAP_EFFECTIVE 3f
_CMDLINE /usr/lib/systemd/systemd --switched-root --system --deserialize 17
_COMM systemd
_EXE /usr/lib/systemd/systemd
_GID 0
_HOSTNAME ovirt1.altignus.com
_MACHINE_ID 0d2ee365ebc64b03982bae07fe190e25
_PID 1
_SELINUX_CONTEXT system_u:system_r:init_t:s0
_SOURCE_REALTIME_TIMESTAMP 1615827351504037
_SYSTEMD_CGROUP /init.scope
_SYSTEMD_SLICE -.slice
_SYSTEMD_UNIT init.scope
_TRANSPORT journal
_UID 0
__CURSOR
s=896394b4edaf41349024e42366d9e760;i=3393;b=4bd6b8dcfcc04655bb96228bbc07e371;m=30ad6a7e;t=5bd961f4e04b9;x=b3fe6e1de39c7ab8
__MONOTONIC_TIMESTAMP 816671358
__REALTIME_TIMESTAMP 1615827351504057
___
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/DNB73ZMUB5DIMV7UK74MTFYTE7SGZ5J7/

[ovirt-users] Re: Reset NVRAM

2021-03-15 Thread Shantur Rathore 
Thanks Tomáš,

Actually I hit "Send" too quickly. Are you experiencing the issue after
> VM reboot or even after shutdown? Because NVRAM is kept between reboots
> and is removed only after VM shutdown.


It happens after shutdown and reboot. The VM just goes into a weird state
with "Guest hasn't initialised the display (yet)" error.
If I create another VM with the same configuration and use the same boot
disk it works fine.

So, if it's not NVRAM, I am not sure what could it be which stays with VM
but is not a disk.

Thanks,
shantur

On Mon, Mar 15, 2021 at 3:47 PM Tomáš Golembiovský 
wrote:

> On Mon, Mar 15, 2021 at 04:43:20PM +0100, Tomáš Golembiovský wrote:
> > On Mon, Mar 15, 2021 at 01:13:10PM +, Shantur Rathore wrote:
> > > Hi all,
> > >
> > > I am doing some testing with GPU passthrough to VMs and in some cases
> the
> > > OVMF stops booting after a GPU passthrough.
> > > I have figured out that it's related to some state stored in NVRAM by
> OVMF
> > > and as soon as I create another VM with the same disks it starts
> booting up.
> > >
> > > I believe oVirt saves the NVRAM state.
> >
> > No it isn't. Or, better said, it wasn't. Storing of NVRAM is a new
> > feature in 4.4.5 and it will be enabled only for VMs with Secure Boot.
> >
> > So whatever you're experiencing is probably caused by something else.
>
> Actually I hit "Send" too quickly. Are you experiencing the issue after
> VM reboot or even after shutdown? Because NVRAM is kept between reboots
> and is removed only after VM shutdown.
>
> Tomas
>
> >
> > >  Is there a way to clear NVRAM for a VM without deleting it?
> >
> > This is not part of the feature introduced in 4.4.5. But it would make
> > sense to have it if we later extend the NVRAM storing to all VMs with
> > UEFI. So despite what I wrote above it would be worth opening a feature
> > request bug.
> >
> > Tomas
> >
> > >
> > > Regards,
> > > Shantur
> >
> > > ___
> > > 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/GJ4AQHJ6SIAT7ML526SSO7IKRTY2BHCQ/
> >
> >
> > --
> > Tomáš Golembiovský 
>
> --
> Tomáš Golembiovský 
>
>
___
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/ODXSQZ3EUAK75MA2OPHDIMTOMKNJJKGJ/

[ovirt-users] Re: Reset NVRAM

2021-03-15 Thread Tomáš Golembiovský 
On Mon, Mar 15, 2021 at 04:43:20PM +0100, Tomáš Golembiovský wrote:
> On Mon, Mar 15, 2021 at 01:13:10PM +, Shantur Rathore wrote:
> > Hi all,
> > 
> > I am doing some testing with GPU passthrough to VMs and in some cases the
> > OVMF stops booting after a GPU passthrough.
> > I have figured out that it's related to some state stored in NVRAM by OVMF
> > and as soon as I create another VM with the same disks it starts booting up.
> > 
> > I believe oVirt saves the NVRAM state.
> 
> No it isn't. Or, better said, it wasn't. Storing of NVRAM is a new
> feature in 4.4.5 and it will be enabled only for VMs with Secure Boot.
> 
> So whatever you're experiencing is probably caused by something else.

Actually I hit "Send" too quickly. Are you experiencing the issue after
VM reboot or even after shutdown? Because NVRAM is kept between reboots
and is removed only after VM shutdown.

Tomas

> 
> >  Is there a way to clear NVRAM for a VM without deleting it?
> 
> This is not part of the feature introduced in 4.4.5. But it would make
> sense to have it if we later extend the NVRAM storing to all VMs with
> UEFI. So despite what I wrote above it would be worth opening a feature
> request bug.
> 
> Tomas
> 
> > 
> > Regards,
> > Shantur
> 
> > ___
> > 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/GJ4AQHJ6SIAT7ML526SSO7IKRTY2BHCQ/
> 
> 
> -- 
> Tomáš Golembiovský 

-- 
Tomáš Golembiovský 
___
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/CM6IJQI5LIVH6OPTWTRPKXITODFYCQUH/

[ovirt-users] Re: Reset NVRAM

2021-03-15 Thread Tomáš Golembiovský 
On Mon, Mar 15, 2021 at 01:13:10PM +, Shantur Rathore wrote:
> Hi all,
> 
> I am doing some testing with GPU passthrough to VMs and in some cases the
> OVMF stops booting after a GPU passthrough.
> I have figured out that it's related to some state stored in NVRAM by OVMF
> and as soon as I create another VM with the same disks it starts booting up.
> 
> I believe oVirt saves the NVRAM state.

No it isn't. Or, better said, it wasn't. Storing of NVRAM is a new
feature in 4.4.5 and it will be enabled only for VMs with Secure Boot.

So whatever you're experiencing is probably caused by something else.

>  Is there a way to clear NVRAM for a VM without deleting it?

This is not part of the feature introduced in 4.4.5. But it would make
sense to have it if we later extend the NVRAM storing to all VMs with
UEFI. So despite what I wrote above it would be worth opening a feature
request bug.

Tomas

> 
> Regards,
> Shantur

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


-- 
Tomáš Golembiovský 
___
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/ZL6MWWUCU3IOCXYLXZI2YGTR26GH66OS/

[ovirt-users] Re: Upgrade from 4.3.5 to 4.3.10 HE Host issue

2021-03-15 Thread Marko Vrgotic 
No problem,

Just wanted to make sure they all arrived, as I was getting some strange errors.
Anyway, if needed, I will send it again.

-
kind regards/met vriendelijke groeten

Marko Vrgotic
Sr. System Engineer @ System Administration

ActiveVideo
o: +31 (35) 6774131
m: +31 (65) 5734174
e: m.vrgo...@activevideo.com
w: www.activevideo.com

ActiveVideo Networks BV. Mediacentrum 3745 Joop van den Endeplein 1.1217 WJ 
Hilversum, The Netherlands. The information contained in this message may be 
legally privileged and confidential. It is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any distribution of this message, in any form, is strictly prohibited.  If you 
have received this message in error, please immediately notify the sender 
and/or ActiveVideo Networks, LLC by telephone at +1 408.931.9200 and delete or 
destroy any copy of this message.



From: Yedidyah Bar David 
Date: Monday, 15 March 2021 at 10:56
To: Marko Vrgotic 
Cc: users@ovirt.org 
Subject: Re: [ovirt-users] Re: Upgrade from 4.3.5 to 4.3.10 HE Host issue
***CAUTION: This email originated from outside of the organization. Do not 
click links or open attachments unless you recognize the sender!!!***

On Mon, Mar 15, 2021 at 11:24 AM Marko Vrgotic
 wrote:
>
> Hi Didi,
>
>
>
> Have you received all logs I sent? I did send all requested. Just wondering 
> if you were able to find something.

I did saw that you sent them, but was a bit busy, and didn't yet have
a look at them. Hope to update soon.

Best regards,

>
>
>
> -
>
> kind regards/met vriendelijke groeten
>
>
>
> Marko Vrgotic
> Sr. System Engineer @ System Administration
>
>
> ActiveVideo
>
> o: +31 (35) 6774131
>
> m: +31 (65) 5734174
>
> e: m.vrgo...@activevideo.com
> w: 
> https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.activevideo.com%2Fdata=04%7C01%7Cm.vrgotic%40activevideo.com%7Cbb920c84c04f49bb9ef608d8e79895e7%7C214268a3e1214486acd4545c9faf2252%7C0%7C0%7C637513989830726333%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=9zno8%2BSG1BUi9YWYOqBegyVt13OGO9H0TfI1OKqnwD0%3Dreserved=0
>
>
>
> ActiveVideo Networks BV. Mediacentrum 3745 Joop van den Endeplein 1.1217 WJ 
> Hilversum, The Netherlands. The information contained in this message may be 
> legally privileged and confidential. It is intended to be read only by the 
> individual or entity to whom it is addressed or by their designee. If the 
> reader of this message is not the intended recipient, you are on notice that 
> any distribution of this message, in any form, is strictly prohibited.  If 
> you have received this message in error, please immediately notify the sender 
> and/or ActiveVideo Networks, LLC by telephone at +1 408.931.9200 and delete 
> or destroy any copy of this message.
>
>
>
>
>
>
>
> From: Marko Vrgotic 
> Date: Monday, 8 March 2021 at 15:55
> To: Yedidyah Bar David 
> Cc: users@ovirt.org 
> Subject: Re: [ovirt-users] Re: Upgrade from 4.3.5 to 4.3.10 HE Host issue
>
> The broker log, these lines are pretty much repeating:
>
>
>
> MainThread::WARNING::2021-03-03 
> 09:19:12,086::storage_broker::97::ovirt_hosted_engine_ha.broker.storage_broker.StorageBroker::(__init__)
>  Can't connect vdsm storage: 'metadata_image_UUID can't be 'None'
>
> MainThread::INFO::2021-03-03 
> 09:19:12,829::broker::47::ovirt_hosted_engine_ha.broker.broker.Broker::(run) 
> ovirt-hosted-engine-ha broker 2.3.6 started
>
> MainThread::INFO::2021-03-03 
> 09:19:12,829::monitor::40::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
>  Searching for submonitors in 
> /usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/sub
>
> monitors
>
> MainThread::INFO::2021-03-03 
> 09:19:12,829::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
>  Loaded submonitor cpu-load
>
> MainThread::INFO::2021-03-03 
> 09:19:12,832::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
>  Loaded submonitor cpu-load-no-engine
>
> MainThread::INFO::2021-03-03 
> 09:19:12,832::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
>  Loaded submonitor engine-health
>
> MainThread::INFO::2021-03-03 
> 09:19:12,832::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
>  Loaded submonitor mem-free
>
> MainThread::INFO::2021-03-03 
> 09:19:12,833::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
>  Loaded submonitor mgmt-bridge
>
> MainThread::INFO::2021-03-03 
> 09:19:12,833::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
>  Loaded submonitor network
>
> MainThread::INFO::2021-03-03 
>

[ovirt-users] Reset NVRAM

2021-03-15 Thread Shantur Rathore 
Hi all,

I am doing some testing with GPU passthrough to VMs and in some cases the
OVMF stops booting after a GPU passthrough.
I have figured out that it's related to some state stored in NVRAM by OVMF
and as soon as I create another VM with the same disks it starts booting up.

I believe oVirt saves the NVRAM state.
 Is there a way to clear NVRAM for a VM without deleting it?

Regards,
Shantur
___
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/GJ4AQHJ6SIAT7ML526SSO7IKRTY2BHCQ/

[ovirt-users] Re: 4.4.5 Release timeline

2021-03-15 Thread Sandro Bonazzola 
Il giorno ven 12 mar 2021 alle ore 14:22 David White via Users <
users@ovirt.org> ha scritto:

> Hello,
> Reviewing https://ovirt.org/release/4.4.5/, I see that the target release
> date was set to March 9. However, glancing at
> https://bugzilla.redhat.com/buglist.cgi?quicksearch=ALL%20target_milestone%3A%22ovirt-4.4.5%22%20-target_milestone%3A%22ovirt-4.4.5-%22,
> I see a number of outstanding open tickets.
>
> Do the maintainers anticipate that 4.4.5 will be released soon? I'm trying
> to decide if I should wait for 4.4.5 to be released, or if I should go with
> 4.4.4, as I am getting ready to do a fresh install for a 3-node
> hyperconverged cluster, and need to begin setting up VMs and configuring
> things very soon.
>

We had an ovirt-engine respin at last minute last week, we are testing the
latest compose right now and hopefully we'll promote it to GA this week.
There are no outstanding blockers and the remaining bugs currently targeted
to 4.4.5 and not marked as blockers are going to be re-planned.



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


-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R 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/STPI5KNTAMZMN4O5YIW3C5KYI4KV6V3X/

[ovirt-users] RHV is allocating more space than it should

2021-03-15 Thread Łukasz Kołaciński 
Hello,
I have a question about restoring virtual machines. Why is ovirt/rhv allocating 
~10% more space than it should. For example, we have a 10 GB disk, and after 
restore the size is 11 GB. This only happens with a SPARSE disk type on ISCSI 
storage. Is it a normal behavior?


Regards,

Łukasz Kołaciński

Junior Java Developer

e-mail: l.kolacin...@storware.eu





[STORWARE]

ul. Leszno 8/44
01-192 Warszawa
www.storware.eu 

[facebook]

[twitter]

[linkedin]

[Storware_Stopka_09]



Storware Spółka z o.o. nr wpisu do ewidencji KRS dla M.St. Warszawa 000510131 , 
NIP 5213672602. Wiadomość ta jest przeznaczona jedynie dla osoby lub podmiotu, 
który jest jej adresatem i może zawierać poufne i/lub uprzywilejowane 
informacje. Zakazane jest jakiekolwiek przeglądanie, przesyłanie, 
rozpowszechnianie lub inne wykorzystanie tych informacji lub podjęcie 
jakichkolwiek działań odnośnie tych informacji przez osoby lub podmioty inne 
niż zamierzony adresat. Jeżeli Państwo otrzymali przez pomyłkę tę informację 
prosimy o poinformowanie o tym nadawcy i usunięcie tej wiadomości z wszelkich 
komputerów. This message is intended only for the person or entity to which it 
is addressed and may contain confidential and/or privileged material. Any 
review, retransmission, dissemination or other use of, or taking of any action 
in reliance upon, this information by persons or entities other than the 
intended recipient is prohibited. If you have received this message in error, 
please contact the sender and remove the material from all of your computer 
systems.

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

[ovirt-users] Re: Upgrade from 4.3.5 to 4.3.10 HE Host issue

2021-03-15 Thread Yedidyah Bar David 
On Mon, Mar 15, 2021 at 11:24 AM Marko Vrgotic
 wrote:
>
> Hi Didi,
>
>
>
> Have you received all logs I sent? I did send all requested. Just wondering 
> if you were able to find something.

I did saw that you sent them, but was a bit busy, and didn't yet have
a look at them. Hope to update soon.

Best regards,

>
>
>
> -
>
> kind regards/met vriendelijke groeten
>
>
>
> Marko Vrgotic
> Sr. System Engineer @ System Administration
>
>
> ActiveVideo
>
> o: +31 (35) 6774131
>
> m: +31 (65) 5734174
>
> e: m.vrgo...@activevideo.com
> w: www.activevideo.com
>
>
>
> ActiveVideo Networks BV. Mediacentrum 3745 Joop van den Endeplein 1.1217 WJ 
> Hilversum, The Netherlands. The information contained in this message may be 
> legally privileged and confidential. It is intended to be read only by the 
> individual or entity to whom it is addressed or by their designee. If the 
> reader of this message is not the intended recipient, you are on notice that 
> any distribution of this message, in any form, is strictly prohibited.  If 
> you have received this message in error, please immediately notify the sender 
> and/or ActiveVideo Networks, LLC by telephone at +1 408.931.9200 and delete 
> or destroy any copy of this message.
>
>
>
>
>
>
>
> From: Marko Vrgotic 
> Date: Monday, 8 March 2021 at 15:55
> To: Yedidyah Bar David 
> Cc: users@ovirt.org 
> Subject: Re: [ovirt-users] Re: Upgrade from 4.3.5 to 4.3.10 HE Host issue
>
> The broker log, these lines are pretty much repeating:
>
>
>
> MainThread::WARNING::2021-03-03 
> 09:19:12,086::storage_broker::97::ovirt_hosted_engine_ha.broker.storage_broker.StorageBroker::(__init__)
>  Can't connect vdsm storage: 'metadata_image_UUID can't be 'None'
>
> MainThread::INFO::2021-03-03 
> 09:19:12,829::broker::47::ovirt_hosted_engine_ha.broker.broker.Broker::(run) 
> ovirt-hosted-engine-ha broker 2.3.6 started
>
> MainThread::INFO::2021-03-03 
> 09:19:12,829::monitor::40::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
>  Searching for submonitors in 
> /usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/sub
>
> monitors
>
> MainThread::INFO::2021-03-03 
> 09:19:12,829::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
>  Loaded submonitor cpu-load
>
> MainThread::INFO::2021-03-03 
> 09:19:12,832::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
>  Loaded submonitor cpu-load-no-engine
>
> MainThread::INFO::2021-03-03 
> 09:19:12,832::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
>  Loaded submonitor engine-health
>
> MainThread::INFO::2021-03-03 
> 09:19:12,832::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
>  Loaded submonitor mem-free
>
> MainThread::INFO::2021-03-03 
> 09:19:12,833::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
>  Loaded submonitor mgmt-bridge
>
> MainThread::INFO::2021-03-03 
> 09:19:12,833::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
>  Loaded submonitor network
>
> MainThread::INFO::2021-03-03 
> 09:19:12,833::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
>  Loaded submonitor storage-domain
>
> MainThread::INFO::2021-03-03 
> 09:19:12,833::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
>  Loaded submonitor cpu-load
>
> MainThread::INFO::2021-03-03 
> 09:19:12,834::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
>  Loaded submonitor cpu-load-no-engine
>
> MainThread::INFO::2021-03-03 
> 09:19:12,835::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
>  Loaded submonitor engine-health
>
> MainThread::INFO::2021-03-03 
> 09:19:12,835::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
>  Loaded submonitor mem-free
>
> MainThread::INFO::2021-03-03 
> 09:19:12,835::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
>  Loaded submonitor mgmt-bridge
>
> MainThread::INFO::2021-03-03 
> 09:19:12,835::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
>  Loaded submonitor network
>
> MainThread::INFO::2021-03-03 
> 09:19:12,836::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
>  Loaded submonitor storage-domain
>
> MainThread::INFO::2021-03-03 
> 09:19:12,836::monitor::50::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
>  Finished loading submonitors
>
> MainThread::WARNING::2021-03-03 
> 09:19:12,836::storage_broker::97::ovirt_hosted_engine_ha.broker.storage_broker.StorageBroker::(__init__)
>  Can't connect vdsm storage: 'metadata_image_UUID can't be 'None'
>
> MainThread::INFO::2021-03-03 
> 09:19:13,574::broker::47::ovirt_hosted_engine_ha.broker.broker.Broker::(run) 
> ovirt-hosted-engine-ha broker 2.3.6

[ovirt-users] Re: Upgrade from 4.3.5 to 4.3.10 HE Host issue

2021-03-15 Thread Marko Vrgotic 
Hi Didi,

Have you received all logs I sent? I did send all requested. Just wondering if 
you were able to find something.

-
kind regards/met vriendelijke groeten

Marko Vrgotic
Sr. System Engineer @ System Administration

ActiveVideo
o: +31 (35) 6774131
m: +31 (65) 5734174
e: m.vrgo...@activevideo.com
w: www.activevideo.com

ActiveVideo Networks BV. Mediacentrum 3745 Joop van den Endeplein 1.1217 WJ 
Hilversum, The Netherlands. The information contained in this message may be 
legally privileged and confidential. It is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any distribution of this message, in any form, is strictly prohibited.  If you 
have received this message in error, please immediately notify the sender 
and/or ActiveVideo Networks, LLC by telephone at +1 408.931.9200 and delete or 
destroy any copy of this message.



From: Marko Vrgotic 
Date: Monday, 8 March 2021 at 15:55
To: Yedidyah Bar David 
Cc: users@ovirt.org 
Subject: Re: [ovirt-users] Re: Upgrade from 4.3.5 to 4.3.10 HE Host issue
The broker log, these lines are pretty much repeating:

MainThread::WARNING::2021-03-03 
09:19:12,086::storage_broker::97::ovirt_hosted_engine_ha.broker.storage_broker.StorageBroker::(__init__)
 Can't connect vdsm storage: 'metadata_image_UUID can't be 'None'
MainThread::INFO::2021-03-03 
09:19:12,829::broker::47::ovirt_hosted_engine_ha.broker.broker.Broker::(run) 
ovirt-hosted-engine-ha broker 2.3.6 started
MainThread::INFO::2021-03-03 
09:19:12,829::monitor::40::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
 Searching for submonitors in 
/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/sub
monitors
MainThread::INFO::2021-03-03 
09:19:12,829::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
 Loaded submonitor cpu-load
MainThread::INFO::2021-03-03 
09:19:12,832::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
 Loaded submonitor cpu-load-no-engine
MainThread::INFO::2021-03-03 
09:19:12,832::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
 Loaded submonitor engine-health
MainThread::INFO::2021-03-03 
09:19:12,832::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
 Loaded submonitor mem-free
MainThread::INFO::2021-03-03 
09:19:12,833::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
 Loaded submonitor mgmt-bridge
MainThread::INFO::2021-03-03 
09:19:12,833::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
 Loaded submonitor network
MainThread::INFO::2021-03-03 
09:19:12,833::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
 Loaded submonitor storage-domain
MainThread::INFO::2021-03-03 
09:19:12,833::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
 Loaded submonitor cpu-load
MainThread::INFO::2021-03-03 
09:19:12,834::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
 Loaded submonitor cpu-load-no-engine
MainThread::INFO::2021-03-03 
09:19:12,835::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
 Loaded submonitor engine-health
MainThread::INFO::2021-03-03 
09:19:12,835::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
 Loaded submonitor mem-free
MainThread::INFO::2021-03-03 
09:19:12,835::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
 Loaded submonitor mgmt-bridge
MainThread::INFO::2021-03-03 
09:19:12,835::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
 Loaded submonitor network
MainThread::INFO::2021-03-03 
09:19:12,836::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
 Loaded submonitor storage-domain
MainThread::INFO::2021-03-03 
09:19:12,836::monitor::50::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
 Finished loading submonitors
MainThread::WARNING::2021-03-03 
09:19:12,836::storage_broker::97::ovirt_hosted_engine_ha.broker.storage_broker.StorageBroker::(__init__)
 Can't connect vdsm storage: 'metadata_image_UUID can't be 'None'
MainThread::INFO::2021-03-03 
09:19:13,574::broker::47::ovirt_hosted_engine_ha.broker.broker.Broker::(run) 
ovirt-hosted-engine-ha broker 2.3.6 started
MainThread::INFO::2021-03-03 
09:19:13,575::monitor::40::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
 Searching for submonitors in 
/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/submonitors
MainThread::INFO::2021-03-03 
09:19:13,575::monitor::49::ovirt_hosted_engine_ha.broker.monitor.Monitor::(_discover_submonitors)
 Loaded submonitor

[ovirt-users] doubt about CentOS 8.3 hypervisor and ansible version

2021-03-15 Thread Gianluca Cecchi 
Hello,
I have a CentOS 8.3 + updates host in a 4.4.4 environment.
The web admin gui shows that it needs to upgrade to some packages.
The check event in web admin gui says:
Check for available updates on host ov300 was completed successfully with
message 'nss.x86_64, grub2-tools-efi.x86_64, bind-utils.x86_64,
dracut-network.x86_64, libvirt-daemon-driver-qemu.x86_64,
qemu-kvm-common.x86_64, libvirt-daemon-driver-storage-scsi.x86_64,
libvirt-daemon-driver-nodedev.x86_64, nss-sysinit.x86_64,
grub2-tools-minimal.x86_64 and 74 others. To see all packages check
engine.log.'.

If I go to engine in file ovirt-host-mgmt-ansible-check-.log I get:

  "yum_result" :
"bind-export-libs.x86_64\nbind-libs.x86_64\nbind-libs-lite.x86_64\nbind-lic
ense.noarch\nbind-utils.x86_64\nbpftool.x86_64\nbuildah.x86_64\ncockpit-podman.noarch\nconmon.x86_64
\ncontainer-selinux.noarch\ncontainernetworking-plugins.x86_64\ncontainers-common.x86_64\ncriu.x86_6
4\ndbxtool.x86_64\ndracut.x86_64\ndracut-config-rescue.x86_64\ndracut-network.x86_64\ndracut-squash.
x86_64\nfuse-overlayfs.x86_64\ngrub2-common.noarch\ngrub2-efi-x64.x86_64\ngrub2-tools.x86_64\ngrub2-
tools-extra.x86_64\ngrub2-tools-minimal.x86_64\nkernel.x86_64\nkernel-core.x86_64\nkernel-modules.x8
6_64\nkernel-tools.x86_64\nkernel-tools-libs.x86_64\nkmod-megaraid_sas.x86_64\nlibtpms.x86_64\nlibvi
rt-admin.x86_64\nlibvirt-bash-completion.x86_64\nlibvirt-client.x86_64\nlibvirt-daemon.x86_64\nlibvi
rt-daemon-config-network.x86_64\nlibvirt-daemon-config-nwfilter.x86_64\nlibvirt-daemon-driver-interf
ace.x86_64\nlibvirt-daemon-driver-network.x86_64\nlibvirt-daemon-driver-nodedev.x86_64\nlibvirt-daem
on-driver-nwfilter.x86_64\nlibvirt-daemon-driver-qemu.x86_64\nlibvirt-daemon-driver-secret.x86_64\nl
ibvirt-daemon-driver-storage.x86_64\nlibvirt-daemon-driver-storage-core.x86_64\nlibvirt-daemon-drive
r-storage-disk.x86_64\nlibvirt-daemon-driver-storage-gluster.x86_64\nlibvirt-daemon-driver-storage-i
scsi.x86_64\nlibvirt-daemon-driver-storage-iscsi-direct.x86_64\nlibvirt-daemon-driver-storage-logica
l.x86_64\nlibvirt-daemon-driver-storage-mpath.x86_64\nlibvirt-daemon-driver-storage-rbd.x86_64\nlibv
irt-daemon-driver-storage-scsi.x86_64\nlibvirt-daemon-kvm.x86_64\nlibvirt-libs.x86_64\nlibvirt-lock-
sanlock.x86_64\nmicrocode_ctl.x86_64\nnss.x86_64\nnss-softokn.x86_64\nnss-softokn-freebl.x86_64\nnss
-sysinit.x86_64\nnss-tools.x86_64\nnss-util.x86_64\npodman.x86_64\npodman-catatonit.x86_64\npython3-
bind.noarch\npython3-libvirt.x86_64\npython3-perf.x86_64\nqemu-img.x86_64\nqemu-kvm.x86_64\nqemu-kvm
-block-curl.x86_64\nqemu-kvm-block-gluster.x86_64\nqemu-kvm-block-iscsi.x86_64\nqemu-kvm-block-rbd.x
86_64\nqemu-kvm-block-ssh.x86_64\nqemu-kvm-common.x86_64\nqemu-kvm-core.x86_64\nrunc.x86_64\nslirp4n
etns.x86_64\nswtpm.x86_64\nswtpm-libs.x86_64\nswtpm-tools.x86_64\nvirt-v2v.x86_64\ngrub2-tools.x86_64\ngrub2-tools-efi.x86_64\ngrub2-tools-extra.x86_64\ngrub2-tools-minimal.x86_64\n"

I upgrade the host from the gui (without restart).
So far so good.
But now if I connect to the host I get:

[root@ov300 ~]# yum update
Last metadata expiration check: 0:05:42 ago on Mon 15 Mar 2021 09:36:31 AM
CET.
Dependencies resolved.

 Package   Architecture VersionRepository
   Size

Upgrading:
 ansible   noarch   2.9.18-2.el8
ovirt-4.4-centos-ovirt4417 M

Transaction Summary

Upgrade  1 Package

Total size: 17 M
Is this ok [y/N]:

Current version:

[root@ov300 ~]# rpm -q ansible
ansible-2.9.16-2.el8.noarch
[root@ov300 ~]#

Any suggestions on what is the right thing to do? Why the ansible package
was not updated and why it was not put into a sort of black list if it is
correct to do so?

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