[Engine-devel] Dynamic resource loading in GWT

[Roy Golan]

Painful issue here - we all know the regular drill of maintaining 
messages in many places, I18N files and so on.
Also there's a patch to make all available timezone an java enum and by 
that share it for free with the UI. its a way better than a backend Query.


But this is all hard-coded, not flexible, hard to maintain, we all know.

Why won't we make GWT load a javascript dictionary/dictionaries from a 
servlet or our host page html[1] using GWT Dictionary[3]?


that way the configuration is shared with the engine, it relies on the 
disk, customers and GSS can change it on-site and so on.



| index.html | -> | file servlet | -> |read /etc/ovirt-engine/conf/...|

^
 |

| GWT loads Dictionary |


candidates for dynamic resources
* I18N resources AppErrors...
* config ( just the UI subset )
* osinfo ?



[1] host page html - 
http://www.gwtproject.org/doc/latest/DevGuideOrganizingProjects.html#DevGuideHostPage
[2] Dynamic string internationalisation - 
http://www.gwtproject.org/doc/latest/DevGuideI18n.html#DevGuideDynamicStringInternationalization
[3] 
http://www.gwtproject.org/javadoc/latest/com/google/gwt/i18n/client/Dictionary.html


Thanks,
Roy
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] cannot login after re-deploying development environment

[Lior Vernia]

Hi Einav,

Happens to me repeatedly. I reset options "AdminPassword" and
"LocalAdminPassword" manually in the vdc_options in the DB. Never tried
the aforementioned "-s AdminPassword=interactive" switch for engine-setup.

Lior.

On 06/08/13 20:31, Einav Cohen wrote:
> Hi,
> 
> The following scenario already happened to me several times:
> 
> I created a brand new 'engine' data-base, created / deployed 
> development environment [everything works correctly].
> 
> After ^^^, I re-create/deploy development environment, this 
> time without creating a brand new 'engine' data-base (i.e. I 
> utilized the existing one). Everything seems to be working 
> correctly, only I cannot login into the web-admin (I fail on 
> USER_FAILED_TO_AUTHENTICATE CanDoAction).
> 
> The only workaround I found is to use a brand-new data-base.
> 
> Any ideas?
> 
> [attached: engine.log, engine-setup output, engine-setup.log]
> 
> Thanks in advance.
> Einav
> 
> 
> 
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] [vdsm] How to handle qemu 1.3 dep for Gluster Storage Domain

[Sahina Bose]

[Adding engine-devel]

On 08/06/2013 10:48 AM, Deepak C Shetty wrote:

Hi All,
There were 2 learnings from BZ 
https://bugzilla.redhat.com/show_bug.cgi?id=988299


1) Gluster RPM deps were not proper in VDSM when using Gluster Storage 
Domain. This has been partly addressed
by the gluster-devel thread @ 
http://lists.gnu.org/archive/html/gluster-devel/2013-08/msg8.html
and will be fully addressed once Gluster folks ensure their packaging 
is friendly enuf for VDSM to consume
just the needed bits. Once that happens, i will be sending a patch to 
vdsm.spec.in to update the gluster

deps correctly. So this issue gets addressed in near term.

2) Gluster storage domain needs minimum libvirt 1.0.1 and qemu 1.3.

libvirt 1.0.1 has the support for representing gluster as a network 
block device and qemu 1.3 has the
native support for gluster block backend which supports gluster://... 
URI way of representing a gluster
based file (aka volume/vmdisk in VDSM case). Many distros (incl. 
centos 6.4 in the BZ) won't have qemu

1.3 in their distro repos! How do we handle this dep in VDSM ?

Do we disable gluster storage domain in oVirt engine if VDSM reports 
qemu < 1.3 as part of getCapabilities ?

or
Do we ensure qemu 1.3 is present in ovirt.repo assuming ovirt.repo is 
always present on VDSM hosts in which
case when VDSM gets installed, qemu 1.3 dep in vdsm.spec.in will 
install qemu 1.3 from the ovirt.repo
instead of the distro repo. This means vdsm.spec.in will have qemu >= 
1.3 under Requires.


Is this possible to make this a conditional install? That is, only if 
Storage Domain = GlusterFS in the Data center, the bootstrapping of host 
will install the qemu 1.3 and dependencies.


(The question still remains as to where the qemu 1.3 rpms will be available)


What will be a good way to handle this ?
Appreciate your response

thanx,
deepak

___
vdsm-devel mailing list
vdsm-de...@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel


___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] users cannot log into userportal

[Dead Horse]

I have found some steps to reproduce this easily.

Start the engine bound to an AD for authentication
log in to the user portal as an AD user which has been granted a Role (I
used PowerUserRole)

Result: Login will succeed
Data from engine.log:
2013-08-06 15:54:10,088 INFO  [org.ovirt.engine.core.bll.LoginUserCommand]
(ajp--127.0.0.1-8702-10) Running command: LoginUserCommand internal: false.
2013-08-06 15:54:10,139 INFO
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(ajp--127.0.0.1-8702-10) Correlation ID: 23c4709, Call Stack: null, Custom
Event ID: -1, Message: User ovirttest logged in.

log out of the user portal
Result: log out succeeds
Data from engine.log:
2013-08-06 15:54:12,448 INFO  [org.ovirt.engine.core.bll.LogoutUserCommand]
(ajp--127.0.0.1-8702-2) Running command: LogoutUserCommand internal: false.
2013-08-06 15:54:12,474 INFO
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(ajp--127.0.0.1-8702-2) Correlation ID: 52a89e7d, Call Stack: null, Custom
Event ID: -1, Message: User ovirttest logged out.

