[ovirt-users] (no subject)

2016-08-22 Thread Matt . 
I have one host which has been newly deployed having issues with:

[root@host-01 ~]# tail -f /var/log/ovirt-hosted-engine-ha/agent.log
MainThread::INFO::2016-08-23
02:39:16,799::hosted_engine::860::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_get_domain_monitor_status)
VDSM domain monitor status: PENDING
MainThread::INFO::2016-08-23
02:39:21,834::hosted_engine::860::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_get_domain_monitor_status)
VDSM domain monitor status: PENDING
MainThread::INFO::2016-08-23
02:39:26,894::hosted_engine::860::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_get_domain_monitor_status)
VDSM domain monitor status: PENDING
MainThread::INFO::2016-08-23
02:39:31,931::hosted_engine::860::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_get_domain_monitor_status)
VDSM domain monitor status: PENDING


Now I tried to cleant he metadata, force it, whatever I tried, I get this:


[root@host-01 ~]# hosted-engine --clean-metadata --force-cleanup
/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/vds_client.py:25:
DeprecationWarning: vdscli uses xmlrpc. since ovirt 3.6 xmlrpc is
deprecated, please use vdsm.jsonrpcvdscli
  from vdsm import vdscli
INFO:ovirt_hosted_engine_ha.agent.agent.Agent:ovirt-hosted-engine-ha
agent 2.0.2 started
INFO:ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine:Found
certificate common name: host-01.my.domain
INFO:ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine:Initializing VDSM
/usr/lib/python2.7/site-packages/yajsonrpc/stomp.py:352:
DeprecationWarning: Dispatcher.pending is deprecated. Use
Dispatcher.socket.pending instead.
  pending = getattr(dispatcher, 'pending', lambda: 0)
/usr/lib/python2.7/site-packages/yajsonrpc/stomp.py:352:
DeprecationWarning: Dispatcher.pending is deprecated. Use
Dispatcher.socket.pending instead.
  pending = getattr(dispatcher, 'pending', lambda: 0)
INFO:ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine:Connecting
the storage
INFO:ovirt_hosted_engine_ha.lib.storage_server.StorageServer:Connecting
storage server
/usr/lib/python2.7/site-packages/yajsonrpc/stomp.py:352:
DeprecationWarning: Dispatcher.pending is deprecated. Use
Dispatcher.socket.pending instead.
  pending = getattr(dispatcher, 'pending', lambda: 0)
/usr/lib/python2.7/site-packages/yajsonrpc/stomp.py:352:
DeprecationWarning: Dispatcher.pending is deprecated. Use
Dispatcher.socket.pending instead.
  pending = getattr(dispatcher, 'pending', lambda: 0)
/usr/lib/python2.7/site-packages/yajsonrpc/stomp.py:352:
DeprecationWarning: Dispatcher.pending is deprecated. Use
Dispatcher.socket.pending instead.
  pending = getattr(dispatcher, 'pending', lambda: 0)
/usr/lib/python2.7/site-packages/yajsonrpc/stomp.py:352:
DeprecationWarning: Dispatcher.pending is deprecated. Use
Dispatcher.socket.pending instead.
  pending = getattr(dispatcher, 'pending', lambda: 0)
/usr/lib/python2.7/site-packages/yajsonrpc/stomp.py:352:
DeprecationWarning: Dispatcher.pending is deprecated. Use
Dispatcher.socket.pending instead.
  pending = getattr(dispatcher, 'pending', lambda: 0)
/usr/lib/python2.7/site-packages/yajsonrpc/stomp.py:352:
DeprecationWarning: Dispatcher.pending is deprecated. Use
Dispatcher.socket.pending instead.
  pending = getattr(dispatcher, 'pending', lambda: 0)
/usr/lib/python2.7/site-packages/yajsonrpc/stomp.py:352:
DeprecationWarning: Dispatcher.pending is deprecated. Use
Dispatcher.socket.pending instead.
  pending = getattr(dispatcher, 'pending', lambda: 0)
INFO:ovirt_hosted_engine_ha.lib.storage_server.StorageServer:Connecting
storage server
/usr/lib/python2.7/site-packages/yajsonrpc/stomp.py:352:
DeprecationWarning: Dispatcher.pending is deprecated. Use
Dispatcher.socket.pending instead.
  pending = getattr(dispatcher, 'pending', lambda: 0)
