On 02/20/2018 11:09 PM, Arik Hadas wrote:
On Tue, Feb 20, 2018 at 6:37 PM, Ji=C5=99=C3=AD Sl=C3=A9=C5=BEka <jiri=
=2Eslezka@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=C5=99=C3=AD Sl=C3=A9=C5=BEka= <jiri.slezka@slu.cz <mailto:jiri.slezka@slu.cz> > <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= =AD Sl=C3=A9=C5=BEka <jiri.slezka@slu.cz <mailto:jiri.slezka@slu.cz> <mailto:jiri.slezka@slu.cz <mailto:jiri.slezka@slu.cz>> >=C2=A0 =C2=A0 =C2=A0> <mailto:jiri.slezka@slu.cz <mailto:jiri.sle= zka@slu.cz> <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 impo= rt some ova files into our oVirt instance [1] >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0[2] but I facing problem= s. >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0I have downloaded all ov= a images into one of hosts (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 1= 160387072 Feb 16 16:21 HAAS-hpcowrie.ovf >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-rw-r--r--. 1 vdsm kvm 1= 111785984 Feb 16 16:22 HAAS-hpdio.ova >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-rw-r--r--. 1 vdsm kvm=C2= =A0 846736896 Feb 16 16:22 HAAS-hpjdwpd.ova >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-rw-r--r--. 1 vdsm kvm=C2= =A0 891043328 Feb 16 16:23 HAAS-hptelnetd.ova >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-rw-r--r--. 1 vdsm kvm=C2= =A0 908222464 Feb 16 16:23 HAAS-hpuchotcp.ova >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-rw-r--r--. 1 vdsm kvm=C2= =A0 880643072 Feb 16 16:24 HAAS-hpuchoudp.ova >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-rw-r--r--. 1 vdsm kvm=C2= =A0 890833920 Feb 16 16:24 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 t= hem - from host ovirt01 and directory /ova but >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0spinner spins infinitly = and nothing is happen. >=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=
This is a cryptographically signed message in MIME format. --------------ms070908000408060801060808 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 02/21/2018 03:43 PM, Ji=C5=99=C3=AD Sl=C3=A9=C5=BEka wrote: the actual ova
file, i.e., >=C2=A0 =C2=A0 =C2=A0> /ova/HAAS-hpdio.ova, rather than to the dir=
ectory?
> >=C2=A0 =C2=A0 =C2=A0this time it ends with "Failed to load VM con=
figuration from
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 "tr=
y
> fetching an 'ova folder' out of the destination folder" rather t=
han
> "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 fil=
es
in the folder is implemented (that was the original plan, btw) - could=
you please file a bug? =20 yes, sure =20 =20 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0I cannot see anything re= levant in vdsm log of host ovirt01. >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0In the engine.log of our= standalone ovirt manager is just this >=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+= 01 INFO >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0[org.ovirt.engine.core.c= ommon.utils.ansible.AnsibleExecutor] (default >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0task-31) [458990a7-b054-= 491a-904e-5c4fe44892c4] Executing Ansible >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0command: ANSIBLE_STDOUT_= CALLBACK=3Dovaqueryplugin >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0[/usr/bin/ansible-playbo= ok, >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0--private-key=3D/etc/pki= /ovirt-engine/keys/engine_id_rsa, >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0--inventory=3D/tmp/ansib= le-inventory8237874608161160784, >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0--extra-vars=3Dovirt_que= ry_ova_path=3D/ova, >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0/usr/share/ovirt-engine/= playbooks/ovirt-ova-query.yml] [Logfile: >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0/var/log/ovirt-engine/ov= a/ovirt-query-ova-ansible-20180220123504-ovirt01.net <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net> >=C2=A0 =C2=A0 =C2=A0<http://ovirt-query-ova-ansible-2018022012350= 4-ovirt01.net <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net>> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0<http://20180220123504-o= virt01.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=A0> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0also there are two ansib= le processes which are still running >=C2=A0 =C2=A0 =C2=A0(and makes >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0heavy load on system (lo= ad 9+ and growing, it looks like it >=C2=A0 =C2=A0 =C2=A0eats all the >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0memory and system starts= swapping)) >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0ovirt=C2=A0 =C2=A0 32087= =C2=A0 3.3=C2=A0 0.0 332252=C2=A0 5980 ?=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sl=C2= =A0 =C2=A012:35=C2=A0 =C2=A00:41 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0/usr/bin/python2 /usr/bi= n/ansible-playbook >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0--private-key=3D/etc/pki= /ovirt-engine/keys/engine_id_rsa >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0--inventory=3D/tmp/ansib= le-inventory8237874608161160784 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0--extra-vars=3Dovirt_que= ry_ova_path=3D/ova >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0/usr/share/ovirt-engine/= playbooks/ovirt-ova-query.yml >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0ovirt=C2=A0 =C2=A0 32099= 57.5 78.9 15972880 11215312 ?=C2=A0 =C2=A0R=C2=A0 =C2=A0 12:35=C2=A0 11:52 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0/usr/bin/python2 /usr/bi= n/ansible-playbook >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0--private-key=3D/etc/pki= /ovirt-engine/keys/engine_id_rsa >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0--inventory=3D/tmp/ansib= le-inventory8237874608161160784 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0--extra-vars=3Dovirt_que= ry_ova_path=3D/ova >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0/usr/share/ovirt-engine/= playbooks/ovirt-ova-query.yml >=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-ov=
a-query
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0and it looks like it onl=
y runs query_ova.py but on all
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=
run on when it
>=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 h=
ost.
>=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? ...o=
r should it work?
>=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=
the OVA and is
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-2018022012=
3504-ovirt01.net
<http://ovirt-query-ova-ansible-20180220123504-ovirt01.net> >=C2=A0 =C2=A0 =C2=A0<http://ovirt-query-ova-ansible-2018022012350=
4-ovirt01.net
<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 =
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 o=
vf file
> that resides inside this ova file. > Can you please share that ovf file that resides inside=C2=A0/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:
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: =20 yes, it is most likely ova from VirtualBox =20 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, ed= it 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) whe= re X is either: 1. the actual size of the vmdk file + some buffer (iirc, we used to ta= ke 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=3D"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 shal= l 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 currentl= y be specified in GB, e.g., ovf:populatedSize=3D"20" in the case of HAAS-hpdio.ova. =20 wow, thanks for this excellent explanation. I have changed this in ovf = file =20 ... <Disk ovf:capacity=3D"20" ovf:diskId=3D"vmdisk2" ovf:populatedSize=3D"2= 0" ... ... =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 =20 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=3Doff,compat=3D0.10 libguestfs: command: run: \ /rhev/data-center/mnt/blockSD/088e7ed9-84c7-4fbd-a570-f37fa986a772/images= /d44e1890-3e42-420b-939c-dac1290e19af/9edcccbc-b244-4b94-acd3-3c8ee12bbbe= c libguestfs: command: run: \ 21474836480 Formatting '/rhev/data-center/mnt/blockSD/088e7ed9-84c7-4fbd-a570-f37fa986a772/image= s/d44e1890-3e42-420b-939c-dac1290e19af/9edcccbc-b244-4b94-acd3-3c8ee12bbb= ec', fmt=3Dqcow2 size=3D21474836480 compat=3D0.10 encryption=3Doff cluster_siz= e=3D65536 preallocation=3Doff lazy_refcounts=3Doff refcount_bits=3D16 libguestfs: trace: vdsm_disk_create: disk_create =3D 0 qemu-img 'convert' '-p' '-n' '-f' 'qcow2' '-O' 'qcow2' '/var/tmp/v2vovl2dccbd.qcow2' '/rhev/data-center/mnt/blockSD/088e7ed9-84c7-4fbd-a570-f37fa986a772/image= s/d44e1890-3e42-420b-939c-dac1290e19af/9edcccbc-b244-4b94-acd3-3c8ee12bbb= ec' qemu-img: error while writing sector 1000960: No space left on device virt-v2v: error: qemu-img command failed, see earlier errors
=20
That should do it. If not, please share the OVA file and I will examin= e it in my environment. =20 original file is at =20 https://haas.cesnet.cz/downloads/release-01/HAAS-hpdio.ova =20
[1]=C2=A0https://github.com/oVirt/ovirt-engine/blob/master/backend/man= ager/modules/utils/src/main/java/org/ovirt/engine/core/utils/ovf/OvfOvaRe= ader.java#L220
>=C2=A0 =C2=A0 =C2=A0file >=C2=A0 =C2=A0 =C2=A0/var/log/ovirt-engine/ova/ovirt-query-ova-ansible-2018022012= 3504-ovirt01.net <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net> >=C2=A0 =C2=A0 =C2=A0<http://ovirt-query-ova-ansible-2018022012350= 4-ovirt01.net <http://ovirt-query-ova-ansible-20180220123504-ovirt01.net>> >=C2=A0 =C2=A0 =C2=A0in 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 =C2=A0/var/log/ovirt-engine/o= va/ folder > manually and make sure its permissions match the ones of the oth= er > folders in =C2=A0/var/log/ovirt-engine.
ok, done. After another try there is this log file
/var/log/ovirt-engine/ova/ovirt-query-ova-ansible-20180220173005-o= virt01.net <http://20180220173005-ovirt01.net>.slu.cz.log
Is it the log of the execution of the ansible playbook that was provid= ed with a path to the /ova folder? I'm interested in that in order to see how comes that its execution never completed. =20 well, I dont think so, it is log from import with full path to ova file=
=20 =20 =20
=C2=A0
>=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-1.el7.centos version >=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.= cz/#!index.md <https://haas.cesnet.cz/#!index.md> <https://haas.cesnet.cz/#!index.md <https://haas.cesnet.cz/#!index= =2Emd>> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0<https://haas.cesnet.cz/= #!index.md <https://haas.cesnet.cz/#!index.md> >=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.= cz/downloads/release-01/ <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/=
downloads/release-01/
<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 repositor=
y
>=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@ovirt.org <mailto:=
Users@ovirt.org> <mailto:Users@ovirt.org
<mailto:Users@ovirt.org>> >=C2=A0 =C2=A0 =C2=A0<mailto:Users@ovirt.org <mailto:Users@ovirt.o=
rg>
<mailto:Users@ovirt.org <mailto:Users@ovirt.org>>> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0http://lists.ovirt.org/m=
ailman/listinfo/users
<http://lists.ovirt.org/mailman/listinfo/users> >=C2=A0 =C2=A0 =C2=A0<http://lists.ovirt.org/mailman/listinfo/user=
s
<http://lists.ovirt.org/mailman/listinfo/users>> >=C2=A0 =C2=A0 =C2=A0>=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<http://lists.ovirt.org/mailman/listinfo/user=
s
<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_____________________________________________=
__
>=C2=A0 =C2=A0 =C2=A0Users mailing list >=C2=A0 =C2=A0 =C2=A0Users@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/user=
s
<http://lists.ovirt.org/mailman/listinfo/users>> > >
_______________________________________________ Users mailing list Users@ovirt.org <mailto:Users@ovirt.org> http://lists.ovirt.org/mailman/listinfo/users <http://lists.ovirt.org/mailman/listinfo/users>
=20 =20 =20 =20 _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users =20
--------------ms070908000408060801060808 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC Cn8wggUJMIID8aADAgECAhACt8ndrdK9CetZxFyQDGB4MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xNDExMTgx MjAwMDBaFw0yNDExMTgxMjAwMDBaMHIxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1I b2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEmMCQGA1UEAxMd VEVSRU5BIGVTY2llbmNlIFBlcnNvbmFsIENBIDMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQCwp9Jj5Aej1xPkS1GV3LvBdemFmkUR//nSzBodqsU3dv2BCRD30r4gt5oRsYty qDGF2nnItxV1SkwVoDxFeRzOIHYNYvBRHaiGvCQjEXzPRTocOSVfWpmq/zAL/QOEqpJogeM+ 0IBGiJcAENJshl7UcfjYbBnN5qStk74f52VWFf/aiF7MVJnsUr3oriQvXYOzs8N/NXyyQyim atBbumJVCNszF1X+XHCGfPNvxlNFW9ktv7azK0baminfLcsh6ubCdINZc+Nof2lU387NCDgg oh3KsYVcZTSuhh7qp6MjxE5VqOZod1hpXXzDOkjK+DAMC57iZXssncp24eaN08VlAgMBAAGj ggGmMIIBojASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjB5BggrBgEFBQcB AQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcw AoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENB LmNydDCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDA9BgNVHSAENjA0MDIGBFUdIAAwKjAoBggr BgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzAdBgNVHQ4EFgQUjJ8RLubj egSlHlWLRggEpu2XcKYwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZI hvcNAQELBQADggEBAI5HEV91Oen8WHFCoJkeu2Av+b/kWTV2qH/YNI1Xsbou2hHKhh4IyNkF OxA/TUiuK2qQnQ5hAS0TIrs9SJ1Ke+DjXd/cTBiw7lCYSW5hkzigFV+iSivninpItafWqYBS WxITl1KHBS9YBskhEqO5GLliDMPiAgjqUBQ/H1qZMlZNQIuFu0UaFUQuZUpJFr4+0zpzPxsB iWU2muAoGItwbaP55EYshM7+v/J+x6kIhAJt5Dng8fOmOvR9F6Vw2/E0EZ6oQ8g1fdhwM101 S1OI6J1tUil1r7ES/svNqVWVb7YkUEBcPo8ppfHnTI/uxsn2tslsWefsOGJxNYUUSMAb9Eow ggVuMIIEVqADAgECAhAKebGg8bOvnIyfOWAn4bpzMA0GCSqGSIb3DQEBCwUAMHIxCzAJBgNV BAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzAN BgNVBAoTBlRFUkVOQTEmMCQGA1UEAxMdVEVSRU5BIGVTY2llbmNlIFBlcnNvbmFsIENBIDMw HhcNMTcxMTE2MDAwMDAwWhcNMTgxMjE1MTIwMDAwWjCBlDETMBEGCgmSJomT8ixkARkWA29y ZzEWMBQGCgmSJomT8ixkARkWBnRlcmVuYTETMBEGCgmSJomT8ixkARkWA3RjczELMAkGA1UE BhMCQ1oxJTAjBgNVBAoTHFNpbGVzaWFuIFVuaXZlcnNpdHkgaW4gT3BhdmExHDAaBgNVBAMT E0ppcmkgU2xlemthIHNsZTAwMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC/ VwOD1hlYL6l7GzxNqV1ne7/iMF/gHvPfTwejsC2s9sby7It82qXPRBVA2s1Cjb1A3ucpdlDN MXM83Lvh881XfkxhS2YLLyiZDmlSzAqfoMLxQ2/E0m1UugttzGJF7/10pEwj0FJFhnIVwA/E 8svCcbhxwO9BBpUz8JG1C6fTd0qyzJtNXVyH+WuHQbU2jgu2JJ7miiEKE1Fis0hFf1rKxTzX aVGyXiQLOn7TZDfPtXrJEG7eWYlFUP58edyuJELpWHTPHn8xJKYTy8Qq5BgFNyCRQT/6imsh tZlDBZSEeqyoSNtLsC57ZrjqgtLCEQFK9EX27dOy0/u95zS0OIWdAgMBAAGjggHbMIIB1zAf BgNVHSMEGDAWgBSMnxEu5uN6BKUeVYtGCASm7ZdwpjAdBgNVHQ4EFgQUF1mSlcyDz9wWit9V jCz+zJ9CrpswDAYDVR0TAQH/BAIwADAdBgNVHREEFjAUgRJqaXJpLnNsZXprYUBzbHUuY3ow DgYDVR0PAQH/BAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDA0BgNVHSAE LTArMAwGCiqGSIb3TAUCAgEwDAYKYIZIAYb9bAQfATANBgsqhkiG90wFAgMDAzCBhQYDVR0f BH4wfDA8oDqgOIY2aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL1RFUkVOQWVTY2llbmNlUGVy c29uYWxDQTMuY3JsMDygOqA4hjZodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vVEVSRU5BZVNj aWVuY2VQZXJzb25hbENBMy5jcmwwewYIKwYBBQUHAQEEbzBtMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRQYIKwYBBQUHMAKGOWh0dHA6Ly9jYWNlcnRzLmRpZ2lj ZXJ0LmNvbS9URVJFTkFlU2NpZW5jZVBlcnNvbmFsQ0EzLmNydDANBgkqhkiG9w0BAQsFAAOC AQEADtFRxKphkcHVdWjR/+i1+cdHfkbicraHlU5Mpw8EX6nemKu4GGAWfzH+Y7p6ImZwUHWf /SSbrX+57xaFUBOr3jktQm1GRmGUZESEmsUDB8UZXzdQC79/tO9MzRhvEBXuQhdxdoO64Efx VqtYAB2ydqz7yWh56ioSwaQZEXo5rO1kZuAcmVz8Smd1r/Mur/h8Y+qbrsJng1GS25aMhFts UV6z9zXuHFkT9Ck8SLdCEDzjzYNjXIDB5n+QOmPXnXrZMlGiI/aOqa5k5Sv6xCIPdH2kbpyd M1YiH/ChmU9gWJvy0Jq42KGLvWBvuHEzcb3f473Fvn4GWsXu0zDS2oh2/TGCA8MwggO/AgEB MIGGMHIxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQHEwlB bXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEmMCQGA1UEAxMdVEVSRU5BIGVTY2llbmNlIFBl cnNvbmFsIENBIDMCEAp5saDxs6+cjJ85YCfhunMwDQYJYIZIAWUDBAIBBQCgggINMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDIyMTE2MDM1MFowLwYJ KoZIhvcNAQkEMSIEIMJrV8XUGGxaKJL19bzHjyG0sDf+CSxpwEp0F7zg2/wrMGwGCSqGSIb3 DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG 9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgZcGCSsG AQQBgjcQBDGBiTCBhjByMQswCQYDVQQGEwJOTDEWMBQGA1UECBMNTm9vcmQtSG9sbGFuZDES MBAGA1UEBxMJQW1zdGVyZGFtMQ8wDQYDVQQKEwZURVJFTkExJjAkBgNVBAMTHVRFUkVOQSBl U2NpZW5jZSBQZXJzb25hbCBDQSAzAhAKebGg8bOvnIyfOWAn4bpzMIGZBgsqhkiG9w0BCRAC CzGBiaCBhjByMQswCQYDVQQGEwJOTDEWMBQGA1UECBMNTm9vcmQtSG9sbGFuZDESMBAGA1UE BxMJQW1zdGVyZGFtMQ8wDQYDVQQKEwZURVJFTkExJjAkBgNVBAMTHVRFUkVOQSBlU2NpZW5j ZSBQZXJzb25hbCBDQSAzAhAKebGg8bOvnIyfOWAn4bpzMA0GCSqGSIb3DQEBAQUABIIBABuJ Oiye516O/31ZzufFnnBVNbYTcR1Z0/8IZ1KyIn3tU2pjctSQ5wV8Yo0c4Rk6jPOSjaDZ3HXl 8614pHzSdwSreBktfMmOGm3mI3j71Ed5R2dKFEsTurI+zDyy8NueJNX2fkiw0hvPLG5eH1NH pNxO38cAdJHA20/YwHOCcOBYLTUWKxzAm8LyzH6Id35y7sNwBkS/n326qULzJDv2O3L8ySc+ ij9NduYj9tcd0eNJrHX0VZ6YGaV8YwZiN7laZijY9zNDPIGe48u5EFQnoZL3v25Dy4jkrBpe +L0SOQUNmH6NcUoQmF8CObltmh9JRAJmDIPfYybtcJLd4yV52n4AAAAAAAA= --------------ms070908000408060801060808--