As the same user log in to the user portal again but this purposely input
the wrong password.
Result: log in will fail
Data from engine.log:
2013-08-06 15:54:20,830 ERROR
[org.ovirt.engine.core.bll.adbroker.GSSAPIDirContextAuthenticationStrategy]
(ajp--127.0.0.1-8702-7) Kerberos error: Pre-authentication information was
invalid (24)
2013-08-06 15:54:20,832 ERROR
[org.ovirt.engine.core.bll.adbroker.GSSAPIDirContextAuthenticationStrategy]
(ajp--127.0.0.1-8702-7) Authentication Failed. Please verify the username
and password.
2013-08-06 15:54:20,843 ERROR
[org.ovirt.engine.core.bll.adbroker.DirectorySearcher]
(ajp--127.0.0.1-8702-7) Failed ldap search server LDAP://
foodc02.foo.test.com:389 using user ovirtt...@foo.test.com due to
Authentication Failed. Please verify the username and password.. We should
not try the next server
2013-08-06 15:54:20,850 ERROR
[org.ovirt.engine.core.bll.adbroker.GSSAPIDirContextAuthenticationStrategy]
(ajp--127.0.0.1-8702-7) Kerberos error: Pre-authentication information was
invalid (24)
2013-08-06 15:54:20,851 ERROR
[org.ovirt.engine.core.bll.adbroker.GSSAPIDirContextAuthenticationStrategy]
(ajp--127.0.0.1-8702-7) Authentication Failed. Please verify the username
and password.
2013-08-06 15:54:20,852 ERROR
[org.ovirt.engine.core.bll.adbroker.DirectorySearcher]
(ajp--127.0.0.1-8702-7) Failed ldap search server LDAP://
foodc01.foo.test.com:389 using user ovirtt...@foo.test.com due to
Authentication Failed. Please verify the username and password.. We should
not try the next server
2013-08-06 15:54:20,853 ERROR
[org.ovirt.engine.core.bll.adbroker.LdapAuthenticateUserCommand]
(ajp--127.0.0.1-8702-7) Failed authenticating user: ovirttest to domain
gso.med.ge.com. Ldap Query Type is getUserByName
2013-08-06 15:54:20,854 ERROR
[org.ovirt.engine.core.bll.adbroker.LdapAuthenticateUserCommand]
(ajp--127.0.0.1-8702-7) Authentication Failed. Please verify the username
and password.
2013-08-06 15:54:20,855 ERROR [org.ovirt.engine.core.bll.LoginUserCommand]
(ajp--127.0.0.1-8702-7)
USER_FAILED_TO_AUTHENTICATE_WRONG_USERNAME_OR_PASSWORD : ovirttest
2013-08-06 15:54:20,856 WARN  [org.ovirt.engine.core.bll.LoginUserCommand]
(ajp--127.0.0.1-8702-7) CanDoAction of action LoginUser failed.
Reasons:USER_FAILED_TO_AUTHENTICATE_WRONG_USERNAME_OR_PASSWORD

Try again to log in as the same user this time typing the correct password.
Result: Login fails!
Data from engine.log:
2013-08-06 15:54:25,186 ERROR
[org.ovirt.engine.core.bll.adbroker.LdapAuthenticateUserCommand]
(ajp--127.0.0.1-8702-7) Failed authenticating user: ovirttest to domain
gso.med.ge.com. Ldap Query Type is getUserByName
2013-08-06 15:54:25,187 ERROR [org.ovirt.engine.core.bll.LoginUserCommand]
(ajp--127.0.0.1-8702-7) USER_FAILED_TO_AUTHENTICATE : ovirttest
2013-08-06 15:54:25,187 WARN  [org.ovirt.engine.core.bll.LoginUserCommand]
(ajp--127.0.0.1-8702-7) CanDoAction of action LoginUser failed.
Reasons:USER_FAILED_TO_AUTHENTICATE

Try again with another AD user.
Result: Login fails!
Data from engine.log:
2013-08-06 15:54:38,056 ERROR
[org.ovirt.engine.core.bll.adbroker.LdapAuthenticateUserCommand]
(ajp--127.0.0.1-8702-5) Failed authenticating user: ovirtadmin to domain
gso.med.ge.com. Ldap Query Type is getUserByName
2013-08-06 15:54:38,057 ERROR [org.ovirt.engine.core.bll.LoginUserCommand]
(ajp--127.0.0.1-8702-5) USER_FAILED_TO_AUTHENTICATE : ovirtadmin
2013-08-06 15:54:38,058 WARN  [org.ovirt.engine.core.bll.LoginUserCommand]
(ajp--127.0.0.1-8702-5) CanDoAction of action LoginUser failed.
Reasons:USER_FAILED_TO_AUTHENTICATE

Logging into the admin portal as the admin@internal user will yield that
engine seems to have forgotten about and can no longer enumerate AD users
and groups.
engine stays in this state until it has been restarted.

I also note the two following errors in the engine log file as well:
2013-08-06 15:53:41,098 ERROR
[org.ovirt.engine.core.dal.dbbroker.generic.DBConfig

Re: [Engine-devel] direct manipulation of libvirt

[Itamar Heim]

On 08/06/2013 06:49 PM, Dead Horse wrote:

It would be nice to be able to enable certain types of VM's (or just
purposely for whatever reason) to be able to use for example:
VEPA (macvtap)
Change VRAM sizes


is this covering this?
http://gerrit.ovirt.org/#/c/16803/


change disk IO policies
change dsk Cache Policies


there is a built-in custom property for this one?


change input type to usbtablet or PS2
(new qemu/libvirt features to play or test)

This of course should be limited to admin level roles as it would come
with the understanding of the possibility of things exploding in ones face.

Perhaps this could be implemented as a "Really Advanced Options" on a VM
visible to superuser or admin roles only?


this would be akin to custom properties, some of which come via vdsm, 
just without a special gui on engine side (i.e., they don't need hooks 
on vdsm since they are supported out of the box).
reason they are custom properties without dedicated UI is the use case 
is rare.


other than some custom property to pass libvirt command line args, or 
xml overrides, i think the custom proeprties/hooks (or vdsm builtin 
support) is the cleanest one




  -DHC



On Sun, Aug 4, 2013 at 2:49 AM, Noam Slomianko mailto:nslom...@redhat.com>> wrote:

Since you cannot know what kind of changes the user will do in
libvirt you cannot be sure that VDSM will be able to live with them.
By "Allowing" this officially you will create an impression that it
is safe, which will cause frustration for the user if VDSM breaks.
So keeping this as "do at your own risk, we want nothing to do with
it" sounds like a good plan to me :)