INFO:ovirt_hosted_engine_ha.lib.storage_server.StorageServer:Refreshing
the storage domain
/usr/lib/python2.7/site-packages/yajsonrpc/stomp.py:352:
DeprecationWarning: Dispatcher.pending is deprecated. Use
Dispatcher.socket.pending instead.
  pending = getattr(dispatcher, 'pending', lambda: 0)
INFO:ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine:Preparing images
INFO:ovirt_hosted_engine_ha.lib.image.Image:Preparing images
/usr/lib/python2.7/site-packages/yajsonrpc/stomp.py:352:
DeprecationWarning: Dispatcher.pending is deprecated. Use
Dispatcher.socket.pending instead.
  pending = getattr(dispatcher, 'pending', lambda: 0)
/usr/lib/python2.7/site-packages/yajsonrpc/stomp.py:352:
DeprecationWarning: Dispatcher.pending is deprecated. Use
Dispatcher.socket.pending instead.
  pending = getattr(dispatcher, 'pending', lambda: 0)
/usr/lib/python2.7/site-packages/yajsonrpc/stomp.py:352:
DeprecationWarning: Dispatcher.pending is deprecated. Use
Dispatcher.socket.pending instead.
  pending = getattr(dispatcher, 'pending', lambda: 0)
/usr/lib/python2.7/site-packages/yajsonrpc/stomp.py:352:
DeprecationWarning: Dispatcher.pending is deprecated. Use
Dispatcher.socket.pending

Re: [ovirt-users] Migrate machines in unknown state?

2016-08-22 Thread Ekin Meroğlu 
Hi Yaniv,

On Sun, Aug 7, 2016 at 9:37 PM, Ekin Meroğlu 
> wrote:
>
>> Hi,
>>
>> Just a reminder, if you have power management configured, first turn that
>> off for the host - when you restart vdsmd with the power management
>> configured, engine finds it not responding and tries to fence (e.g. reboot)
>> the host.
>>
>
> That's not true - if it's a graceful restart, it should not happen.
>

​Can you explain this a little more? Is there a mechanism to prevent
fencing on this scenario?

In two of our customers' production systems we've experienced this exact
behavior (i.e. engine fencing the host while restarting vdsm service
manually) for a number of times, and we were specifically advised by Red
Hat Support to turn off PM before restarting service. I'd like to to know
if we have a better / easier way to restart vdsm. ​

​btw, ​b
oth of the environments were RHE​V-H based RHEV 3.5 clusters, and both we
were busy systems, so restarting vdsm service took quite a long time. I'm
guessing this might be a factor.

Regards,
​

>
>

>
>>
>> Other than that, restarting vdsmd has been safe in my experience...
>>
>> Regards,
>>
>> On Thu, Aug 4, 2016 at 6:10 PM, Nicolás  wrote:
>>
>>>
>>>
>>> El 04/08/16 a las 15:25, Arik Hadas escribió:
>>>

 - Original Message -

> El 2016-08-04 08:24, Arik Hadas escribió:
>
>> - Original Message -
>>
>>>
>>> El 04/08/16 a las 07:18, Arik Hadas escribió:
>>>
 - Original Message -

> Hi,
>
> We're running oVirt 4.0.1 and today I found out that one of our
> hosts
> has all its VMs in an unknown state. I actually don't know how (and
> when) did this happen, but I'd like to restore service possibly
> without
> turning off these machines. The host is up, the VMs are up, 'qemu'
> process exists, no errors, it's just the VMs running on it that
> have a
> '?' where status is defined.
>
> Is it safe in this case to simply modify database and set those
> VM's
> status to 'up'? I remember having to do this a time ago when we
> faced
> storage issues, it didn't break anything back then. If not, is
> there a
> "safe" way to migrate those VMs to a different host and restart the
> host
> that marked them as unknown?
>
 Hi Nicolás,

 I assume that the host these VMs are running on is empty in the
 webadmin,
 right? if that is the case then you've probably hit [1]. Changing
 their
 status to up is not the way to go since these VMs will not be
 monitored.

