[ovirt-users] Building ovirt-engine fails due to failing estCanReadFile(org.ovirt.engine.core.utils.servlet.ServletUtilsTest): We should not be able to read this file.

2017-05-22 Thread Leni Kadali Mutungi
Tried to build ovirt-engine on my computer using the command `make
clean install-dev`, on Debian Testing.

The full output of the error is as follows:
https://paste.fedoraproject.org/paste/F6p~LVdNtFlpzQijMbSIYV5M1UNdIGYhyRLivL9gydE=

I modified the following variables in the Makefile to suit where the
required files are:

JS_DEPS_DIR=/home/user/ovirt-js-dependencies
PYFLAKES=/usr/bin/pyflakes
JBOSS_HOME=/home/user/wildfly-11.0.0.Alpha1
WILDFLY_OVERLAY_MODULES=/home/user/wildfly-11.0.0.Alpha1/modules

I have pep8 but was unable to know how to correctly reference it in
the Makefile, the syntax being:

PEP8=pep8

Advice on this would be welcome.


-- 
- Warm regards
Leni Kadali Mutungi
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] migration of a VM: fails

2017-05-22 Thread Michal Skrivanek

> On 18 May 2017, at 16:53, cmc  wrote:
> 
> I have to shut the VM down to stop it trying to repeatedly trying to
> migrate the problematic host (always the same one). If I take it out
> of maintenance, it will move the VMs back to balance (as per policy),
> so this is rather inconvenient. It took leaving it overnight and
> letting oVirt try repeatedly every few minutes to get it to migrate
> the VM (I can't wait that long, so I've had to shut that VM down for
> now)
> 
> On Wed, May 17, 2017 at 4:13 PM, cmc  wrote:
>> Just a note on this: a similar thing is now happening with the same VM
>> when I upgrade the other node, i.e., it can't move this one VM over
>> (so far) from one host to another. I will leave it trying overnight to
>> see if it succeeds.

is it from older host to newr host or vice versa?
can you downgrade the new one to the same version and try again?

Thanks,
michal

