[ovirt-users] problem importing ova vm
Arik Hadas
ahadas at redhat.com
Tue Feb 20 22:09:40 UTC 2018
On Tue, Feb 20, 2018 at 6:37 PM, Jiří Sléžka <jiri.slezka at 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 at slu.cz
> > <mailto:jiri.slezka at 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 at slu.cz
> <mailto:jiri.slezka at slu.cz>
> > > <mailto:jiri.slezka at slu.cz <mailto:jiri.slezka at 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?
>
> > > 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://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://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 at 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:
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.
That should do it. If not, please share the OVA file and I will examine it
in my environment.
[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>
> > 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.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.
>
>
> > 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>> - 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/>> - Image repository
> > >
> > >
> > > _______________________________________________
> > > Users mailing list
> > > Users at ovirt.org <mailto:Users at ovirt.org>
> > <mailto:Users at ovirt.org <mailto:Users at 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 at ovirt.org <mailto:Users at ovirt.org>
> > http://lists.ovirt.org/mailman/listinfo/users
> > <http://lists.ovirt.org/mailman/listinfo/users>
> >
> >
>
>
>
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20180221/597eda6f/attachment.html>
More information about the Users
mailing list