>>> Hi Arik,
>>>
>>> By "empty" you mean the webadmin reports the host being running 0
>>> VMs?
>>> If so, that's not the case, actually the VM count seems to be correct
>>> in
>>> relation to "qemu-*" processes (about 32 VMs), I can even see the
>>> machines in the "Virtual machines" tab of the host, it's just they
>>> are
>>> all marked with the '?' mark.
>>>
>> No, I meant the 'Host' column in the Virtual Machines tab but if you
>> see
>> the VMs in the "Virtual machines" sub-tab of the host then run_on_vds
>> points to the right host..
>>
>> The host is up in the webadmin as well?
>> Can you share the engine log?
>>
>> Yes, the host is up in the webadmin, there are no issues with it, just
> the VMs running on it have the '?' mark. I've made 3 tests:
>
> 1) Restart engine: did not help
> 2) Check firewall, seems to be ok.
> 2) PostgreSQL: UPDATE vm_dynamic SET status = 1 WHERE status = 8; :
> After a while, I see lots of entries like this:
>
>   2016-08-04 09:23:10,910 WARN
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (DefaultQuartzScheduler4) [6ad135b8] Correlation ID: null, Call Stack:
> null, Custom Event ID: -1, Message: VM xxx is not responding.
>
> I'm attaching the engine log, but I don't know when did this happen for
> the first time, though. If there's a manual way/command to migrate VMs
> to a different host I'd appreciate a hint about it.
>
> Is it safe to restart vdsmd on this host?
>
 The engine log looks fine - the VMs are reported as not-responding for
 some reason. I would restart libvirtd and vdsmd then

>>>
>>> Is restarting those two daemons safe? I mean, will that stop all qemu-*
>>> processes, so the VMs marked as unknown will stop?
>>>
>>>
>>> Thanks.
>
> Thanks.
>>>
>>> Yes, there is no other way to resolve it other than changing the DB
 but
 the change should be to update run_on_vds field of these VMs to the
 host
 you know they are running on. Their status will then be updates in
 15
 sec.

Re: [ovirt-users] Storage VLAN Issue

2016-08-22 Thread Kendal Montgomery 
I will re-test this and send the results in a few days.  I have some things 
running currently on that cluster I don’t want to disturb, but I have some new 
hardware to install and I’ll test it and gather information then.

Kendal Montgomery
Lab Manager
O: 614.407.5584 | M: 614.571.0172
kmontgom...@cbuscollaboratory.com 

Empowering collective insights.

> On Aug 21, 2016, at 2:59 AM, Edward Haas  wrote:
> 
> network is set as a VLAN network in Engine? ( a screenshot of your network 
> configuration on Engine



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] [ANN] oVirt 4.0.2 Post Release update is now available

2016-08-22 Thread Sandro Bonazzola 
The oVirt Project is pleased to announce the availability of an oVirt 4.0.2
post release update, as of August 22nd, 2016.

This update includes new builds of oVirt Engine SDKs which fixes password
leaking into HTTPD logs when obtaining SSO token.

See the release notes [1] for installation / upgrade instructions and a
list of new features and bugs fixed.

Notes:
* Mirrors might need up to one day to synchronize.

Additional Resources:
* Read more about the oVirt 4.0.2 release highlights:
http://www.ovirt.org/release/4.0.2/
* Get more oVirt Project updates on Twitter: https://twitter.com/ovirt
* Check out the latest project news on the oVirt blog:
http://www.ovirt.org/blog/

[1] http://www.ovirt.org/release/4.0.2/


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] HostedEngine with HA