But ignoring that, what kind of behaviour would you like? maybe the
ability to pass custom libvirt flags on VM startup?
This can be pretty easily Implemented as an all purpose hook, isn't
it? (write once, pass any argument you like)

- Original Message -
From: "Dead Horse" mailto:deadhorseconsult...@gmail.com>>
To: "engine-devel" mailto:engine-devel@ovirt.org>>
Sent: Friday, August 2, 2013 7:43:31 PM
Subject: [Engine-devel] direct manipulation of libvirt

A broad question here, perhaps not a possibility but I figured I
would toss it out there anyway.

VDSM is great at what it does, however there are those times when
direct manipulation of libvirt or libvirt VM configuration would be
very handy. The safe defaults and tested VM configurations that
VDSM/ovirt provides are great. However at times it would be nice to
simply connect to a hypervisor managed by ovirt/vdsm and make a
couple changes to a VM (via virt-manager or directly via virsh).

This could be enabling a new feature that has made it's way into
QEMU/libvirt/KVM or tweaking a VM configuration for whatever reason.
Now there is nothing stopping someone from doing this now either
directly or via VDSM hooks. Hooks are a pain along with the custom
properties to jack them into engine. Direct manipulation of libvirt
since it has been upstarted by vdsm results in an unhappy VDSM/engine.

Thoughts?
- DHC

___
Engine-devel mailing list
Engine-devel@ovirt.org 
http://lists.ovirt.org/mailman/listinfo/engine-devel




___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel



___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] cannot login after re-deploying development environment

[Dead Horse]

The initial symptom reported was similar, initially I could not log into
the admin portal (albeit with a non-devel env) however an engine restart
seemed to clean that up.
I then noticed the latter part of the issue I mentioned after the thread
grew a bit ;-)
None the less agreed a different issue, I will fire up a diff thread for it.
- DHC



On Tue, Aug 6, 2013 at 1:13 PM, Alon Bar-Lev  wrote:

>
>
> - Original Message -
> > From: "Dead Horse" 
> > To: "Alon Bar-Lev" 
> > Cc: "Einav Cohen" , "engine-devel" <
> engine-devel@ovirt.org>
> > Sent: Tuesday, August 6, 2013 9:11:08 PM
> > Subject: Re: [Engine-devel] cannot login after re-deploying development
> environment
> >
> > Negative, it was built and upgraded via RPMs yum/engine-upgrade.
> > - DHC
>
> So different issue... :)
>
> >
> >
> > On Tue, Aug 6, 2013 at 1:09 PM, Alon Bar-Lev  wrote:
> >
> > >
> > >
> > > - Original Message -
> > > > From: "Dead Horse" 
> > > > To: "Alon Bar-Lev" 
> > > > Cc: "Einav Cohen" , "engine-devel" <
> > > engine-devel@ovirt.org>
> > > > Sent: Tuesday, August 6, 2013 9:05:37 PM
> > > > Subject: Re: [Engine-devel] cannot login after re-deploying
> development
> > > environment
> > > >
> > > > Seeing something similar to this but it pertains users not being
> able to
> > > > log in. Also for some reason the engine is seemingly forgets about AD
> > > > users. Removing the AD domain via engine-manage-domains and
> re-adding it
> > > > works for enumerating the users, however the first attempt to login
> as a
> > > > user results in the engine no longer enumerating the users nor
> allowing
> > > > logins.
> > > > Attached are the pertinent logs.
> > >
> > > Are you using the development environment?
> > >
> > > >
> > > > Engine is built and running from current master as of this morning.
> > > >
> > > >  - DHC
> > > >
> > > >
> > > > On Tue, Aug 6, 2013 at 12:46 PM, Alon Bar-Lev 
> wrote:
> > > >
> > > > >
> > > > >
> > > > > - Original Message -
> > > > > > From: "Einav Cohen" 
> > > > > > To: "engine-devel" 
> > > > > > Sent: Tuesday, August 6, 2013 8:31:07 PM
> > > > > > Subject: [Engine-devel] cannot login after re-deploying
> development
> > > > > environment
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > The following scenario already happened to me several times:
> > > > > >
> > > > > > I created a brand new 'engine' data-base, created / deployed
> > > > > > development environment [everything works correctly].
> > > > > >
> > > > > > After ^^^, I re-create/deploy development environment, this
> > > > > > time without creating a brand new 'engine' data-base (i.e. I
> > > > > > utilized the existing one). Everything seems to be working
> > > > > > correctly, only I cannot login into the web-admin (I fail on
> > > > > > USER_FAILED_TO_AUTHENTICATE CanDoAction).
> > > > > >
> > > > > > The only workaround I found is to use a brand-new data-base.
> > > > > >
> > > > > > Any ideas?
> > > > >
> > > > > If you remove $HOME/ovirt-engine you remove the pki keys.
> > > > > If you do not drop/create the database then the engine-setup is
> perform
> > > > > upgrade not fresh install.
> > > > > This cause the password to be undecryptable by the new key.
> > > > > Using engine-config -s AdminPassword=interactive will store
> encrypted
> > > > > password using the new key.
> > > > > If you want fresh install, please also drop/create database.
> > > > >
> > > > > >
> > > > > > [attached: engine.log, engine-setup output, engine-setup.log]
> > > > > >
> > > > > > Thanks in advance.
> > > > > > Einav
> > > > > >
> > > > > > ___
> > > > > > Engine-devel mailing list
> > > > > > Engine-devel@ovirt.org
> > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > >
> > > > > ___
> > > > > Engine-devel mailing list
> > > > > Engine-devel@ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > >
> > > >
> > >
> >
>
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] cannot login after re-deploying development environment

[Alon Bar-Lev]

- Original Message -
> From: "Dead Horse" 
> To: "Alon Bar-Lev" 
> Cc: "Einav Cohen" , "engine-devel" 
> Sent: Tuesday, August 6, 2013 9:11:08 PM
> Subject: Re: [Engine-devel] cannot login after re-deploying development 
> environment
> 
> Negative, it was built and upgraded via RPMs yum/engine-upgrade.
> - DHC

So different issue... :)

