Re: [ovirt-users] Could not get access to ACL tech driver 'ebiptables'

[Kenneth Bingham]

I suspect this has something to do with macspoofing because I found that I
was able to start a guest by changing the virtual network interface profile
to remove network filtering. I verified the guests are able to start with
filtering enabled on the vnic profile if it is set to false in
engine-config and ovirt-engine service bounced. I'd prefer to leaf
macspoofing disabled globally and only enable for things like VRR, CARP;
but I'll have to leave it enabled for now. Could it be that the macs of the
imported guests, being from the foreign mac pool, are being blocked by an
ebtables policy? I wonder if I add their Ethernet range to the pools of the
gaining Manager...

On Fri, Nov 18, 2016 at 9:35 PM Kenneth Bingham <w...@qrk.us> wrote:

> I imported a guest from its iscsi storage domain and clicked the green UP
> button, but the guest failed to start. This was the first time vdsm tried
> to create a temporary storage domain for a host other than hosted_engine.
> I'm using the same chap credential that was used with the same iscsi
> storage domain with the old instance of Manager. It looks like it wasn't
> able to get permission to do something, but everything was set up with
> sudo-as-root. I used CentOS 7.2 with the ovirt-release repository and
> hosted-engine script to deploy Manager.
>
> From /var/log/vdsm/vdsm.log on the host where it tried to start:
> Thread-23385::ERROR::2016-11-19
> 02:12:41,907::vm::765::virt.vm::(_startUnderlyingVm)
> vmId=`c3125d32-ae2a-4d2f-af4c-13661d90ddf9`::*The vm start process failed*
> Traceback (most recent call last):
>   File "/usr/share/vdsm/virt/vm.py", line 706, in _startUnderlyingVm
> self._run()
>   File "/usr/share/vdsm/virt/vm.py", line 1996, in _run
> self._connection.createXML(domxml, flags),
>   File "/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py", line
> 123, in wrapper
> ret = f(*args, **kwargs)
>   File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 917, in
> wrapper
> return func(inst, *args, **kwargs)
>   File "*/usr/lib64/python2.7/site-packages/libvirt.py*", line 3611, in
> *createXML*
> if ret is None:raise libvirtError('virDomainCreateXML() failed',
> conn=self)
> libvirtError: internal error: *Could not get access to ACL tech driver
> 'ebiptables'*
>
> From /usr/lib64/python2.7/site-packages/libvirt.py which raised the error:
> def createXML(self, xmlDesc, flags=0):
> """Launch a new guest domain, based on an XML description similar
> to the one returned by virDomainGetXMLDesc()
> This function may require privileged access to the hypervisor.
> The domain is not persistent, so its definition will disappear
> when it
> is destroyed, or if the host is restarted (see
> virDomainDefineXML() to
> define persistent domains).
>
> If the VIR_DOMAIN_START_PAUSED flag is set, the guest domain
> will be started, but its CPUs will remain paused. The CPUs
> can later be manually started using virDomainResume.
>
> If the VIR_DOMAIN_START_AUTODESTROY flag is set, the guest
> domain will be automatically destroyed when the virConnectPtr
> object is finally released. This will also happen if the
> client application crashes / loses its connection to the
> libvirtd daemon. Any domains marked for auto destroy will
> block attempts at migration, save-to-file, or snapshots.
>
> virDomainFree should be used to free the resources after the
> domain object is no longer needed. """
> ret = libvirtmod.virDomainCreateXML(self._o, xmlDesc, flags)
> if ret is None:raise libvirtError('virDomainCreateXML() failed',
> conn=self)
> __tmp = virDomain(self,_obj=ret)
> return __tmp
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Could not get access to ACL tech driver 'ebiptables'

[Kenneth Bingham]

I imported a guest from its iscsi storage domain and clicked the green UP
button, but the guest failed to start. This was the first time vdsm tried
to create a temporary storage domain for a host other than hosted_engine.
I'm using the same chap credential that was used with the same iscsi
storage domain with the old instance of Manager. It looks like it wasn't
able to get permission to do something, but everything was set up with
sudo-as-root. I used CentOS 7.2 with the ovirt-release repository and
hosted-engine script to deploy Manager.

>From /var/log/vdsm/vdsm.log on the host where it tried to start:
Thread-23385::ERROR::2016-11-19
02:12:41,907::vm::765::virt.vm::(_startUnderlyingVm)
vmId=`c3125d32-ae2a-4d2f-af4c-13661d90ddf9`::*The vm start process failed*
Traceback (most recent call last):
  File "/usr/share/vdsm/virt/vm.py", line 706, in _startUnderlyingVm
self._run()
  File "/usr/share/vdsm/virt/vm.py", line 1996, in _run
self._connection.createXML(domxml, flags),
  File "/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py", line
