[ovirt-users] Re: failed during installation of ovirt node iso image

2021-12-13 Thread Sandro Bonazzola 
Tracking the issue here: https://bugzilla.redhat.com/show_bug.cgi?id=2031911

Il giorno lun 13 dic 2021 alle ore 17:25 Sandro Bonazzola <
sbona...@redhat.com> ha scritto:

>
>
> Il giorno lun 13 dic 2021 alle ore 17:16 Sandro Bonazzola <
> sbona...@redhat.com> ha scritto:
>
>>
>>
>> Il giorno lun 13 dic 2021 alle ore 16:43 Sandro Bonazzola <
>> sbona...@redhat.com> ha scritto:
>>
>>>
>>>
>>> Il giorno lun 13 dic 2021 alle ore 16:31 
>>> ha scritto:
>>>
 Hi all,
 i have 3 Dell server r740. All have the same hardware configurations.
 When i try to install the 2 last images; 4.4.9-2021120923, and
 4.4.9-2021120714 the installation process fail during boot installation.
 At this linkt he bug report generated by anaconda.

 https://www.dropbox.com/s/5vkymurf8pyiuip/bug.tar.gz?dl=0

 When i install the image 4.4.9-2021102623 all works great.
 Thank all
 bye

>>>
>>> thanks for the report!
>>> Error seems to be:
>>> ERROR:anaconda.modules.common.task.task:Thread
>>> AnaTaskThread-InstallBootloaderTask-1 has failed: Traceback (most recent
>>> call last):
>>>   File "/usr/lib64/python3.6/site-packages/pyanaconda/threading.py",
>>> line 280, in run
>>> threading.Thread.run(self)
>>>   File "/usr/lib64/python3.6/threading.py", line 885, in run
>>> self._target(*self._args, **self._kwargs)
>>>   File
>>> "/usr/lib64/python3.6/site-packages/pyanaconda/modules/common/task/task.py",
>>> line 97, in _task_run_callback
>>> self._set_result(self.run())
>>>   File
>>> "/usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/bootloader/installation.py",
>>> line 103, in run
>>> install_boot_loader(storage=self._storage)
>>>   File
>>> "/usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/bootloader/utils.py",
>>> line 166, in install_boot_loader
>>> storage.bootloader.write()
>>>   File
>>> "/usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/bootloader/efi.py",
>>> line 113, in write
>>> self.install()
>>>   File
>>> "/usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/bootloader/efi.py",
>>> line 122, in install
>>> self.remove_efi_boot_target()
>>>   File
>>> "/usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/bootloader/efi.py",
>>> line 86, in remove_efi_boot_target
>>> buf = self.efibootmgr(capture=True)
>>>   File
>>> "/usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/bootloader/efi.py",
>>> line 57, in efibootmgr
>>> return exec_func("efibootmgr", list(args), **kwargs)
>>>   File "/usr/lib64/python3.6/site-packages/pyanaconda/core/util.py",
>>> line 413, in execWithCapture
>>> filter_stderr=filter_stderr)[1]
>>>   File "/usr/lib64/python3.6/site-packages/pyanaconda/core/util.py",
>>> line 321, in _run_program
>>> env_prune=env_prune)
>>>   File "/usr/lib64/python3.6/site-packages/pyanaconda/core/util.py",
>>> line 202, in startProgram
>>> preexec_fn=preexec, cwd=root, env=env, **kwargs)
>>>   File "/usr/lib64/python3.6/subprocess.py", line 729, in __init__
>>> restore_signals, start_new_session)
>>>   File "/usr/lib64/python3.6/subprocess.py", line 1364, in _execute_child
>>> raise child_exception_type(errno_num, err_msg, err_filename)
>>> FileNotFoundError: [Errno 2] No such file or directory: 'efibootmgr':
>>> 'efibootmgr'
>>>
>>> And indeed between 4.4.9 and 4.4.9.1 build the following packages
>>> disappeared from the manifest:
>>>
>>> efi-filesystem-3-3.el8.noarch
>>> efibootmgr-16-1.el8.x86_64
>>> efivar-libs-37-4.el8.x86_64
>>> grub2-efi-x64-2.02-99.el8_4.1.x86_64
>>>
>>> I also see there's a regression in ovirt-host package:
>>> in 4.4.9 the ISO contained ovirt-host-4.4.9-2.el8.x86_64 while in
>>> 4.4.9.1 it contains ovirt-host-4.4.8-1.el8.x86_64
>>>
>>> I'm digging into the root cause of this issue. I fear some packages got
>>> lost with the migration of the main server out of the Phoenix datacenter.
>>>
>>> I guess we missed this because we tested the ISO on a non-efi system.
>>>
>>> +Lev Veyde  +Sanja Bonic  +Michal
>>> Skrivanek  for awareness.
>>>
>>>
>>
>> The above missing packages are required from ovirt-release-host-node
>> package on x86_64 architecture.
>>
>> Looks like the jenkins job building the iso is not able to detect it's an
>> x86_64 host anymore and it's taking packages from some proxy which or
>> mirror with outdated content.
>>
>> I'm going to try rebuilding by enforcing the use of the master mirror and
>> enforcing the x86_64 architecture there.
>>
>
> Apparently we are already enforcing master mirror:
>
> https://github.com/oVirt/ovirt-node-ng-image/blob/ovirt-4.4/data/ovirt-node-ng-image.j2#L63
> So the master mirror may be broken.
> The 4.4.9-2 package is there:
> https://resources.ovirt.org/pub/ovirt-4.4/rpm/el8/x86_64/ovirt-host-4.4.9-2.el8.x86_64.rpm
> so it's not missing.
> I'm going to re-generate the repodata and retry the build.
>
>
>
>>
>>
>>
>>>
>>>
>>>

 Federico

[ovirt-users] Re: Issue with DWH Installtion "Failed to execute stage 'Misc configuration': terminating connection due to administrator command"

2021-12-13 Thread Maitlin Blundon 
> Please clarify the topology in more details. What exactly is intended
> to run where?

The guess of the engine on one machine (ovirt-ctl) then the db, dwh dwh_db on 
the separate machine (ovirt-net)

> On which machine?

This is on ovirt-net when trying to setup dwh+dwh_db

> This should only happen on the dwh machine ("ovirt-net"?)

Yes, has only happened during the DWH setup on ovirt-net

> A guess:
> 
> Your setup (with the engine on one machine and its db+dwh+dwh_db on
> another) is not a common
> one, and was likely not tested with the addition of grafana
> integration (new in 4.4).
> 
> So you can try this:
> 1. Setup DBs + engine (already done)
> 2. On engine-setup on the other machine, reply 'No' to 'Configure
> grafana?'. This should hopefully succeed.
> 3. Run there 'engine-setup --reconfigure-optional-components' and
> enable grafana. Hopefully will work this time...

Trying this; the initial setup for just dwh+dwh_db without grafana goes by 
successfully now, however the reconfiguration setup run fails similarly as 
before: 

[ INFO  ] Creating a user for Grafana
[ ERROR ] Failed to execute stage 'Misc configuration': terminating connection 
due to administrator command
 server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.

Thank you in advance,
Maitlin
___
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/JEAHPFRMIUIS3Z7MUBZFMLBBFX3HSDFN/

[ovirt-users] Re: failed during installation of ovirt node iso image

2021-12-13 Thread Sandro Bonazzola 
Il giorno lun 13 dic 2021 alle ore 17:16 Sandro Bonazzola <
sbona...@redhat.com> ha scritto:

>
>
> Il giorno lun 13 dic 2021 alle ore 16:43 Sandro Bonazzola <
> sbona...@redhat.com> ha scritto:
>
>>
>>
>> Il giorno lun 13 dic 2021 alle ore 16:31 
>> ha scritto:
>>
>>> Hi all,
>>> i have 3 Dell server r740. All have the same hardware configurations.
>>> When i try to install the 2 last images; 4.4.9-2021120923, and
>>> 4.4.9-2021120714 the installation process fail during boot installation.
>>> At this linkt he bug report generated by anaconda.
>>>
>>> https://www.dropbox.com/s/5vkymurf8pyiuip/bug.tar.gz?dl=0
>>>
>>> When i install the image 4.4.9-2021102623 all works great.
>>> Thank all
>>> bye
>>>
>>
>> thanks for the report!
>> Error seems to be:
>> ERROR:anaconda.modules.common.task.task:Thread
>> AnaTaskThread-InstallBootloaderTask-1 has failed: Traceback (most recent
>> call last):
>>   File "/usr/lib64/python3.6/site-packages/pyanaconda/threading.py", line
>> 280, in run
>> threading.Thread.run(self)
>>   File "/usr/lib64/python3.6/threading.py", line 885, in run
>> self._target(*self._args, **self._kwargs)
>>   File
>> "/usr/lib64/python3.6/site-packages/pyanaconda/modules/common/task/task.py",
>> line 97, in _task_run_callback
>> self._set_result(self.run())
>>   File
>> "/usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/bootloader/installation.py",
>> line 103, in run
>> install_boot_loader(storage=self._storage)
>>   File
>> "/usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/bootloader/utils.py",
>> line 166, in install_boot_loader
>> storage.bootloader.write()
>>   File
>> "/usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/bootloader/efi.py",
>> line 113, in write
>> self.install()
>>   File
>> "/usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/bootloader/efi.py",
>> line 122, in install
>> self.remove_efi_boot_target()
>>   File
>> "/usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/bootloader/efi.py",
>> line 86, in remove_efi_boot_target
>> buf = self.efibootmgr(capture=True)
>>   File
>> "/usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/bootloader/efi.py",
>> line 57, in efibootmgr
>> return exec_func("efibootmgr", list(args), **kwargs)
>>   File "/usr/lib64/python3.6/site-packages/pyanaconda/core/util.py", line
>> 413, in execWithCapture
>> filter_stderr=filter_stderr)[1]
>>   File "/usr/lib64/python3.6/site-packages/pyanaconda/core/util.py", line
>> 321, in _run_program
>> env_prune=env_prune)
>>   File "/usr/lib64/python3.6/site-packages/pyanaconda/core/util.py", line
>> 202, in startProgram
>> preexec_fn=preexec, cwd=root, env=env, **kwargs)
>>   File "/usr/lib64/python3.6/subprocess.py", line 729, in __init__
>> restore_signals, start_new_session)
>>   File "/usr/lib64/python3.6/subprocess.py", line 1364, in _execute_child
>> raise child_exception_type(errno_num, err_msg, err_filename)
>> FileNotFoundError: [Errno 2] No such file or directory: 'efibootmgr':
>> 'efibootmgr'
>>
>> And indeed between 4.4.9 and 4.4.9.1 build the following packages
>> disappeared from the manifest:
>>
>> efi-filesystem-3-3.el8.noarch
>> efibootmgr-16-1.el8.x86_64
>> efivar-libs-37-4.el8.x86_64
>> grub2-efi-x64-2.02-99.el8_4.1.x86_64
>>
>> I also see there's a regression in ovirt-host package:
>> in 4.4.9 the ISO contained ovirt-host-4.4.9-2.el8.x86_64 while in 4.4.9.1
>> it contains ovirt-host-4.4.8-1.el8.x86_64
>>
>> I'm digging into the root cause of this issue. I fear some packages got
>> lost with the migration of the main server out of the Phoenix datacenter.
>>
>> I guess we missed this because we tested the ISO on a non-efi system.
>>
>> +Lev Veyde  +Sanja Bonic  +Michal
>> Skrivanek  for awareness.
>>
>>
>
> The above missing packages are required from ovirt-release-host-node
> package on x86_64 architecture.
>
> Looks like the jenkins job building the iso is not able to detect it's an
> x86_64 host anymore and it's taking packages from some proxy which or
> mirror with outdated content.
>
> I'm going to try rebuilding by enforcing the use of the master mirror and
> enforcing the x86_64 architecture there.
>

Apparently we are already enforcing master mirror:
https://github.com/oVirt/ovirt-node-ng-image/blob/ovirt-4.4/data/ovirt-node-ng-image.j2#L63
So the master mirror may be broken.
The 4.4.9-2 package is there:
https://resources.ovirt.org/pub/ovirt-4.4/rpm/el8/x86_64/ovirt-host-4.4.9-2.el8.x86_64.rpm
so it's not missing.
I'm going to re-generate the repodata and retry the build.



>
>
>
>>
>>
>>
>>>
>>> Federico
>>>
>>> ___
>>> 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: failed during installation of ovirt node iso image

2021-12-13 Thread Sandro Bonazzola 
Il giorno lun 13 dic 2021 alle ore 16:43 Sandro Bonazzola <
sbona...@redhat.com> ha scritto:

>
>
> Il giorno lun 13 dic 2021 alle ore 16:31  ha
> scritto:
>
>> Hi all,
>> i have 3 Dell server r740. All have the same hardware configurations.
>> When i try to install the 2 last images; 4.4.9-2021120923, and
>> 4.4.9-2021120714 the installation process fail during boot installation.
>> At this linkt he bug report generated by anaconda.
>>
>> https://www.dropbox.com/s/5vkymurf8pyiuip/bug.tar.gz?dl=0
>>
>> When i install the image 4.4.9-2021102623 all works great.
>> Thank all
>> bye
>>
>
> thanks for the report!
> Error seems to be:
> ERROR:anaconda.modules.common.task.task:Thread
> AnaTaskThread-InstallBootloaderTask-1 has failed: Traceback (most recent
> call last):
>   File "/usr/lib64/python3.6/site-packages/pyanaconda/threading.py", line
> 280, in run
> threading.Thread.run(self)
>   File "/usr/lib64/python3.6/threading.py", line 885, in run
> self._target(*self._args, **self._kwargs)
>   File
> "/usr/lib64/python3.6/site-packages/pyanaconda/modules/common/task/task.py",
> line 97, in _task_run_callback
> self._set_result(self.run())
>   File
> "/usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/bootloader/installation.py",
> line 103, in run
> install_boot_loader(storage=self._storage)
>   File
> "/usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/bootloader/utils.py",
> line 166, in install_boot_loader
> storage.bootloader.write()
>   File
> "/usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/bootloader/efi.py",
> line 113, in write
> self.install()
>   File
> "/usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/bootloader/efi.py",
> line 122, in install
> self.remove_efi_boot_target()
>   File
> "/usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/bootloader/efi.py",
> line 86, in remove_efi_boot_target
> buf = self.efibootmgr(capture=True)
>   File
> "/usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/bootloader/efi.py",
> line 57, in efibootmgr
> return exec_func("efibootmgr", list(args), **kwargs)
>   File "/usr/lib64/python3.6/site-packages/pyanaconda/core/util.py", line
> 413, in execWithCapture
> filter_stderr=filter_stderr)[1]
>   File "/usr/lib64/python3.6/site-packages/pyanaconda/core/util.py", line
> 321, in _run_program
> env_prune=env_prune)
>   File "/usr/lib64/python3.6/site-packages/pyanaconda/core/util.py", line
> 202, in startProgram
> preexec_fn=preexec, cwd=root, env=env, **kwargs)
>   File "/usr/lib64/python3.6/subprocess.py", line 729, in __init__
> restore_signals, start_new_session)
>   File "/usr/lib64/python3.6/subprocess.py", line 1364, in _execute_child
> raise child_exception_type(errno_num, err_msg, err_filename)
> FileNotFoundError: [Errno 2] No such file or directory: 'efibootmgr':
> 'efibootmgr'
>
> And indeed between 4.4.9 and 4.4.9.1 build the following packages
> disappeared from the manifest:
>
> efi-filesystem-3-3.el8.noarch
> efibootmgr-16-1.el8.x86_64
> efivar-libs-37-4.el8.x86_64
> grub2-efi-x64-2.02-99.el8_4.1.x86_64
>
> I also see there's a regression in ovirt-host package:
> in 4.4.9 the ISO contained ovirt-host-4.4.9-2.el8.x86_64 while in 4.4.9.1
> it contains ovirt-host-4.4.8-1.el8.x86_64
>
> I'm digging into the root cause of this issue. I fear some packages got
> lost with the migration of the main server out of the Phoenix datacenter.
>
> I guess we missed this because we tested the ISO on a non-efi system.
>
> +Lev Veyde  +Sanja Bonic  +Michal
> Skrivanek  for awareness.
>
>

The above missing packages are required from ovirt-release-host-node
package on x86_64 architecture.

Looks like the jenkins job building the iso is not able to detect it's an
x86_64 host anymore and it's taking packages from some proxy which or
mirror with outdated content.

I'm going to try rebuilding by enforcing the use of the master mirror and
enforcing the x86_64 architecture there.



>
>
>
>>
>> Federico
>>
>> ___
>> 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/K5EVL2TPWGQVH3LBOOOB5HW6FMAWZ5RJ/
>>
>
>
> --
>
> 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.*
>
>
>

-- 

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

[ovirt-users] Re: failed during installation of ovirt node iso image

2021-12-13 Thread Sandro Bonazzola 
Il giorno lun 13 dic 2021 alle ore 16:31  ha
scritto:

> Hi all,
> i have 3 Dell server r740. All have the same hardware configurations.
> When i try to install the 2 last images; 4.4.9-2021120923, and
> 4.4.9-2021120714 the installation process fail during boot installation.
> At this linkt he bug report generated by anaconda.
>
> https://www.dropbox.com/s/5vkymurf8pyiuip/bug.tar.gz?dl=0
>
> When i install the image 4.4.9-2021102623 all works great.
> Thank all
> bye
>

thanks for the report!
Error seems to be:
ERROR:anaconda.modules.common.task.task:Thread
AnaTaskThread-InstallBootloaderTask-1 has failed: Traceback (most recent
call last):
  File "/usr/lib64/python3.6/site-packages/pyanaconda/threading.py", line
280, in run
threading.Thread.run(self)
  File "/usr/lib64/python3.6/threading.py", line 885, in run
self._target(*self._args, **self._kwargs)
  File
"/usr/lib64/python3.6/site-packages/pyanaconda/modules/common/task/task.py",
line 97, in _task_run_callback
self._set_result(self.run())
  File
"/usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/bootloader/installation.py",
line 103, in run
install_boot_loader(storage=self._storage)
  File
"/usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/bootloader/utils.py",
line 166, in install_boot_loader
storage.bootloader.write()
  File
"/usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/bootloader/efi.py",
line 113, in write
self.install()
  File
"/usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/bootloader/efi.py",
line 122, in install
self.remove_efi_boot_target()
  File
"/usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/bootloader/efi.py",
line 86, in remove_efi_boot_target
buf = self.efibootmgr(capture=True)
  File
"/usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/bootloader/efi.py",
line 57, in efibootmgr
return exec_func("efibootmgr", list(args), **kwargs)
  File "/usr/lib64/python3.6/site-packages/pyanaconda/core/util.py", line
413, in execWithCapture
filter_stderr=filter_stderr)[1]
  File "/usr/lib64/python3.6/site-packages/pyanaconda/core/util.py", line
321, in _run_program
env_prune=env_prune)
  File "/usr/lib64/python3.6/site-packages/pyanaconda/core/util.py", line
202, in startProgram
preexec_fn=preexec, cwd=root, env=env, **kwargs)
  File "/usr/lib64/python3.6/subprocess.py", line 729, in __init__
restore_signals, start_new_session)
  File "/usr/lib64/python3.6/subprocess.py", line 1364, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'efibootmgr':
'efibootmgr'

And indeed between 4.4.9 and 4.4.9.1 build the following packages
disappeared from the manifest:

efi-filesystem-3-3.el8.noarch
efibootmgr-16-1.el8.x86_64
efivar-libs-37-4.el8.x86_64
grub2-efi-x64-2.02-99.el8_4.1.x86_64

I also see there's a regression in ovirt-host package:
in 4.4.9 the ISO contained ovirt-host-4.4.9-2.el8.x86_64 while in 4.4.9.1
it contains ovirt-host-4.4.8-1.el8.x86_64

I'm digging into the root cause of this issue. I fear some packages got
lost with the migration of the main server out of the Phoenix datacenter.

I guess we missed this because we tested the ISO on a non-efi system.

+Lev Veyde  +Sanja Bonic  +Michal
Skrivanek  for awareness.




>
> Federico
>
> ___
> 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/K5EVL2TPWGQVH3LBOOOB5HW6FMAWZ5RJ/
>


-- 

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

[ovirt-users] failed during installation of ovirt node iso image

2021-12-13 Thread federico . fiordoliva 
Hi all,
i have 3 Dell server r740. All have the same hardware configurations.
When i try to install the 2 last images; 4.4.9-2021120923, and 4.4.9-2021120714 
the installation process fail during boot installation. 
At this linkt he bug report generated by anaconda.

https://www.dropbox.com/s/5vkymurf8pyiuip/bug.tar.gz?dl=0

When i install the image 4.4.9-2021102623 all works great.
Thank all
bye

Federico

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

[ovirt-users] Re: oVirt and log4j vulnerability

2021-12-13 Thread Martin Perina 
On Mon, Dec 13, 2021 at 2:46 PM Derek Atkins  wrote:

>
> On Mon, December 13, 2021 8:04 am, Gianluca Cecchi wrote:
> >>
> > If I understood correctly reading here:
> >
> https://blog.qualys.com/vulnerabilities-threat-research/2021/12/10/apache-log4j2-zero-day-exploited-in-the-wild-log4shell
> >
> > you are protected by the RCE if java is 1.8 and greater than 1.8.121
> > (released on 2017)
>
> Do you mean 1.8.0.121?  For example, my system has:
>
> java-1.8.0-openjdk-headless-1.8.0.252.b09-2.el7_8.x86_64
>

If you are still on oVirt 4.3, which is using OpenJDK 1.8, then you should
have installed java-1.8.0-openjdk-1.8.0.312.b07-1.el7_9.x86_64.

If you are on oVirt 4.4, which is using OpenJDK 11, then you should have
installed java-11-openjdk-headless-11.0.13.0.8-3.el8_5.x86_64


> -derek
>
> --
>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/32PPOVQZRSIMCQMPVKZAKRZITIGGZ774/
>


-- 
Martin Perina
Manager, Software Engineering
Red Hat Czech s.r.o.
___
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/NRHOYBOOEQV2GKHS5WZ4ZQNAFCZZQQKT/

[ovirt-users] Re: oVirt and log4j vulnerability

2021-12-13 Thread Gianluca Cecchi 
On Mon, Dec 13, 2021 at 2:37 PM Derek Atkins  wrote:

>
> On Mon, December 13, 2021 8:04 am, Gianluca Cecchi wrote:
> >>
> > If I understood correctly reading here:
> >
> https://blog.qualys.com/vulnerabilities-threat-research/2021/12/10/apache-log4j2-zero-day-exploited-in-the-wild-log4shell
> >
> > you are protected by the RCE if java is 1.8 and greater than 1.8.121
> > (released on 2017)
>
> Do you mean 1.8.0.121?  For example, my system has:
>
> java-1.8.0-openjdk-headless-1.8.0.252.b09-2.el7_8.x86_64
>
> -derek
>
>
Yes, what the link refers to as 8u121:
https://www.oracle.com/java/technologies/javase/8u121-relnotes.html

Your version: 8u252 (or anyway based on it).
On my 4.4.8 engine I have
java-1.8.0-openjdk-headless-1.8.0.302.b08-0.el8_4.x86_64 but I have also
java-11-openjdk-headless-11.0.12.0.7-0.el8_4.x86_64 that is what
ovirt-engine uses, based on:

[root@ovmgr1 ovirt-engine]# ll /proc/$(pidof ovirt-engine)/fd | grep jvm
lr-x--. 1 ovirt ovirt 64 Sep 24 09:02 3 ->
/usr/lib/jvm/java-11-openjdk-11.0.12.0.7-0.el8_4.x86_64/lib/modules
[root@ovmgr1 ovirt-engine]#

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

[ovirt-users] Re: oVirt and log4j vulnerability

2021-12-13 Thread Derek Atkins 

On Mon, December 13, 2021 8:04 am, Gianluca Cecchi wrote:
>>
> If I understood correctly reading here:
> https://blog.qualys.com/vulnerabilities-threat-research/2021/12/10/apache-log4j2-zero-day-exploited-in-the-wild-log4shell
>
> you are protected by the RCE if java is 1.8 and greater than 1.8.121
> (released on 2017)

Do you mean 1.8.0.121?  For example, my system has:

java-1.8.0-openjdk-headless-1.8.0.252.b09-2.el7_8.x86_64

-derek

-- 
   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/32PPOVQZRSIMCQMPVKZAKRZITIGGZ774/

[ovirt-users] Re: oVirt and log4j vulnerability

2021-12-13 Thread Chris Adams 
Once upon a time, Michal Skrivanek  said:
> We concluded the investigation and we believe we are not affected, while a 
> vulnerable log4j is being shipped (and will be fixed by wildfly/jboss) we are 
> not using this functionality in any of or components.
> Wildfly reimplements log4j and we use that instead, all other usage is in 
> compile time, unit tests. We also use log4j 1.x but without the JMSAppender 
> in runtime.
> Thanks to MartinP for confirmation

Thanks for digging into this and checking.
-- 
Chris Adams 
___
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/UUWYXC6EPVZ7K3ZYYB4M3KAV3NBGY3VZ/

[ovirt-users] Re: oVirt and log4j vulnerability

2021-12-13 Thread Michal Skrivanek 