> 
> 
> On Tue, Aug 6, 2013 at 1:09 PM, Alon Bar-Lev  wrote:
> 
> >
> >
> > - Original Message -
> > > From: "Dead Horse" 
> > > To: "Alon Bar-Lev" 
> > > Cc: "Einav Cohen" , "engine-devel" <
> > engine-devel@ovirt.org>
> > > Sent: Tuesday, August 6, 2013 9:05:37 PM
> > > Subject: Re: [Engine-devel] cannot login after re-deploying development
> > environment
> > >
> > > Seeing something similar to this but it pertains users not being able to
> > > log in. Also for some reason the engine is seemingly forgets about AD
> > > users. Removing the AD domain via engine-manage-domains and re-adding it
> > > works for enumerating the users, however the first attempt to login as a
> > > user results in the engine no longer enumerating the users nor allowing
> > > logins.
> > > Attached are the pertinent logs.
> >
> > Are you using the development environment?
> >
> > >
> > > Engine is built and running from current master as of this morning.
> > >
> > >  - DHC
> > >
> > >
> > > On Tue, Aug 6, 2013 at 12:46 PM, Alon Bar-Lev  wrote:
> > >
> > > >
> > > >
> > > > - Original Message -
> > > > > From: "Einav Cohen" 
> > > > > To: "engine-devel" 
> > > > > Sent: Tuesday, August 6, 2013 8:31:07 PM
> > > > > Subject: [Engine-devel] cannot login after re-deploying development
> > > > environment
> > > > >
> > > > > Hi,
> > > > >
> > > > > The following scenario already happened to me several times:
> > > > >
> > > > > I created a brand new 'engine' data-base, created / deployed
> > > > > development environment [everything works correctly].
> > > > >
> > > > > After ^^^, I re-create/deploy development environment, this
> > > > > time without creating a brand new 'engine' data-base (i.e. I
> > > > > utilized the existing one). Everything seems to be working
> > > > > correctly, only I cannot login into the web-admin (I fail on
> > > > > USER_FAILED_TO_AUTHENTICATE CanDoAction).
> > > > >
> > > > > The only workaround I found is to use a brand-new data-base.
> > > > >
> > > > > Any ideas?
> > > >
> > > > If you remove $HOME/ovirt-engine you remove the pki keys.
> > > > If you do not drop/create the database then the engine-setup is perform
> > > > upgrade not fresh install.
> > > > This cause the password to be undecryptable by the new key.
> > > > Using engine-config -s AdminPassword=interactive will store encrypted
> > > > password using the new key.
> > > > If you want fresh install, please also drop/create database.
> > > >
> > > > >
> > > > > [attached: engine.log, engine-setup output, engine-setup.log]
> > > > >
> > > > > Thanks in advance.
> > > > > Einav
> > > > >
> > > > > ___
> > > > > Engine-devel mailing list
> > > > > Engine-devel@ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > >
> > > > ___
> > > > Engine-devel mailing list
> > > > Engine-devel@ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >
> > >
> >
> 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] cannot login after re-deploying development environment

[Dead Horse]

Negative, it was built and upgraded via RPMs yum/engine-upgrade.
- DHC


On Tue, Aug 6, 2013 at 1:09 PM, Alon Bar-Lev  wrote:

>
>
> - Original Message -
> > From: "Dead Horse" 
> > To: "Alon Bar-Lev" 
> > Cc: "Einav Cohen" , "engine-devel" <
> engine-devel@ovirt.org>
> > Sent: Tuesday, August 6, 2013 9:05:37 PM
> > Subject: Re: [Engine-devel] cannot login after re-deploying development
> environment
> >
> > Seeing something similar to this but it pertains users not being able to
> > log in. Also for some reason the engine is seemingly forgets about AD
> > users. Removing the AD domain via engine-manage-domains and re-adding it
> > works for enumerating the users, however the first attempt to login as a
> > user results in the engine no longer enumerating the users nor allowing
> > logins.
> > Attached are the pertinent logs.
>
> Are you using the development environment?
>
> >
> > Engine is built and running from current master as of this morning.
> >
> >  - DHC
> >
> >
> > On Tue, Aug 6, 2013 at 12:46 PM, Alon Bar-Lev  wrote:
> >
> > >
> > >
> > > - Original Message -
> > > > From: "Einav Cohen" 
> > > > To: "engine-devel" 
> > > > Sent: Tuesday, August 6, 2013 8:31:07 PM
> > > > Subject: [Engine-devel] cannot login after re-deploying development
> > > environment
> > > >
> > > > Hi,
> > > >
> > > > The following scenario already happened to me several times:
> > > >
> > > > I created a brand new 'engine' data-base, created / deployed
> > > > development environment [everything works correctly].
> > > >
> > > > After ^^^, I re-create/deploy development environment, this
> > > > time without creating a brand new 'engine' data-base (i.e. I
> > > > utilized the existing one). Everything seems to be working
> > > > correctly, only I cannot login into the web-admin (I fail on
> > > > USER_FAILED_TO_AUTHENTICATE CanDoAction).
> > > >
> > > > The only workaround I found is to use a brand-new data-base.
> > > >
> > > > Any ideas?
> > >
> > > If you remove $HOME/ovirt-engine you remove the pki keys.
> > > If you do not drop/create the database then the engine-setup is perform
> > > upgrade not fresh install.
> > > This cause the password to be undecryptable by the new key.
> > > Using engine-config -s AdminPassword=interactive will store encrypted
> > > password using the new key.
> > > If you want fresh install, please also drop/create database.
> > >
> > > >
> > > > [attached: engine.log, engine-setup output, engine-setup.log]
> > > >
> > > > Thanks in advance.
> > > > Einav
> > > >
> > > > ___
> > > > Engine-devel mailing list
> > > > Engine-devel@ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >
> > > ___
> > > Engine-devel mailing list
> > > Engine-devel@ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> >
>
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] cannot login after re-deploying development environment

[Alon Bar-Lev]