123, in wrapper
ret = f(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 917, in
wrapper
return func(inst, *args, **kwargs)
  File "*/usr/lib64/python2.7/site-packages/libvirt.py*", line 3611, in
*createXML*
if ret is None:raise libvirtError('virDomainCreateXML() failed',
conn=self)
libvirtError: internal error: *Could not get access to ACL tech driver
'ebiptables'*

>From /usr/lib64/python2.7/site-packages/libvirt.py which raised the error:
def createXML(self, xmlDesc, flags=0):
"""Launch a new guest domain, based on an XML description similar
to the one returned by virDomainGetXMLDesc()
This function may require privileged access to the hypervisor.
The domain is not persistent, so its definition will disappear when
it
is destroyed, or if the host is restarted (see virDomainDefineXML()
to
define persistent domains).

If the VIR_DOMAIN_START_PAUSED flag is set, the guest domain
will be started, but its CPUs will remain paused. The CPUs
can later be manually started using virDomainResume.

If the VIR_DOMAIN_START_AUTODESTROY flag is set, the guest
domain will be automatically destroyed when the virConnectPtr
object is finally released. This will also happen if the
client application crashes / loses its connection to the
libvirtd daemon. Any domains marked for auto destroy will
block attempts at migration, save-to-file, or snapshots.

virDomainFree should be used to free the resources after the
domain object is no longer needed. """
ret = libvirtmod.virDomainCreateXML(self._o, xmlDesc, flags)
if ret is None:raise libvirtError('virDomainCreateXML() failed',
conn=self)
__tmp = virDomain(self,_obj=ret)
return __tmp
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Upgrading oVirt 3.6 with existing HTTPS certificate signed by custom CA to oVirt 4

[Kenneth Bingham]

Do I understand correctly? This procedure allows the oVirt administrator to
install for the Manager HTTP UI a server certificate issued by an authority
other than the built-in certificate authority that is always created when
Manager is installed. It is not possible to also install for VDSM or the
console server a server certificate that is issued by such an external
certificate authority. Only certificates issued by the built-in authority
may be bound to the VDSM and console services, and so it is necessary to
import the signing certificate of that built-in authority into the admin's
browser trust store before connecting to the console server (e.g., novnc
websocket console).

If that is correct then I will propose that we make it more convenient to
obtain the signing cert in the browser and whether it might be possible to
at least install an externally issued server certificate for the console
service so that the explicit trust of Manager's built-in CA is unnecessary.


On Thu, Nov 3, 2016 at 2:09 AM Yedidyah Bar David <d...@redhat.com> wrote:

> On Wed, Nov 2, 2016 at 10:49 PM, Beckman, Daniel
> <daniel.beck...@ingramcontent.com> wrote:
> > Thanks very much for the detailed instructions! I was able to upgrade
> from
> > 3.6.7 to 4.0.4 successfully. Here are some additional notes for those
> (like
> > me) who were already using a custom HTTPS certificate in 3.6:
> >
> >
> >
> > On step #3 “b” -- mv YOUR-3RD-PART-CERT.p12
> > /etc/pki/ovirt-engine/keys/apache.p12 – I didn’t need to perform this as
> the
> > file was already there from my previous 3.6 configuration; setup had not
> > removed it.
> >
> >
> >
> > On step #4 – extracting private key and certificate – I didn’t need to
> > perform this either; existing files were left intact from version 3.6.
> >
> >
> >
> > Restarting Apache and oVirt service was not enough to bring up the web
> admin
> > portal in my case. I had to reboot the server running oVirt engine, after
> > which the web admin portal was accessible.
> >
> >
> >
> > I recommend backing up /etc/pki in addition to /etc/ovirt-engine prior to
> > running setup.
>
> Thanks a lot for the report!
>
> Perhaps you'd like to push a patch to github to update the following page?
>
> http://www.ovirt.org/develop/release-management/features/infra/pki/
>
> Best regards,
>
> >
> >
> >
> > Best,
> >
> > Daniel
> >
> >
> >
> > From: <users-boun...@ovirt.org> on behalf of Martin Perina
> > <mper...@redhat.com>
> > Date: Tuesday, November 1, 2016 at 6:29 AM
> > To: Kenneth Bingham <w...@qrk.us>
> > Cc: users <users@ovirt.org>
> > Subject: Re: [ovirt-users] Upgrading oVirt 3.6 with existing HTTPS
> > certificate signed by custom CA to oVirt 4
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Nov 1, 2016 at 11:49 AM, Martin Perina <mper...@redhat.com>
> wrote:
> >
> > So first of all, we don't support replacing oVirt internal CA which is
> used
> > to sign host certificates. This internal CA is also used to sign HTTPS
> > certificate by default, but you can provided your own HTTPS certificate
> > signed by custom CA. The correct steps how to do that are (assuming you
> have
> > you custom CA certififcate in PEM format and HTTPS ceritificate along
> with
> > private key in PKCS12 format):
> >
> > 1.  Add your commercially issued certificate to the host-wide trust
> store.
> >cp YOUR-3RD-PARTY-CA-CERT.pem /etc/pki/ca-trust/source/anchors
> >update-ca-trust
> >
> > 2. Remove Apache CA link pointing to oVirt internal
> >rm /etc/pki/ovirt-engine/apache-ca.pem
> >
> > 3. Install your custom certificate (including complete certificate chain)
> >mv YOUR-3RD-PARTY-CA-CERT.pem /etc/pki/ovirt-engine/apache-ca.pem
> >
> >
> >
> >   mv YOUR-3RD-PART-CERT.p12 /etc/pki/ovirt-engine/keys/apache.p12
> >
> > The above command was missing in original steps, thanks Didi for pointing
> > this out.
> >
> >
> >
> >
> >
> > 4. Extract private key and certificate
> >
> >
> >
> >
> > openssl pkcs12 -in /etc/pki/ovirt-engine/keys/apache.p12 -nocerts -nodes
> >
> > /etc/pki/ovirt-engine/keys/apache.key.nopass
> >
> >
> >
> > openssl pkcs12 -in /etc/pki/ovirt-engine/keys/apache.p12 -nokeys >
> > /etc/pki/ovirt-engine/certs/apache.cer
> >
> > 5. Restart Apache
> >   service httpd restart
> >
> > 6. Create a new trust store confi

Re: [ovirt-users] Upgrading oVirt 3.6 with existing HTTPS certificate signed by custom CA to oVirt 4

[Kenneth Bingham]

That makes sense, but it is also disappointing to realize that oVirt
Manager will only trust certificates that itself has issued, and that there
is no support for Manager to trust VDSM server certificates issued by
another authority.

If I understand you correctly, then the *only* way to install a VDSM host
certificate is by registering with Manager at which time a certificate is
automatically issued and installed by Manager's built-in certificate
authority.


On Thu, Oct 27, 2016 at 3:27 PM Ravi Nori <rn...@redhat.com> wrote:

Since you replace ca.pem you need to replace the private key of ca.pem

Please copy the private key of  /etc/pki/ovirt-engine/ca.pem to
/etc/pki/ovirt-engine/private/ca.pem and let me know if everything works

On Thu, Oct 27, 2016 at 2:47 PM, Kenneth Bingham <w...@qrk.us> wrote:


Thanks Ravi, that's helpful and I appreciate the precision and attention to
detail. I performed similar steps to install a custom certificate for the
oVirt Manager GUI. But what about configuring ovirt-engine to trust a
certificate issued by the same CA and presented by the VDSM host? On the
hypervisor host, I used the existing private key to generate the CSR,
issued the server certificate, and installed in three locations before
bouncing vdsmd.

On the hypervisor Host server (not the Manager/engine server):
/etc/pki/vdsm/certs/vdsmcert.pem
/etc/pki/vdsm/libvirt-spice/server-cert.pem
/etc/pki/libvirt/clientcert.pem

Now, that host is "non responsive" in Manager because ovirt-engine does not
trust the new certificate even though I already performed all of the steps
that you describe above except that I installed the issuer's CA certificate
as the trusted entity. I've documented all of the steps I took in this Gist
<https://gist.github.com/qrkourier/9c9ac3e8b190dcb91d3767179d5a39ea>.



On Thu, Oct 27, 2016 at 2:12 PM Ravi Nori <rn...@redhat.com> wrote:

Here is a complete set of instructions that works for me

You can skip the first few steps of generating the certificate.

Ravi


Generate a self-signed certificate using openssl
==
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout
privateKey.key -out certificate.pem

Convert a PEM certificate file and a private key to PKCS#12 (.p12)
=
openssl pkcs12 -export -out certificate.p12 -inkey privateKey.key -in
certificate.pem

Extract the key from the bundle
=
openssl pkcs12 -in  certificate.p12 -nocerts -nodes > apache.key.nopass

Extract the certificate from the bundle
==
openssl pkcs12 -in certificate.p12 -nokeys > apache.cer

Create a new Keystore for testing
==
keytool -keystore clientkeystore -genkey -alias client

Convert .pem to .der

openssl x509 -outform der -in certificate.pem -out certificate.der

Import certificates to keystore
===
keytool -import -alias apache -keystore ./clientkeystore -file
./certificate.der

Create Custom conf for ovirt
==
vi /etc/ovirt-engine/engine.conf.d/99-custom-truststore.conf

Set location of truststore and its password
=
ENGINE_HTTPS_PKI_TRUST_STORE="/home/rnori/Downloads/Cert/clientkeystore"
ENGINE_HTTPS_PKI_TRUST_STORE_PASSWORD="123456"

Copy the custom certificates
==
rm /etc/pki/ovirt-engine/apache-ca.pem
cp certificate.pem /etc/pki/ovirt-engine/apache-ca.pem
cp certificate.p12 /etc/pki/ovirt-engine/keys/apache.p12
cp apache.cer /etc/pki/ovirt-engine/certs/apache.cer
cp apache.key.nopass /etc/pki/ovirt-engine/keys/apache.key.nopass

Restart engine and httpd
===
service httpd restart
service ovirt-engine restart

On Thu, Oct 27, 2016 at 5:30 AM, Nicolas Ecarnot <nico...@ecarnot.net>
wrote:

Le 27/10/2016 à 00:14, Kenneth Bingham a écrit :

I did install a server certificate from a private CA on the engine
server for the oVirt 4 Manager GUI, but haven't figured out how to
configure engine to trust the same CA which also issued the server
certificate presented by vdsm. This is important for us because this is
the same server certificate presented by the host when using the console
(e.g. websocket console falls silently if the user agent doesn't trust
the console server's certificate).


Hello,

Maybe related bug : on an oVirt 4, I followed the same procedure below to
install a custom CA, with *SUCCESS*.

Today, I had to reinstall one of the hosts, and it is failing with :
"CA certificate and CA private key do not match" :

http://pastebin.com/9JS05JtJ

Which certificate did we (Kenneth and I) did we mis-used?
What did we do wrong?

Regards,

Nicolas ECARNOT



On Wed, Oct 26, 2016, 16:58 Beckman, Daniel
<daniel.beck...@ingramcontent.com
<mailto:daniel.beck...@ingramcontent.com>> wrote:

We have oVirt 3.6.7 and I am preparing 

Re: [ovirt-users] Upgrading oVirt 3.6 with existing HTTPS certificate signed by custom CA to oVirt 4

[Kenneth Bingham]

Thanks Ravi, that's helpful and I appreciate the precision and attention to
detail. I performed similar steps to install a custom certificate for the
oVirt Manager GUI. But what about configuring ovirt-engine to trust a
certificate issued by the same CA and presented by the VDSM host? On the
hypervisor host, I used the existing private key to generate the CSR,
issued the server certificate, and installed in three locations before
bouncing vdsmd.

On the hypervisor Host server (not the Manager/engine server):
/etc/pki/vdsm/certs/vdsmcert.pem
/etc/pki/vdsm/libvirt-spice/server-cert.pem
/etc/pki/libvirt/clientcert.pem

Now, that host is "non responsive" in Manager because ovirt-engine does not
trust the new certificate even though I already performed all of the steps
that you describe above except that I installed the issuer's CA certificate
as the trusted entity. I've documented all of the steps I took in this Gist
<https://gist.github.com/qrkourier/9c9ac3e8b190dcb91d3767179d5a39ea>.



On Thu, Oct 27, 2016 at 2:12 PM Ravi Nori <rn...@redhat.com> wrote:

> Here is a complete set of instructions that works for me
>
> You can skip the first few steps of generating the certificate.
>
> Ravi
>
>
> Generate a self-signed certificate using openssl
> ==
> openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout
> privateKey.key -out certificate.pem
>
> Convert a PEM certificate file and a private key to PKCS#12 (.p12)
> =
> openssl pkcs12 -export -out certificate.p12 -inkey privateKey.key -in
> certificate.pem
>
> Extract the key from the bundle
> =
> openssl pkcs12 -in  certificate.p12 -nocerts -nodes > apache.key.nopass
>
> Extract the certificate from the bundle
> ==
> openssl pkcs12 -in certificate.p12 -nokeys > apache.cer
>
> Create a new Keystore for testing
> ==
> keytool -keystore clientkeystore -genkey -alias client
>
> Convert .pem to .der
> 
> openssl x509 -outform der -in certificate.pem -out certificate.der
>
> Import certificates to keystore
> ===
> keytool -import -alias apache -keystore ./clientkeystore -file
> ./certificate.der
>
> Create Custom conf for ovirt
> ==
> vi /etc/ovirt-engine/engine.conf.d/99-custom-truststore.conf
>
> Set location of truststore and its password
> =
> ENGINE_HTTPS_PKI_TRUST_STORE="/home/rnori/Downloads/Cert/clientkeystore"
> ENGINE_HTTPS_PKI_TRUST_STORE_PASSWORD="123456"
>
> Copy the custom certificates
> ==
> rm /etc/pki/ovirt-engine/apache-ca.pem
> cp certificate.pem /etc/pki/ovirt-engine/apache-ca.pem
> cp certificate.p12 /etc/pki/ovirt-engine/keys/apache.p12
> cp apache.cer /etc/pki/ovirt-engine/certs/apache.cer
> cp apache.key.nopass /etc/pki/ovirt-engine/keys/apache.key.nopass
>
> Restart engine and httpd
> ===
> service httpd restart
> service ovirt-engine restart
>
> On Thu, Oct 27, 2016 at 5:30 AM, Nicolas Ecarnot <nico...@ecarnot.net>
> wrote:
>
> Le 27/10/2016 à 00:14, Kenneth Bingham a écrit :
>
> I did install a server certificate from a private CA on the engine
> server for the oVirt 4 Manager GUI, but haven't figured out how to
> configure engine to trust the same CA which also issued the server
> certificate presented by vdsm. This is important for us because this is
> the same server certificate presented by the host when using the console
> (e.g. websocket console falls silently if the user agent doesn't trust
> the console server's certificate).
>
>
> Hello,
>
> Maybe related bug : on an oVirt 4, I followed the same procedure below to
> install a custom CA, with *SUCCESS*.
>
> Today, I had to reinstall one of the hosts, and it is failing with :
> "CA certificate and CA private key do not match" :
>
> http://pastebin.com/9JS05JtJ
>
> Which certificate did we (Kenneth and I) did we mis-used?
> What did we do wrong?
>
> Regards,
>
> Nicolas ECARNOT
>
>
>
> On Wed, Oct 26, 2016, 16:58 Beckman, Daniel
> <daniel.beck...@ingramcontent.com
> <mailto:daniel.beck...@ingramcontent.com>> wrote:
>
> We have oVirt 3.6.7 and I am preparing to upgrade to 4.0.4 release.
> I read the release notes (https://www.ovirt.org/release/4.0.4/) and
> noted comment #4 under “Install / Upgrade from previous version”:
>
> __ __
>
> /If you are using HTTPS certificate signed by custom certificate
> authority, please take a look at https://bugzilla.redhat.com/1336838
>

Re: [ovirt-users] Upgrading oVirt 3.6 with existing HTTPS certificate signed by custom CA to oVirt 4

[Kenneth Bingham]

I did install a server certificate from a private CA on the engine server
for the oVirt 4 Manager GUI, but haven't figured out how to configure
engine to trust the same CA which also issued the server certificate
presented by vdsm. This is important for us because this is the same server
certificate presented by the host when using the console (e.g. websocket
console falls silently if the user agent doesn't trust the console server's
certificate).

On Wed, Oct 26, 2016, 16:58 Beckman, Daniel <
daniel.beck...@ingramcontent.com> wrote:

> We have oVirt 3.6.7 and I am preparing to upgrade to 4.0.4 release. I read
> the release notes (https://www.ovirt.org/release/4.0.4/) and noted
> comment #4 under “Install / Upgrade from previous version”:
>
>
>
> *If you are using HTTPS certificate signed by custom certificate
> authority, please take a look at https://bugzilla.redhat.com/1336838
>  for steps which need to be done after
> migration to 4.0. Also please consult https://bugzilla.redhat.com/1313379
>  how to setup this custom CA for use
> with virt-viewer clients.*
>
>
>
> So I referred to the first bugzilla (
> https://bugzilla.redhat.com/show_bug.cgi?id=1336838), where it states as
> follows:
>
>
>
> If customer wants to use custom HTTPS certificate signed by different CA,
> then he has to perform following steps:
>
>
>
> 1. Install custom CA (that signed HTTPS certificate) into host wide
> trustore (more info can be found in update-ca-trust man page)
>
>
>
> 2. Configure HTTPS certificate in Apache (this step is same as in previous
> versions)
>
>
>
> 3. Create new configuration file (for example
> /etc/ovirt-engine/engine.conf.d/99-custom-truststore.conf) with following
> content:
>
> ENGINE_HTTPS_PKI_TRUST_STORE="/etc/pki/java/cacerts"
> ENGINE_HTTPS_PKI_TRUST_STORE_PASSWORD=""
>
>
>
> 4. Restart ovirt-engine service
>
>
>
> I find it humorous that step # 1 suggests reading the “man page” which is
> only slightly better than suggesting to “google” it.
>
>
>
> Has anyone using a custom CA for their HTTPS certificate successfully
> upgraded to oVirt 4? If so could you share your detailed steps? Or can
> anyone point me to an actual example of this procedure? I’m a little
> nervous about the upgrade if you can’t already tell.
>
>
>
> Thanks,
>
> Daniel
> ___
> 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] migrating via pivotting the storage domain between instances of Manager

[Kenneth Bingham]

Is it possible to "pivot" up or down guests from one instance of Manager to
another instance of Manager by detaching the data storage domain from the
source Manager's data center and attaching it to the destination Manager's
data center? I tried this with a block type storage domain, but there are
no storage domains found when I do "import domain" in the destination
Manager.

If I do "import domain" on the source Manager and choose the same oVirt
host to perform the import then the detached storage domain is able to be
imported. If I re-attach the storage domain to the source Manager's data
center the unregistered guests are available for import. Why does this
require that the oVirt host performing the import be the same host that had
formerly mounted the domain? Or, is it that the host is still recognized as
enrolled in the DC that had created the unregistered guests on the detached
storage domain?

What if, instead of detaching the storage domain from the source Manager's
data center, I shut down all guests and put the oVirt host in maintenance
mode and enroll that same oVirt host in the destination Manager's data
center, then would it be possible to import the detached storage domain and
import the unregistered guests and templates stored there?
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] management interface

[Kenneth Bingham]

Fernando, That is the recommended approach, that ovirtmgmt bridge not also
be used for VMs. This is for the sake of separation of privilege if I
understand correctly, and there's no reason that VMs will not be able to
communicate using that bridge. Whether or not you tag depends on your
network's logical topology. If you don't tag in oVirt manager and your
network uses VLANs, then the packets will be treated as belonging to the
default VLAN, often ID 1, but certainly not always.

On Sun, Jul 31, 2016 at 12:20 PM Fernando Fuentes 
wrote:

> Team,
>
> Is it possible to move the ovirt management interface to a separate vlan
> and keep it from been on the same interface as my LAN?
>
> IE: assign a tag to ovirtmanagement and keep another interface as untag
> for my LAN to use with the VM's
>
> Thoughts ideas?
>
> TIA!
>
> Regards,
>
> --
> Fernando Fuentes
> ffuen...@txweather.org
> http://www.txweather.org
> ___
> 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] Safe to upgrade HE hosts from GUI?

[Kenneth Bingham]

Roy, would I do that in the Cluster tab, with New button, and then in host
configurator select Hosted Engine sidebar? I noticed this option existed,
but the RHEV docs and developer blogs I've been referencing specify the
'hosted-engine --deploy' method.

On Sun, Jul 31, 2016 at 3:04 AM Roy Golan <rgo...@redhat.com> wrote:

> On 30 July 2016 at 02:48, Kenneth Bingham <w...@qrk.us> wrote:
>
>> Aw crap. I did exactly the same thing and this could explain a lot of the
>> issues I've been pulling out my beard over. Every time I did 'hosted-engine
>> --deploy' on the RHEV-M|NODE host I entered the FQDN of *that* host, not
>> the first host, as the origin of the Gluster FS volume because at the time
>> I didn't realize that
>> a. the manager would key deduplication on the URI of the volume
>> b. that the volume would be mounted on FUSE, not NFS, and therefore no
>> single point of entry is created by using the FQDN of the first host
>> because the GFS client will persist connections with all peers
>>
>>
> If you ever want to add an hosted engine host to your setup please do that
> from UI and not from CLI. That will prevent all this confusion.
>
>
>
>> On Fri, Jul 29, 2016 at 6:08 AM Simone Tiraboschi <stira...@redhat.com>
>> wrote:
>>
>>> On Fri, Jul 29, 2016 at 11:35 AM, Wee Sritippho <we...@forest.go.th>
>>> wrote:
>>> > On 29/7/2559 15:50, Simone Tiraboschi wrote:
>>> >>
>>> >> On Fri, Jul 29, 2016 at 6:31 AM, Wee Sritippho <we...@forest.go.th>
>>> wrote:
>>> >>>
>>> >>> On 28/7/2559 15:54, Simone Tiraboschi wrote:
>>> >>>
>>> >>> On Thu, Jul 28, 2016 at 10:41 AM, Wee Sritippho <we...@forest.go.th>
>>> >>> wrote:
>>> >>>>
>>> >>>> On 21/7/2559 16:53, Simone Tiraboschi wrote:
>>> >>>>
>>> >>>> On Thu, Jul 21, 2016 at 11:43 AM, Wee Sritippho <we...@forest.go.th
>>> >
>>> >>>> wrote:
>>> >>>>
>>> >>>>> Can I just follow
>>> >>>>>
>>> >>>>>
>>> http://www.ovirt.org/documentation/how-to/hosted-engine/#upgrade-hosted-engine
>>> >>>>> until step 3 and do everything else via GUI?
>>> >>>>
>>> >>>> Yes, absolutely.
>>> >>>>
>>> >>>>
>>> >>>> Hi, I upgrade a host (host02) via GUI and now its score is 0.
>>> Restarted
>>> >>>> the services but the result is still the same. Kinda lost now. What
>>> >>>> should I
>>> >>>> do next?
>>> >>>>
>>> >>> Can you please attach ovirt-ha-agent logs?
>>> >>>
>>> >>>
>>> >>> Yes, here are the logs:
>>> >>> https://app.box.com/s/b4urjty8dsuj98n3ywygpk3oh5o7pbsh
>>> >>
>>> >> Thanks Wee,
>>> >> your issue is here:
>>> >> MainThread::ERROR::2016-07-17
>>> >>
>>> >>
>>> 14:32:45,586::storage_server::143::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(_validate_pre_connected_path)
>>> >> The hosted-engine storage domain is already mounted on
>>> >>
>>> >> '/rhev/data-center/mnt/glusterSD/host02.ovirt.forest.go.th:
>>> _hosted__engine/639e689c-8493-479b-a6eb-cc92b6fc4cf4'
>>> >> with a path that is not supported anymore: the right path should be
>>> >>
>>> >> '/rhev/data-center/mnt/glusterSD/host01.ovirt.forest.go.th:
>>> _hosted__engine/639e689c-8493-479b-a6eb-cc92b6fc4cf4'.
>>> >>
>>> >> Did you manually tried to avoid the issue of a single entry point for
>>> >> the gluster FS volume using host01.ovirt.forest.go.th:_hosted__engine
>>> >> and host02.ovirt.forest.go.th:_hosted__engine there?
>>> >> This could cause a lot of confusion since the code could not detect
>>> >> that the storage domain is the same and you can end with it mounted
>>> >> twice into different locations and a lot of issues.
>>> >> The correct solution of that issue was this one:
>>> >> https://bugzilla.redhat.com/show_bug.cgi?id=1298693#c20
>>> >>
>>> >> Now, to have it fixed on your env you have to hack a bit.
>>> >> First step, you have to edit
>>> >> /etc/ovirt-hosted-engine

Re: [ovirt-users] master storage domain stuck in state "locked"

[Kenneth Bingham]

This is release 4.0.1 Node hypervisor OS image. I installed 4.0.0 from the
.iso and upgraded via the ovirt-4.0 repo. I ended up starting over with the
hosted-engine --deploy and this time, instead of waiting for auto-import of
the /engine storage domain and the hosted engine VM's disk, I did it
manually and it succeeded. There may be a defect in the way that
auto-import functionality works.

I may be able to provide the complete log data, but it's not trivial
because it exists only as a .tar of the discarded hosted engine storage
domain. It would probably be easiest to reproduce the failure mode on a
fresh install.


On Sun, Jul 31, 2016 at 3:07 AM Roy Golan <rgo...@redhat.com> wrote:

> On 31 July 2016 at 06:20, Kenneth Bingham <w...@qrk.us> wrote:
>
>> Correction: /data is the master, /engine is stuck in status "Locked", but
>> is also the volume where the self-hosted engine VM has its virtual disk as
>> deployed by the hosted-engine script. I've since tried rebooting both
>> primary and secondary points of entry to the Gluster volumes
>> simultaneously. The volume is still locked.
>>
>> On Sat, Jul 30, 2016 at 5:24 PM Kenneth Bingham <w...@qrk.us> wrote:
>>
>>> Please help me determine whether this is a defect or user error.
>>>
>>> The master storage domain "hosted_storage" was automatically imported in
>>> oVirt
>>> manager  when I created another new storage domain "/data", a Gluster FS
>>> volume,
>>> immediately after doing 'hosted-engine --deploy' on the
>>> "hosted_storage", a.k.a.
>>> "/engine" volume. The master storage domain transitioned to state
>>> "Locked",
>>> which I   believe to be an intermediate state that should have
>>> automatically
>>> changed to state "Active". It appears to be stuck because there has been
>>> no
>>> change for at least 8 hours. This may be the  cause of "ERROR
>>>
>>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>>>
>>> (org.ovirt.thread.pool-8-thread-28) [] Correlation ID: null, Call Stack:
>>> null,
>>> Custom Event ID: -1, Message: VDSM  command failed: Cannot
>>> find
>>> master domain".
>>>
>>> Self-Hosted Engine unique log hits for "hosted_storage" from
>>> /var/log/ovirt-engine/engine.log: http://pastebin.com/QaHQjB6z
>>>
>>>
>>
> Need all the log to see what's going on. btw what version are you using?
>
>> ___
>> 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] illegal host split-state

[Kenneth Bingham]

Thanks, Roy. It really seemed to be stuck because I waited more than 8
hours. I've since nuked the self-hosted engine VM, reinitialized the
lockspace, and redployed the appliance with hosted-engine. I'm no longer
able to reproduce this cycle and the main difference I see is that the
import of the /engine storage domain succeeded this time and the hosted
engine VM now appears in the "Virtual Machines" tab. It was always visible
in 'virsh --readonly list'.

On Sun, Jul 31, 2016 at 3:20 AM Roy Golan <rgo...@redhat.com> wrote:

> On 31 July 2016 at 02:24, Kenneth Bingham <w...@qrk.us> wrote:
>
>> When I set local maintenance on the self-hosted engine hypervisor host
>> through
>> the manager GUI it becomes stuck in state "Preparing for maintenance".
>> The
>> hosted engine virtual guest is automatically migrated because the HA
>> broker is
>> successfully set to maintenance mode=local. The host returns to state
>> "Up" in
>> the manager if I press button "Activate", but the column "Virtual
>> Machines"
>> continues to count the migrated VM. If I then reboot the host it reverts
>> to
>> state "Up" and the VM count no longer includes the vacated hosted engine,
>> so I'm
>> guessing it never *really* achieved state "Maintenance" even though the
>> event
>> log claims so immediately after the button is pressed. The condition
>> persists
>> after the reboot if the then-current hosted engine hypervisor host is
>> again
>> assigned to mode "Maintenance". I'm running 4.0.1, and I've tried
>> restarting services
>> and rebooting the hosts and VM involved. I suspect it has something to do
>> with my other
>> thread about the locked storage domain.
>>
>>
> how much time did you wait?
>
> The Host is in preparing for maintenance as long as it's VM count is > 0.
> So if the HE VM migrated to another host, the engine will detect that and
> will update the count accordingly. This transition is fast but not instant,
> cause the engine is pulling the info from all the hosts. If  the host is
> not running any vm and still can't be move to maintenance then lets see the
> logs VDSM of src and dst + engine.log
>
> ___
>> 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] HTML5 Console

[Kenneth Bingham]

I had the same problem until I imported the CA certificate from the engine
as a trusted root (self-signed) authority in my browser.

ENGINE:/etc/pki/ovirt-engine/ca.pem

Further possibilities mentioned in here:
https://access.redhat.com/solutions/718653


On Sat, Jul 30, 2016 at 11:12 PM Anantha Raghava <
rag...@exzatechconsulting.com> wrote:

> Hi,
>
> How do we start the HTML5 console for the Virtual Machines?
>
> Under console options, when we set the client console as HTML 5, only
> black screen appears. The same is the case for noVNC as well.
>
> Any suggestions to set this right?
> --
>
> Thanks & Regards,
> Anantha Raghava
> ___
> 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] master storage domain stuck in state "locked"

