=20 =20 On Tue, Feb 20, 2018 at 2:03 PM, Ji=C5=99=C3=AD Sl=C3=A9=C5=BEka <jiri.=

<mailto:jiri.slezka@slu.cz>> wrote: =20 Hi, =20 =20 Hi Ji=C5=99=C3=AD, =C2=A0 =20 =20 I would like to try import some ova files into our oVirt instance [=

[2] but I facing problems. =20 I have downloaded all ova images into one of hosts (ovirt01) into direcory /ova =20 ll /ova/ total 6532872 -rw-r--r--. 1 vdsm kvm 1160387072 Feb 16 16:21 HAAS-hpcowrie.ovf -rw-r--r--. 1 vdsm kvm 1111785984 Feb 16 16:22 HAAS-hpdio.ova -rw-r--r--. 1 vdsm kvm=C2=A0 846736896 Feb 16 16:22 HAAS-hpjdwpd.ov=

-rw-r--r--. 1 vdsm kvm=C2=A0 891043328 Feb 16 16:23 HAAS-hptelnetd.=

-rw-r--r--. 1 vdsm kvm=C2=A0 908222464 Feb 16 16:23 HAAS-hpuchotcp.=

-rw-r--r--. 1 vdsm kvm=C2=A0 880643072 Feb 16 16:24 HAAS-hpuchoudp.=

-rw-r--r--. 1 vdsm kvm=C2=A0 890833920 Feb 16 16:24 HAAS-hpuchoweb.=

=20 Then I tried to import them - from host ovirt01 and directory /ova =

spinner spins infinitly and nothing is happen. =20 =20 And does it work when you provide a path to the actual ova file, i.e., /ova/HAAS-hpdio.ova, rather than to the directory?

I cannot see anything relevant in vdsm log of host ovirt01. =20 In the engine.log of our standalone ovirt manager is just this relevant line =20 2018-02-20 12:35:04,289+01 INFO [org.ovirt.engine.core.common.utils.ansible.AnsibleExecutor] (defau=

task-31) [458990a7-b054-491a-904e-5c4fe44892c4] Executing Ansible command: ANSIBLE_STDOUT_CALLBACK=3Dovaqueryplugin [/usr/bin/ansible-playbook, --private-key=3D/etc/pki/ovirt-engine/keys/engine_id_rsa, --inventory=3D/tmp/ansible-inventory8237874608161160784, --extra-vars=3Dovirt_query_ova_path=3D/ova, /usr/share/ovirt-engine/playbooks/ovirt-ova-query.yml] [Logfile: /var/log/ovirt-engine/ova/ovirt-query-ova-ansible-20180220123504-ov=

<http://20180220123504-ovirt01.net>.slu.cz.log] =20 also there are two ansible processes which are still running (and m=

heavy load on system (load 9+ and growing, it looks like it eats al=

memory and system starts swapping)) =20 ovirt=C2=A0 =C2=A0 32087=C2=A0 3.3=C2=A0 0.0 332252=C2=A0 5980 ?=C2=

/usr/bin/python2 /usr/bin/ansible-playbook --private-key=3D/etc/pki/ovirt-engine/keys/engine_id_rsa --inventory=3D/tmp/ansible-inventory8237874608161160784 --extra-vars=3Dovirt_query_ova_path=3D/ova /usr/share/ovirt-engine/playbooks/ovirt-ova-query.yml ovirt=C2=A0 =C2=A0 32099 57.5 78.9 15972880 11215312 ?=C2=A0 =C2=A0=

/usr/bin/python2 /usr/bin/ansible-playbook --private-key=3D/etc/pki/ovirt-engine/keys/engine_id_rsa --inventory=3D/tmp/ansible-inventory8237874608161160784 --extra-vars=3Dovirt_query_ova_path=3D/ova /usr/share/ovirt-engine/playbooks/ovirt-ova-query.yml =20 playbook looks like =20 - hosts: all =C2=A0 remote_user: root =C2=A0 gather_facts: no =20 =C2=A0 roles: =C2=A0 =C2=A0 - ovirt-ova-query =20 and it looks like it only runs query_ova.py but on all hosts? =20 =20 No, the engine provides ansible the host to run on when it executes the=

playbook. It would only be executed on the selected host. =C2=A0 =20 =20 How does this work? ...or should it work? =20 =20 It should, especially that part of querying the OVA and is supposed to be really quick. Can you please share the engine log and /var/log/ovirt-engine/ova/ovirt-query-ova-ansible-20180220123504-ovirt0=

<http://20180220123504-ovirt01.net>.slu.cz.log ?

=C2=A0 =20 =20 I am using latest 4.2.1.7-1.el7.centos version =20 Cheers, Jiri Slezka =20 =20 [1] https://haas.cesnet.cz/#!index.md <https://haas.cesnet.cz/#!index.md> - Cesnet HAAS [2] https://haas.cesnet.cz/downloads/release-01/ <https://haas.cesnet.cz/downloads/release-01/> - Image repository =20 =20 _______________________________________________ Users mailing list Users(a)ovirt.org <mailto:Users@ovirt.org> http://lists.ovirt.org/mailman/listinfo/users <http://lists.ovirt.org/mailman/listinfo/users> =20 =20

=20 =20 On Tue, Feb 20, 2018 at 3:49 PM, Ji=C5=99=C3=AD Sl=C3=A9=C5=BEka <jiri.=

<mailto:jiri.slezka@slu.cz>> wrote: =20 Hi Arik, =20 On 02/20/2018 01:22 PM, Arik Hadas wrote: > > > On Tue, Feb 20, 2018 at 2:03 PM, Ji=C5=99=C3=AD Sl=C3=A9=C5=BEka =

> <mailto:jiri.slezka@slu.cz <mailto:jiri.slezka@slu.cz>>> wrote: > >=C2=A0 =C2=A0 =C2=A0Hi, > > > Hi Ji=C5=99=C3=AD, > =C2=A0 > > >=C2=A0 =C2=A0 =C2=A0I would like to try import some ova files into=

>=C2=A0 =C2=A0 =C2=A0[2] but I facing problems. > >=C2=A0 =C2=A0 =C2=A0I have downloaded all ova images into one of h=

>=C2=A0 =C2=A0 =C2=A0direcory /ova > >=C2=A0 =C2=A0 =C2=A0ll /ova/ >=C2=A0 =C2=A0 =C2=A0total 6532872 >=C2=A0 =C2=A0 =C2=A0-rw-r--r--. 1 vdsm kvm 1160387072 Feb 16 16:21=

>=C2=A0 =C2=A0 =C2=A0-rw-r--r--. 1 vdsm kvm 1111785984 Feb 16 16:22=

>=C2=A0 =C2=A0 =C2=A0-rw-r--r--. 1 vdsm kvm=C2=A0 846736896 Feb 16 =

>=C2=A0 =C2=A0 =C2=A0-rw-r--r--. 1 vdsm kvm=C2=A0 891043328 Feb 16 =

>=C2=A0 =C2=A0 =C2=A0-rw-r--r--. 1 vdsm kvm=C2=A0 908222464 Feb 16 =

>=C2=A0 =C2=A0 =C2=A0-rw-r--r--. 1 vdsm kvm=C2=A0 880643072 Feb 16 =

>=C2=A0 =C2=A0 =C2=A0-rw-r--r--. 1 vdsm kvm=C2=A0 890833920 Feb 16 =

> >=C2=A0 =C2=A0 =C2=A0Then I tried to import them - from host ovirt0=

>=C2=A0 =C2=A0 =C2=A0spinner spins infinitly and nothing is happen.=

> > > And does it work when you provide a path to the actual ova file, =

> /ova/HAAS-hpdio.ova, rather than to the directory? =20 this time it ends with "Failed to load VM configuration from OVA fi=

/ova/HAAS-hpdio.ova" error.=C2=A0 =20 =20 Note that the logic that is applied on a specified folder is "try fetching an 'ova folder' out of the destination folder" rather than "list all the ova files inside the specified folder". It seems that you=

expected the former output since there are no disks in that folder, rig=

>=C2=A0 =C2=A0 =C2=A0I cannot see anything relevant in vdsm log of =

> >=C2=A0 =C2=A0 =C2=A0In the engine.log of our standalone ovirt mana=

>=C2=A0 =C2=A0 =C2=A0relevant line > >=C2=A0 =C2=A0 =C2=A02018-02-20 12:35:04,289+01 INFO >=C2=A0 =C2=A0 =C2=A0[org.ovirt.engine.core.common.utils.ansible.An=

>=C2=A0 =C2=A0 =C2=A0task-31) [458990a7-b054-491a-904e-5c4fe44892c4=

>=C2=A0 =C2=A0 =C2=A0command: ANSIBLE_STDOUT_CALLBACK=3Dovaqueryplu=

>=C2=A0 =C2=A0 =C2=A0[/usr/bin/ansible-playbook, >=C2=A0 =C2=A0 =C2=A0--private-key=3D/etc/pki/ovirt-engine/keys/eng=

>=C2=A0 =C2=A0 =C2=A0--inventory=3D/tmp/ansible-inventory8237874608=

>=C2=A0 =C2=A0 =C2=A0--extra-vars=3Dovirt_query_ova_path=3D/ova, >=C2=A0 =C2=A0 =C2=A0/usr/share/ovirt-engine/playbooks/ovirt-ova-qu=

>=C2=A0 =C2=A0 =C2=A0/var/log/ovirt-engine/ova/ovirt-query-ova-ansi=

<http://ovirt-query-ova-ansible-20180220123504-ovirt01.net> >=C2=A0 =C2=A0 =C2=A0<http://20180220123504-ovirt01.net <http://20180220123504-ovirt01.net>>.slu.cz.log] > >=C2=A0 =C2=A0 =C2=A0also there are two ansible processes which are=

(and makes >=C2=A0 =C2=A0 =C2=A0heavy load on system (load 9+ and growing, it =

eats all the >=C2=A0 =C2=A0 =C2=A0memory and system starts swapping)) > >=C2=A0 =C2=A0 =C2=A0ovirt=C2=A0 =C2=A0 32087=C2=A0 3.3=C2=A0 0.0 3=

>=C2=A0 =C2=A0 =C2=A0/usr/bin/python2 /usr/bin/ansible-playbook >=C2=A0 =C2=A0 =C2=A0--private-key=3D/etc/pki/ovirt-engine/keys/eng=

>=C2=A0 =C2=A0 =C2=A0--inventory=3D/tmp/ansible-inventory8237874608=

>=C2=A0 =C2=A0 =C2=A0--extra-vars=3Dovirt_query_ova_path=3D/ova >=C2=A0 =C2=A0 =C2=A0/usr/share/ovirt-engine/playbooks/ovirt-ova-qu=

>=C2=A0 =C2=A0 =C2=A0ovirt=C2=A0 =C2=A0 32099 57.5 78.9 15972880 11=

>=C2=A0 =C2=A0 =C2=A0/usr/bin/python2 /usr/bin/ansible-playbook >=C2=A0 =C2=A0 =C2=A0--private-key=3D/etc/pki/ovirt-engine/keys/eng=

>=C2=A0 =C2=A0 =C2=A0--inventory=3D/tmp/ansible-inventory8237874608=

>=C2=A0 =C2=A0 =C2=A0--extra-vars=3Dovirt_query_ova_path=3D/ova >=C2=A0 =C2=A0 =C2=A0/usr/share/ovirt-engine/playbooks/ovirt-ova-qu=

> >=C2=A0 =C2=A0 =C2=A0playbook looks like > >=C2=A0 =C2=A0 =C2=A0- hosts: all >=C2=A0 =C2=A0 =C2=A0=C2=A0 remote_user: root >=C2=A0 =C2=A0 =C2=A0=C2=A0 gather_facts: no > >=C2=A0 =C2=A0 =C2=A0=C2=A0 roles: >=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 - ovirt-ova-query > >=C2=A0 =C2=A0 =C2=A0and it looks like it only runs query_ova.py bu=

> > > No, the engine provides ansible the host to run on when it executes the > playbook. > It would only be executed on the selected host. > =C2=A0 > > >=C2=A0 =C2=A0 =C2=A0How does this work? ...or should it work? > > > It should, especially that part of querying the OVA and is suppos=

> be really quick. > Can you please share the engine log and > /var/log/ovirt-engine/ova/ovirt-query-ova-ansible-20180220123504-ov=

<http://ovirt-query-ova-ansible-20180220123504-ovirt01.net> > <http://20180220123504-ovirt01.net <http://20180220123504-ovirt01.net>>.slu.cz.log ? =20 engine log is here: =20 https://pastebin.com/nWWM3UUq =20 =20 Thanks. Alright, so now the configuration is fetched but its processing fails. We fixed many issues in this area recently, but it appears that something is wrong with the actual size of the disk within the ovf file=

that resides inside this ova file. Can you please share that ovf file that resides inside=C2=A0/ova/HAAS-h=

file /var/log/ovirt-engine/ova/ovirt-query-ova-ansible-20180220123504-ov=

<http://ovirt-query-ova-ansible-20180220123504-ovirt01.net> in the fact does not exists (nor folder /var/log/ovirt-engine/ova/)=

=20 =20 This issue is also resolved in 4.2.2. In the meantime, please create the =C2=A0/var/log/ovirt-engine/ova/ fol=

manually and make sure its permissions match the ones of the other folders in =C2=A0/var/log/ovirt-engine.

Cheers, =20 Jiri Slezka =20 > =C2=A0 > > >=C2=A0 =C2=A0 =C2=A0I am using latest 4.2.1.7-1.el7.centos version=

> >=C2=A0 =C2=A0 =C2=A0Cheers, >=C2=A0 =C2=A0 =C2=A0Jiri Slezka > > >=C2=A0 =C2=A0 =C2=A0[1] https://haas.cesnet.cz/#!index.md <https:/=

>=C2=A0 =C2=A0 =C2=A0<https://haas.cesnet.cz/#!index.md <https://haas.cesnet.cz/#!index.md>> - Cesnet HAAS >=C2=A0 =C2=A0 =C2=A0[2] https://haas.cesnet.cz/downloads/release-0=

<https://haas.cesnet.cz/downloads/release-01/> >=C2=A0 =C2=A0 =C2=A0<https://haas.cesnet.cz/downloads/release-01/ <https://haas.cesnet.cz/downloads/release-01/>> - Image repository > > >=C2=A0 =C2=A0 =C2=A0______________________________________________=

>=C2=A0 =C2=A0 =C2=A0Users mailing list >=C2=A0 =C2=A0 =C2=A0Users(a)ovirt.org <mailto:Users@ovirt.org> <mailto:Users@ovirt.org <mailto:Users@ovirt.org>> >=C2=A0 =C2=A0 =C2=A0http://lists.ovirt.org/mailman/listinfo/users <http://lists.ovirt.org/mailman/listinfo/users> >=C2=A0 =C2=A0 =C2=A0<http://lists.ovirt.org/mailman/listinfo/users=

<http://lists.ovirt.org/mailman/listinfo/users>> > > =20 =20 =20 _______________________________________________ Users mailing list Users(a)ovirt.org <mailto:Users@ovirt.org> http://lists.ovirt.org/mailman/listinfo/users <http://lists.ovirt.org/mailman/listinfo/users> =20 =20

=20 =20 On Tue, Feb 20, 2018 at 6:37 PM, Ji=C5=99=C3=AD Sl=C3=A9=C5=BEka <jiri.=

<mailto:jiri.slezka@slu.cz>> wrote: =20 On 02/20/2018 03:48 PM, Arik Hadas wrote: > > > On Tue, Feb 20, 2018 at 3:49 PM, Ji=C5=99=C3=AD Sl=C3=A9=C5=BEka =

> <mailto:jiri.slezka@slu.cz <mailto:jiri.slezka@slu.cz>>> wrote: > >=C2=A0 =C2=A0 =C2=A0Hi Arik, > >=C2=A0 =C2=A0 =C2=A0On 02/20/2018 01:22 PM, Arik Hadas wrote: >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> On Tue, Feb 20, 2018 at 2:03 PM, Ji=C5=99=C3=

<mailto:jiri.slezka@slu.cz <mailto:jiri.slezka@slu.cz>> >=C2=A0 =C2=A0 =C2=A0> <mailto:jiri.slezka@slu.cz <mailto:jiri.slez=

<mailto:jiri.slezka@slu.cz <mailto:jiri.slezka@slu.cz>>>> wrote: >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Hi, >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> Hi Ji=C5=99=C3=AD, >=C2=A0 =C2=A0 =C2=A0> =C2=A0 >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0I would like to try impor=

instance [1] >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0[2] but I facing problems=

>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0I have downloaded all ova=

(ovirt01) into >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0direcory /ova >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0ll /ova/ >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0total 6532872 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-rw-r--r--. 1 vdsm kvm 11=

HAAS-hpcowrie.ovf >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-rw-r--r--. 1 vdsm kvm 11=

HAAS-hpdio.ova >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-rw-r--r--. 1 vdsm kvm=C2=

HAAS-hpjdwpd.ova >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-rw-r--r--. 1 vdsm kvm=C2=

HAAS-hptelnetd.ova >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-rw-r--r--. 1 vdsm kvm=C2=

HAAS-hpuchotcp.ova >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-rw-r--r--. 1 vdsm kvm=C2=

HAAS-hpuchoudp.ova >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-rw-r--r--. 1 vdsm kvm=C2=

HAAS-hpuchoweb.ova >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Then I tried to import th=

directory /ova but >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0spinner spins infinitly a=

>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> And does it work when you provide a path to =

file, i.e., >=C2=A0 =C2=A0 =C2=A0> /ova/HAAS-hpdio.ova, rather than to the dire=

> >=C2=A0 =C2=A0 =C2=A0this time it ends with "Failed to load VM conf=

OVA file: >=C2=A0 =C2=A0 =C2=A0/ova/HAAS-hpdio.ova" error.=C2=A0 > > > Note that the logic that is applied on a specified folder is "try=

> fetching an 'ova folder' out of the destination folder" rather th=

> "list all the ova files inside the specified folder". It seems that you > expected the former output since there are no disks in that folder, right? =20 yes, It would be more user friendly to list all ova files and then select which one to import (like listing all vms in vmware import) =20 Maybe description of path field in manager should be "Path to ova f=

instead of "Path" :-) =20 =20 Sorry, I obviously meant 'latter' rather than 'former' before.. Yeah, I agree that would be better, at least until listing the OVA file=

in the folder is implemented (that was the original plan, btw) - could you please file a bug?

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0I cannot see anything rel=

>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0In the engine.log of our =

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0relevant line >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A02018-02-20 12:35:04,289+0=

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0[org.ovirt.engine.core.co=

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0task-31) [458990a7-b054-4=

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0command: ANSIBLE_STDOUT_C=

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0[/usr/bin/ansible-playboo=

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0--private-key=3D/etc/pki/=

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0--inventory=3D/tmp/ansibl=

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0--extra-vars=3Dovirt_quer=

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0/usr/share/ovirt-engine/p=

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0/var/log/ovirt-engine/ova=

<http://ovirt-query-ova-ansible-20180220123504-ovirt01.net> >=C2=A0 =C2=A0 =C2=A0<http://ovirt-query-ova-ansible-20180220123504=

<http://ovirt-query-ova-ansible-20180220123504-ovirt01.net>> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0<http://20180220123504-ov=

<http://20180220123504-ovirt01.net> >=C2=A0 =C2=A0 =C2=A0<http://20180220123504-ovirt01.net <http://20180220123504-ovirt01.net>>>.slu.cz.log] >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0also there are two ansibl=

>=C2=A0 =C2=A0 =C2=A0(and makes >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0heavy load on system (loa=

>=C2=A0 =C2=A0 =C2=A0eats all the >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0memory and system starts =

>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0ovirt=C2=A0 =C2=A0 32087=C2=

=C2=A012:35=C2=A0 =C2=A00:41 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0/usr/bin/python2 /usr/bin=

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0--private-key=3D/etc/pki/=

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0--inventory=3D/tmp/ansibl=

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0--extra-vars=3Dovirt_quer=

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0/usr/share/ovirt-engine/p=

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0ovirt=C2=A0 =C2=A0 32099 =

12:35=C2=A0 11:52 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0/usr/bin/python2 /usr/bin=

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0--private-key=3D/etc/pki/=

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0--inventory=3D/tmp/ansibl=

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0--extra-vars=3Dovirt_quer=

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0/usr/share/ovirt-engine/p=

>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0playbook looks like >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0- hosts: all >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 remote_user: root >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 gather_facts: no >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 roles: >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 - ovirt-ova=

>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0and it looks like it only=

hosts? >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> No, the engine provides ansible the host to =

>=C2=A0 =C2=A0 =C2=A0executes the >=C2=A0 =C2=A0 =C2=A0> playbook. >=C2=A0 =C2=A0 =C2=A0> It would only be executed on the selected ho=

>=C2=A0 =C2=A0 =C2=A0> =C2=A0 >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0How does this work? ...or=

>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> It should, especially that part of querying =

supposed to >=C2=A0 =C2=A0 =C2=A0> be really quick. >=C2=A0 =C2=A0 =C2=A0> Can you please share the engine log and >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0/var/log/ovirt-engine/ova/ovirt-query-ova-ansible-20180220123=

<http://ovirt-query-ova-ansible-20180220123504-ovirt01.net> >=C2=A0 =C2=A0 =C2=A0<http://ovirt-query-ova-ansible-20180220123504=

<http://ovirt-query-ova-ansible-20180220123504-ovirt01.net>> >=C2=A0 =C2=A0 =C2=A0> <http://20180220123504-ovirt01.net <http://20180220123504-ovirt01.net> >=C2=A0 =C2=A0 =C2=A0<http://20180220123504-ovirt01.net <http://20180220123504-ovirt01.net>>>.slu.cz.log ? > >=C2=A0 =C2=A0 =C2=A0engine log is here: > >=C2=A0 =C2=A0 =C2=A0https://pastebin.com/nWWM3UUq > > > Thanks. > Alright, so now the configuration is fetched but its processing f=

> We fixed many issues in this area recently, but it appears that > something is wrong with the actual size of the disk within the ov=

> that resides inside this ova file. > Can you please share that ovf file that resides inside=C2=A0/ova/=

=20 file HAAS-hpdio.ova HAAS-hpdio.ova: POSIX tar archive (GNU) =20 [root@ovirt01 backup]# tar xvf HAAS-hpdio.ova HAAS-hpdio.ovf HAAS-hpdio-disk001.vmdk =20 file HAAS-hpdio.ovf is here: =20 https://pastebin.com/80qAU0wB =20 =20 Thanks again. So that seems to be a VM that was exported from Virtual Box, right? They don't do anything that violates the OVF specification but they do some non-common things that we don't anticipate:

First, they don't specify the actual size of the disk and the current code in oVirt relies on that property. There is a workaround for this though: you can extract an OVA file, edi=

its OVF configuration - adding ovf:populatedSize=3D"X" (and change ovf:capacity as I'll describe next) to the Disk element inside the DiskSection and pack the OVA again (tar cvf <ovf_file> <disk_file) wher=

X is either: 1. the actual size of the vmdk file + some buffer (iirc, we used to tak=

15% of extra space for the conversion) 2. if you're using a file storage or you don't mind consuming more storage space on your block storage, simply set X to the virtual size o=

the disk (in bytes) as indicated by the ovf:capacity filed, e.g., ovf:populatedSize=3D"21474836480" in the case of HAAS-hpdio.ova. =20 Second, the virtual size (indicated by ovf:capacity) is specified in bytes. The specification says that the default unit of allocation shall=

be bytes, but practically every OVA file that I've ever saw specified i=

in GB and the current code in oVirt kind of assumes that this is the case without checking the ovf:capacityAllocationUnits attribute that could indicate the real unit of allocation [1]. Anyway, long story short, the virtual size of the disk should currently=

be specified in GB, e.g., ovf:populatedSize=3D"20" in the case of HAAS-hpdio.ova.

That should do it. If not, please share the OVA file and I will examine=

it in my environment.

=20 [1]=C2=A0https://github.com/oVirt/ovirt-engine/blob/master/backend/mana=

=20 =20 =20 >=C2=A0 =C2=A0 =C2=A0file >=C2=A0 =C2=A0 =C2=A0/var/log/ovirt-engine/ova/ovirt-query-ova-ansible-20180220123=

<http://ovirt-query-ova-ansible-20180220123504-ovirt01.net> >=C2=A0 =C2=A0 =C2=A0<http://ovirt-query-ova-ansible-20180220123504=

<http://ovirt-query-ova-ansible-20180220123504-ovirt01.net>> >=C2=A0 =C2=A0 =C2=A0in the fact does not exists (nor folder /var/l=

> > > This issue is also resolved in 4.2.2. > In the meantime, please create the =C2=A0/var/log/ovirt-engine/ov=

> manually and make sure its permissions match the ones of the othe=

> folders in =C2=A0/var/log/ovirt-engine. =20 ok, done. After another try there is this log file =20 /var/log/ovirt-engine/ova/ovirt-query-ova-ansible-20180220173005-ov=

<http://20180220173005-ovirt01.net>.slu.cz.log =20 https://pastebin.com/M5J44qur =20 =20 Is it the log of the execution of the ansible playbook that was provide=

with a path to the /ova folder? I'm interested in that in order to see how comes that its execution never completed.

=C2=A0 =20 =20 =20 >=C2=A0 =C2=A0 =C2=A0Cheers, > >=C2=A0 =C2=A0 =C2=A0Jiri Slezka > >=C2=A0 =C2=A0 =C2=A0> =C2=A0 >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0I am using latest 4.2.1.7=

>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Cheers, >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Jiri Slezka >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0[1] https://haas.cesnet.c=

<https://haas.cesnet.cz/#!index.md> <https://haas.cesnet.cz/#!index.md <https://haas.cesnet.cz/#!index.=

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0<https://haas.cesnet.cz/#=

>=C2=A0 =C2=A0 =C2=A0<https://haas.cesnet.cz/#!index.md <https://haas.cesnet.cz/#!index.md>>> - Cesnet HAAS >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0[2] https://haas.cesnet.c=

<https://haas.cesnet.cz/downloads/release-01/> >=C2=A0 =C2=A0 =C2=A0<https://haas.cesnet.cz/downloads/release-01/ <https://haas.cesnet.cz/downloads/release-01/>> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0<https://haas.cesnet.cz/d=

<https://haas.cesnet.cz/downloads/release-01/> >=C2=A0 =C2=A0 =C2=A0<https://haas.cesnet.cz/downloads/release-01/ <https://haas.cesnet.cz/downloads/release-01/>>> - Image repository=

>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0_________________________=

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Users mailing list >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Users(a)ovirt.org <mailto:U=

<mailto:Users@ovirt.org>> >=C2=A0 =C2=A0 =C2=A0<mailto:Users@ovirt.org <mailto:Users@ovirt.or=

<mailto:Users@ovirt.org <mailto:Users@ovirt.org>>> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0http://lists.ovirt.org/ma=

<http://lists.ovirt.org/mailman/listinfo/users> >=C2=A0 =C2=A0 =C2=A0<http://lists.ovirt.org/mailman/listinfo/users=

<http://lists.ovirt.org/mailman/listinfo/users>> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0<http://lists.ovirt.org/m=

<http://lists.ovirt.org/mailman/listinfo/users> >=C2=A0 =C2=A0 =C2=A0<http://lists.ovirt.org/mailman/listinfo/users=

<http://lists.ovirt.org/mailman/listinfo/users>>> >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> > > > >=C2=A0 =C2=A0 =C2=A0______________________________________________=

<http://lists.ovirt.org/mailman/listinfo/users> >=C2=A0 =C2=A0 =C2=A0<http://lists.ovirt.org/mailman/listinfo/users=

<http://lists.ovirt.org/mailman/listinfo/users>> > > =20 =20 =20 _______________________________________________ Users mailing list Users(a)ovirt.org <mailto:Users@ovirt.org> http://lists.ovirt.org/mailman/listinfo/users <http://lists.ovirt.org/mailman/listinfo/users> =20 =20

On 02/21/2018 03:43 PM, Jiří Sléžka wrote: > On 02/20/2018 11:09 PM, Arik Hadas wrote: >> >> >> On Tue, Feb 20, 2018 at 6:37 PM, Jiří Sléžka <jiri.slezka(a)slu.cz >> <mailto:jiri.slezka@slu.cz>> wrote: >> >> On 02/20/2018 03:48 PM, Arik Hadas wrote: >> > >> > >> > On Tue, Feb 20, 2018 at 3:49 PM, Jiří Sléžka <jiri.slezka(a)slu.cz <mailto:jiri.slezka@slu.cz> >> > <mailto:jiri.slezka@slu.cz <mailto:jiri.slezka@slu.cz>>> wrote: >> > >> > Hi Arik, >> > >> > On 02/20/2018 01:22 PM, Arik Hadas wrote: >> > > >> > > >> > > On Tue, Feb 20, 2018 at 2:03 PM, Jiří Sléžka < jiri.slezka(a)slu.cz <mailto:jiri.slezka@slu.cz> >> <mailto:jiri.slezka@slu.cz <mailto:jiri.slezka@slu.cz>> >> > > <mailto:jiri.slezka@slu.cz <mailto:jiri.slezka@slu.cz> >> <mailto:jiri.slezka@slu.cz <mailto:jiri.slezka@slu.cz>>>> wrote: >> > > >> > > Hi, >> > > >> > > >> > > Hi Jiří, >> > > >> > > >> > > >> > > I would like to try import some ova files into our oVirt >> instance [1] >> > > [2] but I facing problems. >> > > >> > > I have downloaded all ova images into one of hosts >> (ovirt01) into >> > > direcory /ova >> > > >> > > ll /ova/ >> > > total 6532872 >> > > -rw-r--r--. 1 vdsm kvm 1160387072 Feb 16 16:21 >> HAAS-hpcowrie.ovf >> > > -rw-r--r--. 1 vdsm kvm 1111785984 Feb 16 16:22 >> HAAS-hpdio.ova >> > > -rw-r--r--. 1 vdsm kvm 846736896 Feb 16 16:22 >> HAAS-hpjdwpd.ova >> > > -rw-r--r--. 1 vdsm kvm 891043328 Feb 16 16:23 >> HAAS-hptelnetd.ova >> > > -rw-r--r--. 1 vdsm kvm 908222464 Feb 16 16:23 >> HAAS-hpuchotcp.ova >> > > -rw-r--r--. 1 vdsm kvm 880643072 Feb 16 16:24 >> HAAS-hpuchoudp.ova >> > > -rw-r--r--. 1 vdsm kvm 890833920 Feb 16 16:24 >> HAAS-hpuchoweb.ova >> > > >> > > Then I tried to import them - from host ovirt01 and >> directory /ova but >> > > spinner spins infinitly and nothing is happen. >> > > >> > > >> > > And does it work when you provide a path to the actual ova >> file, i.e., >> > > /ova/HAAS-hpdio.ova, rather than to the directory? >> > >> > this time it ends with "Failed to load VM configuration from >> OVA file: >> > /ova/HAAS-hpdio.ova" error. >> > >> > >> > Note that the logic that is applied on a specified folder is "try >> > fetching an 'ova folder' out of the destination folder" rather than >> > "list all the ova files inside the specified folder". It seems >> that you >> > expected the former output since there are no disks in that >> folder, right? >> >> yes, It would be more user friendly to list all ova files and then >> select which one to import (like listing all vms in vmware import) >> >> Maybe description of path field in manager should be "Path to ova file" >> instead of "Path" :-) >> >> >> Sorry, I obviously meant 'latter' rather than 'former' before.. >> Yeah, I agree that would be better, at least until listing the OVA files >> in the folder is implemented (that was the original plan, btw) - could >> you please file a bug? > > yes, sure > > >> > > I cannot see anything relevant in vdsm log of host ovirt01. >> > > >> > > In the engine.log of our standalone ovirt manager is just this >> > > relevant line >> > > >> > > 2018-02-20 12:35:04,289+01 INFO >> > > [org.ovirt.engine.core.common.utils.ansible.AnsibleExecutor] (default >> > > task-31) [458990a7-b054-491a-904e-5c4fe44892c4] Executing Ansible >> > > command: ANSIBLE_STDOUT_CALLBACK=ovaqueryplugin >> > > [/usr/bin/ansible-playbook, >> > > --private-key=/etc/pki/ovirt-engine/keys/engine_id_rsa, >> > > --inventory=/tmp/ansible-inventory8237874608161160784, >> > > --extra-vars=ovirt_query_ova_path=/ova, >> > > /usr/share/ovirt-engine/playbooks/ovirt-ova-query.yml] [Logfile: >> > > /var/log/ovirt-engine/ova/ovirt-query-ova-ansible- 20180220123504-ovirt01.net >> <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net> >> > <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net >> <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net>> >> > > <http://20180220123504-ovirt01.net >> <http://20180220123504-ovirt01.net> >> > <http://20180220123504-ovirt01.net >> <http://20180220123504-ovirt01.net>>>.slu.cz.log] >> > > >> > > also there are two ansible processes which are still running >> > (and makes >> > > heavy load on system (load 9+ and growing, it looks like it >> > eats all the >> > > memory and system starts swapping)) >> > > >> > > ovirt 32087 3.3 0.0 332252 5980 ? Sl >> 12:35 0:41 >> > > /usr/bin/python2 /usr/bin/ansible-playbook >> > > --private-key=/etc/pki/ovirt-engine/keys/engine_id_rsa >> > > --inventory=/tmp/ansible-inventory8237874608161160784 >> > > --extra-vars=ovirt_query_ova_path=/ova >> > > /usr/share/ovirt-engine/playbooks/ovirt-ova-query.yml >> > > ovirt 32099 57.5 78.9 15972880 11215312 ? R >> 12:35 11:52 >> > > /usr/bin/python2 /usr/bin/ansible-playbook >> > > --private-key=/etc/pki/ovirt-engine/keys/engine_id_rsa >> > > --inventory=/tmp/ansible-inventory8237874608161160784 >> > > --extra-vars=ovirt_query_ova_path=/ova >> > > /usr/share/ovirt-engine/playbooks/ovirt-ova-query.yml >> > > >> > > playbook looks like >> > > >> > > - hosts: all >> > > remote_user: root >> > > gather_facts: no >> > > >> > > roles: >> > > - ovirt-ova-query >> > > >> > > and it looks like it only runs query_ova.py but on all >> hosts? >> > > >> > > >> > > No, the engine provides ansible the host to run on when it >> > executes the >> > > playbook. >> > > It would only be executed on the selected host. >> > > >> > > >> > > >> > > How does this work? ...or should it work? >> > > >> > > >> > > It should, especially that part of querying the OVA and is >> supposed to >> > > be really quick. >> > > Can you please share the engine log and >> > > >> > >> /var/log/ovirt-engine/ova/ovirt-query-ova-ansible- 20180220123504-ovirt01.net >> <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net> >> > <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net >> <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net>> >> > > <http://20180220123504-ovirt01.net >> <http://20180220123504-ovirt01.net> >> > <http://20180220123504-ovirt01.net >> <http://20180220123504-ovirt01.net>>>.slu.cz.log ? >> > >> > engine log is here: >> > >> > https://pastebin.com/nWWM3UUq >> > >> > >> > Thanks. >> > Alright, so now the configuration is fetched but its processing fails. >> > We fixed many issues in this area recently, but it appears that >> > something is wrong with the actual size of the disk within the ovf file >> > that resides inside this ova file. >> > Can you please share that ovf file that resides inside /ova/HAAS-hpdio.ova? >> >> file HAAS-hpdio.ova >> HAAS-hpdio.ova: POSIX tar archive (GNU) >> >> [root@ovirt01 backup]# tar xvf HAAS-hpdio.ova >> HAAS-hpdio.ovf >> HAAS-hpdio-disk001.vmdk >> >> file HAAS-hpdio.ovf is here: >> >> https://pastebin.com/80qAU0wB >> >> >> Thanks again. >> So that seems to be a VM that was exported from Virtual Box, right? >> They don't do anything that violates the OVF specification but they do >> some non-common things that we don't anticipate: > > yes, it is most likely ova from VirtualBox > >> First, they don't specify the actual size of the disk and the current >> code in oVirt relies on that property. >> There is a workaround for this though: you can extract an OVA file, edit >> its OVF configuration - adding ovf:populatedSize="X" (and change >> ovf:capacity as I'll describe next) to the Disk element inside the >> DiskSection and pack the OVA again (tar cvf <ovf_file> <disk_file) where >> X is either: >> 1. the actual size of the vmdk file + some buffer (iirc, we used to take >> 15% of extra space for the conversion) >> 2. if you're using a file storage or you don't mind consuming more >> storage space on your block storage, simply set X to the virtual size of >> the disk (in bytes) as indicated by the ovf:capacity filed, e.g., >> ovf:populatedSize="21474836480" in the case of HAAS-hpdio.ova. >> >> Second, the virtual size (indicated by ovf:capacity) is specified in >> bytes. The specification says that the default unit of allocation shall >> be bytes, but practically every OVA file that I've ever saw specified it >> in GB and the current code in oVirt kind of assumes that this is the >> case without checking the ovf:capacityAllocationUnits attribute that >> could indicate the real unit of allocation [1]. >> Anyway, long story short, the virtual size of the disk should currently >> be specified in GB, e.g., ovf:populatedSize="20" in the case of >> HAAS-hpdio.ova. > > wow, thanks for this excellent explanation. I have changed this in ovf file > > ... > <Disk ovf:capacity="20" ovf:diskId="vmdisk2" ovf:populatedSize="20" ... > ... > > then I was able to import this mofified ova file (HAAS-hpdio_new.ova). > Interesting thing is that the vm was shown in vm list for while (with > state down with lock and status was initializing). After while this vm > disapeared :-o > > I am going to test it again and collect some logs... there are interesting logs in /var/log/vdsm/import/ at the host used for import http://mirror.slu.cz/tmp/ovirt-import.tar.bz2 first of them describes situation where I chose thick provisioning, second situation with thin provisioning interesting part is I believe libguestfs: command: run: qemu-img libguestfs: command: run: \ create libguestfs: command: run: \ -f qcow2 libguestfs: command: run: \ -o preallocation=off,compat=0.10 libguestfs: command: run: \ /rhev/data-center/mnt/blockSD/088e7ed9-84c7-4fbd-a570- f37fa986a772/images/d44e1890-3e42-420b-939c-dac1290e19af/ 9edcccbc-b244-4b94-acd3-3c8ee12bbbec libguestfs: command: run: \ 21474836480 Formatting '/rhev/data-center/mnt/blockSD/088e7ed9-84c7-4fbd- a570-f37fa986a772/images/d44e1890-3e42-420b-939c- dac1290e19af/9edcccbc-b244-4b94-acd3-3c8ee12bbbec', fmt=qcow2 size=21474836480 compat=0.10 encryption=off cluster_size=65536 preallocation=off lazy_refcounts=off refcount_bits=16 libguestfs: trace: vdsm_disk_create: disk_create = 0 qemu-img 'convert' '-p' '-n' '-f' 'qcow2' '-O' 'qcow2' '/var/tmp/v2vovl2dccbd.qcow2' '/rhev/data-center/mnt/blockSD/088e7ed9-84c7-4fbd- a570-f37fa986a772/images/d44e1890-3e42-420b-939c- dac1290e19af/9edcccbc-b244-4b94-acd3-3c8ee12bbbec' qemu-img: error while writing sector 1000960: No space left on device virt-v2v: error: qemu-img command failed, see earlier errors

> >> That should do it. If not, please share the OVA file and I will examine >> it in my environment. > > original file is at > > https://haas.cesnet.cz/downloads/release-01/HAAS-hpdio.ova > >> >> [1] https://github.com/oVirt/ovirt-engine/blob/master/ backend/manager/modules/utils/src/main/java/org/ovirt/ engine/core/utils/ovf/OvfOvaReader.java#L220 >> >> >> >> > file >> > >> /var/log/ovirt-engine/ova/ovirt-query-ova-ansible- 20180220123504-ovirt01.net >> <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net> >> > <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net >> <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net>> >> > in the fact does not exists (nor folder /var/log/ovirt-engine/ova/) >> > >> > >> > This issue is also resolved in 4.2.2. >> > In the meantime, please create the /var/log/ovirt-engine/ova/ folder >> > manually and make sure its permissions match the ones of the other >> > folders in /var/log/ovirt-engine. >> >> ok, done. After another try there is this log file >> >> /var/log/ovirt-engine/ova/ovirt-query-ova-ansible- 20180220173005-ovirt01.net >> <http://20180220173005-ovirt01.net>.slu.cz.log >> >> https://pastebin.com/M5J44qur >> >> >> Is it the log of the execution of the ansible playbook that was provided >> with a path to the /ova folder? >> I'm interested in that in order to see how comes that its execution >> never completed. > > well, I dont think so, it is log from import with full path to ova file > > > >> >> >> >> >> > Cheers, >> > >> > Jiri Slezka >> > >> > > >> > > >> > > >> > > I am using latest 4.2.1.7-1.el7.centos version >> > > >> > > Cheers, >> > > Jiri Slezka >> > > >> > > >> > > [1] https://haas.cesnet.cz/#!index.md >> <https://haas.cesnet.cz/#!index.md> >> <https://haas.cesnet.cz/#!index.md <https://haas.cesnet.cz/#! index.md>> >> > > <https://haas.cesnet.cz/#!index.md < https://haas.cesnet.cz/#!index.md> >> > <https://haas.cesnet.cz/#!index.md >> <https://haas.cesnet.cz/#!index.md>>> - Cesnet HAAS >> > > [2] https://haas.cesnet.cz/downloads/release-01/ >> <https://haas.cesnet.cz/downloads/release-01/> >> > <https://haas.cesnet.cz/downloads/release-01/ >> <https://haas.cesnet.cz/downloads/release-01/>> >> > > <https://haas.cesnet.cz/downloads/release-01/ >> <https://haas.cesnet.cz/downloads/release-01/> >> > <https://haas.cesnet.cz/downloads/release-01/ >> <https://haas.cesnet.cz/downloads/release-01/>>> - Image repository >> > > >> > > >> > > _______________________________________________ >> > > Users mailing list >> > > Users(a)ovirt.org <mailto:Users@ovirt.org> <mailto: Users(a)ovirt.org >> <mailto:Users@ovirt.org>> >> > <mailto:Users@ovirt.org <mailto:Users@ovirt.org> >> <mailto:Users@ovirt.org <mailto:Users@ovirt.org>>> >> > > http://lists.ovirt.org/mailman/listinfo/users >> <http://lists.ovirt.org/mailman/listinfo/users> >> > <http://lists.ovirt.org/mailman/listinfo/users >> <http://lists.ovirt.org/mailman/listinfo/users>> >> > > <http://lists.ovirt.org/mailman/listinfo/users >> <http://lists.ovirt.org/mailman/listinfo/users> >> > <http://lists.ovirt.org/mailman/listinfo/users >> <http://lists.ovirt.org/mailman/listinfo/users>>> >> > > >> > > >> > >> > >> > >> > _______________________________________________ >> > Users mailing list >> > Users(a)ovirt.org <mailto:Users@ovirt.org> >> <mailto:Users@ovirt.org <mailto:Users@ovirt.org>> >> > http://lists.ovirt.org/mailman/listinfo/users >> <http://lists.ovirt.org/mailman/listinfo/users> >> > <http://lists.ovirt.org/mailman/listinfo/users >> <http://lists.ovirt.org/mailman/listinfo/users>> >> > >> > >> >> >> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org <mailto:Users@ovirt.org> >> http://lists.ovirt.org/mailman/listinfo/users >> <http://lists.ovirt.org/mailman/listinfo/users> >> >> > > > > > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users

On 02/21/2018 05:35 PM, Arik Hadas wrote: > > > On Wed, Feb 21, 2018 at 6:03 PM, Jiří Sléžka <jiri.slezka(a)slu.cz > <mailto:jiri.slezka@slu.cz>> wrote: > > On 02/21/2018 03:43 PM, Jiří Sléžka wrote: > > On 02/20/2018 11:09 PM, Arik Hadas wrote: > >> > >> > >> On Tue, Feb 20, 2018 at 6:37 PM, Jiří Sléžka <jiri.slezka(a)slu.cz > <mailto:jiri.slezka@slu.cz> > >> <mailto:jiri.slezka@slu.cz <mailto:jiri.slezka@slu.cz>>> wrote: > >> > >> On 02/20/2018 03:48 PM, Arik Hadas wrote: > >> > > >> > > >> > On Tue, Feb 20, 2018 at 3:49 PM, Jiří Sléžka > <jiri.slezka(a)slu.cz <mailto:jiri.slezka@slu.cz> > <mailto:jiri.slezka@slu.cz <mailto:jiri.slezka@slu.cz>> > >> > <mailto:jiri.slezka@slu.cz <mailto:jiri.slezka@slu.cz> > <mailto:jiri.slezka@slu.cz <mailto:jiri.slezka@slu.cz>>>> wrote: > >> > > >> > Hi Arik, > >> > > >> > On 02/20/2018 01:22 PM, Arik Hadas wrote: > >> > > > >> > > > >> > > On Tue, Feb 20, 2018 at 2:03 PM, Jiří Sléžka > <jiri.slezka(a)slu.cz <mailto:jiri.slezka@slu.cz> > <mailto:jiri.slezka@slu.cz <mailto:jiri.slezka@slu.cz>> > >> <mailto:jiri.slezka@slu.cz <mailto:jiri.slezka@slu.cz> > <mailto:jiri.slezka@slu.cz <mailto:jiri.slezka@slu.cz>>> > >> > > <mailto:jiri.slezka@slu.cz > <mailto:jiri.slezka@slu.cz> <mailto:jiri.slezka@slu.cz > <mailto:jiri.slezka@slu.cz>> > >> <mailto:jiri.slezka@slu.cz <mailto:jiri.slezka@slu.cz> > <mailto:jiri.slezka@slu.cz <mailto:jiri.slezka@slu.cz>>>>> wrote: > >> > > > >> > > Hi, > >> > > > >> > > > >> > > Hi Jiří, > >> > > > >> > > > >> > > > >> > > I would like to try import some ova files into > our oVirt > >> instance [1] > >> > > [2] but I facing problems. > >> > > > >> > > I have downloaded all ova images into one of hosts > >> (ovirt01) into > >> > > direcory /ova > >> > > > >> > > ll /ova/ > >> > > total 6532872 > >> > > -rw-r--r--. 1 vdsm kvm 1160387072 Feb 16 16:21 > >> HAAS-hpcowrie.ovf > >> > > -rw-r--r--. 1 vdsm kvm 1111785984 Feb 16 16:22 > >> HAAS-hpdio.ova > >> > > -rw-r--r--. 1 vdsm kvm 846736896 Feb 16 16:22 > >> HAAS-hpjdwpd.ova > >> > > -rw-r--r--. 1 vdsm kvm 891043328 Feb 16 16:23 > >> HAAS-hptelnetd.ova > >> > > -rw-r--r--. 1 vdsm kvm 908222464 Feb 16 16:23 > >> HAAS-hpuchotcp.ova > >> > > -rw-r--r--. 1 vdsm kvm 880643072 Feb 16 16:24 > >> HAAS-hpuchoudp.ova > >> > > -rw-r--r--. 1 vdsm kvm 890833920 Feb 16 16:24 > >> HAAS-hpuchoweb.ova > >> > > > >> > > Then I tried to import them - from host ovirt01 and > >> directory /ova but > >> > > spinner spins infinitly and nothing is happen. > >> > > > >> > > > >> > > And does it work when you provide a path to the > actual ova > >> file, i.e., > >> > > /ova/HAAS-hpdio.ova, rather than to the directory? > >> > > >> > this time it ends with "Failed to load VM configuration > from > >> OVA file: > >> > /ova/HAAS-hpdio.ova" error. > >> > > >> > > >> > Note that the logic that is applied on a specified folder > is "try > >> > fetching an 'ova folder' out of the destination folder" > rather than > >> > "list all the ova files inside the specified folder". It seems > >> that you > >> > expected the former output since there are no disks in that > >> folder, right? > >> > >> yes, It would be more user friendly to list all ova files and > then > >> select which one to import (like listing all vms in vmware > import) > >> > >> Maybe description of path field in manager should be "Path to > ova file" > >> instead of "Path" :-) > >> > >> > >> Sorry, I obviously meant 'latter' rather than 'former' before.. > >> Yeah, I agree that would be better, at least until listing the > OVA files > >> in the folder is implemented (that was the original plan, btw) - > could > >> you please file a bug? > > > > yes, sure > > > > > >> > > I cannot see anything relevant in vdsm log of > host ovirt01. > >> > > > >> > > In the engine.log of our standalone ovirt manager > is just this > >> > > relevant line > >> > > > >> > > 2018-02-20 12:35:04,289+01 INFO > >> > > > [org.ovirt.engine.core.common.utils.ansible.AnsibleExecutor] (default > >> > > task-31) [458990a7-b054-491a-904e-5c4fe44892c4] > Executing Ansible > >> > > command: ANSIBLE_STDOUT_CALLBACK=ovaqueryplugin > >> > > [/usr/bin/ansible-playbook, > >> > > > --private-key=/etc/pki/ovirt-engine/keys/engine_id_rsa, > >> > > > --inventory=/tmp/ansible-inventory8237874608161160784, > >> > > --extra-vars=ovirt_query_ova_path=/ova, > >> > > > /usr/share/ovirt-engine/playbooks/ovirt-ova-query.yml] [Logfile: > >> > > > /var/log/ovirt-engine/ova/ovirt-query-ova-ansible- 20180220123504-ovirt01.net > <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net> > >> <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net > <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net>> > >> > > <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net > <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net> > >> <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net > <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net>>> > >> > > <http://20180220123504-ovirt01.net > <http://20180220123504-ovirt01.net> > >> <http://20180220123504-ovirt01.net > <http://20180220123504-ovirt01.net>> > >> > <http://20180220123504-ovirt01.net > <http://20180220123504-ovirt01.net> > >> <http://20180220123504-ovirt01.net > <http://20180220123504-ovirt01.net>>>>.slu.cz.log] > >> > > > >> > > also there are two ansible processes which are > still running > >> > (and makes > >> > > heavy load on system (load 9+ and growing, it > looks like it > >> > eats all the > >> > > memory and system starts swapping)) > >> > > > >> > > ovirt 32087 3.3 0.0 332252 5980 ? Sl > >> 12:35 0:41 > >> > > /usr/bin/python2 /usr/bin/ansible-playbook > >> > > > --private-key=/etc/pki/ovirt-engine/keys/engine_id_rsa > >> > > --inventory=/tmp/ansible- inventory8237874608161160784 > >> > > --extra-vars=ovirt_query_ova_path=/ova > >> > > /usr/share/ovirt-engine/ playbooks/ovirt-ova-query.yml > >> > > ovirt 32099 57.5 78.9 15972880 11215312 ? R > >> 12:35 11:52 > >> > > /usr/bin/python2 /usr/bin/ansible-playbook > >> > > > --private-key=/etc/pki/ovirt-engine/keys/engine_id_rsa > >> > > --inventory=/tmp/ansible- inventory8237874608161160784 > >> > > --extra-vars=ovirt_query_ova_path=/ova > >> > > /usr/share/ovirt-engine/ playbooks/ovirt-ova-query.yml > >> > > > >> > > playbook looks like > >> > > > >> > > - hosts: all > >> > > remote_user: root > >> > > gather_facts: no > >> > > > >> > > roles: > >> > > - ovirt-ova-query > >> > > > >> > > and it looks like it only runs query_ova.py but > on all > >> hosts? > >> > > > >> > > > >> > > No, the engine provides ansible the host to run on > when it > >> > executes the > >> > > playbook. > >> > > It would only be executed on the selected host. > >> > > > >> > > > >> > > > >> > > How does this work? ...or should it work? > >> > > > >> > > > >> > > It should, especially that part of querying the OVA > and is > >> supposed to > >> > > be really quick. > >> > > Can you please share the engine log and > >> > > > >> > > >> > /var/log/ovirt-engine/ova/ovirt-query-ova-ansible- 20180220123504-ovirt01.net > <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net> > >> <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net > <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net>> > >> > > <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net > <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net> > >> <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net > <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net>>> > >> > > <http://20180220123504-ovirt01.net > <http://20180220123504-ovirt01.net> > >> <http://20180220123504-ovirt01.net > <http://20180220123504-ovirt01.net>> > >> > <http://20180220123504-ovirt01.net > <http://20180220123504-ovirt01.net> > >> <http://20180220123504-ovirt01.net > <http://20180220123504-ovirt01.net>>>>.slu.cz.log ? > >> > > >> > engine log is here: > >> > > >> > https://pastebin.com/nWWM3UUq > >> > > >> > > >> > Thanks. > >> > Alright, so now the configuration is fetched but its > processing fails. > >> > We fixed many issues in this area recently, but it appears that > >> > something is wrong with the actual size of the disk within > the ovf file > >> > that resides inside this ova file. > >> > Can you please share that ovf file that resides > inside /ova/HAAS-hpdio.ova? > >> > >> file HAAS-hpdio.ova > >> HAAS-hpdio.ova: POSIX tar archive (GNU) > >> > >> [root@ovirt01 backup]# tar xvf HAAS-hpdio.ova > >> HAAS-hpdio.ovf > >> HAAS-hpdio-disk001.vmdk > >> > >> file HAAS-hpdio.ovf is here: > >> > >> https://pastebin.com/80qAU0wB > >> > >> > >> Thanks again. > >> So that seems to be a VM that was exported from Virtual Box, right? > >> They don't do anything that violates the OVF specification but > they do > >> some non-common things that we don't anticipate: > > > > yes, it is most likely ova from VirtualBox > > > >> First, they don't specify the actual size of the disk and the current > >> code in oVirt relies on that property. > >> There is a workaround for this though: you can extract an OVA > file, edit > >> its OVF configuration - adding ovf:populatedSize="X" (and change > >> ovf:capacity as I'll describe next) to the Disk element inside the > >> DiskSection and pack the OVA again (tar cvf <ovf_file> > <disk_file) where > >> X is either: > >> 1. the actual size of the vmdk file + some buffer (iirc, we used > to take > >> 15% of extra space for the conversion) > >> 2. if you're using a file storage or you don't mind consuming more > >> storage space on your block storage, simply set X to the virtual > size of > >> the disk (in bytes) as indicated by the ovf:capacity filed, e.g., > >> ovf:populatedSize="21474836480" in the case of HAAS-hpdio.ova. > >> > >> Second, the virtual size (indicated by ovf:capacity) is specified in > >> bytes. The specification says that the default unit of allocation > shall > >> be bytes, but practically every OVA file that I've ever saw > specified it > >> in GB and the current code in oVirt kind of assumes that this is the > >> case without checking the ovf:capacityAllocationUnits attribute that > >> could indicate the real unit of allocation [1]. > >> Anyway, long story short, the virtual size of the disk should > currently > >> be specified in GB, e.g., ovf:populatedSize="20" in the case of > >> HAAS-hpdio.ova. > > > > wow, thanks for this excellent explanation. I have changed this in > ovf file > > > > ... > > <Disk ovf:capacity="20" ovf:diskId="vmdisk2" > ovf:populatedSize="20" ... > > ... > > > > then I was able to import this mofified ova file (HAAS-hpdio_new.ova). > > Interesting thing is that the vm was shown in vm list for while (with > > state down with lock and status was initializing). After while this vm > > disapeared :-o > > > > I am going to test it again and collect some logs... > > there are interesting logs in /var/log/vdsm/import/ at the host used for > import > > http://mirror.slu.cz/tmp/ovirt-import.tar.bz2 > <http://mirror.slu.cz/tmp/ovirt-import.tar.bz2> > > first of them describes situation where I chose thick provisioning, > second situation with thin provisioning > > interesting part is I believe > > libguestfs: command: run: qemu-img > libguestfs: command: run: \ create > libguestfs: command: run: \ -f qcow2 > libguestfs: command: run: \ -o preallocation=off,compat=0.10 > libguestfs: command: run: \ > /rhev/data-center/mnt/blockSD/088e7ed9-84c7-4fbd-a570- f37fa986a772/images/d44e1890-3e42-420b-939c-dac1290e19af/ 9edcccbc-b244-4b94-acd3-3c8ee12bbbec > libguestfs: command: run: \ 21474836480 > Formatting > '/rhev/data-center/mnt/blockSD/088e7ed9-84c7-4fbd- a570-f37fa986a772/images/d44e1890-3e42-420b-939c- dac1290e19af/9edcccbc-b244-4b94-acd3-3c8ee12bbbec', > fmt=qcow2 size=21474836480 compat=0.10 encryption=off cluster_size=65536 > preallocation=off lazy_refcounts=off refcount_bits=16 > libguestfs: trace: vdsm_disk_create: disk_create = 0 > qemu-img 'convert' '-p' '-n' '-f' 'qcow2' '-O' 'qcow2' > '/var/tmp/v2vovl2dccbd.qcow2' > '/rhev/data-center/mnt/blockSD/088e7ed9-84c7-4fbd- a570-f37fa986a772/images/d44e1890-3e42-420b-939c- dac1290e19af/9edcccbc-b244-4b94-acd3-3c8ee12bbbec' > qemu-img: error while writing sector 1000960: No space left on device > > virt-v2v: error: qemu-img command failed, see earlier errors > > > > Sorry again, I made a mistake in: > "Anyway, long story short, the virtual size of the disk should currently > be specified in GB, e.g., ovf:populatedSize="20" in the case of > HAAS-hpdio.ova." > I should have write ovf:capacity="20". > So if you wish the actual size of the disk to be 20GB (which means the > disk is preallocated), the disk element should be set with: > <Disk ovf:capacity="20" ovf:diskId="vmdisk2" > ovf:populatedSize="21474836480" ... now I have this inf ovf file <Disk ovf:capacity="20" ovf:diskId="vmdisk2" ovf:populatedSize="21474836480"... but while import it fails again, but in this case faster. It looks like SPM cannot create disk image log from SPM host... 2018-02-21 18:02:03,599+0100 INFO (jsonrpc/1) [vdsm.api] START createVolume(sdUUID=u'69f6b3e7-d754-44cf-a665-9d7128260401', spUUID=u'00000002-0002-0002-0002-0000000002b9', imgUUID=u'0a5c4ecb-2c04-4f96-858a-4f74915d5caa', size=u'20', volFormat=4, preallocate=2, diskType=u'DATA', volUUID=u'bd3ae91a-3b37-4610-9ad3-6c5fdc6cc9b0', desc=u'{"DiskAlias":"HAAS-hpdio-disk001.vmdk","DiskDescription":""}', srcImgUUID=u'00000000-0000-0000-0000-000000000000', srcVolUUID=u'00000000-0000-0000-0000-000000000000', initialSize=u'21474836480') from=::ffff:193.84.206.172,53154, flow_id=e27cd35a-dc4e-4e72-a3ef-aa5b67c2bdab, task_id=e7598aa1-420a-4612-9ee8-03012b1277d9 (api:46) 2018-02-21 18:02:03,603+0100 INFO (jsonrpc/1) [IOProcessClient] Starting client ioprocess-3931 (__init__:330) 2018-02-21 18:02:03,638+0100 INFO (ioprocess/56120) [IOProcess] Starting ioprocess (__init__:452) 2018-02-21 18:02:03,661+0100 INFO (jsonrpc/1) [vdsm.api] FINISH createVolume return=None from=::ffff:193.84.206.172,53154, flow_id=e27cd35a-dc4e-4e72-a3ef-aa5b67c2bdab, task_id=e7598aa1-420a-4612-9ee8-03012b1277d9 (api:52) 2018-02-21 18:02:03,692+0100 INFO (jsonrpc/1) [jsonrpc.JsonRpcServer] RPC call Volume.create succeeded in 0.09 seconds (__init__:573) 2018-02-21 18:02:03,694+0100 INFO (tasks/1) [storage.ThreadPool.WorkerThread] START task e7598aa1-420a-4612-9ee8-03012b1277d9 (cmd=<bound method Task.commit of <vdsm.storage.task.Task instance at 0x3faa050>>, args=None) (threadPool:208) 2018-02-21 18:02:03,995+0100 INFO (tasks/1) [storage.StorageDomain] Create placeholder /rhev/data-center/mnt/blockSD/69f6b3e7-d754-44cf-a665- 9d7128260401/images/0a5c4ecb-2c04-4f96-858a-4f74915d5caa for image's volumes (sd:1244) 2018-02-21 18:02:04,016+0100 INFO (tasks/1) [storage.Volume] Creating volume bd3ae91a-3b37-4610-9ad3-6c5fdc6cc9b0 (volume:1151) 2018-02-21 18:02:04,060+0100 ERROR (tasks/1) [storage.Volume] The requested initial 21474836480 is bigger than the max size 134217728 (blockVolume:345) 2018-02-21 18:02:04,060+0100 ERROR (tasks/1) [storage.Volume] Failed to create volume /rhev/data-center/mnt/blockSD/69f6b3e7-d754-44cf-a665- 9d7128260401/images/0a5c4ecb-2c04-4f96-858a-4f74915d5caa/ bd3ae91a-3b37-4610-9ad3-6c5fdc6cc9b0: Invalid parameter: 'initial size=41943040' (volume:1175) 2018-02-21 18:02:04,061+0100 ERROR (tasks/1) [storage.Volume] Unexpected error (volume:1215) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/storage/volume.py", line 1172, in create initialSize=initialSize) File "/usr/lib/python2.7/site-packages/vdsm/storage/blockVolume.py", line 501, in _create size, initialSize) File "/usr/lib/python2.7/site-packages/vdsm/storage/blockVolume.py", line 545, in calculate_volume_alloc_size preallocate, capacity, initial_size) File "/usr/lib/python2.7/site-packages/vdsm/storage/blockVolume.py", line 347, in calculate_volume_alloc_size initial_size) InvalidParameterException: Invalid parameter: 'initial size=41943040' 2018-02-21 18:02:04,062+0100 ERROR (tasks/1) [storage.TaskManager.Task] (Task='e7598aa1-420a-4612-9ee8-03012b1277d9') Unexpected error (task:875) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 882, in _run return fn(*args, **kargs) File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 336, in run return self.cmd(*self.argslist, **self.argsdict) File "/usr/lib/python2.7/site-packages/vdsm/storage/securable.py", line 79, in wrapper return method(self, *args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/storage/sp.py", line 1936, in createVolume initialSize=initialSize) File "/usr/lib/python2.7/site-packages/vdsm/storage/sd.py", line 801, in createVolume initialSize=initialSize) File "/usr/lib/python2.7/site-packages/vdsm/storage/volume.py", line 1217, in create (volUUID, e)) VolumeCreationError: Error creating a new volume: (u"Volume creation bd3ae91a-3b37-4610-9ad3-6c5fdc6cc9b0 failed: Invalid parameter: 'initial size=41943040'",) there are no new logs in import folder on host used for import... > > > > > > >> That should do it. If not, please share the OVA file and I will > examine > >> it in my environment. > > > > original file is at > > > > https://haas.cesnet.cz/downloads/release-01/HAAS-hpdio.ova > <https://haas.cesnet.cz/downloads/release-01/HAAS-hpdio.ova> > > > >> > >> > [1] https://github.com/oVirt/ovirt-engine/blob/master/ backend/manager/modules/utils/src/main/java/org/ovirt/ engine/core/utils/ovf/OvfOvaReader.java#L220 > <https://github.com/oVirt/ovirt-engine/blob/master/ backend/manager/modules/utils/src/main/java/org/ovirt/ engine/core/utils/ovf/OvfOvaReader.java#L220> > >> > >> > >> > >> > file > >> > > >> > /var/log/ovirt-engine/ova/ovirt-query-ova-ansible- 20180220123504-ovirt01.net > <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net> > >> <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net > <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net>> > >> > > <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net > <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net> > >> <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net > <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net>>> > >> > in the fact does not exists (nor folder > /var/log/ovirt-engine/ova/) > >> > > >> > > >> > This issue is also resolved in 4.2.2. > >> > In the meantime, please create the > /var/log/ovirt-engine/ova/ folder > >> > manually and make sure its permissions match the ones of > the other > >> > folders in /var/log/ovirt-engine. > >> > >> ok, done. After another try there is this log file > >> > >> > /var/log/ovirt-engine/ova/ovirt-query-ova-ansible- 20180220173005-ovirt01.net > <http://ovirt-query-ova-ansible-20180220173005-ovirt01.net> > >> <http://20180220173005-ovirt01.net > <http://20180220173005-ovirt01.net>>.slu.cz.log > >> > >> https://pastebin.com/M5J44qur > >> > >> > >> Is it the log of the execution of the ansible playbook that was > provided > >> with a path to the /ova folder? > >> I'm interested in that in order to see how comes that its execution > >> never completed. > > > > well, I dont think so, it is log from import with full path to ova > file > > > > > > > >> > >> > >> > >> > >> > Cheers, > >> > > >> > Jiri Slezka > >> > > >> > > > >> > > > >> > > > >> > > I am using latest 4.2.1.7-1.el7.centos version > >> > > > >> > > Cheers, > >> > > Jiri Slezka > >> > > > >> > > > >> > > [1] https://haas.cesnet.cz/#!index.md > <https://haas.cesnet.cz/#!index.md> > >> <https://haas.cesnet.cz/#!index.md > <https://haas.cesnet.cz/#!index.md>> > >> <https://haas.cesnet.cz/#!index.md > <https://haas.cesnet.cz/#!index.md> > <https://haas.cesnet.cz/#!index.md <https://haas.cesnet.cz/#! index.md>>> > >> > > <https://haas.cesnet.cz/#!index.md > <https://haas.cesnet.cz/#!index.md> > <https://haas.cesnet.cz/#!index.md <https://haas.cesnet.cz/#! index.md>> > >> > <https://haas.cesnet.cz/#!index.md > <https://haas.cesnet.cz/#!index.md> > >> <https://haas.cesnet.cz/#!index.md > <https://haas.cesnet.cz/#!index.md>>>> - Cesnet HAAS > >> > > [2] https://haas.cesnet.cz/downloads/release-01/ > <https://haas.cesnet.cz/downloads/release-01/> > >> <https://haas.cesnet.cz/downloads/release-01/ > <https://haas.cesnet.cz/downloads/release-01/>> > >> > <https://haas.cesnet.cz/downloads/release-01/ > <https://haas.cesnet.cz/downloads/release-01/> > >> <https://haas.cesnet.cz/downloads/release-01/ > <https://haas.cesnet.cz/downloads/release-01/>>> > >> > > <https://haas.cesnet.cz/downloads/release-01/ > <https://haas.cesnet.cz/downloads/release-01/> > >> <https://haas.cesnet.cz/downloads/release-01/ > <https://haas.cesnet.cz/downloads/release-01/>> > >> > <https://haas.cesnet.cz/downloads/release-01/ > <https://haas.cesnet.cz/downloads/release-01/> > >> <https://haas.cesnet.cz/downloads/release-01/ > <https://haas.cesnet.cz/downloads/release-01/>>>> - Image repository > >> > > > >> > > > >> > > _______________________________________________ > >> > > Users mailing list > >> > > Users(a)ovirt.org <mailto:Users@ovirt.org> > <mailto:Users@ovirt.org <mailto:Users@ovirt.org>> > <mailto:Users@ovirt.org <mailto:Users@ovirt.org> > >> <mailto:Users@ovirt.org <mailto:Users@ovirt.org>>> > >> > <mailto:Users@ovirt.org <mailto:Users@ovirt.org> > <mailto:Users@ovirt.org <mailto:Users@ovirt.org>> > >> <mailto:Users@ovirt.org <mailto:Users@ovirt.org> > <mailto:Users@ovirt.org <mailto:Users@ovirt.org>>>> > >> > > http://lists.ovirt.org/mailman/listinfo/users > <http://lists.ovirt.org/mailman/listinfo/users> > >> <http://lists.ovirt.org/mailman/listinfo/users > <http://lists.ovirt.org/mailman/listinfo/users>> > >> > <http://lists.ovirt.org/mailman/listinfo/users > <http://lists.ovirt.org/mailman/listinfo/users> > >> <http://lists.ovirt.org/mailman/listinfo/users > <http://lists.ovirt.org/mailman/listinfo/users>>> > >> > > <http://lists.ovirt.org/mailman/listinfo/users > <http://lists.ovirt.org/mailman/listinfo/users> > >> <http://lists.ovirt.org/mailman/listinfo/users > <http://lists.ovirt.org/mailman/listinfo/users>> > >> > <http://lists.ovirt.org/mailman/listinfo/users > <http://lists.ovirt.org/mailman/listinfo/users> > >> <http://lists.ovirt.org/mailman/listinfo/users > <http://lists.ovirt.org/mailman/listinfo/users>>>> > >> > > > >> > > > >> > > >> > > >> > > >> > _______________________________________________ > >> > Users mailing list > >> > Users(a)ovirt.org <mailto:Users@ovirt.org> > <mailto:Users@ovirt.org <mailto:Users@ovirt.org>> > >> <mailto:Users@ovirt.org <mailto:Users@ovirt.org> > <mailto:Users@ovirt.org <mailto:Users@ovirt.org>>> > >> > http://lists.ovirt.org/mailman/listinfo/users > <http://lists.ovirt.org/mailman/listinfo/users> > >> <http://lists.ovirt.org/mailman/listinfo/users > <http://lists.ovirt.org/mailman/listinfo/users>> > >> > <http://lists.ovirt.org/mailman/listinfo/users > <http://lists.ovirt.org/mailman/listinfo/users> > >> <http://lists.ovirt.org/mailman/listinfo/users > <http://lists.ovirt.org/mailman/listinfo/users>>> > >> > > >> > > >> > >> > >> > >> _______________________________________________ > >> Users mailing list > >> Users(a)ovirt.org <mailto:Users@ovirt.org> > <mailto:Users@ovirt.org <mailto:Users@ovirt.org>> > >> http://lists.ovirt.org/mailman/listinfo/users > <http://lists.ovirt.org/mailman/listinfo/users> > >> <http://lists.ovirt.org/mailman/listinfo/users > <http://lists.ovirt.org/mailman/listinfo/users>> > >> > >> > > > > > > > > > > _______________________________________________ > > Users mailing list > > Users(a)ovirt.org <mailto:Users@ovirt.org> > > http://lists.ovirt.org/mailman/listinfo/users > <http://lists.ovirt.org/mailman/listinfo/users> > > > > > > _______________________________________________ > Users mailing list > Users(a)ovirt.org <mailto:Users@ovirt.org> > http://lists.ovirt.org/mailman/listinfo/users > <http://lists.ovirt.org/mailman/listinfo/users> > > _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users

On Thu, Feb 22, 2018 at 12:09:56PM +0200, Arik Hadas wrote: > supermin: failed to find a suitable kernel (host_cpu=3Dx86_64). =20 Please run =E2=80=98libguestfs-test-tool=E2=80=99 and attach the comple=

=20 > @Richard, this is an OVA of a VM installed with Debian64 as guest OS t=

> was exported from VirtualBox, is it supported by virt-v2v? =20 No, we only support OVAs exported from VMware. OVF isn't a real standard, it's a ploy by VMware to pretend that they conform to standards.

On Thu, Feb 22, 2018 at 01:27:18PM +0100, Ji=C5=99=C3=AD Sl=C3=A9=C5=BE=

> libvirt needs authentication to connect to libvirt URI qemu:///system > (see also: http://libvirt.org/auth.html http://libvirt.org/uri.html) =20 You can set the backend to direct to avoid needing libvirt: =20 export LIBGUESTFS_BACKEND=3Ddirect =20 Alternately you can fiddle with the libvirt polkit configuration to permit access:

=20 https://libvirt.org/aclpolkit.html =20 Rich. =20