- Original Message -
> From: "Dead Horse" 
> To: "Alon Bar-Lev" 
> Cc: "Einav Cohen" , "engine-devel" 
> Sent: Tuesday, August 6, 2013 9:05:37 PM
> Subject: Re: [Engine-devel] cannot login after re-deploying development 
> environment
> 
> Seeing something similar to this but it pertains users not being able to
> log in. Also for some reason the engine is seemingly forgets about AD
> users. Removing the AD domain via engine-manage-domains and re-adding it
> works for enumerating the users, however the first attempt to login as a
> user results in the engine no longer enumerating the users nor allowing
> logins.
> Attached are the pertinent logs.

Are you using the development environment?

> 
> Engine is built and running from current master as of this morning.
> 
>  - DHC
> 
> 
> On Tue, Aug 6, 2013 at 12:46 PM, Alon Bar-Lev  wrote:
> 
> >
> >
> > - Original Message -
> > > From: "Einav Cohen" 
> > > To: "engine-devel" 
> > > Sent: Tuesday, August 6, 2013 8:31:07 PM
> > > Subject: [Engine-devel] cannot login after re-deploying development
> > environment
> > >
> > > Hi,
> > >
> > > The following scenario already happened to me several times:
> > >
> > > I created a brand new 'engine' data-base, created / deployed
> > > development environment [everything works correctly].
> > >
> > > After ^^^, I re-create/deploy development environment, this
> > > time without creating a brand new 'engine' data-base (i.e. I
> > > utilized the existing one). Everything seems to be working
> > > correctly, only I cannot login into the web-admin (I fail on
> > > USER_FAILED_TO_AUTHENTICATE CanDoAction).
> > >
> > > The only workaround I found is to use a brand-new data-base.
> > >
> > > Any ideas?
> >
> > If you remove $HOME/ovirt-engine you remove the pki keys.
> > If you do not drop/create the database then the engine-setup is perform
> > upgrade not fresh install.
> > This cause the password to be undecryptable by the new key.
> > Using engine-config -s AdminPassword=interactive will store encrypted
> > password using the new key.
> > If you want fresh install, please also drop/create database.
> >
> > >
> > > [attached: engine.log, engine-setup output, engine-setup.log]
> > >
> > > Thanks in advance.
> > > Einav
> > >
> > > ___
> > > Engine-devel mailing list
> > > Engine-devel@ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > ___
> > Engine-devel mailing list
> > Engine-devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] cannot login after re-deploying development environment

[Alon Bar-Lev]

- Original Message -
> From: "Einav Cohen" 
> To: "Alon Bar-Lev" 
> Cc: "engine-devel" 
> Sent: Tuesday, August 6, 2013 9:00:37 PM
> Subject: Re: [Engine-devel] cannot login after re-deploying   development 
> environment
> 
> > - Original Message -
> > From: "Alon Bar-Lev" 
> > Sent: Tuesday, August 6, 2013 1:46:09 PM
> > 
> > 
> > 
> > - Original Message -
> > > From: "Einav Cohen" 
> > > To: "engine-devel" 
> > > Sent: Tuesday, August 6, 2013 8:31:07 PM
> > > Subject: [Engine-devel] cannot login after re-deploying development
> > >   environment
> > > 
> > > Hi,
> > > 
> > > The following scenario already happened to me several times:
> > > 
> > > I created a brand new 'engine' data-base, created / deployed
> > > development environment [everything works correctly].
> > > 
> > > After ^^^, I re-create/deploy development environment, this
> > > time without creating a brand new 'engine' data-base (i.e. I
> > > utilized the existing one). Everything seems to be working
> > > correctly, only I cannot login into the web-admin (I fail on
> > > USER_FAILED_TO_AUTHENTICATE CanDoAction).
> > > 
> > > The only workaround I found is to use a brand-new data-base.
> > > 
> > > Any ideas?
> > 
> > If you remove $HOME/ovirt-engine you remove the pki keys.
> > If you do not drop/create the database then the engine-setup is perform
> > upgrade not fresh install.
> > This cause the password to be undecryptable by the new key.
> > Using engine-config -s AdminPassword=interactive will store encrypted
> > password using the new key.
> > If you want fresh install, please also drop/create database.
> 
> Thanks, Alon; so assuming that I want to utilize my existing database
> (after working hard filling it with Hosts, Storage Domains, VMs, etc...),
> but to re-deploy the environment (since I just fetched latest code from
> ovirt master, for example, and I want to run it) - I assume that I should
> NOT remove "$HOME/ovirt-engine" (or "PREFIX"); is it safe to simply
> run:
>  "make clean install-dev PREFIX=[old-PREFIX]"

Right, if there is no significant change this will work, if there are database 
changes, you should run engine-setup again to perform upgrade.

However, you do able to remove the entire environment without cleaning 
database, just run engine-setup and then reset password using:

"${HOME}"/ovirt-engine/bin/engine-config -s AdminPassword=interactive

And you will be able to login, but lose encrypted storage secrets.

> or is there something that needs to be removed / some cleanup that should
> be performed in order to make sure that there are no leftovers from
> previous deployments?

As files are only added, there might be side effects.
If, for example, dbscripts were modified, you may have duplicates etc..
In this case you can remove $HOME/ovirt-engine/share/ovirt-engine/dbscripts 
before install-dev.
There can be other side effects if packaging files are added.

> > 
> > > 
> > > [attached: engine.log, engine-setup output, engine-setup.log]
> > > 
> > > Thanks in advance.
> > > Einav
> > > 
> > > ___
> > > Engine-devel mailing list
> > > Engine-devel@ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > ___
> > Engine-devel mailing list
> > Engine-devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> > 
> > 
> 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] cannot login after re-deploying development environment

[Einav Cohen]

> - Original Message -
> From: "Alon Bar-Lev" 
> Sent: Tuesday, August 6, 2013 1:46:09 PM
> 
> 
> 
> - Original Message -
> > From: "Einav Cohen" 
> > To: "engine-devel" 
> > Sent: Tuesday, August 6, 2013 8:31:07 PM
> > Subject: [Engine-devel] cannot login after re-deploying development
> > environment
> > 
> > Hi,
> > 
> > The following scenario already happened to me several times:
> > 
> > I created a brand new 'engine' data-base, created / deployed
> > development environment [everything works correctly].
> > 
> > After ^^^, I re-create/deploy development environment, this
> > time without creating a brand new 'engine' data-base (i.e. I
> > utilized the existing one). Everything seems to be working
> > correctly, only I cannot login into the web-admin (I fail on
> > USER_FAILED_TO_AUTHENTICATE CanDoAction).
> > 
> > The only workaround I found is to use a brand-new data-base.
> > 
> > Any ideas?
> 
> If you remove $HOME/ovirt-engine you remove the pki keys.
> If you do not drop/create the database then the engine-setup is perform
> upgrade not fresh install.
> This cause the password to be undecryptable by the new key.
> Using engine-config -s AdminPassword=interactive will store encrypted
> password using the new key.
> If you want fresh install, please also drop/create database.