[Kenneth Bingham]

Correction: /data is the master, /engine is stuck in status "Locked", but
is also the volume where the self-hosted engine VM has its virtual disk as
deployed by the hosted-engine script. I've since tried rebooting both
primary and secondary points of entry to the Gluster volumes
simultaneously. The volume is still locked.

On Sat, Jul 30, 2016 at 5:24 PM Kenneth Bingham <w...@qrk.us> wrote:

> Please help me determine whether this is a defect or user error.
>
> The master storage domain "hosted_storage" was automatically imported in
> oVirt
> manager  when I created another new storage domain "/data", a Gluster FS
> volume,
> immediately after doing 'hosted-engine --deploy' on the "hosted_storage",
> a.k.a.
> "/engine" volume. The master storage domain transitioned to state
> "Locked",
> which I   believe to be an intermediate state that should have
> automatically
> changed to state "Active". It appears to be stuck because there has been
> no
> change for at least 8 hours. This may be the  cause of "ERROR
>
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>
> (org.ovirt.thread.pool-8-thread-28) [] Correlation ID: null, Call Stack:
> null,
> Custom Event ID: -1, Message: VDSM  command failed: Cannot find
>
> master domain".
>
> Self-Hosted Engine unique log hits for "hosted_storage" from
> /var/log/ovirt-engine/engine.log: http://pastebin.com/QaHQjB6z
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] illegal host split-state