2016-08-22 Thread Carlos Rodrigues 
On Fri, 2016-08-19 at 11:50 +0100, Carlos Rodrigues wrote:
> On Fri, 2016-08-19 at 12:24 +0200, Simone Tiraboschi wrote:
> > 
> > On Fri, Aug 19, 2016 at 12:07 PM, Carlos Rodrigues  > m>
> > wrote:
> > > 
> > > 
> > > On Fri, 2016-08-19 at 10:47 +0100, Carlos Rodrigues wrote:
> > > > 
> > > > 
> > > > On Fri, 2016-08-19 at 11:36 +0200, Simone Tiraboschi wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > On Fri, Aug 19, 2016 at 11:29 AM, Carlos Rodrigues  > > > > tu
> > > > > x.co
> > > > > m>
> > > > > wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > After night, the OVF_STORE it was created:
> > > > > > 
> > > > > 
> > > > > It's quite strange that it got so long but now it looks fine.
> > > > > 
> > > > > If the ISO_DOMAIN that I see in your screenshot is served by
> > > > > the
> > > > > engine VM itself, I suggest to remove it and export from an
> > > > > external
> > > > > server.
> > > > > Serving the ISO storage domain from the engine VM itself is
> > > > > not
> > > > > a
> > > > > good idea since when the engine VM is down you can experiment
> > > > > long
> > > > > delays before getting the engine VM restarted due to the
> > > > > unavailable
> > > > > storage domain.
> > > > 
> > > > Ok, thank you for advice.
> > > > 
> > > > Now, apparently is all ok. I'll do more tests with HA and any
> > > > issue
> > > > i'll tell you.
> > > > 
> > > > Thank you for your support.
> > > > 
> > > > Regards,
> > > > Carlos Rodrigues
> > > > 
> > > 
> > > I shutdown the network of host with engine VM and i expected that
> > > other
> > > host fence the host and start engine VM but i don't see any fence
> > > action and the "free" host keep trying to start VM but get and
> > > error of
> > > sanlock
> > > 
> > > Aug 19 11:03:03 ied-blade11.install.eurotux.local kernel: qemu-
> > > kvm:
> > > sending ioctl 5326 to a partition!
> > > Aug 19 11:03:03 ied-blade11.install.eurotux.local kernel: qemu-
> > > kvm:
> > > sending ioctl 80200204 to a partition!
> > > Aug 19 11:03:03 ied-blade11.install.eurotux.local kvm[7867]: 1
> > > guest
> > > now active
> > > Aug 19 11:03:03 ied-blade11.install.eurotux.local sanlock[884]:
> > > 2016-
> > > 08-19 11:03:03+0100 1023 [903]: r3 paxos_acquire owner 1 delta 1
> > > 9
> > > 245502 alive
> > > Aug 19 11:03:03 ied-blade11.install.eurotux.local sanlock[884]:
> > > 2016-
> > > 08-19 11:03:03+0100 1023 [903]: r3 acquire_token held error -243
> > > Aug 19 11:03:03 ied-blade11.install.eurotux.local sanlock[884]:
> > > 2016-
> > > 08-19 11:03:03+0100 1023 [903]: r3 cmd_acquire 2,9,7862
> > > acquire_token
> > > -243 lease owned by other host
> > > Aug 19 11:03:03 ied-blade11.install.eurotux.local libvirtd[1369]:
> > > resource busy: Failed to acquire lock: error -243
> > > Aug 19 11:03:03 ied-blade11.install.eurotux.local kernel:
> > > ovirtmgmt:
> > > port 2(vnet0) entered disabled state
> > > Aug 19 11:03:03 ied-blade11.install.eurotux.local kernel: device
> > > vnet0
> > > left promiscuous mode
> > > Aug 19 11:03:03 ied-blade11.install.eurotux.local kernel:
> > > ovirtmgmt:
> > > port 2(vnet0) entered disabled state
> > > Aug 19 11:03:03 ied-blade11.install.eurotux.local kvm[7885]: 0
> > > guests
> > > now active
> > > Aug 19 11:03:03 ied-blade11.install.eurotux.local systemd-
> > > machined[7863]: Machine qemu-4-HostedEngine terminated.
> > 
> > Maybe you hit this one:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1322849
> > 
> > 
> > Can you please check it as described in comment 28 and eventually
> > apply the workaround in comment 18?
> > 
> 
> Apparently the host-id its ok. I don't need to apply the workaround.
> 

Any other suggestion? 
I check that second host doens't fence the failed host and maybe this
cause the lock of hosted storage domain.

After recover network, engine VM check hosts and send fence commands to
the hosts. In some cases, it sends fence commands to both hosts.

Regards,
Carlos Rodrigues