Thanks, Alon; so assuming that I want to utilize my existing database 
(after working hard filling it with Hosts, Storage Domains, VMs, etc...), 
but to re-deploy the environment (since I just fetched latest code from 
ovirt master, for example, and I want to run it) - I assume that I should 
NOT remove "$HOME/ovirt-engine" (or "PREFIX"); is it safe to simply 
run:
 "make clean install-dev PREFIX=[old-PREFIX]"
or is there something that needs to be removed / some cleanup that should  
be performed in order to make sure that there are no leftovers from 
previous deployments?

> 
> > 
> > [attached: engine.log, engine-setup output, engine-setup.log]
> > 
> > Thanks in advance.
> > Einav
> > 
> > ___
> > Engine-devel mailing list
> > Engine-devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] cannot login after re-deploying development environment

[Alon Bar-Lev]

- Original Message -
> From: "Einav Cohen" 
> To: "engine-devel" 
> Sent: Tuesday, August 6, 2013 8:31:07 PM
> Subject: [Engine-devel] cannot login after re-deploying development   
> environment
> 
> Hi,
> 
> The following scenario already happened to me several times:
> 
> I created a brand new 'engine' data-base, created / deployed
> development environment [everything works correctly].
> 
> After ^^^, I re-create/deploy development environment, this
> time without creating a brand new 'engine' data-base (i.e. I
> utilized the existing one). Everything seems to be working
> correctly, only I cannot login into the web-admin (I fail on
> USER_FAILED_TO_AUTHENTICATE CanDoAction).
> 
> The only workaround I found is to use a brand-new data-base.
> 
> Any ideas?

If you remove $HOME/ovirt-engine you remove the pki keys.
If you do not drop/create the database then the engine-setup is perform upgrade 
not fresh install.
This cause the password to be undecryptable by the new key.
Using engine-config -s AdminPassword=interactive will store encrypted password 
using the new key.
If you want fresh install, please also drop/create database.

> 
> [attached: engine.log, engine-setup output, engine-setup.log]
> 
> Thanks in advance.
> Einav
> 
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] cannot login after re-deploying development environment

[Yair Zaslavsky]

Can we get server.log as well?

- Original Message -
> From: "Einav Cohen" 
> To: "engine-devel" 
> Sent: Tuesday, August 6, 2013 8:31:07 PM
> Subject: [Engine-devel] cannot login after re-deploying development   
> environment
> 
> Hi,
> 
> The following scenario already happened to me several times:
> 
> I created a brand new 'engine' data-base, created / deployed
> development environment [everything works correctly].
> 
> After ^^^, I re-create/deploy development environment, this
> time without creating a brand new 'engine' data-base (i.e. I
> utilized the existing one). Everything seems to be working
> correctly, only I cannot login into the web-admin (I fail on
> USER_FAILED_TO_AUTHENTICATE CanDoAction).
> 
> The only workaround I found is to use a brand-new data-base.
> 
> Any ideas?
> 
> [attached: engine.log, engine-setup output, engine-setup.log]
> 
> Thanks in advance.
> Einav
> 
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] direct manipulation of libvirt

[Dead Horse]

It would be nice to be able to enable certain types of VM's (or just
purposely for whatever reason) to be able to use for example:
VEPA (macvtap)
Change VRAM sizes
change disk IO policies
change dsk Cache Policies
change input type to usbtablet or PS2
(new qemu/libvirt features to play or test)

This of course should be limited to admin level roles as it would come with
the understanding of the possibility of things exploding in ones face.

Perhaps this could be implemented as a "Really Advanced Options" on a VM
visible to superuser or admin roles only?

 -DHC



On Sun, Aug 4, 2013 at 2:49 AM, Noam Slomianko  wrote:

> Since you cannot know what kind of changes the user will do in libvirt you
> cannot be sure that VDSM will be able to live with them.
> By "Allowing" this officially you will create an impression that it is
> safe, which will cause frustration for the user if VDSM breaks.
> So keeping this as "do at your own risk, we want nothing to do with it"
> sounds like a good plan to me :)
>
> But ignoring that, what kind of behaviour would you like? maybe the
> ability to pass custom libvirt flags on VM startup?
> This can be pretty easily Implemented as an all purpose hook, isn't it?
> (write once, pass any argument you like)
>
> - Original Message -
> From: "Dead Horse" 
> To: "engine-devel" 
> Sent: Friday, August 2, 2013 7:43:31 PM
> Subject: [Engine-devel] direct manipulation of libvirt
>
> A broad question here, perhaps not a possibility but I figured I would
> toss it out there anyway.
>
> VDSM is great at what it does, however there are those times when direct
> manipulation of libvirt or libvirt VM configuration would be very handy.
> The safe defaults and tested VM configurations that VDSM/ovirt provides are
> great. However at times it would be nice to simply connect to a hypervisor
> managed by ovirt/vdsm and make a couple changes to a VM (via virt-manager
> or directly via virsh).
>
> This could be enabling a new feature that has made it's way into
> QEMU/libvirt/KVM or tweaking a VM configuration for whatever reason. Now
> there is nothing stopping someone from doing this now either directly or
> via VDSM hooks. Hooks are a pain along with the custom properties to jack
> them into engine. Direct manipulation of libvirt since it has been
> upstarted by vdsm results in an unhappy VDSM/engine.
>
> Thoughts?
> - DHC
>
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup

[Nicholas Kesick]