> On 13. 12. 2021, at 14:04, Gianluca Cecchi  wrote:
> 
> On Mon, Dec 13, 2021 at 1:38 PM Sandro Bonazzola  > wrote:
> So far we can't confirm whether oVirt engine systems are affected or not: the 
> oVirt infra team is digging into this.
> I can confirm that ovirt-engine-wildfly is shipping a log4j version which is 
> affected by the vulnerability and we are monitoring Wildfly project so we'll 
> be able to ship an update as soon as a fix will be available (we are just 
> repackaging the binary build they provide).
> But I got no report so far confirming if the way we run Wildfly exposes the 
> vulnerable system to potential attackers yet.

We concluded the investigation and we believe we are not affected, while a 
vulnerable log4j is being shipped (and will be fixed by wildfly/jboss) we are 
not using this functionality in any of or components.
Wildfly reimplements log4j and we use that instead, all other usage is in 
compile time, unit tests. We also use log4j 1.x but without the JMSAppender in 
runtime.
Thanks to MartinP for confirmation

Thanks,
michal

> 
> 
> 
> If I understood correctly reading here:
> https://blog.qualys.com/vulnerabilities-threat-research/2021/12/10/apache-log4j2-zero-day-exploited-in-the-wild-log4shell
>  
> 
> 
> you are protected by the RCE if java is 1.8 and greater than 1.8.121 
> (released on 2017) 
> 
> "
> If the server has Java runtimes later than 8u121, then it is protected 
> against remote code execution by defaulting 
> “com.sun.jndi.rmi.object.trustURLCodebase” and 
> “com.sun.jndi.cosnaming.object.trustURLCodebase” to “false”(see 
> https://www.oracle.com/java/technologies/javase/8u121-relnotes.html 
> ).
> "
> 
> It is not clear to me if it means that Java 11 (and 17) also maintained that 
> setting.
> In one of my oVirt with 4.4.8 it seems that engine is using 
> java-11-openjdk-headless-11.0.12.0.7-0.el8_4.x86_64 package
> 
> 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/WH3WZLRM6NYC7MJVWSTA4LY5YWDF57VW/

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

[ovirt-users] Re: oVirt and log4j vulnerability

2021-12-13 Thread Gianluca Cecchi 
On Mon, Dec 13, 2021 at 1:38 PM Sandro Bonazzola 
wrote:

> So far we can't confirm whether oVirt engine systems are affected or not:
> the oVirt infra team is digging into this.
> I can confirm that ovirt-engine-wildfly is shipping a log4j version which
> is affected by the vulnerability and we are monitoring Wildfly project so
> we'll be able to ship an update as soon as a fix will be available (we are
> just repackaging the binary build they provide).
> But I got no report so far confirming if the way we run Wildfly exposes
> the vulnerable system to potential attackers yet.
>
>
>
If I understood correctly reading here:
https://blog.qualys.com/vulnerabilities-threat-research/2021/12/10/apache-log4j2-zero-day-exploited-in-the-wild-log4shell

you are protected by the RCE if java is 1.8 and greater than 1.8.121
(released on 2017)

"
If the server has Java runtimes later than 8u121, then it is protected
against remote code execution by defaulting
“com.sun.jndi.rmi.object.trustURLCodebase” and
“com.sun.jndi.cosnaming.object.trustURLCodebase” to “false”(see
https://www.oracle.com/java/technologies/javase/8u121-relnotes.html).
"

It is not clear to me if it means that Java 11 (and 17) also maintained
that setting.
In one of my oVirt with 4.4.8 it seems that engine is using
java-11-openjdk-headless-11.0.12.0.7-0.el8_4.x86_64 package

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

[ovirt-users] Re: oVirt and log4j vulnerability

2021-12-13 Thread Sandro Bonazzola 
So far we can't confirm whether oVirt engine systems are affected or not:
the oVirt infra team is digging into this.
I can confirm that ovirt-engine-wildfly is shipping a log4j version which
is affected by the vulnerability and we are monitoring Wildfly project so
we'll be able to ship an update as soon as a fix will be available (we are
just repackaging the binary build they provide).
But I got no report so far confirming if the way we run Wildfly exposes the
vulnerable system to potential attackers yet.


Il giorno lun 13 dic 2021 alle ore 13:27 Klaas Demter 
ha scritto:

> Hi,
>
> no, I am not sure :)
>
> but if it's only the log4j-api package it should not be vulnerable either:
>
>
> https://issues.apache.org/jira/browse/LOG4J2-3201?focusedCommentId=17456962=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17456962
>
> But I am guessing for a real answer you need to wait for a maintainer of
> the package :)
>
>
> Greetings
>
> Klaas
>
>
> On 12/12/21 15:48, Kapetanakis Giannis wrote:
>
> Are you sure?
>
> lsof -n -P |grep log4j
>
> java2977 892943 EE-Manage   ovirt  213r
> REG  253,03014182071533
> /usr/share/ovirt-engine-wildfly/modules/system/layers/base/org/apache/logging/log4j/api/main/log4j-api-2.14.0.jar
>
> seems vulnerable to me.
>
> ovirt   2977  1.1 11.9 3955136 1954500 ? Sl   Dec03 157:37
> ovirt-engine --add-modules java.se -server -XX:+TieredCompilation
> -Xms1462M -Xmx1462M -Xss1M -Djava.awt.headless=true
> -Dsun.rmi.dgc.client.gcInterval=360
> -Dsun.rmi.dgc.server.gcInterval=360 -Djsse.enableSNIExtension=false
> -Dresteasy.preferJacksonOverJsonB=true
> -Djackson.deserialization.whitelist.packages=org,com,java,javax
> -Dcom.redhat.fips=false -XX:+HeapDumpOnOutOfMemoryError
> -XX:HeapDumpPath=/var/log/ovirt-engine/dump
> -Djava.util.logging.manager=org.jboss.logmanager -Dlogging.configuration=
> file:///var/lib/ovirt-engine/jboss_runtime/config/ovirt-engine-logging.properties
> -Dorg.jboss.resolver.warning=true
> -Djboss.modules.system.pkgs=org.jboss.byteman
> -Djboss.server.default.config=ovirt-engine
> -Djboss.home.dir=/usr/share/ovirt-engine-wildfly
> -Djboss.server.base.dir=/usr/share/ovirt-engine
> -Djboss.server.data.dir=/var/lib/ovirt-engine
> -Djboss.server.log.dir=/var/log/ovirt-engine
> -Djboss.server.config.dir=/var/lib/ovirt-engine/jboss_runtime/config
> -Djboss.server.temp.dir=/var/lib/ovirt-engine/jboss_runtime/tmp
> -Djboss.controller.temp.dir=/var/lib/ovirt-engine/jboss_runtime/tmp -jar
> /usr/share/ovirt-engine-wildfly/jboss-modules.jar -mp
> /usr/share/ovirt-engine-wildfly-overlay/modules:/usr/share/ovirt-engine/modules/common:/usr/share/ovirt-engine-extension-aaa-jdbc/modules:/usr/share/ovirt-engine-extension-aaa-ldap/modules:/usr/share/ovirt-engine-wildfly/modules
> -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -c
> ovirt-engine.xml
>
> rpm -qf
> /usr/share/ovirt-engine-wildfly/modules/system/layers/base/org/apache/logging/log4j/api/main/log4j-api-2.14.0.jar
> ovirt-engine-wildfly-23.0.2-1.el8.x86_64
>
> I believe we should start engine with -Dlog4j2.formatMsgNoLookups=true
> for mitigation but I cannot find where to apply this for jboss.
>
> maybe directly in
> /usr/share/ovirt-engine/services/ovirt-engine/ovirt-engine.py somewhere in
> _engineArgs
>
> G
>
> On 12/12/2021 10:25, Klaas Demter wrote:
>
> Hi,
>
> I think this only affects between 2.0 <= and <= 2.14.1 (
> https://bugzilla.redhat.com/show_bug.cgi?id=2030932)
>
> ovirt engine uses 1.2.17
>
>
> So I don't think this hits ovirt 4.4
>
>
> Greetings
>
> Klaas
>
>
> On 12/11/21 22:53, Chris Adams wrote:
>
> Can an oVirt developer comment about the log4j vulnerability - is
> oVirt's use of log4j vulnerable?
>
>
> ___
> 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/TH5FF4AMOB5VO4FUS7TRJIFBP7ISQDCY/
>
>
>
> ___
> 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/3WY4NXNYOKWN5YX5YDXGOGS2KZVK3IIS/
>
> ___
> 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: oVirt and log4j vulnerability

2021-12-13 Thread Klaas Demter 

Hi,

no, I am not sure :)

but if it's only the log4j-api package it should not be vulnerable either:

https://issues.apache.org/jira/browse/LOG4J2-3201?focusedCommentId=17456962=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17456962

But I am guessing for a real answer you need to wait for a maintainer of 
the package :)



Greetings

Klaas