> 
> > 
> > 
> > 
> > > 
> > > 
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > Regards,
> > > > > > Carlos Rodrigues
> > > > > > 
> > > > > > On Fri, 2016-08-19 at 08:29 +0200, Simone Tiraboschi wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On Thu, Aug 18, 2016 at 6:38 PM, Carlos Rodrigues  > > > > > > ur
> > > > > > > otux
> > > > > > > .c
> > > > > > > om> wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On Thu, 2016-08-18 at 17:45 +0200, Simone Tiraboschi
> > > > > > > > wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On Thu, Aug 18, 2016 at 5:43 PM, Carlos Rodrigues
> > > > > > > > >  > > > > > > > > @eur
> > > > > > > > > ot
> > > > > > > > > ux.com> wrote:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > I increase hosted_engine disk space to 160G. How do
> > > > > > > > > > i
> > > > > > > > > > force

Re: [ovirt-users] Hosted Engine 3.6 Questions

2016-08-22 Thread Simone Tiraboschi 
On Thu, Aug 18, 2016 at 6:38 PM, C Williams  wrote:
> Hello,
>
> We have an installation with 2 filers on CentOS 7.2 with the hosted engine
> appliance. We use iscsi for our backend storage.
>
> We have some issues
>
> We had to dedicate an entire dedicated storage domain for the sole use of
> the Hosted Engine appliance. Is this required ?

Yes, it is.

> Or can the Hosted Engine
> appliance co-exist on another storage domain with VMs ?  I have not been
> able to migrate the Hosted Engine VM to other storage. Because of this
> limitation and to be efficient with our storage use, we asked our storage
> admin to make a small iscsi LUN 20GB for the storage domain for the
> appliance. However, we are constantly getting errors regarding low disk
> space for this domain even though it has only the 10GB appliance.

A storage domain on block devices requires 5 or 6 GB of ancillary data
due to extents size and, if I'm not wrong, there is a low disk space
threshold at about 4 GB; using slightly larger LUN will help.

> Could this size problem be related to my problems with importing VMWare VMs
> into our larger (Multi TB) storage using the Import tool in 3.6.
>
> Thank You
>
>
>
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Dedicated NICs for gluster network

2016-08-22 Thread Nicolas Ecarnot 

Le 22/08/2016 à 08:10, Ramesh Nachimuthu a écrit :



Now, I can smoothly configure their NICs.

Doing all this, I saw that oVirt detected there already was
existing gluster cluster and volume, and integrated it in oVirt.

Then, I was able to create a new storage domain in this new DC
and cluster, using one of the *gluster* FQDN's host. It went nicely.

BUT, when viewing the volume tab and brick details, the displayed
brick names are the host DNS name, and NOT the host GLUSTER DNS
names.

I'm worrying about this, confirmed by what I read in the logs :

2016-08-19 14:46:30,484 WARN 
[org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturnForXmlRpc]

(DefaultQuartzScheduler_Worker-100) [107dc2e3] Could not
associate brick
'serv-vm-al04-data.sdis.isere.fr:/gluster/data/brick04
' of volume '35026521-e76e-4774-8ddf-0a701b9eb40c' with correct
network as no gluster network found in cluster
'1c8e75a0-af3f-4e97-a8fb-2f7ef3ed9f30'
2016-08-19 14:46:30,492 WARN 
[org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturnForXmlRpc]

(DefaultQuartzScheduler_Worker-100) [107dc2e3] Could not
associate brick
'serv-vm-al05-data.sdis.isere.fr:/gluster/data/brick04
' of volume '35026521-e76e-4774-8ddf-0a701b9eb40c' with correct
network as no gluster network found in cluster
'1c8e75a0-af3f-4e97-a8fb-2f7ef3ed9f30'
2016-08-19 14:46:30,500 WARN 
[org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturnForXmlRpc]

(DefaultQuartzScheduler_Worker-100) [107dc2e3] Could not
associate brick
'serv-vm-al06-data.sdis.isere.fr:/gluster/data/brick04
' of volume '35026521-e76e-4774-8ddf-0a701b9eb40c' with correct
network as no gluster network found in cluster
'1c8e75a0-af3f-4e97-a8fb-2f7ef3ed9f30'

[oVirt shell (connected)]# list clusters

id : 0001-0001-0001-0001-0045
name   : cluster51
description: Cluster d'alerte de test

id : 1c8e75a0-af3f-4e97-a8fb-2f7ef3ed9f30
name   : cluster52
description: Cluster d'alerte de test

[oVirt shell (connected)]#