I did some testing with Fedora 18 (waiting for the Fedora 19 dvd to finish 
downloading) and I think that the behavior was the same way in Fedora 18. In 
Fedora 18 when installing from DVD if you select “Minimal Install”, you do not 
get tar.

 

However, if you select “Minimal install” and “standard” under the add-on list, 
you *do* get tar. And if memory serves I learned the hard way in Fedora 18 that 
a lot of familiar commands are missing in minimal install without the standard 
add-on items including “ifconfig”. Yea, you can’t even easily tell what your IP 
address is!... unless you are used to the ip command.


 

Is there any other commands that are missing on the “minimal” install that are 
needed? Would it be easier to mention in the install directions to use the 
standard add-on if selecting the minimal package set for host deployment?

 

Just thoughts. I also wonder if it would be possible to include tar as a 
dependency for the RPMs (like ovirt-engine or vdsm) so when installed using a 
package manager, tar would be checked for.

 

- Nick

 


From: Alon Bar-Lev
Sent: ‎August‎ ‎5‎, ‎2013 ‎6‎:‎02‎ ‎PM
To: users, arch, engine-devel
Subject: Re: [Users] [Engine-devel] [Feedback required][host-deploy] Fedora-19 
misses tar at minimal setup



Hello Again,

I tend to keep state as-is, require tar at host machine.

Whoever installs Fedora minimal should install tar manually.

I hope Fedora people will add tar per some of the requests, as tar is important 
utility in *NIX environment.

I do not think that the extra complexity is required.

If you strongly think otherwise, then I prefer to merge the self extracting 
python script.

Speak now, and emphasis.

Regards,
Alon Bar-Lev.

- Original Message -
> From: "Alon Bar-Lev" 
> To: "users" , "arch" , "engine-devel" 
> 
> Cc: "Juan Hernandez" 
> Sent: Tuesday, July 30, 2013 4:12:03 PM
> Subject: Re: [Engine-devel] [Users] [Feedback required][host-deploy] 
> Fedora-19 misses tar at minimal setup
> 
> Hello All,
> 
> Starting the discussion again...
> 
> I would like to receive feedback regarding how we should cope with a state
> presented to use by Fedora.
> 
> Fedora-19 minimal setup does not install tar utility which is required to
> deploy files during the host-deploy process (Hosts->Add Host).
> 
> I guess because of 2.8M in size (including translations) -- a standard
> commonly used utility was removed.
> 
> There are three alternatives :
> 
> 1. Instruct users who are using minimal installations to manually install tar
> utility just like they configure repository, dns, etc..
> 
> Benefit: simplicity.
> Benefit: use standard tools.
> Benefit: lower payload to transmit.
> Drawback: require tar at destination machine.
> 
> 2. Do not use tar but self extracting python script, a patch is ready[1].
> 
> Benefit: ability to deploy environment in which tar is missing.
> Drawback: non standard tool at destination machine.
> Drawback: complexity within our code.
> 
> 3. Do not use tar but cpio, a patch is ready[2].
> 
> Benefit: simplicity.
> Benefit: use standard tools.
> Benefit: lower payload to transmit.
> Benefit: ability to use Fedora-19 minimal.
> Drawback: cpio is even less common than tar, even if it exists in Fedora-19
> it can be removed without anyone notice.
> Drawback: most other distributions will not have cpio in their minimal
> installation.
> 
> [[[
> There was 4rd alternative, using python tar module to deploy tar.
> However, there is a bug in that module when processing last block if empty.
> This is edge condition but happened to at least one of the users and I could
> reproduce it.
> ]]]
> 
> What option do you prefer?
> 
> Regards,
> Alon Bar-Lev
> 
> [1] http://gerrit.ovirt.org/#/c/17295/
> [2] http://gerrit.ovirt.org/#/c/17396/
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
___
Users mailing list
us...@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup

[Roy Golan]

On 07/30/2013 04:25 PM, Michal Skrivanek wrote:

On Jul 30, 2013, at 15:12 , Alon Bar-Lev  wrote:


Hello All,

Starting the discussion again...

I would like to receive feedback regarding how we should cope with a state 
presented to use by Fedora.

Fedora-19 minimal setup does not install tar utility which is required to deploy 
files during the host-deploy process (Hosts->Add Host).

I guess because of 2.8M in size (including translations) -- a standard commonly 
used utility was removed.

How about filing bug on that? This is such a basic utility I can't imagine 
anyone removing it.
+1 it would make the most proper solution from all.

There are three alternatives :

1. Instruct users who are using minimal installations to manually install tar 
utility just like they configure repository, dns, etc..

Benefit: simplicity.
Benefit: use standard tools.
Benefit: lower payload to transmit.
Drawback: require tar at destination machine.

2. Do not use tar but self extracting python script, a patch is ready[1].

Benefit: ability to deploy environment in which tar is missing.
Drawback: non standard tool at destination machine.
Drawback: complexity within our code.

3. Do not use tar but cpio, a patch is ready[2].

Benefit: simplicity.
Benefit: use standard tools.
Benefit: lower payload to transmit.
Benefit: ability to use Fedora-19 minimal.
Drawback: cpio is even less common than tar, even if it exists in Fedora-19 it 
can be removed without anyone notice.
Drawback: most other distributions will not have cpio in their minimal 
installation.

[[[
There was 4rd alternative, using python tar module to deploy tar.
However, there is a bug in that module when processing last block if empty.
This is edge condition but happened to at least one of the users and I could
reproduce it.
]]]

What option do you prefer?

Regards,
Alon Bar-Lev

[1] http://gerrit.ovirt.org/#/c/17295/
[2] http://gerrit.ovirt.org/#/c/17396/
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

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


___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] failed to add host into cluster

[Chen, Wei D]

The issue is solved by reinstalling host OS.

Best Regards,
Dave Chen