[Kenneth Bingham]

When I set local maintenance on the self-hosted engine hypervisor host
through
the manager GUI it becomes stuck in state "Preparing for maintenance". The

hosted engine virtual guest is automatically migrated because the HA broker
is
successfully set to maintenance mode=local. The host returns to state "Up"
in
the manager if I press button "Activate", but the column "Virtual Machines"

continues to count the migrated VM. If I then reboot the host it reverts to

state "Up" and the VM count no longer includes the vacated hosted engine,
so I'm
guessing it never *really* achieved state "Maintenance" even though the
event
log claims so immediately after the button is pressed. The condition
persists
after the reboot if the then-current hosted engine hypervisor host is again

assigned to mode "Maintenance". I'm running 4.0.1, and I've tried
restarting services
and rebooting the hosts and VM involved. I suspect it has something to do
with my other
thread about the locked storage domain.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] master storage domain stuck in state "locked"

[Kenneth Bingham]

Please help me determine whether this is a defect or user error.

The master storage domain "hosted_storage" was automatically imported in
oVirt
manager  when I created another new storage domain "/data", a Gluster FS
volume,
immediately after doing 'hosted-engine --deploy' on the "hosted_storage",
a.k.a.
"/engine" volume. The master storage domain transitioned to state "Locked",

which I   believe to be an intermediate state that should have
automatically
changed to state "Active". It appears to be stuck because there has been no

change for at least 8 hours. This may be the  cause of "ERROR

[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]

(org.ovirt.thread.pool-8-thread-28) [] Correlation ID: null, Call Stack:
null,
Custom Event ID: -1, Message: VDSM  command failed: Cannot find

master domain".

Self-Hosted Engine unique log hits for "hosted_storage" from
/var/log/ovirt-engine/engine.log: http://pastebin.com/QaHQjB6z
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Safe to upgrade HE hosts from GUI?

[Kenneth Bingham]

Aw crap. I did exactly the same thing and this could explain a lot of the
issues I've been pulling out my beard over. Every time I did 'hosted-engine
--deploy' on the RHEV-M|NODE host I entered the FQDN of *that* host, not
the first host, as the origin of the Gluster FS volume because at the time
I didn't realize that
a. the manager would key deduplication on the URI of the volume
b. that the volume would be mounted on FUSE, not NFS, and therefore no
single point of entry is created by using the FQDN of the first host
because the GFS client will persist connections with all peers

On Fri, Jul 29, 2016 at 6:08 AM Simone Tiraboschi 
wrote:

> On Fri, Jul 29, 2016 at 11:35 AM, Wee Sritippho 
> wrote:
> > On 29/7/2559 15:50, Simone Tiraboschi wrote:
> >>
> >> On Fri, Jul 29, 2016 at 6:31 AM, Wee Sritippho 
> wrote:
> >>>
> >>> On 28/7/2559 15:54, Simone Tiraboschi wrote:
> >>>
> >>> On Thu, Jul 28, 2016 at 10:41 AM, Wee Sritippho 
> >>> wrote:
> 
>  On 21/7/2559 16:53, Simone Tiraboschi wrote:
> 
>  On Thu, Jul 21, 2016 at 11:43 AM, Wee Sritippho 
>  wrote:
> 
> > Can I just follow
> >
> >
> http://www.ovirt.org/documentation/how-to/hosted-engine/#upgrade-hosted-engine
> > until step 3 and do everything else via GUI?
> 
>  Yes, absolutely.
> 
> 
>  Hi, I upgrade a host (host02) via GUI and now its score is 0.
> Restarted
>  the services but the result is still the same. Kinda lost now. What
>  should I
>  do next?
> 
> >>> Can you please attach ovirt-ha-agent logs?
> >>>
> >>>
> >>> Yes, here are the logs:
> >>> https://app.box.com/s/b4urjty8dsuj98n3ywygpk3oh5o7pbsh
> >>
> >> Thanks Wee,
> >> your issue is here:
> >> MainThread::ERROR::2016-07-17
> >>
> >>
> 14:32:45,586::storage_server::143::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(_validate_pre_connected_path)
> >> The hosted-engine storage domain is already mounted on
> >>
> >> '/rhev/data-center/mnt/glusterSD/host02.ovirt.forest.go.th:
> _hosted__engine/639e689c-8493-479b-a6eb-cc92b6fc4cf4'
> >> with a path that is not supported anymore: the right path should be
> >>
> >> '/rhev/data-center/mnt/glusterSD/host01.ovirt.forest.go.th:
> _hosted__engine/639e689c-8493-479b-a6eb-cc92b6fc4cf4'.
> >>
> >> Did you manually tried to avoid the issue of a single entry point for
> >> the gluster FS volume using host01.ovirt.forest.go.th:_hosted__engine
> >> and host02.ovirt.forest.go.th:_hosted__engine there?
> >> This could cause a lot of confusion since the code could not detect
> >> that the storage domain is the same and you can end with it mounted
> >> twice into different locations and a lot of issues.
> >> The correct solution of that issue was this one:
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1298693#c20
> >>
> >> Now, to have it fixed on your env you have to hack a bit.
> >> First step, you have to edit
> >> /etc/ovirt-hosted-engine/hosted-engine.conf on all your hosted-engine
> >> hosts to ensure that the storage field always point to the same entry
> >> point (host01 for instance)
> >> Then on each host you can add something like:
> >>
> >> mnt_options=backupvolfile-server=host02.ovirt.forest.go.th:h
> ost03.ovirt.forest.go.th
> ,fetch-attempts=2,log-level=WARNING,log-file=/var/log/engine_domain.log
> >>
> >> Then check the representation of your storage connection in the table
> >> storage_server_connections of the engine DB and make sure that
> >> connection refers to the entry point you used in hosted-engine.conf on
> >> all your hosts, you have lastly to set the value of mount_options also
> >> here.
> >
> > Weird. The configuration in all hosts are already referring to host01.
>
> but for sure you have a connection pointing to host02 somewhere, did
> you try to manually deploy from CLI connecting the gluster volume on
> host02?
>
> > Also, in the storage_server_connections table:
> >
> > engine=> SELECT * FROM storage_server_connections;
> >   id  | connection|
> > user_name | password | iqn | port | portal | storage_type |
> mount_options |
> > vfs_type
> >  | nfs_version | nfs_timeo | nfs_retrans
> >
> --+--+---+--+-+--++--+---+--
> > -+-+---+-
> >  bd78d299-c8ff-4251-8aab-432ce6443ae8 |
> > host01.ovirt.forest.go.th:/hosted_engine |   | | |  | 1
> > |7 |   | glusterfs
> >  | |   |
> > (1 row)
> >
> >
> >>
> >> Please tune also the value of network.ping-timeout for your glusterFS
> >> volume to avoid this:
> >>   https://bugzilla.redhat.com/show_bug.cgi?id=1319657#c17
> >
> >
> > --
> > Wee
> >
> ___
> Users mailing list
> 

[ovirt-users] made the mistake of configuring bond before 'hosted-engine --deploy'

[Kenneth Bingham]

Do you know of a way to force vdsmd to forget what it knows about the
network configuration on the hypervisor host? If I synchronize or make any
change through the engine the host drops off the network because of an
invalid configuration pushed by some component of oVirt which creates bond1
with BRIDGE=ovirtmgmt when the bridge should be assigned to bond1.$vid If I
manually edit the ifcfg files or make changes with the ip command I can
restore network connectivity, but can not make any changes in engine. It's
not clear how to recover from this situation without reinstalling the OS.

I've concluded that I should have manually configured the VLAN sub
interface only before deploying hosted engine which activates vdsmd, then
configured bonds and VLANs through engine. I believe the ovirtmgmt bridge
became assigned to the bond instead of the VLAN interface because I
de-selected VLAN tagging in the logical network configuration in engine,
and I think most of the problems I'm having are due to my needing to
manually edit the configuration files written by VDSM in order to bring the
host back on the network so that it can be managed by engine.

# node 4.0.1
# yum list installed |grep ovirt
cockpit-ovirt-dashboard.noarch 0.10.5-1.0.0.el7.centos
 installed
libgovirt.x86_64   0.3.3-1.el7_2.1
 installed
ovirt-engine-appliance.noarch  4.0-20160718.1.el7.centos
 @ovirt-4.0
ovirt-engine-sdk-python.noarch 3.6.7.0-1.el7.centos
installed
ovirt-host-deploy.noarch   1.5.1-1.el7.centos
installed
ovirt-hosted-engine-ha.noarch  2.0.1-1.el7.centos
installed
ovirt-hosted-engine-setup.noarch   2.0.1-1.el7.centos
installed
ovirt-imageio-common.noarch
 0.3.0-0.201606191345.git9f3d6d4.el7.centos
ovirt-imageio-daemon.noarch
 0.3.0-0.201606191345.git9f3d6d4.el7.centos
ovirt-node-ng-image-update-placeholder.noarch
ovirt-release-host-node.noarch 4.0.1-1.el7
 installed
ovirt-release40-pre.noarch 4.0.1-1
 installed
ovirt-setup-lib.noarch 1.0.2-1.el7.centos
installed
ovirt-vmconsole.noarch 1.0.3-1.el7.centos
installed
ovirt-vmconsole-host.noarch1.0.3-1.el7.centos
installed

# hosted engine appliance
# yum list installed|grep ovirt
ebay-cors-filter.noarch 1.0.1-3.el7
 @centos-ovirt40-candidate
libtomcrypt.x86_64  1.17-23.el7
 @ovirt-4.0-epel
libtommath.x86_64   0.42.0-4.el7
@ovirt-4.0-epel
novnc.noarch0.5.1-2.el7
 @centos-ovirt40-candidate