>> 
>> Thanks,
>> 
>> Cam
>> 
>> On Wed, May 17, 2017 at 11:40 AM, cmc  wrote:
>>> Hi Francesco,
>>> 
>>> I left it running after I posted to the list, and it eventually (after
>>> many failed attempts) moved the VM without any intervention by me, and
>>> then updated the host, so that explains the differences in the
>>> versions of qemu between the hosts (they probably would have been the
>>> same when I tried the move first). The xml is attached.
>>> 
>>> qemu and libvirt versions on the source host:
>>> 
>>> ipxe-roms-qemu-20160127-5.git6366fa7a.el7.noarch
>>> libvirt-daemon-driver-qemu-2.0.0-10.el7_3.5.x86_64
>>> qemu-img-ev-2.6.0-28.el7_3.9.1.x86_64
>>> qemu-kvm-common-ev-2.6.0-28.el7_3.9.1.x86_64
>>> qemu-kvm-ev-2.6.0-28.el7_3.9.1.x86_64
>>> qemu-kvm-tools-ev-2.6.0-28.el7_3.3.1.x86_64
>>> 
>>> libvirt-2.0.0-10.el7_3.5.x86_64
>>> libvirt-client-2.0.0-10.el7_3.5.x86_64
>>> libvirt-daemon-2.0.0-10.el7_3.5.x86_64
>>> libvirt-daemon-config-network-2.0.0-10.el7_3.5.x86_64
>>> libvirt-daemon-config-nwfilter-2.0.0-10.el7_3.5.x86_64
>>> libvirt-daemon-driver-interface-2.0.0-10.el7_3.5.x86_64
>>> libvirt-daemon-driver-lxc-2.0.0-10.el7_3.5.x86_64
>>> libvirt-daemon-driver-network-2.0.0-10.el7_3.5.x86_64
>>> libvirt-daemon-driver-nodedev-2.0.0-10.el7_3.5.x86_64
>>> libvirt-daemon-driver-nwfilter-2.0.0-10.el7_3.5.x86_64
>>> libvirt-daemon-driver-qemu-2.0.0-10.el7_3.5.x86_64
>>> libvirt-daemon-driver-secret-2.0.0-10.el7_3.5.x86_64
>>> libvirt-daemon-driver-storage-2.0.0-10.el7_3.5.x86_64
>>> libvirt-daemon-kvm-2.0.0-10.el7_3.5.x86_64
>>> libvirt-lock-sanlock-2.0.0-10.el7_3.5.x86_64
>>> libvirt-python-2.0.0-2.el7.x86_64
>>> 
>>> qemu and libvirt versions on the dest host:
>>> 
>>> ipxe-roms-qemu-20160127-5.git6366fa7a.el7.noarch
>>> libvirt-daemon-driver-qemu-2.0.0-10.el7_3.4.x86_64
>>> qemu-img-ev-2.6.0-28.el7_3.3.1.x86_64
>>> qemu-kvm-common-ev-2.6.0-28.el7_3.3.1.x86_64
>>> qemu-kvm-ev-2.6.0-28.el7_3.3.1.x86_64
>>> qemu-kvm-tools-ev-2.6.0-28.el7_3.3.1.x86_64
>>> 
>>> libvirt-client-2.0.0-10.el7_3.4.x86_64
>>> libvirt-daemon-2.0.0-10.el7_3.4.x86_64
>>> libvirt-daemon-config-nwfilter-2.0.0-10.el7_3.4.x86_64
>>> libvirt-daemon-driver-interface-2.0.0-10.el7_3.4.x86_64
>>> libvirt-daemon-driver-network-2.0.0-10.el7_3.4.x86_64
>>> libvirt-daemon-driver-nodedev-2.0.0-10.el7_3.4.x86_64
>>> libvirt-daemon-driver-nwfilter-2.0.0-10.el7_3.4.x86_64
>>> libvirt-daemon-driver-qemu-2.0.0-10.el7_3.4.x86_64
>>> libvirt-daemon-driver-secret-2.0.0-10.el7_3.4.x86_64
>>> libvirt-daemon-driver-storage-2.0.0-10.el7_3.4.x86_64
>>> libvirt-daemon-kvm-2.0.0-10.el7_3.4.x86_64
>>> libvirt-lock-sanlock-2.0.0-10.el7_3.4.x86_64
>>> libvirt-python-2.0.0-2.el7.x86_64
>>> 
>>> 
>>> Thanks,
>>> 
>>> Cam
>>> 
>>> On Wed, May 17, 2017 at 9:12 AM, Francesco Romani  
>>> wrote:
 
 On 05/16/2017 01:06 PM, cmc wrote:
> Hi,
> 
> Just trying to place in maintenance mode for a version upgrade, and
> one VM fails to migrate. The other 20-odd move over successfully. In
> /var/log/libvirt/qemu/, the VM's log on the source reports:
> 
> 2017-05-16 09:48:06.339+: initiating migration
> 2017-05-16T09:52:25.498932Z qemu-kvm: socket_writev_buffer: Got err=32
> for (131328/18446744073709551615)
> 2017-05-16 09:52:47.311+: initiating migration
> 2017-05-16T09:57:06.755402Z qemu-kvm: socket_writev_buffer: Got err=32
> for (69776/18446744073709551615)
> 2017-05-16 09:57:55.109+: initiating migration
> 2017-05-16T10:02:14.143221Z qemu-kvm: socket_writev_buffer: Got err=32
> for (69776/18446744073709551615)
> 2017-05-16 10:02:59.497+: initiating migration
> 2017-05-16T10:07:18.542872Z qemu-kvm: socket_writev_buffer: Got err=32
> for (69776/18446744073709551615)
> 2017-05-16 10:08:03.896+: initiating migration
> 2017-05-16T10:12:23.206731Z qemu-kvm: socket_writev_buffer: Got err=32
> for (69776/18446744073709551615)
> 2017-05-16 10:13:08.941+: initiating migration
> 2017-05-16T10:17:27.861843Z 

Re: [ovirt-users] upload image