On 12/12/21 15:48, Kapetanakis Giannis wrote:

Are you sure?

lsof -n -P |grep log4j

java    2977 892943 EE-Manage   ovirt  213r  
REG  253,0 301418    2071533 
/usr/share/ovirt-engine-wildfly/modules/system/layers/base/org/apache/logging/log4j/api/main/log4j-api-2.14.0.jar


seems vulnerable to me.
ovirt   2977  1.1 11.9 3955136 1954500 ? Sl   Dec03 157:37 
ovirt-engine --add-modules java.se -server -XX:+TieredCompilation 
-Xms1462M -Xmx1462M -Xss1M -Djava.awt.headless=true 
-Dsun.rmi.dgc.client.gcInterval=360 
-Dsun.rmi.dgc.server.gcInterval=360 
-Djsse.enableSNIExtension=false -Dresteasy.preferJacksonOverJsonB=true 
-Djackson.deserialization.whitelist.packages=org,com,java,javax 
-Dcom.redhat.fips=false -XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/var/log/ovirt-engine/dump 
-Djava.util.logging.manager=org.jboss.logmanager 
-Dlogging.configuration=file:///var/lib/ovirt-engine/jboss_runtime/config/ovirt-engine-logging.properties 
-Dorg.jboss.resolver.warning=true 
-Djboss.modules.system.pkgs=org.jboss.byteman 
-Djboss.server.default.config=ovirt-engine 
-Djboss.home.dir=/usr/share/ovirt-engine-wildfly 
-Djboss.server.base.dir=/usr/share/ovirt-engine 
-Djboss.server.data.dir=/var/lib/ovirt-engine 
-Djboss.server.log.dir=/var/log/ovirt-engine 
-Djboss.server.config.dir=/var/lib/ovirt-engine/jboss_runtime/config 
-Djboss.server.temp.dir=/var/lib/ovirt-engine/jboss_runtime/tmp 
-Djboss.controller.temp.dir=/var/lib/ovirt-engine/jboss_runtime/tmp 
-jar /usr/share/ovirt-engine-wildfly/jboss-modules.jar -mp 
/usr/share/ovirt-engine-wildfly-overlay/modules:/usr/share/ovirt-engine/modules/common:/usr/share/ovirt-engine-extension-aaa-jdbc/modules:/usr/share/ovirt-engine-extension-aaa-ldap/modules:/usr/share/ovirt-engine-wildfly/modules 
-jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -c 
ovirt-engine.xml


rpm -qf 
/usr/share/ovirt-engine-wildfly/modules/system/layers/base/org/apache/logging/log4j/api/main/log4j-api-2.14.0.jar

ovirt-engine-wildfly-23.0.2-1.el8.x86_64

I believe we should start engine with -Dlog4j2.formatMsgNoLookups=true
for mitigation but I cannot find where to apply this for jboss.

maybe directly in 
/usr/share/ovirt-engine/services/ovirt-engine/ovirt-engine.py 
somewhere in _engineArgs


G

On 12/12/2021 10:25, Klaas Demter wrote:


Hi,