> -Original Message-
> From: Chen, Wei D
> Sent: Tuesday, August 06, 2013 2:44 PM
> To: 'Laszlo Hornyak'; Itamar Heim
> Cc: Zhang, Lijuan; engine-devel@ovirt.org
> Subject: RE: [Engine-devel] failed to add host into cluster
>
> Hi,
>
>
> [root@onode vdsm]# vdsClient -s 0 getVdsCaps
> HBAInventory = {'iSCSI': [{'InitiatorName': 
> 'iqn.1994-05.com.redhat:9fb571e343'}], 'FC': []}
> ISCSIInitiatorName = iqn.1994-05.com.redhat:9fb571e343
> bondings = {'bond4': {'addr': '', 'cfg': {}, 'mtu': '1500', 
> 'netmask': '', 'slaves': [], 'hwaddr': '0e:00:b7:57:2c:c9'},
> 'bond0': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': [], 
> 'hwaddr': '32:b3:88:1f:ef:91'}, 'bond1': {'addr': '',
> 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': [], 'hwaddr': 
> '4e:e5:80:93:ea:d9'}, 'bond2': {'addr': '', 'cfg': {}, 'mtu': 
> '1500',
> 'netmask': '', 'slaves': [], 'hwaddr': '16:ab:f6:e4:f2:27'}, 'bond3': 
> {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', 
> 'slaves':
> [], 'hwaddr': 'ee:55:f5:e7:31:7c'}}
> bridges = {'ovirtmgmt': {'addr': '10.239.131.217', 'cfg': 
> {'PEERROUTES': 'yes', 'DEVICE': 'ovirtmgmt', 'IPV6INIT': 'yes',
> 'UUID': 'b6ecfa9d-0deb-4213-9348-11137f76735d', 'IPV6_PEERDNS': 'yes', 
> 'DEFROUTE': 'yes', 'PEERDNS': 'yes', 'IPV4_FAILURE_FATAL':
> 'no', 'DELAY': '0', 'NM_CONTROLLED': 'no', 'IPV6_DEFROUTE': 'yes', 
> 'IPV6_AUTOCONF': 'yes', 'IPV6_FAILURE_FATAL': 'no', 'TYPE':
> 'Bridge', 'ONBOOT': 'yes', 'BOOTPROTO': 'dhcp', 'IPV6_PEERROUTES': 'yes'}, 
> 'mtu': '1500', 'netmask': '255.255.255.0', 'stp': 'off',
> 'ports': ['em1']}}
> clusterLevels = ['3.0', '3.1', '3.2']
> cpuCores = 4
> cpuFlags =
> fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,r
> dtscp,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,aperfmperf,eagerfpu,pni,pclmulqdq,dtes64,monitor,
> ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr,pdcm,pcid,sse4_1,sse4_2,x2apic,popcnt,tsc_deadline_timer,aes,xsave,avx,lahf_lm,ida,arat,epb,
> xsaveopt,pln,pts,dtherm,tpr_shadow,vnmi,flexpriority,ept,vpid,model_Nehalem,model_Conroe,model_coreduo,model_core2duo,model_P
> enryn,model_Westmere,model_n270,model_SandyBridge
> cpuModel = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
> cpuSockets = 1
> cpuSpeed = 3672.000
> cpuThreads = 8
> emulatedMachines = ['clipper', 'none']
> guestOverhead = 65
> hooks = {}
> kvmEnabled = true
> lastClient = 10.239.131.222
> lastClientIface = ovirtmgmt
> management_ip =
> memSize = 7944
> netConfigDirty = False
> networks = {'ovirtmgmt': {'iface': 'ovirtmgmt', 'addr': 
> '10.239.131.217', 'cfg': {'PEERROUTES': 'yes', 'DEVICE': 
> 'ovirtmgmt',
> 'IPV6INIT': 'yes', 'UUID': 'b6ecfa9d-0deb-4213-9348-11137f76735d', 
> 'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'PEERDNS': 'yes',
> 'IPV4_FAILURE_FATAL': 'no', 'DELAY': '0', 'NM_CONTROLLED': 'no', 
> 'IPV6_DEFROUTE': 'yes', 'IPV6_AUTOCONF': 'yes',
> 'IPV6_FAILURE_FATAL':
> 'no', 'TYPE': 'Bridge', 'ONBOOT': 'yes', 'BOOTPROTO': 'dhcp', 
> 'IPV6_PEERROUTES': 'yes'}, 'mtu': '1500', 'netmask': '255.255.255.0',
> 'stp': 'off', 'bridged': True, 'gateway': '10.239.131.1', 'ports': ['em1']}}
> nics = {'em1': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', 
> 'hwaddr': '2c:41:38:b2:d0:e8', 'speed': 100}}
> operatingSystem = {'release': '0.5', 'version': '19', 'name': 
> 'Fedora'}
> packages2 = {'kernel': {'release': '301.fc19.x86_64', 'buildtime': 
> 1368462984.0, 'version': '3.9.2'}, 'spice-server':
> {'release': '5.fc19', 'buildtime': 1366036951, 'version': '0.12.2'}, 'vdsm': 
> {'release': '18.fc19', 'buildtime': 1373484771,
> 'version': '4.10.3'}, 'qemu-kvm': {'release': '4.fc19', 'buildtime': 
> 1371653911, 'version': '1.4.2'}, 'libvirt': {'release': 
> '1.fc19',
> 'buildtime': 1371074681, 'version': '1.0.5.2'}, 'qemu-img': {'release': 
> '4.fc19', 'buildtime': 1371653911, 'version': '1.4.2'}, 
> 'mom':
> {'release': '2.fc19', 'buildtime': 1374564325, 'version': '0.3.2'}}
> reservedMem = 321
> software_revision = 18
> software_version = 4.10
> supportedENGINEs = ['3.0', '3.1']
> supportedProtocols = ['2.2', '2.3']
> uuid = 30BBC800-4F47-11E0--2C4138B2D0E8
> version_name = Snow Man
> vlans = {}
> vmTypes = ['kvm']
>
>
>
>
>
> Best Regards,
> Dave Chen
>
>
> > -Original Message-
> > From: Laszlo Hornyak [mailto:lhorn...@redhat.com]
> > Sent: Monday, August 05, 2013 8:35 PM
> > To: Itamar Heim
> > Cc: Chen, Wei D; Zhang, Lijuan; engine-devel@ovirt.org
> > Subject: Re: [Engine-devel] failed to add host into cluster
> >
> > Hi,
> >
> > Dave, could you also share the vdsm log as well?
> >
> > I managed to reproduce this on the hos