2017-05-22 Thread Daniel Erez
The oVirt's CA certificate can be fetched from http://
/ovirt-engine/services/pki-resource?resource=ca-certificate=X509-PEM-CA

(more details in 'SSL installation' section at:
https://github.com/oVirt/ovirt-imageio/blob/master/proxy/README).

For importing the certificate to firefox, try the following instruction
demo :
https://danielerez.github.io/slides-image-io/#/3/2

On Mon, May 22, 2017 at 10:56 AM qinglong.d...@horebdata.cn <
qinglong.d...@horebdata.cn> wrote:

> Thanks! But I don't know how to import CA to browser. I have tried to
> import the CA to my firefox browser, but I failed. Is there any
> documentations about that?
>
>
> *From:* Niyazi Elvan 
> *Date:* 2017-05-19 15:54
> *To:* qinglong.dong 
> *CC:* users 
> *Subject:* Re: [ovirt-users] upload image
>
> Most probably it's ovirt engine CA certificate. You need to import it to
> your browser.
>
>
> On May 19, 2017 6:36 AM, "qinglong.d...@horebdata.cn" <
> qinglong.d...@horebdata.cn> wrote:
>
>> Hi all,
>> I wanted to upload a qcow2 image using web UI. But I got an
>> error:
>>  "
>> Unable to upload image to disk a38f29f4-594a-438b-a8e0-6a85ac56055d due to a 
>> network error. Make sure ovirt-imageio-proxy service is installed and 
>> configured, and ovirt-engine's certificate is registered as a valid CA in 
>> the browser.
>> "
>> The ovirt-imageio-proxy service had been installed when I
>> excuted "engine-setup". What shoud I do about ovirt-imageio-proxy or CA?
>> Hope someone can help, thanks!
>>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


[ovirt-users] adding a nic with its network with ansible module

2017-05-22 Thread Nathanaël Blanchet

Hello,

I'm used to easily add multiple network to vm with the following 
ovirt-shell command:


add nic --parent-vm-name acier --network-name brv106 --name admin

I try to do the same with ovirt_nics module (with ansible-console or 
with regular yml file)


ovirt_nics vm=acier name=admin network=brv106 profile=brv106 state=present

interface is successfully created but network is empty, as if network 
field were skipped.


Thanks for your help

--
Nathanaël Blanchet

Supervision réseau
Pôle Infrastrutures Informatiques
227 avenue Professeur-Jean-Louis-Viala
34193 MONTPELLIER CEDEX 5   
Tél. 33 (0)4 67 54 84 55
Fax  33 (0)4 67 54 84 14
blanc...@abes.fr

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] 4.1 appliance yum install fails

2017-05-22 Thread Simone Tiraboschi
Hi Michael,
could you please attach also you hosted-engine-setup logs?

thanks

On Sun, May 21, 2017 at 12:16 AM, Michael Hall 
wrote:

> Note: screenshot attached.
>
> I installed an oVirt node 4.1, then attempted to install oVirt engine on
> that using ovirt-hosted-engine-setup The installer downloads the appliance
> RPM, but installation fails due to missing GPG key. Installation fails
> whether I answer yes or no to "Use this key?" question. There is what
> appears to be an oVirt key in /etc/pki/rpm-gpg.
>
>
> Have I missed something?
>
> Thanks, Mike
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] upload image

2017-05-22 Thread qinglong.d...@horebdata.cn
Thanks! But I don't know how to import CA to browser. I have tried to import 
the CA to my firefox browser, but I failed. Is there any documentations about 
that?
 
From: Niyazi Elvan
Date: 2017-05-19 15:54
To: qinglong.dong
CC: users
Subject: Re: [ovirt-users] upload image
Most probably it's ovirt engine CA certificate. You need to import it to your 
browser.


On May 19, 2017 6:36 AM, "qinglong.d...@horebdata.cn" 
 wrote:
Hi all,
I wanted to upload a qcow2 image using web UI. But I got an error:
 "Unable to upload image to disk a38f29f4-594a-438b-a8e0-6a85ac56055d due to a 
network error. Make sure ovirt-imageio-proxy service is installed and 
configured, and ovirt-engine's certificate is registered as a valid CA in the 
browser."
The ovirt-imageio-proxy service had been installed when I excuted 
"engine-setup". What shoud I do about ovirt-imageio-proxy or CA? Hope someone 
can help, thanks!

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


[ovirt-users] unable to install ovirt-node-ng 3.6

2017-05-22 Thread Sachar de Vries
Hello,

I am trying to upgrade a cluster from 3.5 -> 3.6 -> 4.0. The engine is
currently on the 3.6 release but I seem unable to upgrade the ovirt-nodes
(thin hypervisors) to 3.6.

When trying a fresh install (clean bare metal server) using the
ovirt-node-ng-installer-ovirt-3.6-201606052403.iso the install fails at the
end with the following error:

>
> error: sum of all thin volume sizes (495.16 GB) exceeds the side of thin
> pool onn/pool00 and the size of the whole volume group (465.24GB)


This is when having the installer choose the partition schema. However when
I try to install using a manual partition schema based on the schema
recommendation it still fails.

The 4.x installer works fine, but I don't think I can use this since I will
have to upgrade to the cluster to 3.6 with el7 hosts firsts?

Any workarounds that I can try to get 3.6 installed?

Thanks
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] migration of a VM: fails

2017-05-22 Thread Francesco Romani
On 05/18/2017 04:53 PM, cmc wrote:
> I have to shut the VM down to stop it trying to repeatedly trying to
> migrate the problematic host (always the same one). If I take it out
> of maintenance, it will move the VMs back to balance (as per policy),
> so this is rather inconvenient. It took leaving it overnight and
> letting oVirt try repeatedly every few minutes to get it to migrate
> the VM (I can't wait that long, so I've had to shut that VM down for
> now)

Hi,

do you always have the same error?

This:

2017-05-16T10:12:23.206731Z qemu-kvm: socket_writev_buffer: Got err=32
for (69776/18446744073709551615)

is most likely found when QEMU is (failing to) transferring the VM state
during the migration.

>From https://bugzilla.redhat.com/show_bug.cgi?id=1355662 , however, we
learn that this message could be a red herring - if we see it, doesn't
mean something's wrong.

>From oVirt perspective, it seems all good. We need to investigate the
lower layers: libvirt, qemu. Let's start.


Are you by any chance using the post copy migration mode?

Could you please share the libvirt debug logs, at least on the source side?

https://wiki.libvirt.org/page/DebugLogs

You may want to do a test run with the debug logs turned on and disable them
just after, those are VERY verbose.


Thanks,

>
> On Wed, May 17, 2017 at 4:13 PM, cmc  wrote:
>> Just a note on this: a similar thing is now happening with the same VM
>> when I upgrade the other node, i.e., it can't move this one VM over
>> (so far) from one host to another. I will leave it trying overnight to
>> see if it succeeds.
>>
>> Thanks,
>>
>> Cam
>>
>> On Wed, May 17, 2017 at 11:40 AM, cmc  wrote:
>>> Hi Francesco,
>>>
>>> I left it running after I posted to the list, and it eventually (after
>>> many failed attempts) moved the VM without any intervention by me, and
>>> then updated the host, so that explains the differences in the
>>> versions of qemu between the hosts (they probably would have been the
>>> same when I tried the move first). The xml is attached.
>>>
>>> qemu and libvirt versions on the source host:
>>>
>>> ipxe-roms-qemu-20160127-5.git6366fa7a.el7.noarch
>>> libvirt-daemon-driver-qemu-2.0.0-10.el7_3.5.x86_64
>>> qemu-img-ev-2.6.0-28.el7_3.9.1.x86_64
>>> qemu-kvm-common-ev-2.6.0-28.el7_3.9.1.x86_64
>>> qemu-kvm-ev-2.6.0-28.el7_3.9.1.x86_64
>>> qemu-kvm-tools-ev-2.6.0-28.el7_3.3.1.x86_64
>>>
>>> libvirt-2.0.0-10.el7_3.5.x86_64
>>> libvirt-client-2.0.0-10.el7_3.5.x86_64
>>> libvirt-daemon-2.0.0-10.el7_3.5.x86_64
>>> libvirt-daemon-config-network-2.0.0-10.el7_3.5.x86_64
>>> libvirt-daemon-config-nwfilter-2.0.0-10.el7_3.5.x86_64
>>> libvirt-daemon-driver-interface-2.0.0-10.el7_3.5.x86_64
>>> libvirt-daemon-driver-lxc-2.0.0-10.el7_3.5.x86_64
>>> libvirt-daemon-driver-network-2.0.0-10.el7_3.5.x86_64
>>> libvirt-daemon-driver-nodedev-2.0.0-10.el7_3.5.x86_64
>>> libvirt-daemon-driver-nwfilter-2.0.0-10.el7_3.5.x86_64
>>> libvirt-daemon-driver-qemu-2.0.0-10.el7_3.5.x86_64
>>> libvirt-daemon-driver-secret-2.0.0-10.el7_3.5.x86_64
>>> libvirt-daemon-driver-storage-2.0.0-10.el7_3.5.x86_64
>>> libvirt-daemon-kvm-2.0.0-10.el7_3.5.x86_64
>>> libvirt-lock-sanlock-2.0.0-10.el7_3.5.x86_64
>>> libvirt-python-2.0.0-2.el7.x86_64
>>>
>>> qemu and libvirt versions on the dest host:
>>>
>>> ipxe-roms-qemu-20160127-5.git6366fa7a.el7.noarch
>>> libvirt-daemon-driver-qemu-2.0.0-10.el7_3.4.x86_64
>>> qemu-img-ev-2.6.0-28.el7_3.3.1.x86_64
>>> qemu-kvm-common-ev-2.6.0-28.el7_3.3.1.x86_64
>>> qemu-kvm-ev-2.6.0-28.el7_3.3.1.x86_64
>>> qemu-kvm-tools-ev-2.6.0-28.el7_3.3.1.x86_64
>>>
>>> libvirt-client-2.0.0-10.el7_3.4.x86_64
>>> libvirt-daemon-2.0.0-10.el7_3.4.x86_64
>>> libvirt-daemon-config-nwfilter-2.0.0-10.el7_3.4.x86_64
>>> libvirt-daemon-driver-interface-2.0.0-10.el7_3.4.x86_64
>>> libvirt-daemon-driver-network-2.0.0-10.el7_3.4.x86_64
>>> libvirt-daemon-driver-nodedev-2.0.0-10.el7_3.4.x86_64
>>> libvirt-daemon-driver-nwfilter-2.0.0-10.el7_3.4.x86_64
>>> libvirt-daemon-driver-qemu-2.0.0-10.el7_3.4.x86_64
>>> libvirt-daemon-driver-secret-2.0.0-10.el7_3.4.x86_64
>>> libvirt-daemon-driver-storage-2.0.0-10.el7_3.4.x86_64
>>> libvirt-daemon-kvm-2.0.0-10.el7_3.4.x86_64
>>> libvirt-lock-sanlock-2.0.0-10.el7_3.4.x86_64
>>> libvirt-python-2.0.0-2.el7.x86_64
>>>
>>>
>>> Thanks,
>>>
>>> Cam
>>>
>>> On Wed, May 17, 2017 at 9:12 AM, Francesco Romani  
>>> wrote:
 On 05/16/2017 01:06 PM, cmc wrote:
> Hi,
>
> Just trying to place in maintenance mode for a version upgrade, and
> one VM fails to migrate. The other 20-odd move over successfully. In
> /var/log/libvirt/qemu/, the VM's log on the source reports:
>
> 2017-05-16 09:48:06.339+: initiating migration
> 2017-05-16T09:52:25.498932Z qemu-kvm: socket_writev_buffer: Got err=32
> for (131328/18446744073709551615)
> 2017-05-16 09:52:47.311+: initiating migration
> 2017-05-16T09:57:06.755402Z qemu-kvm: socket_writev_buffer: Got