I think this only affects between 2.0 <= and <= 2.14.1 
(https://bugzilla.redhat.com/show_bug.cgi?id=2030932)


ovirt engine uses 1.2.17


So I don't think this hits ovirt 4.4


Greetings

Klaas


On 12/11/21 22:53, Chris Adams wrote:

Can an oVirt developer comment about the log4j vulnerability - is
oVirt's use of log4j vulnerable?


___
Users mailing list --users@ovirt.org
To unsubscribe send an email tousers-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/TH5FF4AMOB5VO4FUS7TRJIFBP7ISQDCY/




___
Users mailing list --users@ovirt.org
To unsubscribe send an email tousers-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/3WY4NXNYOKWN5YX5YDXGOGS2KZVK3IIS/___
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/FHJWJHADUF4VLQVBK4LRGYQMD5ZMNBU5/

[ovirt-users] Re: Upgrading 4.3.7 -> 4.4.9 :: Can't migrate vm from old to new host

2021-12-13 Thread Niklas Larsson via Users 

Hi,

I an sorry for the noise - and thanks for obvious question - and the 
answer is that resolv.conf had the wrong dns entries on the old host. 
Fixed it and now we can migrate. Unknown how it ended there - but we are 
now happy and rocking.


/nikas

On 2021-12-13 09:45, Ales Musil wrote:

And are you able to reach from one host to another via IP and via FQDN?

Best regards,
Ales

On Mon, Dec 13, 2021 at 9:42 AM Niklas Larsson via Users 
 wrote:


Hi,

Can't see any errors for networking - we only have one logical
network, that has all the features:



/niklas

On 2021-12-13 09:26, Ales Musil wrote:

Hi,

is your engine reporting out-of-sync on that migration network?

Best regards,
Ales

On Mon, Dec 13, 2021 at 9:23 AM Niklas Larsson via Users
 wrote:

Hi,

we are using static ip, and the iptable-save is pretty empty
- all rules
are ACCEPT as default.

We are doing this in our lab environment, not yet i
production - so it's
not affecting anything yet.

/niklas

On 2021-12-10 17:37, Nathanaël Blanchet wrote:
> Hi,
>
> Is your migration network provisionned by DHCP?
>
> If so, there is a known bug that prevents NetworkManager to
set ip
> rule table for your migration network, and it won't be
fixed before
> 4.5 release.
>
> As a workaround, you can set the protocol to static or
manually assign
> rule table to 0 as folowing on all on your hosts:
>
> nmcli connection mod migration ipv4.route-table 0 && nmcli
con up
> migration
>
> Le 10/12/2021 à 17:07, Niklas Larsson via Users a écrit :
>> Hi,
>>
>> we are trying to upgrade 4.3.7 -> 4.4.9 (Ovirt-Node,
hosted engine).
>> And things looks good until we try to migrate VM from
4.3.7 host to
>> the 4.4.9 host, it fails with an generic error - and in
below is from
>> the vsdm.log from the 4.3.7 host.
>>
>> Migrating VM from 4.4.9 host -> 4.3.7 host works.
>>
>> Upgraded the 4.3.7 to 4.3.10 - did not solve it
>>
>> Log from the 4.3 host:
>> 2021-12-10 16:18:22,829+0100 INFO (jsonrpc/1) [api.virt]
START
>> migrate(params={u'incomingLimit': 2, u'src':
>> u'kvm22.shg.mgn.weblink.se
', u'dstqemu': u'10.1.2.111',
>> u'autoConverge': u'true', u'tunneled': u'false',
u'enableGuestEvents': T
>> rue, u'dst': u'kvm21.shg.mgn.weblink.se:54321
',
>> u'convergenceSchedule': {u'init': [{u'params': [u'100'],
u'name':
>> u'setDowntime'}], u'stalling': [{u'action': {u'params':
[u'150'],
>> u'name': u'setDowntime'}, u'limit': 1}, {u'action':
{u'params':
>> [u'200'], u'name': u'setDowntime'}, u'limit': 2}, {u'action':
>> {u'params': [u'300'], u'name': u'setDowntime'}, u'limit': 3},
>> {u'action': {u'params': [u'400'], u'name':
u'setDowntime'}, u'limit':
>> 4}, {u'action': {u'params': [u'500'], u'name':
u'setDowntime'},
>> u'limit': 6}, {u'action': {u'params': [], u'name': u'abort'},
>> u'limit': -1}]}, u'vmId':
u'11f3a2aa-7951-4064-92f9-bb8ab515373b',
>> u'abortOnError': u'true', u'outgoingLimit': 2, u'compressed':
>> u'false', u'maxBandwidth': 62, u'method': u'online'})
>> from=:::10.1.2.51,46546,
>> flow_id=03aca28c-00c9-4b58-a1e8-3aa355e162c2,
>> vmId=11f3a2aa-7951-4064-92f9-bb8ab515373b (api:48)
>> 2021-12-10 16:18:22,831+0100 INFO (jsonrpc/1) [api.virt]
FINISH
>> migrate return={'status': {'message': 'Migration in
progress',
>> 'code': 0}, 'progress': 0} from=:::10.1.2.51,46546,
>> flow_id=03aca28c-00c9-4b58-a1e8-3aa355e162c2,
>> vmId=11f3a2aa-7951-4064-92f9-bb8ab515373b (api:54)
>> 2021-12-10 16:18:22,831+0100 INFO (jsonrpc/1)
>> [jsonrpc.JsonRpcServer] RPC call VM.migrate succeeded in
0.01 seconds
>> (__init__:312)
>> 2021-12-10 16:18:22,873+0100 ERROR (migsrc/11f3a2aa)
[virt.vm]
>> (vmId='11f3a2aa-7951-4064-92f9-bb8ab515373b') [Errno -2]
Name or
>> service not known (migration:282)
>> 2021-12-10 16:18:22,875+0100 ERROR (migsrc/11f3a2aa)
[virt.vm]
>> (vmId='11f3a2aa-7951-4064-92f9-bb8ab515373b') Failed to
migrate
>> (migration:450)
>> Traceback (most recent call last):
>>   File
"/usr/lib/python2.7/site-packages/vdsm/virt/migration.py",
>> line 402, in _regular_run
>>     self._setupVdsConnection()
>>   File
"/usr/lib/python2.7/site-packages/vdsm/virt/migration.py",

[ovirt-users] Re: Upgrading 4.3.7 -> 4.4.9 :: Can't migrate vm from old to new host

2021-12-13 Thread Ales Musil 
And are you able to reach from one host to another via IP and via FQDN?

Best regards,
Ales

On Mon, Dec 13, 2021 at 9:42 AM Niklas Larsson via Users 
wrote:

> Hi,
>
> Can't see any errors for networking - we only have one logical network,
> that has all the features:
>
>
>
> /niklas
>
> On 2021-12-13 09:26, Ales Musil wrote:
>
> Hi,
>
> is your engine reporting out-of-sync on that migration network?
>
> Best regards,
> Ales
>
> On Mon, Dec 13, 2021 at 9:23 AM Niklas Larsson via Users 
> wrote:
>
>> Hi,
>>
>> we are using static ip, and the iptable-save is pretty empty - all rules
>> are ACCEPT as default.
>>
>> We are doing this in our lab environment, not yet i production - so it's
>> not affecting anything yet.
>>
>> /niklas
>>
>> On 2021-12-10 17:37, Nathanaël Blanchet wrote:
>> > Hi,
>> >
>> > Is your migration network provisionned by DHCP?
>> >
>> > If so, there is a known bug that prevents NetworkManager to set ip
>> > rule table for your migration network, and it won't be fixed before
>> > 4.5 release.
>> >
>> > As a workaround, you can set the protocol to static or manually assign
>> > rule table to 0 as folowing on all on your hosts:
>> >
>> > nmcli connection mod migration ipv4.route-table 0 && nmcli con up
>> > migration
>> >
>> > Le 10/12/2021 à 17:07, Niklas Larsson via Users a écrit :
>> >> Hi,
>> >>
>> >> we are trying to upgrade 4.3.7 -> 4.4.9 (Ovirt-Node, hosted engine).
>> >> And things looks good until we try to migrate VM from 4.3.7 host to
>> >> the 4.4.9 host, it fails with an generic error - and in below is from
>> >> the vsdm.log from the 4.3.7 host.
>> >>
>> >> Migrating VM from 4.4.9 host -> 4.3.7 host works.
>> >>
>> >> Upgraded the 4.3.7 to 4.3.10 - did not solve it
>> >>
>> >> Log from the 4.3 host:
>> >> 2021-12-10 16:18:22,829+0100 INFO  (jsonrpc/1) [api.virt] START
>> >> migrate(params={u'incomingLimit': 2, u'src':
>> >> u'kvm22.shg.mgn.weblink.se', u'dstqemu': u'10.1.2.111',
>> >> u'autoConverge': u'true', u'tunneled': u'false', u'enableGuestEvents':
>> T
>> >> rue, u'dst': u'kvm21.shg.mgn.weblink.se:54321',
>> >> u'convergenceSchedule': {u'init': [{u'params': [u'100'], u'name':
>> >> u'setDowntime'}], u'stalling': [{u'action': {u'params': [u'150'],
>> >> u'name': u'setDowntime'}, u'limit': 1}, {u'action': {u'params':
>> >> [u'200'], u'name': u'setDowntime'}, u'limit': 2}, {u'action':
>> >> {u'params': [u'300'], u'name': u'setDowntime'}, u'limit': 3},
>> >> {u'action': {u'params': [u'400'], u'name': u'setDowntime'}, u'limit':
>> >> 4}, {u'action': {u'params': [u'500'], u'name': u'setDowntime'},
>> >> u'limit': 6}, {u'action': {u'params': [], u'name': u'abort'},
>> >> u'limit': -1}]}, u'vmId': u'11f3a2aa-7951-4064-92f9-bb8ab515373b',
>> >> u'abortOnError': u'true', u'outgoingLimit': 2, u'compressed':
>> >> u'false', u'maxBandwidth': 62, u'method': u'online'})
>> >> from=:::10.1.2.51,46546,
>> >> flow_id=03aca28c-00c9-4b58-a1e8-3aa355e162c2,
>> >> vmId=11f3a2aa-7951-4064-92f9-bb8ab515373b (api:48)
>> >> 2021-12-10 16:18:22,831+0100 INFO  (jsonrpc/1) [api.virt] FINISH
>> >> migrate return={'status': {'message': 'Migration in progress',
>> >> 'code': 0}, 'progress': 0} from=:::10.1.2.51,46546,
>> >> flow_id=03aca28c-00c9-4b58-a1e8-3aa355e162c2,
>> >> vmId=11f3a2aa-7951-4064-92f9-bb8ab515373b (api:54)
>> >> 2021-12-10 16:18:22,831+0100 INFO  (jsonrpc/1)
>> >> [jsonrpc.JsonRpcServer] RPC call VM.migrate succeeded in 0.01 seconds
>> >> (__init__:312)
>> >> 2021-12-10 16:18:22,873+0100 ERROR (migsrc/11f3a2aa) [virt.vm]
>> >> (vmId='11f3a2aa-7951-4064-92f9-bb8ab515373b') [Errno -2] Name or
>> >> service not known (migration:282)
>> >> 2021-12-10 16:18:22,875+0100 ERROR (migsrc/11f3a2aa) [virt.vm]
>> >> (vmId='11f3a2aa-7951-4064-92f9-bb8ab515373b') Failed to migrate
>> >> (migration:450)
>> >> Traceback (most recent call last):
>> >>   File "/usr/lib/python2.7/site-packages/vdsm/virt/migration.py",
>> >> line 402, in _regular_run
>> >> self._setupVdsConnection()
>> >>   File "/usr/lib/python2.7/site-packages/vdsm/virt/migration.py",
>> >> line 239, in _setupVdsConnection
>> >> client = self._createClient(port)
>> >>   File "/usr/lib/python2.7/site-packages/vdsm/virt/migration.py",
>> >> line 227, in _createClient
>> >> client_socket = utils.create_connected_socket(host, int(port),
>> >> sslctx)
>> >>   File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 435, in
>> >> create_connected_socket
>> >> socket.AF_UNSPEC, socket.SOCK_STREAM)
>> >> gaierror: [Errno -2] Name or service not known
>> >> 2021-12-10 16:18:22,888+0100 INFO  (jsonrpc/7) [api.virt] START
>> >> getMigrationStatus() from=:::10.1.2.51,46546,
>> >> vmId=11f3a2aa-7951-4064-92f9-bb8ab515373b (api:48)
>> >> 2021-12-10 16:18:22,888+0100 INFO  (jsonrpc/7) [api.virt] FINISH
>> >> getMigrationStatus return={'status': {'message': 'Done', 'code': 0},
>> >> 'migrationStats': {'status': {'message': 'Fatal error during
>> >> migration', 'code': 12}, 'progress': 0}} from=:::10.1.2.51,46546,

[ovirt-users] Re: Upgrading 4.3.7 -> 4.4.9 :: Can't migrate vm from old to new host

2021-12-13 Thread Niklas Larsson via Users 

Hi,

Can't see any errors for networking - we only have one logical network, 
that has all the features:




/niklas

On 2021-12-13 09:26, Ales Musil wrote:

Hi,

is your engine reporting out-of-sync on that migration network?

Best regards,
Ales

On Mon, Dec 13, 2021 at 9:23 AM Niklas Larsson via Users 
 wrote:


Hi,

we are using static ip, and the iptable-save is pretty empty - all
rules
are ACCEPT as default.

We are doing this in our lab environment, not yet i production -
so it's
not affecting anything yet.

/niklas

On 2021-12-10 17:37, Nathanaël Blanchet wrote:
> Hi,
>
> Is your migration network provisionned by DHCP?
>
> If so, there is a known bug that prevents NetworkManager to set ip
> rule table for your migration network, and it won't be fixed before
> 4.5 release.
>
> As a workaround, you can set the protocol to static or manually
assign
> rule table to 0 as folowing on all on your hosts:
>
> nmcli connection mod migration ipv4.route-table 0 && nmcli con up
> migration
>
> Le 10/12/2021 à 17:07, Niklas Larsson via Users a écrit :
>> Hi,
>>
>> we are trying to upgrade 4.3.7 -> 4.4.9 (Ovirt-Node, hosted
engine).
>> And things looks good until we try to migrate VM from 4.3.7
host to
>> the 4.4.9 host, it fails with an generic error - and in below
is from
>> the vsdm.log from the 4.3.7 host.
>>
>> Migrating VM from 4.4.9 host -> 4.3.7 host works.
>>
>> Upgraded the 4.3.7 to 4.3.10 - did not solve it
>>
>> Log from the 4.3 host:
>> 2021-12-10 16:18:22,829+0100 INFO  (jsonrpc/1) [api.virt] START
>> migrate(params={u'incomingLimit': 2, u'src':
>> u'kvm22.shg.mgn.weblink.se ',
u'dstqemu': u'10.1.2.111',
>> u'autoConverge': u'true', u'tunneled': u'false',
u'enableGuestEvents': T
>> rue, u'dst': u'kvm21.shg.mgn.weblink.se:54321
',
>> u'convergenceSchedule': {u'init': [{u'params': [u'100'], u'name':
>> u'setDowntime'}], u'stalling': [{u'action': {u'params': [u'150'],
>> u'name': u'setDowntime'}, u'limit': 1}, {u'action': {u'params':
>> [u'200'], u'name': u'setDowntime'}, u'limit': 2}, {u'action':
>> {u'params': [u'300'], u'name': u'setDowntime'}, u'limit': 3},
>> {u'action': {u'params': [u'400'], u'name': u'setDowntime'},
u'limit':
>> 4}, {u'action': {u'params': [u'500'], u'name': u'setDowntime'},
>> u'limit': 6}, {u'action': {u'params': [], u'name': u'abort'},
>> u'limit': -1}]}, u'vmId': u'11f3a2aa-7951-4064-92f9-bb8ab515373b',
>> u'abortOnError': u'true', u'outgoingLimit': 2, u'compressed':
>> u'false', u'maxBandwidth': 62, u'method': u'online'})
>> from=:::10.1.2.51,46546,
>> flow_id=03aca28c-00c9-4b58-a1e8-3aa355e162c2,
>> vmId=11f3a2aa-7951-4064-92f9-bb8ab515373b (api:48)
>> 2021-12-10 16:18:22,831+0100 INFO  (jsonrpc/1) [api.virt] FINISH
>> migrate return={'status': {'message': 'Migration in progress',
>> 'code': 0}, 'progress': 0} from=:::10.1.2.51,46546,
>> flow_id=03aca28c-00c9-4b58-a1e8-3aa355e162c2,
>> vmId=11f3a2aa-7951-4064-92f9-bb8ab515373b (api:54)
>> 2021-12-10 16:18:22,831+0100 INFO  (jsonrpc/1)
>> [jsonrpc.JsonRpcServer] RPC call VM.migrate succeeded in 0.01
seconds
>> (__init__:312)
>> 2021-12-10 16:18:22,873+0100 ERROR (migsrc/11f3a2aa) [virt.vm]
>> (vmId='11f3a2aa-7951-4064-92f9-bb8ab515373b') [Errno -2] Name or
>> service not known (migration:282)
>> 2021-12-10 16:18:22,875+0100 ERROR (migsrc/11f3a2aa) [virt.vm]
>> (vmId='11f3a2aa-7951-4064-92f9-bb8ab515373b') Failed to migrate
>> (migration:450)
>> Traceback (most recent call last):
>>   File "/usr/lib/python2.7/site-packages/vdsm/virt/migration.py",
>> line 402, in _regular_run
>>     self._setupVdsConnection()
>>   File "/usr/lib/python2.7/site-packages/vdsm/virt/migration.py",
>> line 239, in _setupVdsConnection
>>     client = self._createClient(port)
>>   File "/usr/lib/python2.7/site-packages/vdsm/virt/migration.py",
>> line 227, in _createClient
>>     client_socket = utils.create_connected_socket(host, int(port),
>> sslctx)
>>   File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line
435, in
>> create_connected_socket
>>     socket.AF_UNSPEC, socket.SOCK_STREAM)
>> gaierror: [Errno -2] Name or service not known
>> 2021-12-10 16:18:22,888+0100 INFO  (jsonrpc/7) [api.virt] START
>> getMigrationStatus() from=:::10.1.2.51,46546,
>> vmId=11f3a2aa-7951-4064-92f9-bb8ab515373b (api:48)
>> 2021-12-10 16:18:22,888+0100 INFO  (jsonrpc/7) [api.virt] FINISH
>> getMigrationStatus return={'status': {'message': 'Done',
'code': 0},
>> 'migrationStats': {'status': {'message': 'Fatal error during
>> migration', 'code': 12}, 'progress': 0}}

[ovirt-users] Re: Upgrading 4.3.7 -> 4.4.9 :: Can't migrate vm from old to new host

2021-12-13 Thread Ales Musil 
Hi,

is your engine reporting out-of-sync on that migration network?

Best regards,
Ales

On Mon, Dec 13, 2021 at 9:23 AM Niklas Larsson via Users 
wrote:

> Hi,
>
> we are using static ip, and the iptable-save is pretty empty - all rules
> are ACCEPT as default.
>
> We are doing this in our lab environment, not yet i production - so it's
> not affecting anything yet.
>
> /niklas
>
> On 2021-12-10 17:37, Nathanaël Blanchet wrote:
> > Hi,
> >
> > Is your migration network provisionned by DHCP?
> >
> > If so, there is a known bug that prevents NetworkManager to set ip
> > rule table for your migration network, and it won't be fixed before
> > 4.5 release.
> >
> > As a workaround, you can set the protocol to static or manually assign
> > rule table to 0 as folowing on all on your hosts:
> >
> > nmcli connection mod migration ipv4.route-table 0 && nmcli con up
> > migration
> >
> > Le 10/12/2021 à 17:07, Niklas Larsson via Users a écrit :
> >> Hi,
> >>
> >> we are trying to upgrade 4.3.7 -> 4.4.9 (Ovirt-Node, hosted engine).
> >> And things looks good until we try to migrate VM from 4.3.7 host to
> >> the 4.4.9 host, it fails with an generic error - and in below is from
> >> the vsdm.log from the 4.3.7 host.
> >>
> >> Migrating VM from 4.4.9 host -> 4.3.7 host works.
> >>
> >> Upgraded the 4.3.7 to 4.3.10 - did not solve it
> >>
> >> Log from the 4.3 host:
> >> 2021-12-10 16:18:22,829+0100 INFO  (jsonrpc/1) [api.virt] START
> >> migrate(params={u'incomingLimit': 2, u'src':
> >> u'kvm22.shg.mgn.weblink.se', u'dstqemu': u'10.1.2.111',
> >> u'autoConverge': u'true', u'tunneled': u'false', u'enableGuestEvents': T
> >> rue, u'dst': u'kvm21.shg.mgn.weblink.se:54321',
> >> u'convergenceSchedule': {u'init': [{u'params': [u'100'], u'name':
> >> u'setDowntime'}], u'stalling': [{u'action': {u'params': [u'150'],
> >> u'name': u'setDowntime'}, u'limit': 1}, {u'action': {u'params':
> >> [u'200'], u'name': u'setDowntime'}, u'limit': 2}, {u'action':
> >> {u'params': [u'300'], u'name': u'setDowntime'}, u'limit': 3},
> >> {u'action': {u'params': [u'400'], u'name': u'setDowntime'}, u'limit':
> >> 4}, {u'action': {u'params': [u'500'], u'name': u'setDowntime'},
> >> u'limit': 6}, {u'action': {u'params': [], u'name': u'abort'},
> >> u'limit': -1}]}, u'vmId': u'11f3a2aa-7951-4064-92f9-bb8ab515373b',
> >> u'abortOnError': u'true', u'outgoingLimit': 2, u'compressed':
> >> u'false', u'maxBandwidth': 62, u'method': u'online'})
> >> from=:::10.1.2.51,46546,
> >> flow_id=03aca28c-00c9-4b58-a1e8-3aa355e162c2,
> >> vmId=11f3a2aa-7951-4064-92f9-bb8ab515373b (api:48)
> >> 2021-12-10 16:18:22,831+0100 INFO  (jsonrpc/1) [api.virt] FINISH
> >> migrate return={'status': {'message': 'Migration in progress',
> >> 'code': 0}, 'progress': 0} from=:::10.1.2.51,46546,
> >> flow_id=03aca28c-00c9-4b58-a1e8-3aa355e162c2,
> >> vmId=11f3a2aa-7951-4064-92f9-bb8ab515373b (api:54)
> >> 2021-12-10 16:18:22,831+0100 INFO  (jsonrpc/1)
> >> [jsonrpc.JsonRpcServer] RPC call VM.migrate succeeded in 0.01 seconds
> >> (__init__:312)
> >> 2021-12-10 16:18:22,873+0100 ERROR (migsrc/11f3a2aa) [virt.vm]
> >> (vmId='11f3a2aa-7951-4064-92f9-bb8ab515373b') [Errno -2] Name or
> >> service not known (migration:282)
> >> 2021-12-10 16:18:22,875+0100 ERROR (migsrc/11f3a2aa) [virt.vm]
> >> (vmId='11f3a2aa-7951-4064-92f9-bb8ab515373b') Failed to migrate
> >> (migration:450)
> >> Traceback (most recent call last):
> >>   File "/usr/lib/python2.7/site-packages/vdsm/virt/migration.py",
> >> line 402, in _regular_run
> >> self._setupVdsConnection()
> >>   File "/usr/lib/python2.7/site-packages/vdsm/virt/migration.py",
> >> line 239, in _setupVdsConnection
> >> client = self._createClient(port)
> >>   File "/usr/lib/python2.7/site-packages/vdsm/virt/migration.py",
> >> line 227, in _createClient
> >> client_socket = utils.create_connected_socket(host, int(port),
> >> sslctx)
> >>   File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 435, in
> >> create_connected_socket
> >> socket.AF_UNSPEC, socket.SOCK_STREAM)
> >> gaierror: [Errno -2] Name or service not known
> >> 2021-12-10 16:18:22,888+0100 INFO  (jsonrpc/7) [api.virt] START
> >> getMigrationStatus() from=:::10.1.2.51,46546,
> >> vmId=11f3a2aa-7951-4064-92f9-bb8ab515373b (api:48)
> >> 2021-12-10 16:18:22,888+0100 INFO  (jsonrpc/7) [api.virt] FINISH
> >> getMigrationStatus return={'status': {'message': 'Done', 'code': 0},
> >> 'migrationStats': {'status': {'message': 'Fatal error during
> >> migration', 'code': 12}, 'progress': 0}} from=:::10.1.2.51,46546,
> >> vmId=11f3a2aa-7951-4064-92f9-bb8ab515373b (api:54)
> >> 2021-12-10 16:18:22,889+0100 INFO  (jsonrpc/7)
> >> [jsonrpc.JsonRpcServer] RPC call VM.getMigrationStatus succeeded in
> >> 0.00 seconds (__init__:312)
> >> 2021-12-10 16:18:23,431+0100 INFO  (jsonrpc/3)
> >> [jsonrpc.JsonRpcServer] RPC call Host.ping2 succeeded in 0.00 seconds
> >> (__init__:312)
> >>
> >> Any ideas?
> >>
> >> /niklas
> >>

[ovirt-users] Re: Upgrading 4.3.7 -> 4.4.9 :: Can't migrate vm from old to new host

2021-12-13 Thread Niklas Larsson via Users 

Hi,

we are using static ip, and the iptable-save is pretty empty - all rules 
are ACCEPT as default.


We are doing this in our lab environment, not yet i production - so it's 
not affecting anything yet.


/niklas

On 2021-12-10 17:37, Nathanaël Blanchet wrote:

Hi,

Is your migration network provisionned by DHCP?

If so, there is a known bug that prevents NetworkManager to set ip 
rule table for your migration network, and it won't be fixed before 
4.5 release.


As a workaround, you can set the protocol to static or manually assign 
rule table to 0 as folowing on all on your hosts:


nmcli connection mod migration ipv4.route-table 0 && nmcli con up 
migration


Le 10/12/2021 à 17:07, Niklas Larsson via Users a écrit :

Hi,

we are trying to upgrade 4.3.7 -> 4.4.9 (Ovirt-Node, hosted engine). 
And things looks good until we try to migrate VM from 4.3.7 host to 
the 4.4.9 host, it fails with an generic error - and in below is from 
the vsdm.log from the 4.3.7 host.


Migrating VM from 4.4.9 host -> 4.3.7 host works.

Upgraded the 4.3.7 to 4.3.10 - did not solve it

Log from the 4.3 host:
2021-12-10 16:18:22,829+0100 INFO  (jsonrpc/1) [api.virt] START 
migrate(params={u'incomingLimit': 2, u'src': 
u'kvm22.shg.mgn.weblink.se', u'dstqemu': u'10.1.2.111', 
u'autoConverge': u'true', u'tunneled': u'false', u'enableGuestEvents': T
rue, u'dst': u'kvm21.shg.mgn.weblink.se:54321', 
u'convergenceSchedule': {u'init': [{u'params': [u'100'], u'name': 
u'setDowntime'}], u'stalling': [{u'action': {u'params': [u'150'], 
u'name': u'setDowntime'}, u'limit': 1}, {u'action': {u'params': 
[u'200'], u'name': u'setDowntime'}, u'limit': 2}, {u'action': 
{u'params': [u'300'], u'name': u'setDowntime'}, u'limit': 3}, 
{u'action': {u'params': [u'400'], u'name': u'setDowntime'}, u'limit': 
4}, {u'action': {u'params': [u'500'], u'name': u'setDowntime'}, 
u'limit': 6}, {u'action': {u'params': [], u'name': u'abort'}, 
u'limit': -1}]}, u'vmId': u'11f3a2aa-7951-4064-92f9-bb8ab515373b', 
u'abortOnError': u'true', u'outgoingLimit': 2, u'compressed': 
u'false', u'maxBandwidth': 62, u'method': u'online'}) 
from=:::10.1.2.51,46546, 
flow_id=03aca28c-00c9-4b58-a1e8-3aa355e162c2, 
vmId=11f3a2aa-7951-4064-92f9-bb8ab515373b (api:48)
2021-12-10 16:18:22,831+0100 INFO  (jsonrpc/1) [api.virt] FINISH 
migrate return={'status': {'message': 'Migration in progress', 
'code': 0}, 'progress': 0} from=:::10.1.2.51,46546, 
flow_id=03aca28c-00c9-4b58-a1e8-3aa355e162c2, 
vmId=11f3a2aa-7951-4064-92f9-bb8ab515373b (api:54)
2021-12-10 16:18:22,831+0100 INFO  (jsonrpc/1) 
[jsonrpc.JsonRpcServer] RPC call VM.migrate succeeded in 0.01 seconds 
(__init__:312)
2021-12-10 16:18:22,873+0100 ERROR (migsrc/11f3a2aa) [virt.vm] 
(vmId='11f3a2aa-7951-4064-92f9-bb8ab515373b') [Errno -2] Name or 
service not known (migration:282)
2021-12-10 16:18:22,875+0100 ERROR (migsrc/11f3a2aa) [virt.vm] 
(vmId='11f3a2aa-7951-4064-92f9-bb8ab515373b') Failed to migrate 
(migration:450)

Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/vdsm/virt/migration.py", 
line 402, in _regular_run

    self._setupVdsConnection()
  File "/usr/lib/python2.7/site-packages/vdsm/virt/migration.py", 
line 239, in _setupVdsConnection

    client = self._createClient(port)
  File "/usr/lib/python2.7/site-packages/vdsm/virt/migration.py", 
line 227, in _createClient
    client_socket = utils.create_connected_socket(host, int(port), 
sslctx)
  File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 435, in 
create_connected_socket

    socket.AF_UNSPEC, socket.SOCK_STREAM)
gaierror: [Errno -2] Name or service not known
2021-12-10 16:18:22,888+0100 INFO  (jsonrpc/7) [api.virt] START 
getMigrationStatus() from=:::10.1.2.51,46546, 
vmId=11f3a2aa-7951-4064-92f9-bb8ab515373b (api:48)
2021-12-10 16:18:22,888+0100 INFO  (jsonrpc/7) [api.virt] FINISH 
getMigrationStatus return={'status': {'message': 'Done', 'code': 0}, 
'migrationStats': {'status': {'message': 'Fatal error during 
migration', 'code': 12}, 'progress': 0}} from=:::10.1.2.51,46546, 
vmId=11f3a2aa-7951-4064-92f9-bb8ab515373b (api:54)
2021-12-10 16:18:22,889+0100 INFO  (jsonrpc/7) 
[jsonrpc.JsonRpcServer] RPC call VM.getMigrationStatus succeeded in 
0.00 seconds (__init__:312)
2021-12-10 16:18:23,431+0100 INFO  (jsonrpc/3) 
[jsonrpc.JsonRpcServer] RPC call Host.ping2 succeeded in 0.00 seconds 
(__init__:312)


Any ideas?

/niklas
___
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/BWSVMZGNRNK5MBLJH3HSKZPRBCITL5XL/



___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: