date:20190213

I'm also a bit unclear about updating to 4.3 cluster level.  I have a 3
host HCI setup which I just updated to 4.3 manually.  I upgraded engine to
4.3 then upgraded each of the three hosts to ovirt node 4.3.  I still need
to change cluster/data centre compatibility level to 4.3.  If I try to
change cluster compatibility level to 4.3 it tells me that all hosts need
to be in maintenance to do so (does this mean I need to shut down all VMs
and put each host in maintenance?)

On Wed, Feb 13, 2019 at 7:24 AM Roman Last  wrote:

> Hello!
> What sequence of upgrading cluster to 4.3 version?
> When i click upgrade on host w or w\o host reboot it just says "Upgrade
> has started for" and nothing after timeout reached. When i force restart
> host, version 4.3 not added. Is that normal?
> https://prnt.sc/mki3v8
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/P4A7VQIDM6GM54XGQRETANU5ACVROYYG/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/KGOEOR6VRN4TSBYTQZLQ7HSKXUGC7YBE/

[ovirt-users] Re: Cluster Compatibility Version Upgrading Order

I just realized that when I change compatibility level to 4.3 under edit
cluster settings it is automatically switching CPU type from "Intel
SandyBridge IBRS Family" to "Intel Nahalem Family".  I believe the CPU type
change is what is requiring all hosts to be in maintenance mode.  My
question is, is the change of the family type correct or is it a different
family type being selected due to a bug or some other issue?

On Wed, Feb 13, 2019 at 9:54 AM Jayme  wrote:

> I'm also a bit unclear about updating to 4.3 cluster level.  I have a 3
> host HCI setup which I just updated to 4.3 manually.  I upgraded engine to
> 4.3 then upgraded each of the three hosts to ovirt node 4.3.  I still need
> to change cluster/data centre compatibility level to 4.3.  If I try to
> change cluster compatibility level to 4.3 it tells me that all hosts need
> to be in maintenance to do so (does this mean I need to shut down all VMs
> and put each host in maintenance?)
>
> On Wed, Feb 13, 2019 at 7:24 AM Roman Last  wrote:
>
>> Hello!
>> What sequence of upgrading cluster to 4.3 version?
>> When i click upgrade on host w or w\o host reboot it just says "Upgrade
>> has started for" and nothing after timeout reached. When i force restart
>> host, version 4.3 not added. Is that normal?
>> https://prnt.sc/mki3v8
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/P4A7VQIDM6GM54XGQRETANU5ACVROYYG/
>>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/E5QFFFQ7ATIPE37ZPZ4OYOEYR3N2DH2I/

[ovirt-users] Re: SURVEY: your NFS configuration (Bug 1666795 - SHE doesn't start after power-off, 4.1 to 4.3 upgrade - VolumeDoesNotExist: Volume does not exist )

2019-02-13 Thread Torsten Stolpmann


/etc/exports:

/export/volumes *(rw,all_squash,anonuid=36,anongid=36)


exportfs -v:

/data/volumes 
(sync,wdelay,hide,no_subtree_check,anonuid=36,anongid=36,sec=sys,rw,secure,root_squash,all_squash)


Centos7.6, oVirt 4.2.8. We are not running HE, ovirt-engine runs on bare 
metal. Not sure if this information is relevant then.


Torsten

On 12.02.2019 23:39, Nir Soffer wrote:

Looking at
https://bugzilla.redhat.com/1666795

It seems that a change in vdsm/libvirt exposed NFS configuration issue, 
that may was

needed in the past and probably not needed now.

If you use NFS, I would like to see your /etc/exports (after sanitizing 
it if needed).

For extra bonus, output of "exportfs -v" would be useful.

In particular, I want to know if you use root_squash, all_squash, or 
no_root_squash.


Thanks,
Nir

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/7J3ZV25DP2X5TD6A4IV63W5PANKWERTO/


___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/3JLCVXS72DTSM6C2KXTYCERWZAA44WIO/

[ovirt-users] Re: SURVEY: your NFS configuration (Bug 1666795 - SHE doesn't start after power-off, 4.1 to 4.3 upgrade - VolumeDoesNotExist: Volume does not exist )

2019-02-13 Thread Arman Khalatyan

/data on ZoL exported with nfs4:
(rw,sync,all_squash,no_subtree_check,anonuid=36,anongid=36)
Centos7.6, oVirt 4.2.8, ovirt-engine runs on a bare metal

On Wed, Feb 13, 2019 at 3:17 PM Torsten Stolpmann
 wrote:
>
> /etc/exports:
>
> /export/volumes *(rw,all_squash,anonuid=36,anongid=36)
>
>
> exportfs -v:
>
> /data/volumes
> (sync,wdelay,hide,no_subtree_check,anonuid=36,anongid=36,sec=sys,rw,secure,root_squash,all_squash)
>
> Centos7.6, oVirt 4.2.8. We are not running HE, ovirt-engine runs on bare
> metal. Not sure if this information is relevant then.
>
> Torsten
>
> On 12.02.2019 23:39, Nir Soffer wrote:
> > Looking at
> > https://bugzilla.redhat.com/1666795
> >
> > It seems that a change in vdsm/libvirt exposed NFS configuration issue,
> > that may was
> > needed in the past and probably not needed now.
> >
> > If you use NFS, I would like to see your /etc/exports (after sanitizing
> > it if needed).
> > For extra bonus, output of "exportfs -v" would be useful.
> >
> > In particular, I want to know if you use root_squash, all_squash, or
> > no_root_squash.
> >
> > Thanks,
> > Nir
> >
> > ___
> > Users mailing list -- users@ovirt.org
> > To unsubscribe send an email to users-le...@ovirt.org
> > Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> > oVirt Code of Conduct: 
> > https://www.ovirt.org/community/about/community-guidelines/
> > List Archives: 
> > https://lists.ovirt.org/archives/list/users@ovirt.org/message/7J3ZV25DP2X5TD6A4IV63W5PANKWERTO/
> >
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/3JLCVXS72DTSM6C2KXTYCERWZAA44WIO/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/JYQEPGP5CHODFR7F7ZZUHBVI3H6UA6HX/

[ovirt-users] Re: Problem installing hyperconverged setup

2019-02-13 Thread Edward Berger

I don't believe the wizard followed your wishes if it comes up with 1005gb
for the thinpool.
500gb data + 500gb vmstore +5gb metadata = 1005gb

The wizard tries to do the same setup on all three gluster hosts.
So if you change anything, you have to "check and edit" the config file it
generates in all three locations
before deploy..

With only 450gb min-size-disk, I'd start over again, delete the data and
vmstore domains during the wizard setup
and bump up engine size to fill up the available space on the smallest disk
(400gb or so).

The other domains aren't necessary and you might want to give them their
own larger disks later.

On Wed, Feb 13, 2019 at 8:41 AM  wrote:

> Hi,
>
> I am currently setting up an Ovirt cluster in a test environment and
> cannot get the hyperconverged setup to run properly.  I have installed 3
> nodes on version 4.2.8.
>
> I keep getting the following error -
>
> TASK [Create LVs with specified size for the VGs]
> **
> failed: [node01.ovirt.local] (item={u'lv': u'gluster_thinpool_sdb',
> u'size': u'1005GB', u'extent': u'100%FREE', u'vg': u'gluster_vg_sdb'}) =>
> {"changed": false, "item": {"extent": "100%FREE", "lv":
> "gluster_thinpool_sdb", "size": "1005GB", "vg": "gluster_vg_sdb"}, "msg":
> "  WARNING: Pool zeroing and 3.00 MiB large chunk size slows down thin
> provisioning.\n  WARNING: Consider disabling zeroing (-Zn) or using smaller
> chunk size (<512.00 KiB).\n  Volume group \"gluster_vg_sdb\" has
> insufficient free space (157261 extents): 343040 required.\n", "rc": 5}
> to retry, use: --limit @/tmp/tmpbXqHhw/lvcreate.retry
>
> All 3 nodes have an /sdb installed which are different sizes but all in
> excess of 450Gb.  I have specified JBOD in the setup.
>
> I have tried reducing the size of the engine, data and vmstore bricks to
> 50Gb each instead of the default but the installation still fails.
>
> I think it has something to do with the thin provisioning but not sure
> what.
>
> Any help would be much appreciated.
>
> Thanks
> Paul.
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/BXNOIJCQHCOZCHEH4MLVB4F4AURGHBIZ/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/4LQUWXCPNVTJWGH4UMO7WOVZRCGTBOPO/

[ovirt-users] Stuck completing last step of 4.3 upgrade

Environment setup:

3 Host HCI GlusterFS setup. Identical hosts, Dell R720s w/ Intel E5-2690
CPUs

1 default data center (4.2 compat)
1 default cluster (4.2 compat)

Situation: I recently upgraded my three node HCI cluster from Ovirt 4.2 to
4.3. I did so by first updating the engine to 4.3 then upgrading each
ovirt-node host to 4.3 and rebooting.

Currently engine and all hosts are running 4.3 and all is working fine.

To complete the upgrade I need to update cluster compatibility to 4.3 and
then data centre to 4.3. This is where I am stuck.

The CPU type on cluster is "Intel SandyBridge IBRS Family". This option is
no longer available if I select 4.3 compatibility. Any other option chosen
such as SandyBridge IBRS SSBD will not allow me to switch to 4.3 as all
hosts must be in maintenance mode (which is not possible w/ self hosted
engine).

I saw another post about this where someone else followed steps to create a
second cluster on 4.3 with new CPU type then move one host to it, start
engine on it then perform other steps to eventually get to 4.3
compatibility.

I tried to add a 4.3 cluster with gluster service and put one of my hosts
in to maintenance mode but could not move it to the new cluster, it gave me
an error about the host having gluster service. If I try to import gluster
config in cluster add UI it fails in engine log with
"SERVER_ALREADY_EXISTS_IN_ANOTHER_CLUSTER"

My question is, what is the proper procedure for me to complete upgrading
my three node HCI environment to 4.3 cluster compatibility along with
changing CPU type?

Do I really need to create a second cluster and move host(s) to it? If so
how can I move an existing host with running gluster service to a new
cluster?

Thanks in advance!
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/FJVNWEA5XB2ZKPCLJWTASZYVY2IIGTNO/

[ovirt-users] Re: Stuck completing last step of 4.3 upgrade

> Environment setup:
> 
> 3 Host HCI GlusterFS setup.  Identical hosts, Dell R720s w/ Intel E5-2690
> CPUs
> 
> 1 default data center (4.2 compat)
> 1 default cluster (4.2 compat)
> 
> Situation: I recently upgraded my three node HCI cluster from Ovirt 4.2 to
> 4.3.  I did so by first updating the engine to 4.3 then upgrading each
> ovirt-node host to 4.3 and rebooting.
> 
> Currently engine and all hosts are running 4.3 and all is working fine.
> 
> To complete the upgrade I need to update cluster compatibility to 4.3 and
> then data centre to 4.3.  This is where I am stuck.
> 
> The CPU type on cluster is "Intel SandyBridge IBRS Family".  This option is
> no longer available if I select 4.3 compatibility.  Any other option chosen
> such as SandyBridge IBRS SSBD will not allow me to switch to 4.3 as all
> hosts must be in maintenance mode (which is not possible w/ self hosted
> engine).
> 
> I saw another post about this where someone else followed steps to create a
> second cluster on 4.3 with new CPU type then move one host to it, start
> engine on it then perform other steps to eventually get to 4.3
> compatibility.
> 

I have the exact same hardware configuration and was able to change to 
"SandyBridge IBRS SSBD" without creating a new cluster.  How I made that 
happen, I'm not so sure, but the cluster may have been in "Global Maintenance" 
mode when I changed it.

 
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/5B3TAXKO7IBTWRVNF2K4II472TDISO6P/

[ovirt-users] Re: Stuck completing last step of 4.3 upgrade

I think I just figured out what I was doing wrong.  On edit cluster screen
I was changing both the CPU type and cluster level 4.3.  I tried it again
by switching to the new CPU type first (leaving cluster on 4.2) then
saving, then going back in and switching compat level to 4.3.  It appears
that you need to do this in two steps for it to work.



On Wed, Feb 13, 2019 at 12:57 PM Jayme  wrote:

> Hmm interesting, I wonder how you were able to switch from SandyBridge
> IBRS to SandyBridge IBRS SSBD.  I just attempted the same in both regular
> mode and in global maintenance mode and it won't allow me to, it says that
> all hosts have to be in maintenance mode (screenshots attached).   Are you
> also running HCI/Gluster setup?
>
>
>
> On Wed, Feb 13, 2019 at 12:44 PM Ron Jerome  wrote:
>
>> > Environment setup:
>> >
>> > 3 Host HCI GlusterFS setup.  Identical hosts, Dell R720s w/ Intel
>> E5-2690
>> > CPUs
>> >
>> > 1 default data center (4.2 compat)
>> > 1 default cluster (4.2 compat)
>> >
>> > Situation: I recently upgraded my three node HCI cluster from Ovirt 4.2
>> to
>> > 4.3.  I did so by first updating the engine to 4.3 then upgrading each
>> > ovirt-node host to 4.3 and rebooting.
>> >
>> > Currently engine and all hosts are running 4.3 and all is working fine.
>> >
>> > To complete the upgrade I need to update cluster compatibility to 4.3
>> and
>> > then data centre to 4.3.  This is where I am stuck.
>> >
>> > The CPU type on cluster is "Intel SandyBridge IBRS Family".  This
>> option is
>> > no longer available if I select 4.3 compatibility.  Any other option
>> chosen
>> > such as SandyBridge IBRS SSBD will not allow me to switch to 4.3 as all
>> > hosts must be in maintenance mode (which is not possible w/ self hosted
>> > engine).
>> >
>> > I saw another post about this where someone else followed steps to
>> create a
>> > second cluster on 4.3 with new CPU type then move one host to it, start
>> > engine on it then perform other steps to eventually get to 4.3
>> > compatibility.
>> >
>>
>> I have the exact same hardware configuration and was able to change to
>> "SandyBridge IBRS SSBD" without creating a new cluster.  How I made that
>> happen, I'm not so sure, but the cluster may have been in "Global
>> Maintenance" mode when I changed it.
>>
>>
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/5B3TAXKO7IBTWRVNF2K4II472TDISO6P/
>>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/V6IAVNC3Z5PMTTA263QOAJZ5P2HILPUP/

[ovirt-users] Re: engine-iso-uploader taking a REALLY long time

2019-02-13 Thread Dominik Holler

On Fri, 25 Jan 2019 14:23:33 +0100
Sandro Bonazzola  wrote:

> Il giorno ven 25 gen 2019 alle ore 13:50  ha
> scritto:
> 
> > I am noticing that the engine-iso-uploader tool on oVirt 4.2.7 (running on
> > CentOS  7.6.1810) takes a very long time to load individual ISO's, usually
> > on the order of hours for a single ISO.  Is this normal?
> >
> 
> It may be normal if you're uploading on a very slow network connection
> otherwise seems suspicious.

Bug 1676713 - ovirt-iso-uploader is very slow
https://bugzilla.redhat.com/show_bug.cgi?id=1676713
is created to solve this issue.

Your input on the bug would be helpful, because
currently I am not able to reproduce locally.

> As a side note, ISO domains are deprecated, you should upload ISO images
> directly on DATA domains from the web admin console.
> 
> 
> > ___
> > Users mailing list -- users@ovirt.org
> > To unsubscribe send an email to users-le...@ovirt.org
> > Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> > oVirt Code of Conduct:
> > https://www.ovirt.org/community/about/community-guidelines/
> > List Archives:
> > https://lists.ovirt.org/archives/list/users@ovirt.org/message/VGA4GV2Q2762633TXOX3L62XZFFLMSST/
> >
> 
> 
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/DNOYE3MLARSG3P3HKCMZIF3NJJZGJBA5/

[ovirt-users] Re: engine-iso-uploader very slow

Hi all,

We had a couple reports of this, so I think it's a real bug.
I opened https://bugzilla.redhat.com/show_bug.cgi?id=1676713

Thanks for reporting!

On Thu, Jan 31, 2019 at 5:08 AM Tommaso M  wrote:

> Hi Sandro, and thank you, my sos report : https://bit.ly/2MJleA0
>
> bye
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/UI6TL4JYILYMGK4YSZYO6M46OFFRPRDJ/
>


-- 

GREG SHEREMETA

SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX

Red Hat NA



gsher...@redhat.comIRC: gshereme

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/LBMT5O5E2FMFJJNJED3PVIA5AYGZOX3H/

[ovirt-users] Re: Stuck completing last step of 4.3 upgrade

I may have made matters worse.  So I changed to 4.3 compatible cluster then
4.3 compatible data center.  All VMs were marked as requiring a reboot.  I
restarted a couple of them and none of them will start up, they are saying
"bad volume specification".  The ones running that I did not yet restart
are still running ok.  I need to figure out why the VMs aren't restarting.

Here is an example from vdsm.log

olumeError: Bad volume specification {'address': {'function': '0x0', 'bus':
'0x00', 'domain': '0x', 'type': 'pci', 'slot': '0x06'}, 'serial':
'd81a6826-dc46-44db-8de7-405d30e44d57', 'index': 0, 'iface': 'virtio',
'apparentsize': '64293699584', 'specParams': {}, 'cache': 'none',
'imageID': 'd81a6826-dc46-44db-8de7-405d30e44d57', 'truesize':
'64293814272', 'type': 'disk', 'domainID':
'1f2e9989-9ab3-43d5-971d-568b8feca918', 'reqsize': '0', 'format': 'cow',
'poolID': 'a45e442e-9989-11e8-b0e4-00163e4bf18a', 'device': 'disk', 'path':
'/rhev/data-center/a45e442e-9989-11e8-b0e4-00163e4bf18a/1f2e9989-9ab3-43d5-971d-568b8feca918/images/d81a6826-dc46-44db-8de7-405d30e44d57/2d6d5f87-ccb0-48ce-b3ac-84495bd12d32',
'propagateErrors': 'off', 'name': 'vda', 'bootOrder': '1', 'volumeID':
'2d6d5f87-ccb0-48ce-b3ac-84495bd12d32', 'diskType': 'file', 'alias':
'ua-d81a6826-dc46-44db-8de7-405d30e44d57', 'discard': False}

On Wed, Feb 13, 2019 at 1:01 PM Jayme  wrote:

> I think I just figured out what I was doing wrong.  On edit cluster screen
> I was changing both the CPU type and cluster level 4.3.  I tried it again
> by switching to the new CPU type first (leaving cluster on 4.2) then
> saving, then going back in and switching compat level to 4.3.  It appears
> that you need to do this in two steps for it to work.
>
>
>
> On Wed, Feb 13, 2019 at 12:57 PM Jayme  wrote:
>
>> Hmm interesting, I wonder how you were able to switch from SandyBridge
>> IBRS to SandyBridge IBRS SSBD.  I just attempted the same in both regular
>> mode and in global maintenance mode and it won't allow me to, it says that
>> all hosts have to be in maintenance mode (screenshots attached).   Are you
>> also running HCI/Gluster setup?
>>
>>
>>
>> On Wed, Feb 13, 2019 at 12:44 PM Ron Jerome  wrote:
>>
>>> > Environment setup:
>>> >
>>> > 3 Host HCI GlusterFS setup.  Identical hosts, Dell R720s w/ Intel
>>> E5-2690
>>> > CPUs
>>> >
>>> > 1 default data center (4.2 compat)
>>> > 1 default cluster (4.2 compat)
>>> >
>>> > Situation: I recently upgraded my three node HCI cluster from Ovirt
>>> 4.2 to
>>> > 4.3.  I did so by first updating the engine to 4.3 then upgrading each
>>> > ovirt-node host to 4.3 and rebooting.
>>> >
>>> > Currently engine and all hosts are running 4.3 and all is working fine.
>>> >
>>> > To complete the upgrade I need to update cluster compatibility to 4.3
>>> and
>>> > then data centre to 4.3.  This is where I am stuck.
>>> >
>>> > The CPU type on cluster is "Intel SandyBridge IBRS Family".  This
>>> option is
>>> > no longer available if I select 4.3 compatibility.  Any other option
>>> chosen
>>> > such as SandyBridge IBRS SSBD will not allow me to switch to 4.3 as all
>>> > hosts must be in maintenance mode (which is not possible w/ self hosted
>>> > engine).
>>> >
>>> > I saw another post about this where someone else followed steps to
>>> create a
>>> > second cluster on 4.3 with new CPU type then move one host to it, start
>>> > engine on it then perform other steps to eventually get to 4.3
>>> > compatibility.
>>> >
>>>
>>> I have the exact same hardware configuration and was able to change to
>>> "SandyBridge IBRS SSBD" without creating a new cluster.  How I made that
>>> happen, I'm not so sure, but the cluster may have been in "Global
>>> Maintenance" mode when I changed it.
>>>
>>>
>>> ___
>>> Users mailing list -- users@ovirt.org
>>> To unsubscribe send an email to users-le...@ovirt.org
>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>>> oVirt Code of Conduct:
>>> https://www.ovirt.org/community/about/community-guidelines/
>>> List Archives:
>>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/5B3TAXKO7IBTWRVNF2K4II472TDISO6P/
>>>
>>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/CPFLAV4W4OQGDV7SUUTSHFFD6KSTHOAB/

[ovirt-users] Re: Stuck completing last step of 4.3 upgrade

This may be happening because I changed cluster compatibility to 4.3 then
immediately after changed data center compatibility to 4.3 (before
restarting VMs after cluster compatibility change).  If this is the case I
can't fix by downgrading the data center compatibility to 4.2 as it won't
allow me to do so.  What can I do to fix this, any VM I restart will break
(I am leaving the others running for now, but there are some down that I
can't start).

Full error from VDSM:

2019-02-13 13:30:55,465-0400 ERROR (vm/d070ce80) [storage.TaskManager.Task]
(Task='d5c8e50a-0a6f-4fe7-be79-fd322b273a1e') Unexpected error (task:875)
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 882,
in _run
return fn(*args, **kargs)
  File "", line 2, in prepareImage
  File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 50, in
method
ret = func(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 3198,
in prepareImage
legality = dom.produceVolume(imgUUID, volUUID).getLegality()
  File "/usr/lib/python2.7/site-packages/vdsm/storage/sd.py", line 818, in
produceVolume
volUUID)
  File "/usr/lib/python2.7/site-packages/vdsm/storage/glusterVolume.py",
line 45, in __init__
volUUID)
  File "/usr/lib/python2.7/site-packages/vdsm/storage/volume.py", line 800,
in __init__
self._manifest = self.manifestClass(repoPath, sdUUID, imgUUID, volUUID)
  File "/usr/lib/python2.7/site-packages/vdsm/storage/fileVolume.py", line
71, in __init__
volUUID)
  File "/usr/lib/python2.7/site-packages/vdsm/storage/volume.py", line 86,
in __init__
self.validate()
  File "/usr/lib/python2.7/site-packages/vdsm/storage/volume.py", line 112,
in validate
self.validateVolumePath()
  File "/usr/lib/python2.7/site-packages/vdsm/storage/fileVolume.py", line
131, in validateVolumePath
raise se.VolumeDoesNotExist(self.volUUID)
VolumeDoesNotExist: Volume does not exist:
(u'2d6d5f87-ccb0-48ce-b3ac-84495bd12d32',)
2019-02-13 13:30:55,468-0400 ERROR (vm/d070ce80) [storage.Dispatcher]
FINISH prepareImage error=Volume does not exist:
(u'2d6d5f87-ccb0-48ce-b3ac-84495bd12d32',) (dispatcher:81)
2019-02-13 13:30:55,469-0400 ERROR (vm/d070ce80) [virt.vm]
(vmId='d070ce80-e0bc-489d-8ee0-47d5926d5ae2') The vm start process failed
(vm:937)
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 866, in
_startUnderlyingVm
self._run()
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2749, in
_run
self._devices = self._make_devices()
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2589, in
_make_devices
disk_objs = self._perform_host_local_adjustment()
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2662, in
_perform_host_local_adjustment
self._preparePathsForDrives(disk_params)
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 1011, in
_preparePathsForDrives
drive['path'] = self.cif.prepareVolumePath(drive, self.id)
  File "/usr/lib/python2.7/site-packages/vdsm/clientIF.py", line 415, in
prepareVolumePath
raise vm.VolumeError(drive)
VolumeError: Bad volume specification {'address': {'function': '0x0',
'bus': '0x00', 'domain': '0x', 'type': 'pci', 'slot': '0x06'},
'serial': 'd81a6826-dc46-44db-8de7-405d30e44d57', 'index': 0, 'iface':
'virtio', 'apparentsize': '64293699584', 'specParams': {}, 'cache': 'none',
'imageID': 'd81a6826-dc46-44db-8de7-405d30e44d57', 'truesize':
'64293814272', 'type': 'disk', 'domainID':
'1f2e9989-9ab3-43d5-971d-568b8feca918', 'reqsize': '0', 'format': 'cow',
'poolID': 'a45e442e-9989-11e8-b0e4-00163e4bf18a', 'device': 'disk', 'path':
'/rhev/data-center/a45e442e-9989-11e8-b0e4-00163e4bf18a/1f2e9989-9ab3-43d5-971d-568b8feca918/images/d81a6826-dc46-44db-8de7-405d30e44d57/2d6d5f87-ccb0-48ce-b3ac-84495bd12d32',
'propagateErrors': 'off', 'name': 'vda', 'bootOrder': '1', 'volumeID':
'2d6d5f87-ccb0-48ce-b3ac-84495bd12d32', 'diskType': 'file', 'alias':
'ua-d81a6826-dc46-44db-8de7-405d30e44d57', 'discard': False}

On Wed, Feb 13, 2019 at 1:19 PM Jayme  wrote:

> I may have made matters worse.  So I changed to 4.3 compatible cluster
> then 4.3 compatible data center.  All VMs were marked as requiring a
> reboot.  I restarted a couple of them and none of them will start up, they
> are saying "bad volume specification".  The ones running that I did not yet
> restart are still running ok.  I need to figure out why the VMs aren't
> restarting.
>
> Here is an example from vdsm.log
>
> olumeError: Bad volume specification {'address': {'function': '0x0',
> 'bus': '0x00', 'domain': '0x', 'type': 'pci', 'slot': '0x06'},
> 'serial': 'd81a6826-dc46-44db-8de7-405d30e44d57', 'index': 0, 'iface':
> 'virtio', 'apparentsize': '64293699584', 'specParams': {}, 'cache': 'none',
> 'imageID': 'd81a6826-dc46-44db-8de7-405d30e44d57', 'truesize':
> '64293814272', 'type': 'disk', 'domainID':
> '1f2e9989-9ab3-43d5-971d-568b8feca918', 'r

[ovirt-users] Re: Stuck completing last step of 4.3 upgrade

I might be hitting this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1666795

On Wed, Feb 13, 2019 at 1:35 PM Jayme  wrote:

> This may be happening because I changed cluster compatibility to 4.3 then
> immediately after changed data center compatibility to 4.3 (before
> restarting VMs after cluster compatibility change).  If this is the case I
> can't fix by downgrading the data center compatibility to 4.2 as it won't
> allow me to do so.  What can I do to fix this, any VM I restart will break
> (I am leaving the others running for now, but there are some down that I
> can't start).
>
> Full error from VDSM:
>
> 2019-02-13 13:30:55,465-0400 ERROR (vm/d070ce80)
> [storage.TaskManager.Task] (Task='d5c8e50a-0a6f-4fe7-be79-fd322b273a1e')
> Unexpected error (task:875)
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 882,
> in _run
> return fn(*args, **kargs)
>   File "", line 2, in prepareImage
>   File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 50, in
> method
> ret = func(*args, **kwargs)
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 3198,
> in prepareImage
> legality = dom.produceVolume(imgUUID, volUUID).getLegality()
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/sd.py", line 818, in
> produceVolume
> volUUID)
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/glusterVolume.py",
> line 45, in __init__
> volUUID)
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/volume.py", line
> 800, in __init__
> self._manifest = self.manifestClass(repoPath, sdUUID, imgUUID, volUUID)
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/fileVolume.py", line
> 71, in __init__
> volUUID)
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/volume.py", line 86,
> in __init__
> self.validate()
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/volume.py", line
> 112, in validate
> self.validateVolumePath()
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/fileVolume.py", line
> 131, in validateVolumePath
> raise se.VolumeDoesNotExist(self.volUUID)
> VolumeDoesNotExist: Volume does not exist:
> (u'2d6d5f87-ccb0-48ce-b3ac-84495bd12d32',)
> 2019-02-13 13:30:55,468-0400 ERROR (vm/d070ce80) [storage.Dispatcher]
> FINISH prepareImage error=Volume does not exist:
> (u'2d6d5f87-ccb0-48ce-b3ac-84495bd12d32',) (dispatcher:81)
> 2019-02-13 13:30:55,469-0400 ERROR (vm/d070ce80) [virt.vm]
> (vmId='d070ce80-e0bc-489d-8ee0-47d5926d5ae2') The vm start process failed
> (vm:937)
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 866, in
> _startUnderlyingVm
> self._run()
>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2749, in
> _run
> self._devices = self._make_devices()
>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2589, in
> _make_devices
> disk_objs = self._perform_host_local_adjustment()
>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2662, in
> _perform_host_local_adjustment
> self._preparePathsForDrives(disk_params)
>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 1011, in
> _preparePathsForDrives
> drive['path'] = self.cif.prepareVolumePath(drive, self.id)
>   File "/usr/lib/python2.7/site-packages/vdsm/clientIF.py", line 415, in
> prepareVolumePath
> raise vm.VolumeError(drive)
> VolumeError: Bad volume specification {'address': {'function': '0x0',
> 'bus': '0x00', 'domain': '0x', 'type': 'pci', 'slot': '0x06'},
> 'serial': 'd81a6826-dc46-44db-8de7-405d30e44d57', 'index': 0, 'iface':
> 'virtio', 'apparentsize': '64293699584', 'specParams': {}, 'cache': 'none',
> 'imageID': 'd81a6826-dc46-44db-8de7-405d30e44d57', 'truesize':
> '64293814272', 'type': 'disk', 'domainID':
> '1f2e9989-9ab3-43d5-971d-568b8feca918', 'reqsize': '0', 'format': 'cow',
> 'poolID': 'a45e442e-9989-11e8-b0e4-00163e4bf18a', 'device': 'disk', 'path':
> '/rhev/data-center/a45e442e-9989-11e8-b0e4-00163e4bf18a/1f2e9989-9ab3-43d5-971d-568b8feca918/images/d81a6826-dc46-44db-8de7-405d30e44d57/2d6d5f87-ccb0-48ce-b3ac-84495bd12d32',
> 'propagateErrors': 'off', 'name': 'vda', 'bootOrder': '1', 'volumeID':
> '2d6d5f87-ccb0-48ce-b3ac-84495bd12d32', 'diskType': 'file', 'alias':
> 'ua-d81a6826-dc46-44db-8de7-405d30e44d57', 'discard': False}
>
> On Wed, Feb 13, 2019 at 1:19 PM Jayme  wrote:
>
>> I may have made matters worse.  So I changed to 4.3 compatible cluster
>> then 4.3 compatible data center.  All VMs were marked as requiring a
>> reboot.  I restarted a couple of them and none of them will start up, they
>> are saying "bad volume specification".  The ones running that I did not yet
>> restart are still running ok.  I need to figure out why the VMs aren't
>> restarting.
>>
>> Here is an example from vdsm.log
>>
>> olumeError: Bad volume specification {'address': {'function': '0x0',
>> 'bus': '0x00', 'domain': '0x', 'type': 'pci', 'slot': '0x0

[ovirt-users] Re: Stuck completing last step of 4.3 upgrade

> This may be happening because I changed cluster compatibility to 4.3 then
> immediately after changed data center compatibility to 4.3 (before
> restarting VMs after cluster compatibility change).  If this is the case I
> can't fix by downgrading the data center compatibility to 4.2 as it won't
> allow me to do so.  What can I do to fix this, any VM I restart will break
> (I am leaving the others running for now, but there are some down that I
> can't start).
> 
>

It would seem you ran into the "next" issue that I also ran into.  During the 
upgrade process, the ownership of the disk image of the running VM's gets 
changed from vdsm.kvm to root.root.  (see 
https://lists.ovirt.org/archives/list/users@ovirt.org/thread/6JFTGJ37KDZQ5KMLU32LNB5ZZTFQIRFG/)
 

You need to find those disk images and change the ownership back to vdsm.kvm 
then they will boot again.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/LJRGBB2MFYHRB3VCJLSZ36DMEI42IZIM/

[ovirt-users] Re: Stuck completing last step of 4.3 upgrade

2019-02-13 Thread Simone Tiraboschi

On Wed, Feb 13, 2019 at 8:06 PM Jayme  wrote:

>
> I might be hitting this bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=1666795
>

Yes, you definitively are.
Fixing files ownership on file system side is a valid workaround.


>
> On Wed, Feb 13, 2019 at 1:35 PM Jayme  wrote:
>
>> This may be happening because I changed cluster compatibility to 4.3 then
>> immediately after changed data center compatibility to 4.3 (before
>> restarting VMs after cluster compatibility change).  If this is the case I
>> can't fix by downgrading the data center compatibility to 4.2 as it won't
>> allow me to do so.  What can I do to fix this, any VM I restart will break
>> (I am leaving the others running for now, but there are some down that I
>> can't start).
>>
>> Full error from VDSM:
>>
>> 2019-02-13 13:30:55,465-0400 ERROR (vm/d070ce80)
>> [storage.TaskManager.Task] (Task='d5c8e50a-0a6f-4fe7-be79-fd322b273a1e')
>> Unexpected error (task:875)
>> Traceback (most recent call last):
>>   File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 882,
>> in _run
>> return fn(*args, **kargs)
>>   File "", line 2, in prepareImage
>>   File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 50, in
>> method
>> ret = func(*args, **kwargs)
>>   File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 3198,
>> in prepareImage
>> legality = dom.produceVolume(imgUUID, volUUID).getLegality()
>>   File "/usr/lib/python2.7/site-packages/vdsm/storage/sd.py", line 818,
>> in produceVolume
>> volUUID)
>>   File "/usr/lib/python2.7/site-packages/vdsm/storage/glusterVolume.py",
>> line 45, in __init__
>> volUUID)
>>   File "/usr/lib/python2.7/site-packages/vdsm/storage/volume.py", line
>> 800, in __init__
>> self._manifest = self.manifestClass(repoPath, sdUUID, imgUUID,
>> volUUID)
>>   File "/usr/lib/python2.7/site-packages/vdsm/storage/fileVolume.py",
>> line 71, in __init__
>> volUUID)
>>   File "/usr/lib/python2.7/site-packages/vdsm/storage/volume.py", line
>> 86, in __init__
>> self.validate()
>>   File "/usr/lib/python2.7/site-packages/vdsm/storage/volume.py", line
>> 112, in validate
>> self.validateVolumePath()
>>   File "/usr/lib/python2.7/site-packages/vdsm/storage/fileVolume.py",
>> line 131, in validateVolumePath
>> raise se.VolumeDoesNotExist(self.volUUID)
>> VolumeDoesNotExist: Volume does not exist:
>> (u'2d6d5f87-ccb0-48ce-b3ac-84495bd12d32',)
>> 2019-02-13 13:30:55,468-0400 ERROR (vm/d070ce80) [storage.Dispatcher]
>> FINISH prepareImage error=Volume does not exist:
>> (u'2d6d5f87-ccb0-48ce-b3ac-84495bd12d32',) (dispatcher:81)
>> 2019-02-13 13:30:55,469-0400 ERROR (vm/d070ce80) [virt.vm]
>> (vmId='d070ce80-e0bc-489d-8ee0-47d5926d5ae2') The vm start process failed
>> (vm:937)
>> Traceback (most recent call last):
>>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 866, in
>> _startUnderlyingVm
>> self._run()
>>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2749, in
>> _run
>> self._devices = self._make_devices()
>>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2589, in
>> _make_devices
>> disk_objs = self._perform_host_local_adjustment()
>>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2662, in
>> _perform_host_local_adjustment
>> self._preparePathsForDrives(disk_params)
>>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 1011, in
>> _preparePathsForDrives
>> drive['path'] = self.cif.prepareVolumePath(drive, self.id)
>>   File "/usr/lib/python2.7/site-packages/vdsm/clientIF.py", line 415, in
>> prepareVolumePath
>> raise vm.VolumeError(drive)
>> VolumeError: Bad volume specification {'address': {'function': '0x0',
>> 'bus': '0x00', 'domain': '0x', 'type': 'pci', 'slot': '0x06'},
>> 'serial': 'd81a6826-dc46-44db-8de7-405d30e44d57', 'index': 0, 'iface':
>> 'virtio', 'apparentsize': '64293699584', 'specParams': {}, 'cache': 'none',
>> 'imageID': 'd81a6826-dc46-44db-8de7-405d30e44d57', 'truesize':
>> '64293814272', 'type': 'disk', 'domainID':
>> '1f2e9989-9ab3-43d5-971d-568b8feca918', 'reqsize': '0', 'format': 'cow',
>> 'poolID': 'a45e442e-9989-11e8-b0e4-00163e4bf18a', 'device': 'disk', 'path':
>> '/rhev/data-center/a45e442e-9989-11e8-b0e4-00163e4bf18a/1f2e9989-9ab3-43d5-971d-568b8feca918/images/d81a6826-dc46-44db-8de7-405d30e44d57/2d6d5f87-ccb0-48ce-b3ac-84495bd12d32',
>> 'propagateErrors': 'off', 'name': 'vda', 'bootOrder': '1', 'volumeID':
>> '2d6d5f87-ccb0-48ce-b3ac-84495bd12d32', 'diskType': 'file', 'alias':
>> 'ua-d81a6826-dc46-44db-8de7-405d30e44d57', 'discard': False}
>>
>> On Wed, Feb 13, 2019 at 1:19 PM Jayme  wrote:
>>
>>> I may have made matters worse.  So I changed to 4.3 compatible cluster
>>> then 4.3 compatible data center.  All VMs were marked as requiring a
>>> reboot.  I restarted a couple of them and none of them will start up, they
>>> are saying "bad volume specification".  The ones running that I did not yet
>>> restart are sti

[ovirt-users] Re: Stuck completing last step of 4.3 upgrade

I can confirm that this worked.  I had to shut down every single VM then
change ownership to vdsm:kvm of the image file then start VM back up.

On Wed, Feb 13, 2019 at 3:08 PM Simone Tiraboschi 
wrote:

>
>
> On Wed, Feb 13, 2019 at 8:06 PM Jayme  wrote:
>
>>
>> I might be hitting this bug:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1666795
>>
>
> Yes, you definitively are.
> Fixing files ownership on file system side is a valid workaround.
>
>
>>
>> On Wed, Feb 13, 2019 at 1:35 PM Jayme  wrote:
>>
>>> This may be happening because I changed cluster compatibility to 4.3
>>> then immediately after changed data center compatibility to 4.3 (before
>>> restarting VMs after cluster compatibility change).  If this is the case I
>>> can't fix by downgrading the data center compatibility to 4.2 as it won't
>>> allow me to do so.  What can I do to fix this, any VM I restart will break
>>> (I am leaving the others running for now, but there are some down that I
>>> can't start).
>>>
>>> Full error from VDSM:
>>>
>>> 2019-02-13 13:30:55,465-0400 ERROR (vm/d070ce80)
>>> [storage.TaskManager.Task] (Task='d5c8e50a-0a6f-4fe7-be79-fd322b273a1e')
>>> Unexpected error (task:875)
>>> Traceback (most recent call last):
>>>   File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line
>>> 882, in _run
>>> return fn(*args, **kargs)
>>>   File "", line 2, in prepareImage
>>>   File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 50,
>>> in method
>>> ret = func(*args, **kwargs)
>>>   File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line
>>> 3198, in prepareImage
>>> legality = dom.produceVolume(imgUUID, volUUID).getLegality()
>>>   File "/usr/lib/python2.7/site-packages/vdsm/storage/sd.py", line 818,
>>> in produceVolume
>>> volUUID)
>>>   File "/usr/lib/python2.7/site-packages/vdsm/storage/glusterVolume.py",
>>> line 45, in __init__
>>> volUUID)
>>>   File "/usr/lib/python2.7/site-packages/vdsm/storage/volume.py", line
>>> 800, in __init__
>>> self._manifest = self.manifestClass(repoPath, sdUUID, imgUUID,
>>> volUUID)
>>>   File "/usr/lib/python2.7/site-packages/vdsm/storage/fileVolume.py",
>>> line 71, in __init__
>>> volUUID)
>>>   File "/usr/lib/python2.7/site-packages/vdsm/storage/volume.py", line
>>> 86, in __init__
>>> self.validate()
>>>   File "/usr/lib/python2.7/site-packages/vdsm/storage/volume.py", line
>>> 112, in validate
>>> self.validateVolumePath()
>>>   File "/usr/lib/python2.7/site-packages/vdsm/storage/fileVolume.py",
>>> line 131, in validateVolumePath
>>> raise se.VolumeDoesNotExist(self.volUUID)
>>> VolumeDoesNotExist: Volume does not exist:
>>> (u'2d6d5f87-ccb0-48ce-b3ac-84495bd12d32',)
>>> 2019-02-13 13:30:55,468-0400 ERROR (vm/d070ce80) [storage.Dispatcher]
>>> FINISH prepareImage error=Volume does not exist:
>>> (u'2d6d5f87-ccb0-48ce-b3ac-84495bd12d32',) (dispatcher:81)
>>> 2019-02-13 13:30:55,469-0400 ERROR (vm/d070ce80) [virt.vm]
>>> (vmId='d070ce80-e0bc-489d-8ee0-47d5926d5ae2') The vm start process failed
>>> (vm:937)
>>> Traceback (most recent call last):
>>>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 866, in
>>> _startUnderlyingVm
>>> self._run()
>>>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2749, in
>>> _run
>>> self._devices = self._make_devices()
>>>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2589, in
>>> _make_devices
>>> disk_objs = self._perform_host_local_adjustment()
>>>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2662, in
>>> _perform_host_local_adjustment
>>> self._preparePathsForDrives(disk_params)
>>>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 1011, in
>>> _preparePathsForDrives
>>> drive['path'] = self.cif.prepareVolumePath(drive, self.id)
>>>   File "/usr/lib/python2.7/site-packages/vdsm/clientIF.py", line 415, in
>>> prepareVolumePath
>>> raise vm.VolumeError(drive)
>>> VolumeError: Bad volume specification {'address': {'function': '0x0',
>>> 'bus': '0x00', 'domain': '0x', 'type': 'pci', 'slot': '0x06'},
>>> 'serial': 'd81a6826-dc46-44db-8de7-405d30e44d57', 'index': 0, 'iface':
>>> 'virtio', 'apparentsize': '64293699584', 'specParams': {}, 'cache': 'none',
>>> 'imageID': 'd81a6826-dc46-44db-8de7-405d30e44d57', 'truesize':
>>> '64293814272', 'type': 'disk', 'domainID':
>>> '1f2e9989-9ab3-43d5-971d-568b8feca918', 'reqsize': '0', 'format': 'cow',
>>> 'poolID': 'a45e442e-9989-11e8-b0e4-00163e4bf18a', 'device': 'disk', 'path':
>>> '/rhev/data-center/a45e442e-9989-11e8-b0e4-00163e4bf18a/1f2e9989-9ab3-43d5-971d-568b8feca918/images/d81a6826-dc46-44db-8de7-405d30e44d57/2d6d5f87-ccb0-48ce-b3ac-84495bd12d32',
>>> 'propagateErrors': 'off', 'name': 'vda', 'bootOrder': '1', 'volumeID':
>>> '2d6d5f87-ccb0-48ce-b3ac-84495bd12d32', 'diskType': 'file', 'alias':
>>> 'ua-d81a6826-dc46-44db-8de7-405d30e44d57', 'discard': False}
>>>
>>> On Wed, Feb 13, 2019 at 1:19 PM Jayme  wrote:
>>>
 I may hav

[ovirt-users] Re: SURVEY: your NFS configuration (Bug 1666795 - SHE doesn't start after power-off, 4.1 to 4.3 upgrade - VolumeDoesNotExist: Volume does not exist )

On Tue, Feb 12, 2019 at 5:45 PM Nir Soffer  wrote:

> Looking at
> https://bugzilla.redhat.com/1666795
>
> It seems that a change in vdsm/libvirt exposed NFS configuration issue,
> that may was
> needed in the past and probably not needed now.
>
> If you use NFS, I would like to see your /etc/exports (after sanitizing it
> if needed).
> For extra bonus, output of "exportfs -v" would be useful.
>
> In particular, I want to know if you use root_squash, all_squash, or
> no_root_squash.
>

rw,sync,no_subtree_check,all_squash,anonuid=36,anongid=36

(sync,wdelay,hide,no_subtree_check,anonuid=36,anongid=36,sec=sys,rw,secure,root_squash,all_squash)


>
> Thanks,
> Nir
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/7J3ZV25DP2X5TD6A4IV63W5PANKWERTO/
>


-- 

GREG SHEREMETA

SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX

Red Hat NA



gsher...@redhat.comIRC: gshereme

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/INUEUCAMWYIC4BWYQAQZAE37O4G4E2LK/

[ovirt-users] Re: Cluster Compatibility Version Upgrading Order

I see you are now ok on your other thread. For the background, IBRS is
deprecated in 4.3 -- that's why the change. There are some posts from last
week with the gory details.

Greg

On Wed, Feb 13, 2019 at 9:05 AM Jayme  wrote:

> I just realized that when I change compatibility level to 4.3 under edit
> cluster settings it is automatically switching CPU type from "Intel
> SandyBridge IBRS Family" to "Intel Nahalem Family".  I believe the CPU type
> change is what is requiring all hosts to be in maintenance mode.  My
> question is, is the change of the family type correct or is it a different
> family type being selected due to a bug or some other issue?
>
> On Wed, Feb 13, 2019 at 9:54 AM Jayme  wrote:
>
>> I'm also a bit unclear about updating to 4.3 cluster level.  I have a 3
>> host HCI setup which I just updated to 4.3 manually.  I upgraded engine to
>> 4.3 then upgraded each of the three hosts to ovirt node 4.3.  I still need
>> to change cluster/data centre compatibility level to 4.3.  If I try to
>> change cluster compatibility level to 4.3 it tells me that all hosts need
>> to be in maintenance to do so (does this mean I need to shut down all VMs
>> and put each host in maintenance?)
>>
>> On Wed, Feb 13, 2019 at 7:24 AM Roman Last  wrote:
>>
>>> Hello!
>>> What sequence of upgrading cluster to 4.3 version?
>>> When i click upgrade on host w or w\o host reboot it just says "Upgrade
>>> has started for" and nothing after timeout reached. When i force restart
>>> host, version 4.3 not added. Is that normal?
>>> https://prnt.sc/mki3v8
>>> ___
>>> Users mailing list -- users@ovirt.org
>>> To unsubscribe send an email to users-le...@ovirt.org
>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>>> oVirt Code of Conduct:
>>> https://www.ovirt.org/community/about/community-guidelines/
>>> List Archives:
>>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/P4A7VQIDM6GM54XGQRETANU5ACVROYYG/
>>>
>> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/E5QFFFQ7ATIPE37ZPZ4OYOEYR3N2DH2I/
>


-- 

GREG SHEREMETA

SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX

Red Hat NA



gsher...@redhat.comIRC: gshereme

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/NXJRT764BY5ZXHBBV5M5ZFR6Z4K7PFCG/

[ovirt-users] Re: Stuck completing last step of 4.3 upgrade

> I can confirm that this worked.  I had to shut down every single VM then
> change ownership to vdsm:kvm of the image file then start VM back up.
> 
Not to rain on your parade, but you should keep a close eye on your gluster 
file system after the upgrade.  The stability of my gluster file system was 
markedly decreased after the upgrade to gluster 5.3  :-(
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/3Q55MP7XZJJSE3LWBYHIHWRBPUD4BR5J/

[ovirt-users] Re: access engine by http

What are you trying to achieve? SSL is good :)

I suspect you have to disable ssl in the apache server
/etc/httpd/conf.d/ssl.conf
but I'm not really sure.

And, if you do, I suspect some things that use certificates won't work,
either (console, disk upload, etc.)

Ravi might know more.

Greg

On Wed, Feb 13, 2019 at 3:39 AM du_hon...@yeah.net 
wrote:

> I want to access engine by http， after engine-setup success， I fix
> /etc/ovirt-engine/engine.conf.d/10-setup-protocols.conf
>
> ENGINE_FQDN=localhost.localdomain
> ENGINE_PROXY_ENABLED=false
> ENGINE_PROXY_HTTP_PORT=None
> ENGINE_PROXY_HTTPS_PORT=None
> ENGINE_AJP_ENABLED=false
> ENGINE_AJP_PORT=None
> ENGINE_HTTP_ENABLED=true
> ENGINE_HTTPS_ENABLED=false
> ENGINE_HTTP_PORT=8080
> ENGINE_HTTPS_PORT=443
>
> but I access http://ip:8080/ovirt-engine ,  still browser is redirect to
> https,  I should how to disable redirect?
>
>
>
> --
>
> Regards
>
> Hongyu Du
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/5K4Z2Y5ORRCA4QLQLA5BPPJNSEP6JKNN/
>


-- 

GREG SHEREMETA

SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX

Red Hat NA



gsher...@redhat.comIRC: gshereme

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/P3AH62SCPJUEI2ZG4NKR6CUG4W5NOOAO/

[ovirt-users] Re: Stuck completing last step of 4.3 upgrade

On Wed, Feb 13, 2019 at 3:06 PM Ron Jerome  wrote:

> > I can confirm that this worked.  I had to shut down every single VM then
> > change ownership to vdsm:kvm of the image file then start VM back up.
> >
> Not to rain on your parade, but you should keep a close eye on your
> gluster file system after the upgrade.  The stability of my gluster file
> system was markedly decreased after the upgrade to gluster 5.3  :-(
>

Can you be more specific? What things did you see, and did you report bugs?
Thanks!

Best wishes,
Greg


> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/3Q55MP7XZJJSE3LWBYHIHWRBPUD4BR5J/
>


-- 

GREG SHEREMETA

SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX

Red Hat NA



gsher...@redhat.comIRC: gshereme

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/HXKYILEYKO5GHEOASO6PVEWN74ULDUSY/

[ovirt-users] understanding ovirt communication

2019-02-13 Thread hlmstu



Hallo,

I installed ovirt-engine and ovirt-node.
I try add host:new but received errormg InstallFailed.

seem connection to following ports: 49076 49080 49084...

Howto understanding ovirt communication?

keywords: engine,dwh,ovn,libvirt,virtd,node,otopi,vdsmd,sshd,node,goferd

regards Heiko

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/324LTF66XWUMEIQVXZS6KAQMTE4BDU7W/

[ovirt-users] Re: Stuck completing last step of 4.3 upgrade


> 
> Can you be more specific? What things did you see, and did you report bugs?

I've got this one: https://bugzilla.redhat.com/show_bug.cgi?id=1649054 
and this one: https://bugzilla.redhat.com/show_bug.cgi?id=1651246  
and I've got bricks randomly going offline and getting out of sync with the 
others at which point I've had to manually stop and start the volume to get 
things back in sync.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/3RVMLCRK4BWCSBTWVXU2JTIDBWU7WEOP/

[ovirt-users] Re: Stuck completing last step of 4.3 upgrade

Ron, sorry to hear about the troubles.  I haven't seen any gluster crashes
yet *knock on wood*.  I will monitor closely.  Thanks for the heads up!

On Wed, Feb 13, 2019 at 5:09 PM Ron Jerome  wrote:

>
> >
> > Can you be more specific? What things did you see, and did you report
> bugs?
>
> I've got this one: https://bugzilla.redhat.com/show_bug.cgi?id=1649054
> and this one: https://bugzilla.redhat.com/show_bug.cgi?id=1651246
> and I've got bricks randomly going offline and getting out of sync with
> the others at which point I've had to manually stop and start the volume to
> get things back in sync.
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/3RVMLCRK4BWCSBTWVXU2JTIDBWU7WEOP/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/VTOY6J4CEMQPPHCGCKKSX73QQSNGMKI5/

[ovirt-users] Ovirt Cluster completely unstable

2019-02-13 Thread dscott

I'm abandoning my production ovirt cluster due to instability.   I have a 7 
host cluster running about 300 vms and have been for over a year.  It has 
become unstable over the past three days.  I have random hosts both, compute 
and storage disconnecting.  AND many vms disconnecting and becoming unusable.

7 host are 4 compute hosts running Ovirt 4.2.8 and three glusterfs hosts 
running 3.12.5.  I submitted a bugzilla bug and they immediately assigned it to 
the storage people but have not responded with any meaningful information.  I 
have submitted several logs.  

I have found some discussion on problems with instability with gluster 3.12.5.  
I would be willing to upgrade my gluster to a more stable version if that's the 
culprit.  I installed gluster using the ovirt gui and this is the version the 
ovirt gui installed.

Is there an ovirt health monitor available?  Where should I be looking to get a 
resolution the problems I'm facing.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/BL4M3JQA3IEXCQUY4IGQXOAALRUQ7TVB/

[ovirt-users] update to 4.2.8 fails

2019-02-13 Thread Vincent Royer

trying to update from 4.2.6 to 4.2.8

yum update fails with:

--> Finished Dependency Resolution




Error: Package: vdsm-4.20.46-1.el7.x86_64 (ovirt-4.2)




   Requires: libvirt-daemon-kvm >= 4.5.0-10.el7_6.3




   Installed: libvirt-daemon-kvm-3.9.0-14.el7_5.8.x86_64
(installed)



   libvirt-daemon-kvm = 3.9.0-14.el7_5.8




Error: Package: 10:qemu-kvm-ev-2.12.0-18.el7_6.3.1.x86_64
(ovirt-4.2-centos-qemu-ev)



   Requires: libepoxy.so.0()(64bit)




Error: Package: 10:qemu-kvm-ev-2.12.0-18.el7_6.3.1.x86_64
(ovirt-4.2-centos-qemu-ev)



   Requires: libibumad.so.3()(64bit)




Error: Package: 10:qemu-kvm-ev-2.12.0-18.el7_6.3.1.x86_64
(ovirt-4.2-centos-qemu-ev)



   Requires: libgbm.so.1()(64bit)




 You could try using --skip-broken to work around the problem




 You could try running: rpm -Va --nofiles --nodigest




Uploading Enabled Repositories Report




2019-02-13 16:42:14,190 [INFO] yum:17779:Dummy-18 @connection.py:868 -
Connection built: host=subscription.rhsm.redhat.com port=443
handler=/subscription auth=identity_cert ca_dir=/etc/rhsm/ca/
insecure=False

Loaded plugins: fastestmirror, product-id, subscription-manager




2019-02-13 16:42:14,199 [WARNING] yum:17779:Dummy-18 @logutil.py:141 -
logging already initialized



2019-02-13 16:42:14,200 [ERROR] yum:17779:Dummy-18 @identity.py:145 -
Reload of consumer identity cert /etc/pki/consumer/cert.pem raised an
exception with msg: [Errno 2] No such file or directory:
'/etc/pki/consumer/key.pem'

2019-02-13 16:42:14,200 [INFO] yum:17779:Dummy-18 @connection.py:868 -
Connection built: host=subscription.rhsm.redhat.com port=443
handler=/subscription auth=identity_cert ca_dir=/etc/rhsm/ca/
insecure=False

2019-02-13 16:42:14,201 [INFO] yum:17779:Dummy-18 @repolib.py:471 - repos
updated: Repo updates








Total repo updates: 0




Updated









Added (new)









Deleted









This system is not registered with an entitlement server. You can use
subscription-manager to register.



Cannot upload enabled repos report, is this client registered?




[root@brian yum.repos.d]# yum repolist




Loaded plugins: enabled_repos_upload, fastestmirror, imgbased-persist,
package_upload, product-id, search-disabled-repos, subscription-manager,
vdsmupgrade


2019-02-13 16:42:36,489 [ERROR] yum:17809:MainThread @identity.py:145 -
Reload of consumer identity cert /etc/pki/consumer/cert.pem raised an
exception with msg: [Errno 2] No such file or directory:
'/etc/pki/consumer/key.pem'

2019-02-13 16:42:36,490 [INFO] yum:17809:MainThread @connection.py:868 -
Connection built: host=subscription.rhsm.redhat.com port=443
handler=/subscription auth=identity_cert ca_dir=/etc/rhsm/ca/
insecure=False

2019-02-13 16:42:36,491 [INFO] yum:17809:MainThread @repolib.py:471 - repos
updated: Repo updates








Total repo updates: 0




Updated









Added (new)









Deleted









This system is not registered with an entitlement server. You can use
subscription-manager to register.



Loading mirror speeds from cached hostfile




 * ovirt-4.2: mirrors.rit.edu




 * ovirt-4.2-epel: mirror.sjc02.svwh.net




repo id

repo name

  status
centos-sclo-rh-release/x86_64

CentOS-7 - SCLo rh

  8,113
ovirt-4.2/7

Latest oVirt 4.2 Release

  2,558
ovirt-4.2-centos-gluster312/x86_64

 CentOS-7 - Gluster 3.12

 262
ovirt-4.2-centos-opstools/x86_64

 CentOS-7 - OpsTools - release

 853
ovirt-4.2-centos-ovirt42/x86_64

CentOS-7 - oVirt 4.2

631
ovirt-4.2-centos-qemu-ev/x86_64

CentOS-7 - QEMU EV

 71
ovirt-4.2-epel/x86_64

Extra Packages for Enterprise Linux 7 - x86_64


*Help!*
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/TJBM3THB5ZVGYUHCAUBESAQDUKHNBNF4/

[ovirt-users] Re: update to 4.2.8 fails

2019-02-13 Thread Vincent Royer

Sorry, this is a node install w/ he.

On Wed, Feb 13, 2019, 4:44 PM Vincent Royer  trying to update from 4.2.6 to 4.2.8
>
> yum update fails with:
>
> --> Finished Dependency Resolution
>
>
>
>
> Error: Package: vdsm-4.20.46-1.el7.x86_64 (ovirt-4.2)
>
>
>
>
>Requires: libvirt-daemon-kvm >= 4.5.0-10.el7_6.3
>
>
>
>
>Installed: libvirt-daemon-kvm-3.9.0-14.el7_5.8.x86_64
> (installed)
>
>
>
>libvirt-daemon-kvm = 3.9.0-14.el7_5.8
>
>
>
>
> Error: Package: 10:qemu-kvm-ev-2.12.0-18.el7_6.3.1.x86_64
> (ovirt-4.2-centos-qemu-ev)
>
>
>
>Requires: libepoxy.so.0()(64bit)
>
>
>
>
> Error: Package: 10:qemu-kvm-ev-2.12.0-18.el7_6.3.1.x86_64
> (ovirt-4.2-centos-qemu-ev)
>
>
>
>Requires: libibumad.so.3()(64bit)
>
>
>
>
> Error: Package: 10:qemu-kvm-ev-2.12.0-18.el7_6.3.1.x86_64
> (ovirt-4.2-centos-qemu-ev)
>
>
>
>Requires: libgbm.so.1()(64bit)
>
>
>
>
>  You could try using --skip-broken to work around the problem
>
>
>
>
>  You could try running: rpm -Va --nofiles --nodigest
>
>
>
>
> Uploading Enabled Repositories Report
>
>
>
>
> 2019-02-13 16:42:14,190 [INFO] yum:17779:Dummy-18 @connection.py:868 -
> Connection built: host=subscription.rhsm.redhat.com port=443
> handler=/subscription auth=identity_cert ca_dir=/etc/rhsm/ca/
> insecure=False
>
> Loaded plugins: fastestmirror, product-id, subscription-manager
>
>
>
>
> 2019-02-13 16:42:14,199 [WARNING] yum:17779:Dummy-18 @logutil.py:141 -
> logging already initialized
>
>
>
> 2019-02-13 16:42:14,200 [ERROR] yum:17779:Dummy-18 @identity.py:145 -
> Reload of consumer identity cert /etc/pki/consumer/cert.pem raised an
> exception with msg: [Errno 2] No such file or directory:
> '/etc/pki/consumer/key.pem'
>
> 2019-02-13 16:42:14,200 [INFO] yum:17779:Dummy-18 @connection.py:868 -
> Connection built: host=subscription.rhsm.redhat.com port=443
> handler=/subscription auth=identity_cert ca_dir=/etc/rhsm/ca/
> insecure=False
>
> 2019-02-13 16:42:14,201 [INFO] yum:17779:Dummy-18 @repolib.py:471 - repos
> updated: Repo updates
>
>
>
>
>
>
>
>
> Total repo updates: 0
>
>
>
>
> Updated
>
>
>
>
> 
>
>
>
>
> Added (new)
>
>
>
>
> 
>
>
>
>
> Deleted
>
>
>
>
> 
>
>
>
>
> This system is not registered with an entitlement server. You can use
> subscription-manager to register.
>
>
>
> Cannot upload enabled repos report, is this client registered?
>
>
>
>
> [root@brian yum.repos.d]# yum repolist
>
>
>
>
> Loaded plugins: enabled_repos_upload, fastestmirror, imgbased-persist,
> package_upload, product-id, search-disabled-repos, subscription-manager,
> vdsmupgrade
>
>
> 2019-02-13 16:42:36,489 [ERROR] yum:17809:MainThread @identity.py:145 -
> Reload of consumer identity cert /etc/pki/consumer/cert.pem raised an
> exception with msg: [Errno 2] No such file or directory:
> '/etc/pki/consumer/key.pem'
>
> 2019-02-13 16:42:36,490 [INFO] yum:17809:MainThread @connection.py:868 -
> Connection built: host=subscription.rhsm.redhat.com port=443
> handler=/subscription auth=identity_cert ca_dir=/etc/rhsm/ca/
> insecure=False
>
> 2019-02-13 16:42:36,491 [INFO] yum:17809:MainThread @repolib.py:471 -
> repos updated: Repo updates
>
>
>
>
>
>
>
>
> Total repo updates: 0
>
>
>
>
> Updated
>
>
>
>
> 
>
>
>
>
> Added (new)
>
>
>
>
> 
>
>
>
>
> Deleted
>
>
>
>
> 
>
>
>
>
> This system is not registered with an entitlement server. You can use
> subscription-manager to register.
>
>
>
> Loading mirror speeds from cached hostfile
>
>
>
>
>  * ovirt-4.2: mirrors.rit.edu
>
>
>
>
>  * ovirt-4.2-epel: mirror.sjc02.svwh.net
>
>
>
>
> repo id
>
> repo name
>
>   status
> centos-sclo-rh-release/x86_64
>
> CentOS-7 - SCLo rh
>
>   8,113
> ovirt-4.2/7
>
> Latest oVirt 4.2 Release
>
>   2,558
> ovirt-4.2-centos-gluster312/x86_64
>
>  CentOS-7 - Gluster 3.12
>
>  262
> ovirt-4.2-centos-opstools/x86_64
>
>  CentOS-7 - OpsTools - release
>
>  853
> ovirt-4.2-centos-ovirt42/x86_64
>
> CentOS-7 - oVirt 4.2
>
> 631
> ovirt-4.2-centos-qemu-ev/x86_64
>
> CentOS-7 - QEMU EV
>
>  71
> ovirt-4.2-epel/x86_64
>
> Extra Packages for Enterprise Linux 7 - x86_64
>
>
> *Help!*
>
>
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/AJUBXAIGXVD5U5O2VYHO3BONVROSGWNW/

[ovirt-users] Re: Windows 2016 guest auto shutdown

2019-02-13 Thread Aminur Rahman

The VM guest has a single network port and the host has multiple ports for 
managements, ISCSI and it can’t be run everything on a single network as 20 
more guests are running on the same host.

Aminur Rahman

aminur.rah...@iongroup.com

t

+44 20 7398 0243

m

+44 7825 780697

iongroup.com



From: Hetz Ben Hamo 
Sent: 12 February 2019 14:12
To: Aminur Rahman 
Cc: users@oVirt.org
Subject: Re: [ovirt-users] Windows 2016 guest auto shutdown

Are you by any chance run everything (management, iSCSI etc) - on a single 
physical network port?


On Tue, Feb 12, 2019 at 4:10 PM 
mailto:aminur.rah...@iongroup.com>> wrote:
I am using ovirt hosted engine 4.2 to manage 5 nodes cluster and Dell 
Compellent storage domain using ISCSI. The guest is running Windows 2016 OS 
with ovirt 4.2.4 guest tools installed. The guest presented 1.4 TB thin 
provision disks and very often, the VM goes offline while doing big file 
transfer. I didn't find any event errors on OS level. I am wondering if anyone 
has experienced this issue.

Thanks
-Aminur
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to 
users-le...@ovirt.org
Privacy Statement: 
https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/BIZRKRBJXY6L2FOUH4O2WI6A337EF7Q6/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/YM2PDLEOTDTG3MPRSMQ2XHVNQT6AC67A/

[ovirt-users] Re: engine-iso-uploader taking a REALLY long time

2019-02-13 Thread zachary . winter

Any logs I should provide that would be useful?
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/KWI4ZABBEC36XEDSDYTLO6E6U52MHWYP/

[ovirt-users] Re: update to 4.2.8 fails

2019-02-13 Thread Edward Berger

If its a node-ng install, you should just update the whole image with
yum update ovirt-node-ng-image-update

On Wed, Feb 13, 2019 at 8:12 PM Vincent Royer  wrote:

> Sorry, this is a node install w/ he.
>
> On Wed, Feb 13, 2019, 4:44 PM Vincent Royer 
>> trying to update from 4.2.6 to 4.2.8
>>
>> yum update fails with:
>>
>> --> Finished Dependency Resolution
>>
>>
>>
>>
>> Error: Package: vdsm-4.20.46-1.el7.x86_64 (ovirt-4.2)
>>
>>
>>
>>
>>Requires: libvirt-daemon-kvm >= 4.5.0-10.el7_6.3
>>
>>
>>
>>
>>Installed: libvirt-daemon-kvm-3.9.0-14.el7_5.8.x86_64
>> (installed)
>>
>>
>>
>>libvirt-daemon-kvm = 3.9.0-14.el7_5.8
>>
>>
>>
>>
>> Error: Package: 10:qemu-kvm-ev-2.12.0-18.el7_6.3.1.x86_64
>> (ovirt-4.2-centos-qemu-ev)
>>
>>
>>
>>Requires: libepoxy.so.0()(64bit)
>>
>>
>>
>>
>> Error: Package: 10:qemu-kvm-ev-2.12.0-18.el7_6.3.1.x86_64
>> (ovirt-4.2-centos-qemu-ev)
>>
>>
>>
>>Requires: libibumad.so.3()(64bit)
>>
>>
>>
>>
>> Error: Package: 10:qemu-kvm-ev-2.12.0-18.el7_6.3.1.x86_64
>> (ovirt-4.2-centos-qemu-ev)
>>
>>
>>
>>Requires: libgbm.so.1()(64bit)
>>
>>
>>
>>
>>  You could try using --skip-broken to work around the problem
>>
>>
>>
>>
>>  You could try running: rpm -Va --nofiles --nodigest
>>
>>
>>
>>
>> Uploading Enabled Repositories Report
>>
>>
>>
>>
>> 2019-02-13 16:42:14,190 [INFO] yum:17779:Dummy-18 @connection.py:868 -
>> Connection built: host=subscription.rhsm.redhat.com port=443
>> handler=/subscription auth=identity_cert ca_dir=/etc/rhsm/ca/
>> insecure=False
>>
>> Loaded plugins: fastestmirror, product-id, subscription-manager
>>
>>
>>
>>
>> 2019-02-13 16:42:14,199 [WARNING] yum:17779:Dummy-18 @logutil.py:141 -
>> logging already initialized
>>
>>
>>
>> 2019-02-13 16:42:14,200 [ERROR] yum:17779:Dummy-18 @identity.py:145 -
>> Reload of consumer identity cert /etc/pki/consumer/cert.pem raised an
>> exception with msg: [Errno 2] No such file or directory:
>> '/etc/pki/consumer/key.pem'
>>
>> 2019-02-13 16:42:14,200 [INFO] yum:17779:Dummy-18 @connection.py:868 -
>> Connection built: host=subscription.rhsm.redhat.com port=443
>> handler=/subscription auth=identity_cert ca_dir=/etc/rhsm/ca/
>> insecure=False
>>
>> 2019-02-13 16:42:14,201 [INFO] yum:17779:Dummy-18 @repolib.py:471 - repos
>> updated: Repo updates
>>
>>
>>
>>
>>
>>
>>
>>
>> Total repo updates: 0
>>
>>
>>
>>
>> Updated
>>
>>
>>
>>
>> 
>>
>>
>>
>>
>> Added (new)
>>
>>
>>
>>
>> 
>>
>>
>>
>>
>> Deleted
>>
>>
>>
>>
>> 
>>
>>
>>
>>
>> This system is not registered with an entitlement server. You can use
>> subscription-manager to register.
>>
>>
>>
>> Cannot upload enabled repos report, is this client registered?
>>
>>
>>
>>
>> [root@brian yum.repos.d]# yum repolist
>>
>>
>>
>>
>> Loaded plugins: enabled_repos_upload, fastestmirror, imgbased-persist,
>> package_upload, product-id, search-disabled-repos, subscription-manager,
>> vdsmupgrade
>>
>>
>> 2019-02-13 16:42:36,489 [ERROR] yum:17809:MainThread @identity.py:145 -
>> Reload of consumer identity cert /etc/pki/consumer/cert.pem raised an
>> exception with msg: [Errno 2] No such file or directory:
>> '/etc/pki/consumer/key.pem'
>>
>> 2019-02-13 16:42:36,490 [INFO] yum:17809:MainThread @connection.py:868 -
>> Connection built: host=subscription.rhsm.redhat.com port=443
>> handler=/subscription auth=identity_cert ca_dir=/etc/rhsm/ca/
>> insecure=False
>>
>> 2019-02-13 16:42:36,491 [INFO] yum:17809:MainThread @repolib.py:471 -
>> repos updated: Repo updates
>>
>>
>>
>>
>>
>>
>>
>>
>> Total repo updates: 0
>>
>>
>>
>>
>> Updated
>>
>>
>>
>>
>> 
>>
>>
>>
>>
>> Added (new)
>>
>>
>>
>>
>> 
>>
>>
>>
>>
>> Deleted
>>
>>
>>
>>
>> 
>>
>>
>>
>>
>> This system is not registered with an entitlement server. You can use
>> subscription-manager to register.
>>
>>
>>
>> Loading mirror speeds from cached hostfile
>>
>>
>>
>>
>>  * ovirt-4.2: mirrors.rit.edu
>>
>>
>>
>>
>>  * ovirt-4.2-epel: mirror.sjc02.svwh.net
>>
>>
>>
>>
>> repo id
>>
>>   repo name
>>
>> status
>> centos-sclo-rh-release/x86_64
>>
>>   CentOS-7 - SCLo rh
>>
>> 8,113
>> ovirt-4.2/7
>>
>>   Latest oVirt 4.2 Release
>>
>> 2,558
>> ovirt-4.2-centos-gluster312/x86_64
>>
>>  CentOS-7 - Gluster 3.12
>>
>>  262
>> ovirt-4.2-centos-opstools/x86_64
>>
>>  CentOS-7 - OpsTools - release
>>
>>  853
>> ovirt-4.2-centos-ovirt42/x86_64
>>
>>   CentOS-7 - oVirt 4.2
>>
>>   631
>> ovirt-4.2-centos-qemu-ev/x86_64
>>
>>   CentOS-7 - QEMU EV
>>
>>71
>> ovirt-4.2-epel/x86_64
>>
>>   Extra Packages for Enterprise Linux 7 - x86_64
>>
>>
>> *Help!*
>>
>>
>>
>> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users

[ovirt-users] Re: update to 4.2.8 fails

2019-02-13 Thread Vincent Royer

wow am I crazy or is that not mentioned anywhere that I can find in the
docs?

some combinations of commands and reboots finally got the update to take.

Any idea about the messages about not being registered to an entitlement
server?  whats that all about??



On Wed, Feb 13, 2019 at 7:30 PM Edward Berger  wrote:

> If its a node-ng install, you should just update the whole image with
> yum update ovirt-node-ng-image-update
>
> On Wed, Feb 13, 2019 at 8:12 PM Vincent Royer 
> wrote:
>
>> Sorry, this is a node install w/ he.
>>
>> On Wed, Feb 13, 2019, 4:44 PM Vincent Royer >
>>> trying to update from 4.2.6 to 4.2.8
>>>
>>> yum update fails with:
>>>
>>> --> Finished Dependency Resolution
>>>
>>>
>>>
>>>
>>> Error: Package: vdsm-4.20.46-1.el7.x86_64 (ovirt-4.2)
>>>
>>>
>>>
>>>
>>>Requires: libvirt-daemon-kvm >= 4.5.0-10.el7_6.3
>>>
>>>
>>>
>>>
>>>Installed: libvirt-daemon-kvm-3.9.0-14.el7_5.8.x86_64
>>> (installed)
>>>
>>>
>>>
>>>libvirt-daemon-kvm = 3.9.0-14.el7_5.8
>>>
>>>
>>>
>>>
>>> Error: Package: 10:qemu-kvm-ev-2.12.0-18.el7_6.3.1.x86_64
>>> (ovirt-4.2-centos-qemu-ev)
>>>
>>>
>>>
>>>Requires: libepoxy.so.0()(64bit)
>>>
>>>
>>>
>>>
>>> Error: Package: 10:qemu-kvm-ev-2.12.0-18.el7_6.3.1.x86_64
>>> (ovirt-4.2-centos-qemu-ev)
>>>
>>>
>>>
>>>Requires: libibumad.so.3()(64bit)
>>>
>>>
>>>
>>>
>>> Error: Package: 10:qemu-kvm-ev-2.12.0-18.el7_6.3.1.x86_64
>>> (ovirt-4.2-centos-qemu-ev)
>>>
>>>
>>>
>>>Requires: libgbm.so.1()(64bit)
>>>
>>>
>>>
>>>
>>>  You could try using --skip-broken to work around the problem
>>>
>>>
>>>
>>>
>>>  You could try running: rpm -Va --nofiles --nodigest
>>>
>>>
>>>
>>>
>>> Uploading Enabled Repositories Report
>>>
>>>
>>>
>>>
>>> 2019-02-13 16:42:14,190 [INFO] yum:17779:Dummy-18 @connection.py:868 -
>>> Connection built: host=subscription.rhsm.redhat.com port=443
>>> handler=/subscription auth=identity_cert ca_dir=/etc/rhsm/ca/
>>> insecure=False
>>>
>>> Loaded plugins: fastestmirror, product-id, subscription-manager
>>>
>>>
>>>
>>>
>>> 2019-02-13 16:42:14,199 [WARNING] yum:17779:Dummy-18 @logutil.py:141 -
>>> logging already initialized
>>>
>>>
>>>
>>> 2019-02-13 16:42:14,200 [ERROR] yum:17779:Dummy-18 @identity.py:145 -
>>> Reload of consumer identity cert /etc/pki/consumer/cert.pem raised an
>>> exception with msg: [Errno 2] No such file or directory:
>>> '/etc/pki/consumer/key.pem'
>>>
>>> 2019-02-13 16:42:14,200 [INFO] yum:17779:Dummy-18 @connection.py:868 -
>>> Connection built: host=subscription.rhsm.redhat.com port=443
>>> handler=/subscription auth=identity_cert ca_dir=/etc/rhsm/ca/
>>> insecure=False
>>>
>>> 2019-02-13 16:42:14,201 [INFO] yum:17779:Dummy-18 @repolib.py:471 -
>>> repos updated: Repo updates
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Total repo updates: 0
>>>
>>>
>>>
>>>
>>> Updated
>>>
>>>
>>>
>>>
>>> 
>>>
>>>
>>>
>>>
>>> Added (new)
>>>
>>>
>>>
>>>
>>> 
>>>
>>>
>>>
>>>
>>> Deleted
>>>
>>>
>>>
>>>
>>> 
>>>
>>>
>>>
>>>
>>> This system is not registered with an entitlement server. You can use
>>> subscription-manager to register.
>>>
>>>
>>>
>>> Cannot upload enabled repos report, is this client registered?
>>>
>>>
>>>
>>>
>>> [root@brian yum.repos.d]# yum repolist
>>>
>>>
>>>
>>>
>>> Loaded plugins: enabled_repos_upload, fastestmirror, imgbased-persist,
>>> package_upload, product-id, search-disabled-repos, subscription-manager,
>>> vdsmupgrade
>>>
>>>
>>> 2019-02-13 16:42:36,489 [ERROR] yum:17809:MainThread @identity.py:145 -
>>> Reload of consumer identity cert /etc/pki/consumer/cert.pem raised an
>>> exception with msg: [Errno 2] No such file or directory:
>>> '/etc/pki/consumer/key.pem'
>>>
>>> 2019-02-13 16:42:36,490 [INFO] yum:17809:MainThread @connection.py:868 -
>>> Connection built: host=subscription.rhsm.redhat.com port=443
>>> handler=/subscription auth=identity_cert ca_dir=/etc/rhsm/ca/
>>> insecure=False
>>>
>>> 2019-02-13 16:42:36,491 [INFO] yum:17809:MainThread @repolib.py:471 -
>>> repos updated: Repo updates
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Total repo updates: 0
>>>
>>>
>>>
>>>
>>> Updated
>>>
>>>
>>>
>>>
>>> 
>>>
>>>
>>>
>>>
>>> Added (new)
>>>
>>>
>>>
>>>
>>> 
>>>
>>>
>>>
>>>
>>> Deleted
>>>
>>>
>>>
>>>
>>> 
>>>
>>>
>>>
>>>
>>> This system is not registered with an entitlement server. You can use
>>> subscription-manager to register.
>>>
>>>
>>>
>>> Loading mirror speeds from cached hostfile
>>>
>>>
>>>
>>>
>>>  * ovirt-4.2: mirrors.rit.edu
>>>
>>>
>>>
>>>
>>>  * ovirt-4.2-epel: mirror.sjc02.svwh.net
>>>
>>>
>>>
>>>
>>> repo id
>>>
>>>   repo name
>>>
>>> status
>>> centos-sclo-rh-release/x86_64
>>>
>>>   CentOS-7 - SCLo rh
>>>
>>> 8,113
>>> ovirt-4.2/7
>>>
>>>   Latest oVirt 4.2 Release
>>>
>>> 2,558
>>> ovirt-4.2-centos-gluster312/x86_64
>>>
>>>CentOS-7 - Gluster 3.12
>>>
>>>

[ovirt-users] Re: Ovirt Cluster completely unstable

2019-02-13 Thread Leo David

Hi,
I would have a look at engine.log, it might provide usefull informations.
Also, i would test i different storage type (maybe a quick nfs data domain
) and see if problem persist with that one too.


On Thu, Feb 14, 2019, 01:26  I'm abandoning my production ovirt cluster due to instability.   I have a
> 7 host cluster running about 300 vms and have been for over a year.  It has
> become unstable over the past three days.  I have random hosts both,
> compute and storage disconnecting.  AND many vms disconnecting and becoming
> unusable.
>
> 7 host are 4 compute hosts running Ovirt 4.2.8 and three glusterfs hosts
> running 3.12.5.  I submitted a bugzilla bug and they immediately assigned
> it to the storage people but have not responded with any meaningful
> information.  I have submitted several logs.
>
> I have found some discussion on problems with instability with gluster
> 3.12.5.  I would be willing to upgrade my gluster to a more stable version
> if that's the culprit.  I installed gluster using the ovirt gui and this is
> the version the ovirt gui installed.
>
> Is there an ovirt health monitor available?  Where should I be looking to
> get a resolution the problems I'm facing.
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/BL4M3JQA3IEXCQUY4IGQXOAALRUQ7TVB/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/OT2IJ7TJXFJ5BA5POEPHCDYI6LRKVGZT/

[ovirt-users] Re: access engine by http

2019-02-13 Thread du_hon...@yeah.net

hi Greg, Ravi
thanks， https is ok，when I try to visit http://ip:8080/ovirt-engine but still 
rediect https://192.168.122.176:8443/tchyp-engine/,  I want to know How to 
redirect to 8843? 
Besides I try to disable ssl by comment /etc/httpd/conf/httpd.conf   
#IncludeOptional conf.d/*.conf,
But http is still redirect to https,  I should how disable redirect?
I find  this file  
/usr/share/ovirt-engine/services/ovirt-engine/ovirt-engine.xml.in, I try to 
delete follow line. but ovirt-engine server is not boot

/var/log/ovirt-engine/boot.log has some error?
13:12:43,144 INFO  [org.jboss.as] WFLYSRV0049: WildFly Full 11.0.0.Final 
(WildFly Core 3.0.8.Final) starting
13:12:44,644 INFO  [org.jboss.as.controller.management-deprecated] WFLYCTL0028: 
Attribute 'security-realm' in the resource at address 
'/core-service=management/management-interface=native-interface' is deprecated, 
and may be removed in future version. See the attribute description in the 
output of the read-resource-description operation to learn more about the 
deprecation.
13:12:44,646 INFO  [org.jboss.as.controller.management-deprecated] WFLYCTL0028: 
Attribute 'security-realm' in the resource at address 
'/core-service=management/management-interface=http-interface' is deprecated, 
and may be removed in future version. See the attribute description in the 
output of the read-resource-description operation to learn more about the 
deprecation.
13:12:44,677 INFO  [org.jboss.as.controller.management-deprecated] WFLYCTL0028: 
Attribute 'security-realm' in the resource at address 
'/subsystem=undertow/server=default-server/https-listener=https' is deprecated, 
and may be removed in future version. See the attribute description in the 
output of the read-resource-description operation to learn more about the 
deprecation.
13:12:44,677 INFO  [org.jboss.as.controller.management-deprecated] WFLYCTL0028: 
Attribute 'enabled-protocols' in the resource at address 
'/subsystem=undertow/server=default-server/https-listener=https' is deprecated, 
and may be removed in future version. See the attribute description in the 
output of the read-resource-description operation to learn more about the 
deprecation.
13:12:44,840 INFO  [org.jboss.as.server.deployment.scanner] WFLYDS0004: Found 
restapi.war in deployment directory. To trigger deployment create a file called 
restapi.war.dodeploy
13:12:44,840 INFO  [org.jboss.as.server.deployment.scanner] WFLYDS0004: Found 
engine.ear in deployment directory. To trigger deployment create a file called 
engine.ear.dodeploy
13:12:44,840 INFO  [org.jboss.as.server.deployment.scanner] WFLYDS0004: Found 
ovirt-web-ui.war in deployment directory. To trigger deployment create a file 
called ovirt-web-ui.war.dodeploy
13:12:44,840 INFO  [org.jboss.as.server.deployment.scanner] WFLYDS0004: Found 
apidoc.war in deployment directory. To trigger deployment create a file called 
apidoc.war.dodeploy
13:12:44,895 ERROR [org.jboss.as.controller] WFLYCTL0362: Capabilities required 
by resource '/subsystem=undertow/server=default-server/http-listener=http' are 
not available:
org.wildfly.network.socket-binding.redirect; Possible registration points 
for this capability:
/socket-binding-group=*/socket-binding=*
13:12:44,900 FATAL [org.jboss.as.server] WFLYSRV0056: Server boot has failed in 
an unrecoverable manner; exiting. See previous messages for details.
13:12:44,920 INFO  [org.jboss.as] WFLYSRV0050: WildFly Full 11.0.0.Final 
(WildFly Core 3.0.8.Final) stopped in 13ms




Regards
Hongyu Du
 
From: Greg Sheremeta
Date: 2019-02-14 04:08
To: du_hon...@yeah.net; Ravi Nori
CC: users
Subject: Re: [ovirt-users] access engine by http
What are you trying to achieve? SSL is good :)

I suspect you have to disable ssl in the apache server
/etc/httpd/conf.d/ssl.conf
but I'm not really sure.

And, if you do, I suspect some things that use certificates won't work, either 
(console, disk upload, etc.)

Ravi might know more.

Greg

On Wed, Feb 13, 2019 at 3:39 AM du_hon...@yeah.net  wrote:
I want to access engine by http， after engine-setup success， I fix 
/etc/ovirt-engine/engine.conf.d/10-setup-protocols.conf

ENGINE_FQDN=localhost.localdomain
ENGINE_PROXY_ENABLED=false
ENGINE_PROXY_HTTP_PORT=None
ENGINE_PROXY_HTTPS_PORT=None
ENGINE_AJP_ENABLED=false
ENGINE_AJP_PORT=None
ENGINE_HTTP_ENABLED=true
ENGINE_HTTPS_ENABLED=false
ENGINE_HTTP_PORT=8080
ENGINE_HTTPS_PORT=443

but I access http://ip:8080/ovirt-engine ,  still browser is redirect to https, 
 I should how to disable redirect?





Regards
Hongyu Du
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/5K4Z2Y5ORRCA4QLQLA5BPPJNSEP6JKNN/


-- 
GREG SHEREMETA
SENIOR SOFT

[ovirt-users] Re: Engine installation failed at - get local vm ip

2019-02-13 Thread Tailor, Bharat

Hi,

I am still facing this issue. Any help would be appreciated.

Regrards
Bharat Kumar

G15- Vinayak Nagar complex,Opp.Maa Satiya, ayad
Udaipur (Raj.)
313001
Mob: +91-9950-9960-25






On Sun, Feb 10, 2019 at 9:36 PM Tailor, Bharat <
bha...@synergysystemsindia.com> wrote:

> Hi,
>
> Please find logs.
>
> Regrards
> Bharat Kumar
>
> G15- Vinayak Nagar complex,Opp.Maa Satiya, ayad
> Udaipur (Raj.)
> 313001
> Mob: +91-9950-9960-25
>
>
>
>
>
>
> On Sun, Feb 10, 2019 at 1:40 AM Simone Tiraboschi 
> wrote:
>
>>
>>
>> On Sat, Feb 9, 2019 at 9:40 AM Tailor, Bharat <
>> bha...@synergysystemsindia.com> wrote:
>>
>>> Hi Simone,
>>>
>>> Any suggestions to troubleshoot this issue. I've gone through many
>>> community threads but didn't get relevant answer.
>>>
>>
>> Can you please share the whole /var/log/ovirt-hosted-engine-setup ?
>> otherwise it's really difficult guessing what happened.
>>
>>
>>>
>>> On Sat, Feb 9, 2019, 12:55 AM Tailor, Bharat <
>>> bha...@synergysystemsindia.com wrote:
>>>
 Hi,

 I am trying to configure with static ip address.
 I don't have any dns server so using dns entry in /etc/hosts file.
 Didn't try to set anything about mac address. going with system
 generated settings only.

 Regrards
 Bharat Kumar

 G15- Vinayak Nagar complex,Opp.Maa Satiya, ayad
 Udaipur (Raj.)
 313001
 Mob: +91-9950-9960-25






 On Sat, Feb 9, 2019 at 12:40 AM Simone Tiraboschi 
 wrote:

>
>
> On Fri, Feb 8, 2019 at 7:49 PM Tailor, Bharat <
> bha...@synergysystemsindia.com> wrote:
>
>> Hi,
>>
>> I am trying to test ovirt hyperconverged setup. I've a dell server &
>> using vmware ESXi 6.7 as hypervisor. Prepared 3 VMs with cpu hw exposed.
>>
>> VM1 - Ovirt node 4.2
>> 18GB RAM
>> 2*2 vcpu
>> nic 1 - for backend gluster
>> nic 2 - for frontend vm network
>>
>> VM2 - Ovirt node 4.2
>> 18GB RAM
>> 2*2 vcpu
>> nic 1 - for backend gluster
>> nic 2 - for frontend vm network
>>
>> VM3- Ovirt node 4.2
>> 18GB RAM
>> 2*2 vcpu
>> nic 1 - for backend gluster
>> nic 2 - for frontend vm network
>>
>> I've configured gluster storage from cockpit and now trying to
>> install engine from same cockpit but setup failed at "get local vm ip".
>> I've gone through /var/log/ovirt-hosted-engine-setup file also but
>> there are so many log files and I haven't find any related logs. Please
>> help me to get out of it.
>>
>
> Did you choose to configure the engine VM with a static address or
> with DHCP? if so, do you have a proper address reservation for that mac
> address?
> Is the DNS correctly working?
>
>
>
>>
>>
>>
>> Regrards
>> Bharat Kumar
>>
>> G15- Vinayak Nagar complex,Opp.Maa Satiya, ayad
>> Udaipur (Raj.)
>> 313001
>> Mob: +91-9950-9960-25
>>
>>
>>
>>
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/Q3K34XKKGCIVNDFONFE4BCZUTLR32P7C/
>>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/V3T6VSEOTOAOXZ7PIVXNLLONIBI4HIAA/

[ovirt-users] Re: Ovirt Cluster completely unstable

I have a three node HCI gluster which was previously running 4.2 with zero
problems.  I just upgraded it yesterday.  I ran in to a few bugs right away
with the upgrade process, but aside from that I also discovered other users
with severe GlusterFS problems since the upgrade to new GlusterFS version.
It is less than 24 hours since I upgrade my cluster and I just got a notice
that one of my GlusterFS bricks is offline.  There does appear to be a very
real and serious issue here with the latest updates.


On Wed, Feb 13, 2019 at 7:26 PM  wrote:

> I'm abandoning my production ovirt cluster due to instability.   I have a
> 7 host cluster running about 300 vms and have been for over a year.  It has
> become unstable over the past three days.  I have random hosts both,
> compute and storage disconnecting.  AND many vms disconnecting and becoming
> unusable.
>
> 7 host are 4 compute hosts running Ovirt 4.2.8 and three glusterfs hosts
> running 3.12.5.  I submitted a bugzilla bug and they immediately assigned
> it to the storage people but have not responded with any meaningful
> information.  I have submitted several logs.
>
> I have found some discussion on problems with instability with gluster
> 3.12.5.  I would be willing to upgrade my gluster to a more stable version
> if that's the culprit.  I installed gluster using the ovirt gui and this is
> the version the ovirt gui installed.
>
> Is there an ovirt health monitor available?  Where should I be looking to
> get a resolution the problems I'm facing.
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/BL4M3JQA3IEXCQUY4IGQXOAALRUQ7TVB/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/QULCBXHTKSCPKH4UV6GLMOLJE6J7M5UW/

[ovirt-users] Re: Stuck completing last step of 4.3 upgrade