"cluster52" is the recent cluster, and I do have a dedicated
gluster network, marked as gluster network, in the correct DC and
cluster.
The only point is that :
- Each host has its name ("serv-vm-al04") and a second name for
gluster ("serv-vm-al04-data").
- Using blahblahblah-data is correct on a gluster point of view
- Maybe oVirt is disturb not to be able to ping the gluster FQDN
(not routed) and then throwing this error?


We do have a limitation currently that if you use multiple FQDNs, 
oVirt cannot associate it to the gluster brick correctly. This will 
be a problem only when you try brick management from oVirt - i.e try 
to remove or replace brick from oVirt. For monitoring brick status 
and detecting bricks - this is not an issue, and you can ignore the 
error in logs.


Hi Sahina and Ramesh,

what you wrote looks a lot the same at what I witnessed ("oVirt cannot 
associate it to the gluster brick correctly") : oVirt is trying to 
associate, and succeed, but using the host FQDN, and not the host 
gluster FQDN.
That leads to a situation where oVirt is seeing the volume correctly 
(name, number of bricks), but :

- I can not add nor manage the bricks, as you wrote it
- the size is not reported
- the bricks fqdn are not correct, as we just wrote it.

At present, this is not very disturbing, but one major issue I witnessed 
twice was that :
I tried to roughly reboot a host, which at this time was only used as a 
gluster node, and was not running any VM.
I saw my complete oVirt DC crash in flames, maybe because of a STONITH 
storm (some host were power managed the hard way).
I still have to reproduce this issue and provide you the log files, but 
before going further, please tell me if it's worth it on this 3.6.7 
setup, or must I first upgrade to 4.xx ?




Adding Ramesh who has a patch to fix this .


Patch https://gerrit.ovirt.org/#/c/60083/ is posted to address this 
issue. But it will work only if the oVirt Engine can resolve FQDN 
*'serv-vm-al04-data.xx*'* to an IP address which is mapped to the 
gluster NIC (NIC with gluster network) on the host.

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

Re: [ovirt-users] oVirt 4 + Foreman

2016-08-22 Thread Oved Ourfali 
Can you please attach the complete logs of ovirt and foreman?


On Wed, Aug 17, 2016 at 10:25 AM, Martin Perina  wrote:

> Adding Yaniv ...
>
> On Wed, Aug 17, 2016 at 9:16 AM, Arsène Gschwind <
> arsene.gschw...@unibas.ch> wrote:
>
>> Hi,
>>
>> Thanks a lot this did work on the Foreman side using https://
>> /ovirt-engine/api/v3 .
>>
>> But on the oVirt Side, to define Foreman as an external provider, it
>> still doesn't work, is there also a special URL to enter? I didn't find
>> anything in the docs.
>>
>> Thanks for any hint.
>>
>> Regards,
>> Arsène
>>
>>
>> On 08/16/2016 05:01 PM, Juan Hernández wrote:
>>
>>> On 08/16/2016 11:58 AM, Arsène Gschwind wrote:
>>>
 Hi,

 has anybody been able to configure Foreman with oVirt 4 ? When trying to
 add Foreman as an external provider and test the login it always return
 : Failed to communicate with the external provider, see log for
 additional details.

 On the Foreman side i get an SSO failed in the log, the user and
 password entered are correct.

 Running version:

 oVirt Engine Version: 4.0.2.6-1.el7.centos
 Foreman Version 1.12.1

 Please find the log extract attached.
 Thanks for any help/hint.

 Regards,
 Arsène

 There are two important differences in version 4 of oVirt
>>>
>>> 1. The URL is now only /ovirt-engine/api (it used to accept /api and
>>> /ovirt-engine/api).
>>>
>>> 2. There are two versions of the API now, v3, compatible with oVirt 3,
>>> and v4, new and incompatible. Foreman only supports v3.
>>>
>>> So, I'd suggest you try to use "https://.../ovirt-engine/api/v3; in the
>>> URL. Does that work? If it doesn't, can you provide more details? Log
>>> files?
>>>
>>>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Dedicated NICs for gluster network

2016-08-22 Thread Ramesh Nachimuthu 



On 08/22/2016 11:24 AM, Sahina Bose wrote:



On Fri, Aug 19, 2016 at 6:20 PM, Nicolas Ecarnot > wrote:


Le 19/08/2016 à 13:43, Sahina Bose a écrit :



Or are you adding the 3 nodes to your existing cluster? If
so, I suggest you try adding this to a new cluster

OK, I tried and succeed to create a new cluster.
In this new cluster, I was ABLE to add the first new host,
using its mgmt DNS name.
This first host still has to have its NICs configured, and
(using Chrome or FF) the access to the network settings
window is stalling the browser (I tried to restart even the
engine, to no avail). Thus, I can not setup this first node NICs.

Thus, I can not add any further host because oVirt relies on
a first host to validate the further ones.



Network team should be able to help you here.



OK, there were no mean I could continue this way (browser crash),
so I tried and succeed doing so :
- remove the newly created host and cluster
- create a new DATACENTER
- create a new cluster in this DC
- add the first new host : OK
- add the 2 other new hosts : OK

Now, I can smoothly configure their NICs.

Doing all this, I saw that oVirt detected there already was
existing gluster cluster and volume, and integrated it in oVirt.

Then, I was able to create a new storage domain in this new DC and
cluster, using one of the *gluster* FQDN's host. It went nicely.

BUT, when viewing the volume tab and brick details, the displayed
brick names are the host DNS name, and NOT the host GLUSTER DNS names.

I'm worrying about this, confirmed by what I read in the logs :

2016-08-19 14:46:30,484 WARN
[org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturnForXmlRpc]
(DefaultQuartzScheduler_Worker-100) [107dc2e3] Could not associate
brick 'serv-vm-al04-data.sdis.isere.fr:/gluster/data/brick04
' of volume '35026521-e76e-4774-8ddf-0a701b9eb40c' with correct
network as no gluster network found in cluster
'1c8e75a0-af3f-4e97-a8fb-2f7ef3ed9f30'
2016-08-19 14:46:30,492 WARN
[org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturnForXmlRpc]
(DefaultQuartzScheduler_Worker-100) [107dc2e3] Could not associate
brick 'serv-vm-al05-data.sdis.isere.fr:/gluster/data/brick04
' of volume '35026521-e76e-4774-8ddf-0a701b9eb40c' with correct
network as no gluster network found in cluster
'1c8e75a0-af3f-4e97-a8fb-2f7ef3ed9f30'
2016-08-19 14:46:30,500 WARN
[org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturnForXmlRpc]
(DefaultQuartzScheduler_Worker-100) [107dc2e3] Could not associate
brick 'serv-vm-al06-data.sdis.isere.fr:/gluster/data/brick04
' of volume '35026521-e76e-4774-8ddf-0a701b9eb40c' with correct
network as no gluster network found in cluster
'1c8e75a0-af3f-4e97-a8fb-2f7ef3ed9f30'

[oVirt shell (connected)]# list clusters

id : 0001-0001-0001-0001-0045
name   : cluster51
description: Cluster d'alerte de test

id : 1c8e75a0-af3f-4e97-a8fb-2f7ef3ed9f30
name   : cluster52
description: Cluster d'alerte de test

[oVirt shell (connected)]#

"cluster52" is the recent cluster, and I do have a dedicated
gluster network, marked as gluster network, in the correct DC and
cluster.
The only point is that :
- Each host has its name ("serv-vm-al04") and a second name for
gluster ("serv-vm-al04-data").
- Using blahblahblah-data is correct on a gluster point of view
- Maybe oVirt is disturb not to be able to ping the gluster FQDN
(not routed) and then throwing this error?


We do have a limitation currently that if you use multiple FQDNs, 
oVirt cannot associate it to the gluster brick correctly. This will be 
a problem only when you try brick management from oVirt - i.e try to 
remove or replace brick from oVirt. For monitoring brick status and 
detecting bricks - this is not an issue, and you can ignore the error 
in logs.


Adding Ramesh who has a patch to fix this .


Patch https://gerrit.ovirt.org/#/c/60083/ is posted to address this 
issue. But it will work only if the oVirt Engine can resolve FQDN 
*'serv-vm-al04-data.xx*'* to an IP address which is mapped to the 
gluster NIC (NIC with gluster network) on the host.


Sahina: Can you review the patch :-)

Regards,
Ramesh

-- 
Nicolas ECARNOT





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