otopi.noarch1.5.1-1.el7.centos   @ovirt-4.0

otopi-java.noarch   1.5.1-1.el7.centos   @ovirt-4.0

ovirt-engine.noarch 4.0.1.1-1.el7.centos @ovirt-4.0

ovirt-engine-backend.noarch 4.0.1.1-1.el7.centos @ovirt-4.0

ovirt-engine-cli.noarch 3.6.8.0-1.el7.centos @ovirt-4.0

ovirt-engine-dashboard.noarch   1.0.0-0.2.20160610git5d210ea.el7.centos
 @ovirt-4.0

ovirt-engine-dbscripts.noarch   4.0.1.1-1.el7.centos @ovirt-4.0

ovirt-engine-dwh.noarch 4.0.1-1.el7.centos   @ovirt-4.0

ovirt-engine-dwh-setup.noarch   4.0.1-1.el7.centos   @ovirt-4.0

ovirt-engine-extension-aaa-jdbc.noarch
1.1.0-1.el7  @ovirt-4.0

ovirt-engine-extensions-api-impl.noarch
4.0.1.1-1.el7.centos @ovirt-4.0

ovirt-engine-lib.noarch 4.0.1.1-1.el7.centos @ovirt-4.0

ovirt-engine-restapi.noarch 4.0.1.1-1.el7.centos @ovirt-4.0

ovirt-engine-sdk-python.noarch  3.6.7.0-1.el7.centos @ovirt-4.0

ovirt-engine-setup.noarch   4.0.1.1-1.el7.centos @ovirt-4.0

ovirt-engine-setup-base.noarch  4.0.1.1-1.el7.centos @ovirt-4.0

ovirt-engine-setup-plugin-ovirt-engine.noarch
4.0.1.1-1.el7.centos @ovirt-4.0

ovirt-engine-setup-plugin-ovirt-engine-common.noarch
4.0.1.1-1.el7.centos @ovirt-4.0

ovirt-engine-setup-plugin-vmconsole-proxy-helper.noarch
4.0.1.1-1.el7.centos @ovirt-4.0

ovirt-engine-setup-plugin-websocket-proxy.noarch
4.0.1.1-1.el7.centos @ovirt-4.0

ovirt-engine-tools.noarch   4.0.1.1-1.el7.centos @ovirt-4.0

ovirt-engine-tools-backup.noarch4.0.1.1-1.el7.centos @ovirt-4.0

ovirt-engine-userportal.noarch  4.0.1.1-1.el7.centos @ovirt-4.0

ovirt-engine-vmconsole-proxy-helper.noarch
4.0.1.1-1.el7.centos @ovirt-4.0

ovirt-engine-webadmin-portal.noarch 4.0.1.1-1.el7.centos @ovirt-4.0

ovirt-engine-websocket-proxy.noarch 4.0.1.1-1.el7.centos @ovirt-4.0

ovirt-engine-wildfly.x86_64 10.0.0-1.el7