Re: [ovirt-users] Single server hosted engine... almost there

[Mark Steckel]

Hi,

OK, I reset things and tried again but was more more careful regarding the DNS 
setup which I believe was correct this. In other words, the FQDNs were resolved 
from both the host and the HE VM.

After the latest failure I execute 'ip address' to see the state of the 
interfaces. And lo and behold the /29 IP I had on eth0:1 no longer exists. 

So some context.

The server's primary IP is a /24 with the gw being the x.y.z.1.

I have have a /29 subnet to use for the VMs.

I have been presuming that I place the a.b.c.1/29 on eth0:1 for the subnet's gw 
and OVirt will ether keep it in place or migrate it to the ovirtmgmt device. 
Instead it is deleted during "hosted-engine --deploy".(Note, when the .1/29 is 
assigned to eth0:1, the IP address is reachable from the the Internet.)

Dnsmasq is configured to a) serve a.b.c.2/29 a.b.c.6/29 via DHCP and b) to 
resolve unique FQDNs for each IP. The he VM set to receive the a.b.c.2/29 
address.

Am I missing and or just misunderstanding something here?

Oh, and does ip_forwarding need to be set in the kernel? (ie 
net.ipv4.ip_forward=1)

Thanks
Mark



- Derek Atkins  wrote:
> Hi,
> 
> You need to make sure resolv.conf is correct (both on the host AND on the
> engine vm).
> 
> So:   dig hostname
> (without the @local-ip)
> 
> As for the VM not coming up...  I'm not sure how to delay "engine-setup"
> run.  I presume you're running an engine appliance -- I ran my own CentOS
> install on the engine.  The logs imply it's suggesting you can access the
> engine VM console, but maybe it's exiting quickly?
> 
> -derek
> 
> On Wed, December 7, 2016 3:52 pm, Mark Steckel wrote:
> > I tested dnsmasq from the host by
> >
> >dig hostname @local-ip
> >
> > Worked fine.
> >
> > The engine VM never comes up to the point where I can access it via the
> > console...
> >
> >
> > - Derek Atkins  wrote:
> >> Hi,
> >>
> >> Ensure dnsmasq is working and can be accessed by the engine VM?
> >> Log in to the engine VM and test from there?
> >> Maybe set up *real* DNS?
> >>
> >> -derek
> >>
> >> On Wed, December 7, 2016 3:41 pm, Mark Steckel wrote:
> >> > Hi Derek,
> >> >
> >> > - Derek Atkins  wrote:
> >> >> Hi Mark,
> >> >>
> >> >> The error is correct, hosted-engine-1.pcstrac.com is not a valid
> >> >> hostname:
> >> >>
> >> >> $ host hosted-engine-1.pcstrac.com
> >> >> $
> >> >>
> >> >> I'm lost, tho -- was this an error that occurred on the host during
> >> >> hosted-engine --deploy, or was it an error that occurred in the
> >> hosted
> >> >> enging VM when running engine-setup?
> >> >
> >> > I believe when it occurred when the running the engine-setup.
> >> >
> >> >
> >> >> If the former, you need to ensure that you have a real DNS name for
> >> your
> >> >> ovirt engine.  It's unclear (to me) that using /etc/hosts is
> >> sufficient.
> >> >> However looking at the logs, it looks like it can locally resolve (to
> >> >> xx.yy.18.122).
> >> >
> >> > Yep. I tested things to make sure it could resolve before I started
> >> the
> >> > 'hosted-engine --deploy'.
> >> >
> >> >> You might need to answer "Yes" to the /etc/hosts question..
> >> >
> >> > I did answer "Yes".
> >> >
> >> >
> >> >> The log seems to get far enough along that it presents you the engine
> >> vm
> >> >> console URL?  It looks like the issue is that the engine vm cannot
> >> >> resolve
> >> >> its own name.
> >> >
> >> > That is my take as well.
> >> >
> >> > Scratching my head as I config'ed dnsmasq to provide local dns and to
> >> read
> >> > from /etc/hosts for hosted-engine-1.pcstrac.com.
> >> >
> >> > The only thing I think I flubbed was neglecting to add the host's IP
> >> to
> >> > the host's /etc/resolv.conf.
> >> >
> >> > Scrubbing and staring again.
> >> >
> >> > Mark
> >> >
> >> >
> >> >>
> >> >> -derek
> >> >>
> >> >> On Wed, December 7, 2016 3:13 pm, Mark Steckel wrote:
> >> >> > Folks,
> >> >> >
> >> >> > Thanks to Didi in another thread I'm making progress. (Lesson
> >> learned,
> >> >> > choose 'disk' and not 'cdrom' when using the he-appliance.)
> >> >> >
> >> >> > So I reset to a fresh CentOS 7, installed various software packages
> >> >> > including ovirt.
> >> >> >
> >> >> > I configed eth0 with a /32 public IP. I also added an alias for a
> >> >> > x.x.x.1/29 on eth0:1.
> >> >> >
> >> >> > Finally I config'ed dnsmasq to provide both dhcp and dns (ensuring
> >> >> that it
> >> >> > will read from /etc/hosts before forwarding dns requests) and added
> >> >> the
> >> >> > IPs and hostsnames to /etc/hosts from the /29 IPs which are to be
> >> used
> >> >> by
> >> >> > the VMs.
> >> >> >
> >> >> > Things proceeded nicely till resolving the he vm fqdn. (I tested to
> >> >> make
> >> >> > sure that the he vm fqdm would resolve **Before** I ran
> >> 'hosted-engine
> >> >> > --deploy'.)
> >> >> >
> >> >> >   |-   --== NETWORK CONFIGURATION ==--
> >> >> >   |-
> >> >> >   |- [ ERROR ] Host name is not valid:
> 

Re: [ovirt-users] Single server hosted engine... almost there

[Derek Atkins]

Hi,

You need to make sure resolv.conf is correct (both on the host AND on the
engine vm).

So:   dig hostname
(without the @local-ip)

As for the VM not coming up...  I'm not sure how to delay "engine-setup"
run.  I presume you're running an engine appliance -- I ran my own CentOS
install on the engine.  The logs imply it's suggesting you can access the
engine VM console, but maybe it's exiting quickly?

-derek

On Wed, December 7, 2016 3:52 pm, Mark Steckel wrote:
> I tested dnsmasq from the host by
>
>dig hostname @local-ip
>
> Worked fine.
>
> The engine VM never comes up to the point where I can access it via the
> console...
>
>
> - Derek Atkins  wrote:
>> Hi,
>>
>> Ensure dnsmasq is working and can be accessed by the engine VM?
>> Log in to the engine VM and test from there?
>> Maybe set up *real* DNS?
>>
>> -derek
>>
>> On Wed, December 7, 2016 3:41 pm, Mark Steckel wrote:
>> > Hi Derek,
>> >
>> > - Derek Atkins  wrote:
>> >> Hi Mark,
>> >>
>> >> The error is correct, hosted-engine-1.pcstrac.com is not a valid
>> >> hostname:
>> >>
>> >> $ host hosted-engine-1.pcstrac.com
>> >> $
>> >>
>> >> I'm lost, tho -- was this an error that occurred on the host during
>> >> hosted-engine --deploy, or was it an error that occurred in the
>> hosted
>> >> enging VM when running engine-setup?
>> >
>> > I believe when it occurred when the running the engine-setup.
>> >
>> >
>> >> If the former, you need to ensure that you have a real DNS name for
>> your
>> >> ovirt engine.  It's unclear (to me) that using /etc/hosts is
>> sufficient.
>> >> However looking at the logs, it looks like it can locally resolve (to
>> >> xx.yy.18.122).
>> >
>> > Yep. I tested things to make sure it could resolve before I started
>> the
>> > 'hosted-engine --deploy'.
>> >
>> >> You might need to answer "Yes" to the /etc/hosts question..
>> >
>> > I did answer "Yes".
>> >
>> >
>> >> The log seems to get far enough along that it presents you the engine
>> vm
>> >> console URL?  It looks like the issue is that the engine vm cannot
>> >> resolve
>> >> its own name.
>> >
>> > That is my take as well.
>> >
>> > Scratching my head as I config'ed dnsmasq to provide local dns and to
>> read
>> > from /etc/hosts for hosted-engine-1.pcstrac.com.
>> >
>> > The only thing I think I flubbed was neglecting to add the host's IP
>> to
>> > the host's /etc/resolv.conf.
>> >
>> > Scrubbing and staring again.
>> >
>> > Mark
>> >
>> >
>> >>
>> >> -derek
>> >>
>> >> On Wed, December 7, 2016 3:13 pm, Mark Steckel wrote:
>> >> > Folks,
>> >> >
>> >> > Thanks to Didi in another thread I'm making progress. (Lesson
>> learned,
>> >> > choose 'disk' and not 'cdrom' when using the he-appliance.)
>> >> >
>> >> > So I reset to a fresh CentOS 7, installed various software packages
>> >> > including ovirt.
>> >> >
>> >> > I configed eth0 with a /32 public IP. I also added an alias for a
>> >> > x.x.x.1/29 on eth0:1.
>> >> >
>> >> > Finally I config'ed dnsmasq to provide both dhcp and dns (ensuring
>> >> that it
>> >> > will read from /etc/hosts before forwarding dns requests) and added
>> >> the
>> >> > IPs and hostsnames to /etc/hosts from the /29 IPs which are to be
>> used
>> >> by
>> >> > the VMs.
>> >> >
>> >> > Things proceeded nicely till resolving the he vm fqdn. (I tested to
>> >> make
>> >> > sure that the he vm fqdm would resolve **Before** I ran
>> 'hosted-engine
>> >> > --deploy'.)
>> >> >
>> >> >   |-   --== NETWORK CONFIGURATION ==--
>> >> >   |-
>> >> >   |- [ ERROR ] Host name is not valid:
>> >> hosted-engine-1.pcstrac.com
>> >> > did not resolve into an IP address
>> >> >   |- [ ERROR ] Failed to execute stage 'Environment
>> >> > customization': Host name is not valid:
>> >> > hosted-engine-1.pcstrac.com did not resolve into an IP address
>> >> >   |- [ INFO  ] Stage: Clean up
>> >> >   |-   Log file is located at
>> >> > /var/log/ovirt-engine/setup/ovirt-engine-setup-20161207193757-6i03xg.log
>> >> >   |- [ INFO  ] Generating answer file
>> >> > '/var/lib/ovirt-engine/setup/answers/20161207193758-setup.conf'
>> >> >   |- [ INFO  ] Stage: Pre-termination
>> >> >   |- [ INFO  ] Stage: Termination
>> >> >   |- [ ERROR ] Execution of setup failed
>> >> >   |- HE_APPLIANCE_ENGINE_SETUP_FAIL
>> >> > [ ERROR ] Engine setup failed on the appliance
>> >> > [ ERROR ] Failed to execute stage 'Closing up': Engine setup
>> >> failed on
>> >> > the appliance Please check its log on the appliance.
>> >> >
>> >> >
>> >> > The one thing I forgot is to update /etc/resolv.conf to include the
>> >> host
>> >> > though I don't know if this matters...
>> >> >
>> >> > Logs attached.
>> >> >
>> >> > I suspect I've very close to having this working but am admittedly
>> >> > stumped.
>> >> >
>> >> > Pointers appreciated.
>> >> >
>> >> > Thanks
>> >> > Mark
>> >> >
>> >> >
>> >> > 

Re: [ovirt-users] [ovirt-devel] [Feture discussion] Full vacuum tool

[Eldad Marciano]

just forgot to mention that no customization required just plug & play he
will collect a large set of informative data by deafult

On Wed, Dec 7, 2016 at 10:54 PM, Eldad Marciano  wrote:

> In terms of measuring I used pgclu couple of times and it powerfull,easy
> to use, and provide very nice HTML reports
> http://pgcluu.darold.net/
>
> And also provide autovacum analysis
> http://pgcluu.darold.net/example/dolibarr-table-vacuums-analyzes.html
>
>
>
> On Wed, Dec 7, 2016 at 9:55 PM, Roy Golan  wrote:
>
>>
>>
>> On 7 December 2016 at 21:44, Roy Golan  wrote:
>>
>>>
>>>
>>> On 7 December 2016 at 21:00, Michal Skrivanek 
>>> wrote:
>>>


 On 07 Dec 2016, at 11:28, Yaniv Kaul  wrote:



 On Wed, Dec 7, 2016 at 10:57 AM, Roy Golan  wrote:

> Hi all,
>
> This is a discussion on the RFE[1] to provide a tool to perform full
> vacuum on our DBs.
>
> First if you are not familiar with vacuum please read this [2]
>
> # Backgroud
> ovirt 'engine' DB have several busy table with 2 differnt usage
> patten. One is audit_log and the others are the 'v*_statistics' tables and
> the difference between them is mostly inserts vs mostly hot updates.
> Tables with tons of updates creates garbage or 'dead' records that
> should be removed, and for this postgres have the aforementioned 
> autovacuum
> cleaner. It will make the db reuse its already allocated space to perform
> future updates/inserts and so on.
> Autovacuum is essential for a db to function optimally and tweaking it
> is out of the scope of the feature.
>
> Full vacuum is designed to reclaim the disk space and reset the table
> statistics. It is a heavy maintenance task, it takes an exclusive lock on
> the table and may take seconds to minutes. In some situations it is
> effectively a downtime due to the long table lock and should not be 
> running
> when the engine is running.
>

 So, effectively this should be interesting mostly/only for the audit
 log. All other busy table are mostly in-place updates

>>>
>>> Given that autovacuum is performing well the yes but if it starts to
>>> fall behind this may help a bit.
>>> audit_log is insert mostly and also delete, we remove a day, each day.
>>>


> # Critiria
> Provide a way to reclaim disk space claimed by the garbage created
> over time by the engine db and dwh.
>
> # Usage
> Either use it as part of the upgrade procedure (after all dbscipts
> execution)
>

 That does sound as a good start not requiring much user involvement

 or just provide the tool and admin will run in on demand
> - engine db credentials read from /etc/ovirt-engine/engine.conf.d/
> - invocation:
>  ```
>  tool: [dbname(default engine)] [table: (default all)]
>  ```
> - if we invoke it on upgrade than an installation plugin should be
> added to invoke with default, no interaction
>

 +1

 - since VACUUM ANALYZE is consider a recommended maintenance task we
> can to it by default and ask the user for FULL.
>

 When would you run it? ANALYZE nightly?

 No I'd still avoid doing this repeatedly, autovaccum should handle that
>>> as well, but this would cover situations where it isn't functioning
>>> optimally.
>>>
>>> I think  its worth adding a report of the db status and the rate of the
>>> autovacuum (a slight midifed version of the query mskrivanek ran on one of
>>> the production systems [3])  that will go to the logcollector. Perhaps the
>>> output of the ANALYZE will help as well.
>>>
>>> [3] https://gist.github.com/rgolangh/049cff30b89c5b29284ceee80a3
>>> 5dbb4#file-table_status_by_dead_rows-sql
>>>
>>
>>
>> Very interesting collection of pg scrips to measure bloat and vacuum -
>> needs access to postgres objects though
>>
>> - https://github.com/pgexperts/pgx_scripts
>> - https://github.com/pgexperts/pgx_scripts/blob/master/bloat/t
>> able_bloat_check.sql
>> - https://github.com/pgexperts/pgx_scripts/blob/master/vacuum/
>> last_autovacuum.sql
>>
>>
>>>
>>>
>
 Will the user know to answer intelligently if vacuum is needed or not?
 Except for 'yes, you need it', we cannot even provide a time estimate (I
 assume a disk space estimate is available!)

 perhaps we can estimate the bloat, there should be a github script to
>>> calculate that [4] not sure how good it is.
>>>
 I would suggest to run ANALYZE for sure and provide an option at the
 end of installation, to run the required command line - so make it as
 accessible as possible, but not part of the flow.


 If there are no significant gains why bother any other time but on
 upgrade when it can be run unconditionally?


 I'm wondering if 

Re: [ovirt-users] [ovirt-devel] [Feture discussion] Full vacuum tool

[Eldad Marciano]

In terms of measuring I used pgclu couple of times and it powerfull,easy to
use, and provide very nice HTML reports
http://pgcluu.darold.net/

And also provide autovacum analysis
http://pgcluu.darold.net/example/dolibarr-table-vacuums-analyzes.html



On Wed, Dec 7, 2016 at 9:55 PM, Roy Golan  wrote:

>
>
> On 7 December 2016 at 21:44, Roy Golan  wrote:
>
>>
>>
>> On 7 December 2016 at 21:00, Michal Skrivanek 
>> wrote:
>>
>>>
>>>
>>> On 07 Dec 2016, at 11:28, Yaniv Kaul  wrote:
>>>
>>>
>>>
>>> On Wed, Dec 7, 2016 at 10:57 AM, Roy Golan  wrote:
>>>
 Hi all,

 This is a discussion on the RFE[1] to provide a tool to perform full
 vacuum on our DBs.

 First if you are not familiar with vacuum please read this [2]

 # Backgroud
 ovirt 'engine' DB have several busy table with 2 differnt usage patten.
 One is audit_log and the others are the 'v*_statistics' tables and the
 difference between them is mostly inserts vs mostly hot updates.
 Tables with tons of updates creates garbage or 'dead' records that
 should be removed, and for this postgres have the aforementioned autovacuum
 cleaner. It will make the db reuse its already allocated space to perform
 future updates/inserts and so on.
 Autovacuum is essential for a db to function optimally and tweaking it
 is out of the scope of the feature.

 Full vacuum is designed to reclaim the disk space and reset the table
 statistics. It is a heavy maintenance task, it takes an exclusive lock on
 the table and may take seconds to minutes. In some situations it is
 effectively a downtime due to the long table lock and should not be running
 when the engine is running.

>>>
>>> So, effectively this should be interesting mostly/only for the audit
>>> log. All other busy table are mostly in-place updates
>>>
>>
>> Given that autovacuum is performing well the yes but if it starts to fall
>> behind this may help a bit.
>> audit_log is insert mostly and also delete, we remove a day, each day.
>>
>>>
>>>
 # Critiria
 Provide a way to reclaim disk space claimed by the garbage created over
 time by the engine db and dwh.

 # Usage
 Either use it as part of the upgrade procedure (after all dbscipts
 execution)

>>>
>>> That does sound as a good start not requiring much user involvement
>>>
>>> or just provide the tool and admin will run in on demand
 - engine db credentials read from /etc/ovirt-engine/engine.conf.d/
 - invocation:
  ```
  tool: [dbname(default engine)] [table: (default all)]
  ```
 - if we invoke it on upgrade than an installation plugin should be
 added to invoke with default, no interaction

>>>
>>> +1
>>>
>>> - since VACUUM ANALYZE is consider a recommended maintenance task we can
 to it by default and ask the user for FULL.

>>>
>>> When would you run it? ANALYZE nightly?
>>>
>>> No I'd still avoid doing this repeatedly, autovaccum should handle that
>> as well, but this would cover situations where it isn't functioning
>> optimally.
>>
>> I think  its worth adding a report of the db status and the rate of the
>> autovacuum (a slight midifed version of the query mskrivanek ran on one of
>> the production systems [3])  that will go to the logcollector. Perhaps the
>> output of the ANALYZE will help as well.
>>
>> [3] https://gist.github.com/rgolangh/049cff30b89c5b29284ceee80a3
>> 5dbb4#file-table_status_by_dead_rows-sql
>>
>
>
> Very interesting collection of pg scrips to measure bloat and vacuum -
> needs access to postgres objects though
>
> - https://github.com/pgexperts/pgx_scripts
> - https://github.com/pgexperts/pgx_scripts/blob/master/bloat/
> table_bloat_check.sql
> - https://github.com/pgexperts/pgx_scripts/blob/master/
> vacuum/last_autovacuum.sql
>
>
>>
>>

>>> Will the user know to answer intelligently if vacuum is needed or not?
>>> Except for 'yes, you need it', we cannot even provide a time estimate (I
>>> assume a disk space estimate is available!)
>>>
>>> perhaps we can estimate the bloat, there should be a github script to
>> calculate that [4] not sure how good it is.
>>
>>> I would suggest to run ANALYZE for sure and provide an option at the end
>>> of installation, to run the required command line - so make it as
>>> accessible as possible, but not part of the flow.
>>>
>>>
>>> If there are no significant gains why bother any other time but on
>>> upgrade when it can be run unconditionally?
>>>
>>>
>>> I'm wondering if the community can run ANALYZE on their database, and we
>>> can estimate how many are in dire need for full vacuum already.
>>> Y.
>>>
>>> I'll send a different mail for that.
>>
>>
>>>
>>> - remote db is supported as well, doesn't have to be local

>>>
>>> Well, not sure if we need to bother. It was introduced for large
>>> deployments where the host can't 

Re: [ovirt-users] Single server hosted engine... almost there

[Mark Steckel]

I tested dnsmasq from the host by

   dig hostname @local-ip

Worked fine.

The engine VM never comes up to the point where I can access it via the 
console...


- Derek Atkins  wrote:
> Hi,
> 
> Ensure dnsmasq is working and can be accessed by the engine VM?
> Log in to the engine VM and test from there?
> Maybe set up *real* DNS?
> 
> -derek
> 
> On Wed, December 7, 2016 3:41 pm, Mark Steckel wrote:
> > Hi Derek,
> >
> > - Derek Atkins  wrote:
> >> Hi Mark,
> >>
> >> The error is correct, hosted-engine-1.pcstrac.com is not a valid
> >> hostname:
> >>
> >> $ host hosted-engine-1.pcstrac.com
> >> $
> >>
> >> I'm lost, tho -- was this an error that occurred on the host during
> >> hosted-engine --deploy, or was it an error that occurred in the hosted
> >> enging VM when running engine-setup?
> >
> > I believe when it occurred when the running the engine-setup.
> >
> >
> >> If the former, you need to ensure that you have a real DNS name for your
> >> ovirt engine.  It's unclear (to me) that using /etc/hosts is sufficient.
> >> However looking at the logs, it looks like it can locally resolve (to
> >> xx.yy.18.122).
> >
> > Yep. I tested things to make sure it could resolve before I started the
> > 'hosted-engine --deploy'.
> >
> >> You might need to answer "Yes" to the /etc/hosts question..
> >
> > I did answer "Yes".
> >
> >
> >> The log seems to get far enough along that it presents you the engine vm
> >> console URL?  It looks like the issue is that the engine vm cannot
> >> resolve
> >> its own name.
> >
> > That is my take as well.
> >
> > Scratching my head as I config'ed dnsmasq to provide local dns and to read
> > from /etc/hosts for hosted-engine-1.pcstrac.com.
> >
> > The only thing I think I flubbed was neglecting to add the host's IP to
> > the host's /etc/resolv.conf.
> >
> > Scrubbing and staring again.
> >
> > Mark
> >
> >
> >>
> >> -derek
> >>
> >> On Wed, December 7, 2016 3:13 pm, Mark Steckel wrote:
> >> > Folks,
> >> >
> >> > Thanks to Didi in another thread I'm making progress. (Lesson learned,
> >> > choose 'disk' and not 'cdrom' when using the he-appliance.)
> >> >
> >> > So I reset to a fresh CentOS 7, installed various software packages
> >> > including ovirt.
> >> >
> >> > I configed eth0 with a /32 public IP. I also added an alias for a
> >> > x.x.x.1/29 on eth0:1.
> >> >
> >> > Finally I config'ed dnsmasq to provide both dhcp and dns (ensuring
> >> that it
> >> > will read from /etc/hosts before forwarding dns requests) and added
> >> the
> >> > IPs and hostsnames to /etc/hosts from the /29 IPs which are to be used
> >> by
> >> > the VMs.
> >> >
> >> > Things proceeded nicely till resolving the he vm fqdn. (I tested to
> >> make
> >> > sure that the he vm fqdm would resolve **Before** I ran 'hosted-engine
> >> > --deploy'.)
> >> >
> >> >   |-   --== NETWORK CONFIGURATION ==--
> >> >   |-
> >> >   |- [ ERROR ] Host name is not valid:
> >> hosted-engine-1.pcstrac.com
> >> > did not resolve into an IP address
> >> >   |- [ ERROR ] Failed to execute stage 'Environment
> >> > customization': Host name is not valid:
> >> > hosted-engine-1.pcstrac.com did not resolve into an IP address
> >> >   |- [ INFO  ] Stage: Clean up
> >> >   |-   Log file is located at
> >> > /var/log/ovirt-engine/setup/ovirt-engine-setup-20161207193757-6i03xg.log
> >> >   |- [ INFO  ] Generating answer file
> >> > '/var/lib/ovirt-engine/setup/answers/20161207193758-setup.conf'
> >> >   |- [ INFO  ] Stage: Pre-termination
> >> >   |- [ INFO  ] Stage: Termination
> >> >   |- [ ERROR ] Execution of setup failed
> >> >   |- HE_APPLIANCE_ENGINE_SETUP_FAIL
> >> > [ ERROR ] Engine setup failed on the appliance
> >> > [ ERROR ] Failed to execute stage 'Closing up': Engine setup
> >> failed on
> >> > the appliance Please check its log on the appliance.
> >> >
> >> >
> >> > The one thing I forgot is to update /etc/resolv.conf to include the
> >> host
> >> > though I don't know if this matters...
> >> >
> >> > Logs attached.
> >> >
> >> > I suspect I've very close to having this working but am admittedly
> >> > stumped.
> >> >
> >> > Pointers appreciated.
> >> >
> >> > Thanks
> >> > Mark
> >> >
> >> >
> >> > ___
> >> > Users mailing list
> >> > Users@ovirt.org
> >> > http://lists.ovirt.org/mailman/listinfo/users
> >> >
> >>
> >>
> >> --
> >>Derek Atkins 617-623-3745
> >>de...@ihtfp.com www.ihtfp.com
> >>Computer and Internet Security Consultant
> >>
> >
> >
> 
> 
> -- 
>Derek Atkins 617-623-3745
>de...@ihtfp.com www.ihtfp.com
>Computer and Internet Security Consultant
> 

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

Re: [ovirt-users] Single server hosted engine... almost there

[Derek Atkins]

Hi,

Ensure dnsmasq is working and can be accessed by the engine VM?
Log in to the engine VM and test from there?
Maybe set up *real* DNS?

-derek

On Wed, December 7, 2016 3:41 pm, Mark Steckel wrote:
> Hi Derek,
>
> - Derek Atkins  wrote:
>> Hi Mark,
>>
>> The error is correct, hosted-engine-1.pcstrac.com is not a valid
>> hostname:
>>
>> $ host hosted-engine-1.pcstrac.com
>> $
>>
>> I'm lost, tho -- was this an error that occurred on the host during
>> hosted-engine --deploy, or was it an error that occurred in the hosted
>> enging VM when running engine-setup?
>
> I believe when it occurred when the running the engine-setup.
>
>
>> If the former, you need to ensure that you have a real DNS name for your
>> ovirt engine.  It's unclear (to me) that using /etc/hosts is sufficient.
>> However looking at the logs, it looks like it can locally resolve (to
>> xx.yy.18.122).
>
> Yep. I tested things to make sure it could resolve before I started the
> 'hosted-engine --deploy'.
>
>> You might need to answer "Yes" to the /etc/hosts question..
>
> I did answer "Yes".
>
>
>> The log seems to get far enough along that it presents you the engine vm
>> console URL?  It looks like the issue is that the engine vm cannot
>> resolve
>> its own name.
>
> That is my take as well.
>
> Scratching my head as I config'ed dnsmasq to provide local dns and to read
> from /etc/hosts for hosted-engine-1.pcstrac.com.
>
> The only thing I think I flubbed was neglecting to add the host's IP to
> the host's /etc/resolv.conf.
>
> Scrubbing and staring again.
>
> Mark
>
>
>>
>> -derek
>>
>> On Wed, December 7, 2016 3:13 pm, Mark Steckel wrote:
>> > Folks,
>> >
>> > Thanks to Didi in another thread I'm making progress. (Lesson learned,
>> > choose 'disk' and not 'cdrom' when using the he-appliance.)
>> >
>> > So I reset to a fresh CentOS 7, installed various software packages
>> > including ovirt.
>> >
>> > I configed eth0 with a /32 public IP. I also added an alias for a
>> > x.x.x.1/29 on eth0:1.
>> >
>> > Finally I config'ed dnsmasq to provide both dhcp and dns (ensuring
>> that it
>> > will read from /etc/hosts before forwarding dns requests) and added
>> the
>> > IPs and hostsnames to /etc/hosts from the /29 IPs which are to be used
>> by
>> > the VMs.
>> >
>> > Things proceeded nicely till resolving the he vm fqdn. (I tested to
>> make
>> > sure that the he vm fqdm would resolve **Before** I ran 'hosted-engine
>> > --deploy'.)
>> >
>> >   |-   --== NETWORK CONFIGURATION ==--
>> >   |-
>> >   |- [ ERROR ] Host name is not valid:
>> hosted-engine-1.pcstrac.com
>> > did not resolve into an IP address
>> >   |- [ ERROR ] Failed to execute stage 'Environment
>> > customization': Host name is not valid:
>> > hosted-engine-1.pcstrac.com did not resolve into an IP address
>> >   |- [ INFO  ] Stage: Clean up
>> >   |-   Log file is located at
>> > /var/log/ovirt-engine/setup/ovirt-engine-setup-20161207193757-6i03xg.log
>> >   |- [ INFO  ] Generating answer file
>> > '/var/lib/ovirt-engine/setup/answers/20161207193758-setup.conf'
>> >   |- [ INFO  ] Stage: Pre-termination
>> >   |- [ INFO  ] Stage: Termination
>> >   |- [ ERROR ] Execution of setup failed
>> >   |- HE_APPLIANCE_ENGINE_SETUP_FAIL
>> > [ ERROR ] Engine setup failed on the appliance
>> > [ ERROR ] Failed to execute stage 'Closing up': Engine setup
>> failed on
>> > the appliance Please check its log on the appliance.
>> >
>> >
>> > The one thing I forgot is to update /etc/resolv.conf to include the
>> host
>> > though I don't know if this matters...
>> >
>> > Logs attached.
>> >
>> > I suspect I've very close to having this working but am admittedly
>> > stumped.
>> >
>> > Pointers appreciated.
>> >
>> > Thanks
>> > Mark
>> >
>> >
>> > ___
>> > Users mailing list
>> > Users@ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/users
>> >
>>
>>
>> --
>>Derek Atkins 617-623-3745
>>de...@ihtfp.com www.ihtfp.com
>>Computer and Internet Security Consultant
>>
>
>


-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

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

Re: [ovirt-users] Single server hosted engine... almost there

[Mark Steckel]

Hi Derek,

- Derek Atkins  wrote:
> Hi Mark,
> 
> The error is correct, hosted-engine-1.pcstrac.com is not a valid hostname:
> 
> $ host hosted-engine-1.pcstrac.com
> $
> 
> I'm lost, tho -- was this an error that occurred on the host during
> hosted-engine --deploy, or was it an error that occurred in the hosted
> enging VM when running engine-setup?

I believe when it occurred when the running the engine-setup.


> If the former, you need to ensure that you have a real DNS name for your
> ovirt engine.  It's unclear (to me) that using /etc/hosts is sufficient.
> However looking at the logs, it looks like it can locally resolve (to
> xx.yy.18.122).

Yep. I tested things to make sure it could resolve before I started the 
'hosted-engine --deploy'.

> You might need to answer "Yes" to the /etc/hosts question..

I did answer "Yes".


> The log seems to get far enough along that it presents you the engine vm
> console URL?  It looks like the issue is that the engine vm cannot resolve
> its own name.

That is my take as well.

Scratching my head as I config'ed dnsmasq to provide local dns and to read from 
/etc/hosts for hosted-engine-1.pcstrac.com.

The only thing I think I flubbed was neglecting to add the host's IP to the 
host's /etc/resolv.conf.

Scrubbing and staring again. 

Mark


> 
> -derek
> 
> On Wed, December 7, 2016 3:13 pm, Mark Steckel wrote:
> > Folks,
> >
> > Thanks to Didi in another thread I'm making progress. (Lesson learned,
> > choose 'disk' and not 'cdrom' when using the he-appliance.)
> >
> > So I reset to a fresh CentOS 7, installed various software packages
> > including ovirt.
> >
> > I configed eth0 with a /32 public IP. I also added an alias for a
> > x.x.x.1/29 on eth0:1.
> >
> > Finally I config'ed dnsmasq to provide both dhcp and dns (ensuring that it
> > will read from /etc/hosts before forwarding dns requests) and added the
> > IPs and hostsnames to /etc/hosts from the /29 IPs which are to be used by
> > the VMs.
> >
> > Things proceeded nicely till resolving the he vm fqdn. (I tested to make
> > sure that the he vm fqdm would resolve **Before** I ran 'hosted-engine
> > --deploy'.)
> >
> >   |-   --== NETWORK CONFIGURATION ==--
> >   |-
> >   |- [ ERROR ] Host name is not valid: hosted-engine-1.pcstrac.com
> > did not resolve into an IP address
> >   |- [ ERROR ] Failed to execute stage 'Environment
> > customization': Host name is not valid:
> > hosted-engine-1.pcstrac.com did not resolve into an IP address
> >   |- [ INFO  ] Stage: Clean up
> >   |-   Log file is located at
> > /var/log/ovirt-engine/setup/ovirt-engine-setup-20161207193757-6i03xg.log
> >   |- [ INFO  ] Generating answer file
> > '/var/lib/ovirt-engine/setup/answers/20161207193758-setup.conf'
> >   |- [ INFO  ] Stage: Pre-termination
> >   |- [ INFO  ] Stage: Termination
> >   |- [ ERROR ] Execution of setup failed
> >   |- HE_APPLIANCE_ENGINE_SETUP_FAIL
> > [ ERROR ] Engine setup failed on the appliance
> > [ ERROR ] Failed to execute stage 'Closing up': Engine setup failed on
> > the appliance Please check its log on the appliance.
> >
> >
> > The one thing I forgot is to update /etc/resolv.conf to include the host
> > though I don't know if this matters...
> >
> > Logs attached.
> >
> > I suspect I've very close to having this working but am admittedly
> > stumped.
> >
> > Pointers appreciated.
> >
> > Thanks
> > Mark
> >
> >
> > ___
> > Users mailing list
> > Users@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
> >
> 
> 
> -- 
>Derek Atkins 617-623-3745
>de...@ihtfp.com www.ihtfp.com
>Computer and Internet Security Consultant
> 

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

Re: [ovirt-users] Single server hosted engine... almost there

[Derek Atkins]

Hi Mark,

The error is correct, hosted-engine-1.pcstrac.com is not a valid hostname:

$ host hosted-engine-1.pcstrac.com
$

I'm lost, tho -- was this an error that occurred on the host during
hosted-engine --deploy, or was it an error that occurred in the hosted
enging VM when running engine-setup?

If the former, you need to ensure that you have a real DNS name for your
ovirt engine.  It's unclear (to me) that using /etc/hosts is sufficient.
However looking at the logs, it looks like it can locally resolve (to
xx.yy.18.122).

You might need to answer "Yes" to the /etc/hosts question..

The log seems to get far enough along that it presents you the engine vm
console URL?  It looks like the issue is that the engine vm cannot resolve
its own name.

-derek

On Wed, December 7, 2016 3:13 pm, Mark Steckel wrote:
> Folks,
>
> Thanks to Didi in another thread I'm making progress. (Lesson learned,
> choose 'disk' and not 'cdrom' when using the he-appliance.)
>
> So I reset to a fresh CentOS 7, installed various software packages
> including ovirt.
>
> I configed eth0 with a /32 public IP. I also added an alias for a
> x.x.x.1/29 on eth0:1.
>
> Finally I config'ed dnsmasq to provide both dhcp and dns (ensuring that it
> will read from /etc/hosts before forwarding dns requests) and added the
> IPs and hostsnames to /etc/hosts from the /29 IPs which are to be used by
> the VMs.
>
> Things proceeded nicely till resolving the he vm fqdn. (I tested to make
> sure that the he vm fqdm would resolve **Before** I ran 'hosted-engine
> --deploy'.)
>
>   |-   --== NETWORK CONFIGURATION ==--
>   |-
>   |- [ ERROR ] Host name is not valid: hosted-engine-1.pcstrac.com
> did not resolve into an IP address
>   |- [ ERROR ] Failed to execute stage 'Environment
> customization': Host name is not valid:
> hosted-engine-1.pcstrac.com did not resolve into an IP address
>   |- [ INFO  ] Stage: Clean up
>   |-   Log file is located at
> /var/log/ovirt-engine/setup/ovirt-engine-setup-20161207193757-6i03xg.log
>   |- [ INFO  ] Generating answer file
> '/var/lib/ovirt-engine/setup/answers/20161207193758-setup.conf'
>   |- [ INFO  ] Stage: Pre-termination
>   |- [ INFO  ] Stage: Termination
>   |- [ ERROR ] Execution of setup failed
>   |- HE_APPLIANCE_ENGINE_SETUP_FAIL
> [ ERROR ] Engine setup failed on the appliance
> [ ERROR ] Failed to execute stage 'Closing up': Engine setup failed on
> the appliance Please check its log on the appliance.
>
>
> The one thing I forgot is to update /etc/resolv.conf to include the host
> though I don't know if this matters...
>
> Logs attached.
>
> I suspect I've very close to having this working but am admittedly
> stumped.
>
> Pointers appreciated.
>
> Thanks
> Mark
>
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>


-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

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

[ovirt-users] Single server hosted engine... almost there

[Mark Steckel]

Folks,

Thanks to Didi in another thread I'm making progress. (Lesson learned, choose 
'disk' and not 'cdrom' when using the he-appliance.)

So I reset to a fresh CentOS 7, installed various software packages including 
ovirt.

I configed eth0 with a /32 public IP. I also added an alias for a x.x.x.1/29 on 
eth0:1.

Finally I config'ed dnsmasq to provide both dhcp and dns (ensuring that it will 
read from /etc/hosts before forwarding dns requests) and added the IPs and 
hostsnames to /etc/hosts from the /29 IPs which are to be used by the VMs.

Things proceeded nicely till resolving the he vm fqdn. (I tested to make sure 
that the he vm fqdm would resolve **Before** I ran 'hosted-engine --deploy'.)

  |-   --== NETWORK CONFIGURATION ==--
  |-  
  |- [ ERROR ] Host name is not valid: hosted-engine-1.pcstrac.com did 
not resolve into an IP address
  |- [ ERROR ] Failed to execute stage 'Environment customization': 
Host name is not valid: hosted-engine-1.pcstrac.com did not resolve into an IP 
address
  |- [ INFO  ] Stage: Clean up
  |-   Log file is located at 
/var/log/ovirt-engine/setup/ovirt-engine-setup-20161207193757-6i03xg.log
  |- [ INFO  ] Generating answer file 
'/var/lib/ovirt-engine/setup/answers/20161207193758-setup.conf'
  |- [ INFO  ] Stage: Pre-termination
  |- [ INFO  ] Stage: Termination
  |- [ ERROR ] Execution of setup failed
  |- HE_APPLIANCE_ENGINE_SETUP_FAIL
[ ERROR ] Engine setup failed on the appliance
[ ERROR ] Failed to execute stage 'Closing up': Engine setup failed on the 
appliance Please check its log on the appliance. 


The one thing I forgot is to update /etc/resolv.conf to include the host though 
I don't know if this matters...

Logs attached.

I suspect I've very close to having this working but am admittedly stumped.

Pointers appreciated.

Thanks
Mark




ovirt-hosted-engine-setup-20161207202846-lzdp1w.log.gz
Description: GNU Zip compressed data


answers-20161207203800.conf.gz
Description: GNU Zip compressed data
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [Feture discussion] Full vacuum tool

[Roy Golan]

On 7 December 2016 at 21:44, Roy Golan  wrote:

>
>
> On 7 December 2016 at 21:00, Michal Skrivanek  wrote:
>
>>
>>
>> On 07 Dec 2016, at 11:28, Yaniv Kaul  wrote:
>>
>>
>>
>> On Wed, Dec 7, 2016 at 10:57 AM, Roy Golan  wrote:
>>
>>> Hi all,
>>>
>>> This is a discussion on the RFE[1] to provide a tool to perform full
>>> vacuum on our DBs.
>>>
>>> First if you are not familiar with vacuum please read this [2]
>>>
>>> # Backgroud
>>> ovirt 'engine' DB have several busy table with 2 differnt usage patten.
>>> One is audit_log and the others are the 'v*_statistics' tables and the
>>> difference between them is mostly inserts vs mostly hot updates.
>>> Tables with tons of updates creates garbage or 'dead' records that
>>> should be removed, and for this postgres have the aforementioned autovacuum
>>> cleaner. It will make the db reuse its already allocated space to perform
>>> future updates/inserts and so on.
>>> Autovacuum is essential for a db to function optimally and tweaking it
>>> is out of the scope of the feature.
>>>
>>> Full vacuum is designed to reclaim the disk space and reset the table
>>> statistics. It is a heavy maintenance task, it takes an exclusive lock on
>>> the table and may take seconds to minutes. In some situations it is
>>> effectively a downtime due to the long table lock and should not be running
>>> when the engine is running.
>>>
>>
>> So, effectively this should be interesting mostly/only for the audit log.
>> All other busy table are mostly in-place updates
>>
>
> Given that autovacuum is performing well the yes but if it starts to fall
> behind this may help a bit.
> audit_log is insert mostly and also delete, we remove a day, each day.
>
>>
>>
>>> # Critiria
>>> Provide a way to reclaim disk space claimed by the garbage created over
>>> time by the engine db and dwh.
>>>
>>> # Usage
>>> Either use it as part of the upgrade procedure (after all dbscipts
>>> execution)
>>>
>>
>> That does sound as a good start not requiring much user involvement
>>
>> or just provide the tool and admin will run in on demand
>>> - engine db credentials read from /etc/ovirt-engine/engine.conf.d/
>>> - invocation:
>>>  ```
>>>  tool: [dbname(default engine)] [table: (default all)]
>>>  ```
>>> - if we invoke it on upgrade than an installation plugin should be added
>>> to invoke with default, no interaction
>>>
>>
>> +1
>>
>> - since VACUUM ANALYZE is consider a recommended maintenance task we can
>>> to it by default and ask the user for FULL.
>>>
>>
>> When would you run it? ANALYZE nightly?
>>
>> No I'd still avoid doing this repeatedly, autovaccum should handle that
> as well, but this would cover situations where it isn't functioning
> optimally.
>
> I think  its worth adding a report of the db status and the rate of the
> autovacuum (a slight midifed version of the query mskrivanek ran on one of
> the production systems [3])  that will go to the logcollector. Perhaps the
> output of the ANALYZE will help as well.
>
> [3] https://gist.github.com/rgolangh/049cff30b89c5b29284ceee80a35db
> b4#file-table_status_by_dead_rows-sql
>


Very interesting collection of pg scrips to measure bloat and vacuum -
needs access to postgres objects though

- https://github.com/pgexperts/pgx_scripts
-
https://github.com/pgexperts/pgx_scripts/blob/master/bloat/table_bloat_check.sql
-
https://github.com/pgexperts/pgx_scripts/blob/master/vacuum/last_autovacuum.sql


>
>
>>>
>> Will the user know to answer intelligently if vacuum is needed or not?
>> Except for 'yes, you need it', we cannot even provide a time estimate (I
>> assume a disk space estimate is available!)
>>
>> perhaps we can estimate the bloat, there should be a github script to
> calculate that [4] not sure how good it is.
>
>> I would suggest to run ANALYZE for sure and provide an option at the end
>> of installation, to run the required command line - so make it as
>> accessible as possible, but not part of the flow.
>>
>>
>> If there are no significant gains why bother any other time but on
>> upgrade when it can be run unconditionally?
>>
>>
>> I'm wondering if the community can run ANALYZE on their database, and we
>> can estimate how many are in dire need for full vacuum already.
>> Y.
>>
>> I'll send a different mail for that.
>
>
>>
>> - remote db is supported as well, doesn't have to be local
>>>
>>
>> Well, not sure if we need to bother. It was introduced for large
>> deployments where the host can't fit both engine and db load. Do we still
>> have this issue? I wouldn't say so for 4.1. It may be very niche case
>>
>> Running full vacuum is anyway a psql command, so there is no hidden cost
> here (to the development side I mean)
>
>
>> Thanks,
>> michal
>>
>>
>>> # Questions
>>>  - Will remote dwh have the credentials under
>>> /etc/ovirt-engine/engine.conf.d?
>>>  - Should  AAA schema be taken into account as well?
>>>
>>> Please review, thanks
>>> Roy
>>>
>>> [1] 

Re: [ovirt-users] [Feture discussion] Full vacuum tool

[Roy Golan]

On 7 December 2016 at 21:00, Michal Skrivanek  wrote:

>
>
> On 07 Dec 2016, at 11:28, Yaniv Kaul  wrote:
>
>
>
> On Wed, Dec 7, 2016 at 10:57 AM, Roy Golan  wrote:
>
>> Hi all,
>>
>> This is a discussion on the RFE[1] to provide a tool to perform full
>> vacuum on our DBs.
>>
>> First if you are not familiar with vacuum please read this [2]
>>
>> # Backgroud
>> ovirt 'engine' DB have several busy table with 2 differnt usage patten.
>> One is audit_log and the others are the 'v*_statistics' tables and the
>> difference between them is mostly inserts vs mostly hot updates.
>> Tables with tons of updates creates garbage or 'dead' records that should
>> be removed, and for this postgres have the aforementioned autovacuum
>> cleaner. It will make the db reuse its already allocated space to perform
>> future updates/inserts and so on.
>> Autovacuum is essential for a db to function optimally and tweaking it is
>> out of the scope of the feature.
>>
>> Full vacuum is designed to reclaim the disk space and reset the table
>> statistics. It is a heavy maintenance task, it takes an exclusive lock on
>> the table and may take seconds to minutes. In some situations it is
>> effectively a downtime due to the long table lock and should not be running
>> when the engine is running.
>>
>
> So, effectively this should be interesting mostly/only for the audit log.
> All other busy table are mostly in-place updates
>

Given that autovacuum is performing well the yes but if it starts to fall
behind this may help a bit.
audit_log is insert mostly and also delete, we remove a day, each day.

>
>
>> # Critiria
>> Provide a way to reclaim disk space claimed by the garbage created over
>> time by the engine db and dwh.
>>
>> # Usage
>> Either use it as part of the upgrade procedure (after all dbscipts
>> execution)
>>
>
> That does sound as a good start not requiring much user involvement
>
> or just provide the tool and admin will run in on demand
>> - engine db credentials read from /etc/ovirt-engine/engine.conf.d/
>> - invocation:
>>  ```
>>  tool: [dbname(default engine)] [table: (default all)]
>>  ```
>> - if we invoke it on upgrade than an installation plugin should be added
>> to invoke with default, no interaction
>>
>
> +1
>
> - since VACUUM ANALYZE is consider a recommended maintenance task we can
>> to it by default and ask the user for FULL.
>>
>
> When would you run it? ANALYZE nightly?
>
> No I'd still avoid doing this repeatedly, autovaccum should handle that as
well, but this would cover situations where it isn't functioning optimally.

I think  its worth adding a report of the db status and the rate of the
autovacuum (a slight midifed version of the query mskrivanek ran on one of
the production systems [3])  that will go to the logcollector. Perhaps the
output of the ANALYZE will help as well.

[3]
https://gist.github.com/rgolangh/049cff30b89c5b29284ceee80a35dbb4#file-table_status_by_dead_rows-sql

>
>>
> Will the user know to answer intelligently if vacuum is needed or not?
> Except for 'yes, you need it', we cannot even provide a time estimate (I
> assume a disk space estimate is available!)
>
> perhaps we can estimate the bloat, there should be a github script to
calculate that [4] not sure how good it is.

> I would suggest to run ANALYZE for sure and provide an option at the end
> of installation, to run the required command line - so make it as
> accessible as possible, but not part of the flow.
>
>
> If there are no significant gains why bother any other time but on upgrade
> when it can be run unconditionally?
>
>
> I'm wondering if the community can run ANALYZE on their database, and we
> can estimate how many are in dire need for full vacuum already.
> Y.
>
> I'll send a different mail for that.


>
> - remote db is supported as well, doesn't have to be local
>>
>
> Well, not sure if we need to bother. It was introduced for large
> deployments where the host can't fit both engine and db load. Do we still
> have this issue? I wouldn't say so for 4.1. It may be very niche case
>
> Running full vacuum is anyway a psql command, so there is no hidden cost
here (to the development side I mean)


> Thanks,
> michal
>
>
>> # Questions
>>  - Will remote dwh have the credentials under
>> /etc/ovirt-engine/engine.conf.d?
>>  - Should  AAA schema be taken into account as well?
>>
>> Please review, thanks
>> Roy
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1388430
>> [2] https://www.postgresql.org/docs/9.2/static/runtime-config-
>> autovacuum.html
>> [3] https://www.postgresql.org/docs/devel/static/sql-vacuum.html
>>
>> ___
>> 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] [Feture discussion] Full vacuum tool

[Michal Skrivanek]

On 07 Dec 2016, at 11:28, Yaniv Kaul  wrote:



On Wed, Dec 7, 2016 at 10:57 AM, Roy Golan  wrote:

> Hi all,
>
> This is a discussion on the RFE[1] to provide a tool to perform full
> vacuum on our DBs.
>
> First if you are not familiar with vacuum please read this [2]
>
> # Backgroud
> ovirt 'engine' DB have several busy table with 2 differnt usage patten.
> One is audit_log and the others are the 'v*_statistics' tables and the
> difference between them is mostly inserts vs mostly hot updates.
> Tables with tons of updates creates garbage or 'dead' records that should
> be removed, and for this postgres have the aforementioned autovacuum
> cleaner. It will make the db reuse its already allocated space to perform
> future updates/inserts and so on.
> Autovacuum is essential for a db to function optimally and tweaking it is
> out of the scope of the feature.
>
> Full vacuum is designed to reclaim the disk space and reset the table
> statistics. It is a heavy maintenance task, it takes an exclusive lock on
> the table and may take seconds to minutes. In some situations it is
> effectively a downtime due to the long table lock and should not be running
> when the engine is running.
>

So, effectively this should be interesting mostly/only for the audit log.
All other busy table are mostly in-place updates


> # Critiria
> Provide a way to reclaim disk space claimed by the garbage created over
> time by the engine db and dwh.
>
> # Usage
> Either use it as part of the upgrade procedure (after all dbscipts
> execution)
>

That does sound as a good start not requiring much user involvement

or just provide the tool and admin will run in on demand
> - engine db credentials read from /etc/ovirt-engine/engine.conf.d/
> - invocation:
>  ```
>  tool: [dbname(default engine)] [table: (default all)]
>  ```
> - if we invoke it on upgrade than an installation plugin should be added
> to invoke with default, no interaction
>

+1

- since VACUUM ANALYZE is consider a recommended maintenance task we can to
> it by default and ask the user for FULL.
>

When would you run it? ANALYZE nightly?


>
Will the user know to answer intelligently if vacuum is needed or not?
Except for 'yes, you need it', we cannot even provide a time estimate (I
assume a disk space estimate is available!)
I would suggest to run ANALYZE for sure and provide an option at the end of
installation, to run the required command line - so make it as accessible
as possible, but not part of the flow.


If there are no significant gains why bother any other time but on upgrade
when it can be run unconditionally?


I'm wondering if the community can run ANALYZE on their database, and we
can estimate how many are in dire need for full vacuum already.
Y.

- remote db is supported as well, doesn't have to be local
>

Well, not sure if we need to bother. It was introduced for large
deployments where the host can't fit both engine and db load. Do we still
have this issue? I wouldn't say so for 4.1. It may be very niche case

Thanks,
michal


> # Questions
>  - Will remote dwh have the credentials under
> /etc/ovirt-engine/engine.conf.d?
>  - Should  AAA schema be taken into account as well?
>
> Please review, thanks
> Roy
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1388430
> [2] https://www.postgresql.org/docs/9.2/static/runtime-
> config-autovacuum.html
> [3] https://www.postgresql.org/docs/devel/static/sql-vacuum.html
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Ovirt 4.0.5 reporting dashboard not working.

[Andrea Ghelardi]

Hello group,
I noticed that my dashboard does not show little colored "cubes" which show 
storage CPU and RAM usage history status.
Attached an image and logs from /var/log/ovirt-engine-dwh/ovirt-engine-dwhd.log
Here's an extract:

Exception in component tJDBCInput_5
org.postgresql.util.PSQLException: ERROR: smallint out of range
at 
org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2157)
at 
org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1886)
at 
org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255)
at 
org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:555)
at 
org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:403)
at 
org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:283)
at 
ovirt_engine_dwh.statisticssync_4_0.StatisticsSync.tJDBCInput_5Process(StatisticsSync.java:4056)
at 
ovirt_engine_dwh.statisticssync_4_0.StatisticsSync$3.run(StatisticsSync.java:15979)
Exception in component tJDBCInput_8
org.postgresql.util.PSQLException: ERROR: current transaction is aborted, 
commands ignored until end of transaction block
at 
org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2157)
at 
org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1886)
at 
org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255)
at 
org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:555)
at 
org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:403)
at 
org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:283)
at 
ovirt_engine_dwh.statisticssync_4_0.StatisticsSync.tJDBCInput_8Process(StatisticsSync.java:5991)
at 
ovirt_engine_dwh.statisticssync_4_0.StatisticsSync$4.run(StatisticsSync.java:16025)
2016-11-27 
14:27:40|tm1tT6|GCXnuH|0jajaj|OVIRT_ENGINE_DWH|StatisticsSync|Default|6|Java 
Exception|tJDBCInput_5|org.postgresql.util.PSQLException:ERROR: smallint out of 
range|1

This is a quite fresh new installation, and restarting engine VM (hosted-engine 
-vm-stop + hosted-engine -vm-start) does not fix the problem.
Ovirt is behaving normally.

Any clue?
Cheers
Andrea



ovirt-engine-dwhd.log
Description: ovirt-engine-dwhd.log
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Mail server migration

[Duck]

Quack,

The old server is going to retire, so we prepared a replacement.
Tomorrow, between 23:30-00:30 JST, the switch will happen. Any mails on
the ovirt.org domain, including mailing-lists, are affected.

We now have backup servers for imcoming mails, so they will not be lost,
but the processing will not occur until the final sync is done and the
switch is over. This should normally take only a few minutes at most.

Fly well.
\_o<



signature.asc
Description: OpenPGP digital signature
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] oVirt HC setup question

[Sven Achtelik]

Hi All,

I'm planning to install oVirt 4 with the HC setup from this blogpost and did a 
demo setup.

http://www.ovirt.org/blog/2016/08/up-and-running-with-ovirt-4-0-and-gluster-storage/

I've managed to install everything just fine and thought that enabling a 
storage network would move all the bricks to that designated network, but it 
didn't do anything. I made that happen by destroying and recreating the volumes 
with entering the ip addresses of the storage network through the cli. Would 
that be the right way to do this ? If that's the case how could I move the 
engine bricks over to that network to get it off my ovirtmgmt bridge ?  Or is 
there may be more prefered way to complete the HC-Setup ?

Thank you,

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

Re: [ovirt-users] web-ui issues

[Maton, Brett]

Cheers Alex,

  The bug is a PITA, but at least an engine restart makes the UI usable if
only for awhile.

  Looking forward to the next 4.0.6 release :)

On 7 December 2016 at 15:36, Alexander Wels  wrote:

> On Tuesday, December 6, 2016 1:42:33 PM EST Maton, Brett wrote:
> > Ok thanks.
> >
> >   I've restarted the ui a few times today, still nothing ( at all ) in
> > ui.log
> >
> >   The errors do look like 'iffy' queries, no errors in PostgreSQL logs
> > though.
> >
>
> Hi Brett,
>
> Some my wonderful team mates worked out the problem [1], apparently it is a
> bug in 4.0.6-3 that should be fixed in the next release.
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1402401
>
> > On 6 December 2016 at 13:28, Alexander Wels  wrote:
> > > On Monday, December 5, 2016 8:49:20 PM EST Maton, Brett wrote:
> > > > Sure here you go:
> > > >
> > > > [image: Inline images 1]
> > > > Close the dialogs and the dashboard fades in, Virtual Machines tab
> > >
> > > doesn't
> > >
> > > > (or I get fed up of closing dialogs before it does)
> > > >
> > > > [image: Inline images 2]
> > >
> > > Interesting, those aren't actually UI failures, those appear to be
> > > failures
> > > from backend requests. As in, get me some data, and the query fails for
> > > some
> > > reason, there should be something in the engine log. Let me dig up the
> > > ones
> > > you posted again and take a closer look.
> > >
> > > > On 5 December 2016 at 20:11, Alexander Wels 
> wrote:
> > > > > On Monday, December 5, 2016 7:11:52 PM EST Maton, Brett wrote:
> > > > > > Yup those are the logs from the hosted engine,
> > > > > >
> > > > > >   ui.log is still empty, all very very odd...
> > > > >
> > > > > Can you send me a screenshot of what you are seeing? As it makes no
> > >
> > > sense
> > >
> > > > > that
> > > > > the UI.log is empty, since the exception handler tries to write to
> the
> > > > > backend
> > > > > UI log.
> > > > >
> > > > > > On 5 December 2016 at 18:12, Alexander Wels 
> > >
> > > wrote:
> > > > > > > On Monday, December 5, 2016 5:41:59 PM EST Maton, Brett wrote:
> > > > > > > > Logs are here
> > > > > > > >  > > > > > >
> > > > > > > 7a4ccbeab673dfda8aa0c38676063b
> > > > > > >
> > > > > > > > 7a=11138>
> > > > > > >
> > > > > > > Are you sure those are the correct logs? The UI.log is empty
> and
> > >
> > > the
> > >
> > > > > other
> > > > >
> > > > > > > logs don't have much of anything in them.
> > > > > > >
> > > > > > > > On 5 December 2016 at 16:57, Alexander Wels <
> aw...@redhat.com>
> > > > >
> > > > > wrote:
> > > > > > > > > On Monday, December 5, 2016 4:55:19 PM EST Maton, Brett
> wrote:
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > >   I tried restarting the browser and clearing the cache
> but
> > > > > > > > > >   I
> > > > >
> > > > > still
> > > > >
> > > > > > > have
> > > > > > >
> > > > > > > > > > the same problem.
> > > > > > > > > >
> > > > > > > > > >   Symbol maps it is then
> > > > > > > > >
> > > > > > > > > To install the symbol maps do the following on the ENGINE:
> > > > > > > > >
> > > > > > > > > 1. yum install ovirt-engine-webadmin-portal-debuginfo
> > > > > > > > > 2. restart engine
> > > > > > > > > 3. Reproduce the problem.
> > > > > > > > > 4. Send me the UI.log from the engine machine.
> > > > > > > > >
> > > > > > > > > > On 5 December 2016 at 16:00, Alexander Wels <
> > >
> > > aw...@redhat.com>
> > >
> > > > > > > wrote:
> > > > > > > > > > > On Sunday, December 4, 2016 5:57:50 PM EST Maton, Brett
> > >
> > > wrote:
> > > > > > > > > > > > Hi Oved,
> > > > > > > > > > > >
> > > > > > > > > > > >   I've upload the logs here
> > > > > > > > > > > >
> > > > > > > > > > > >  > > > > > > > > > >
> > > > > > > > > > > bd24f303b23c2cd393676f0da5c323
> > > > > > > > > > >
> > > > > > > > > > > > d8=10263>
> > > > > > > > > > > >
> > > > > > > > > > > > On 4 December 2016 at 12:25, Oved Ourfali <
> > > > >
> > > > > oourf...@redhat.com>
> > > > >
> > > > > > > > > wrote:
> > > > > > > > > > > > > Please attach complete logs.
> > > > > > > > > > > > > Engine, server and ui logs.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > Oved
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Dec 4, 2016 13:45, "Maton, Brett" <
> > > > >
> > > > > mat...@ltresources.co.uk
> > > > >
> > > > > > > > > wrote:
> > > > > > > > > > > > >> Since I upgraded to 4.0.6-3 I've been having
> problems
> > > > > > > > > > > > >> with
> > > > > > >
> > > > > > > the UI
> > > > > > >
> > > > > > > > > > > > >> When I login the dash board presents a bunch of
> > >
> > > Operation
> > >
> > > > > > > > > > > > >> Canceled
> > > > > > > > > > > > >> dialogs,
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> ! Operation canceled
> > > > > > > > > > > > >>
> > > > > > > 

Re: [ovirt-users] web-ui issues

[Alexander Wels]

On Tuesday, December 6, 2016 1:42:33 PM EST Maton, Brett wrote:
> Ok thanks.
> 
>   I've restarted the ui a few times today, still nothing ( at all ) in
> ui.log
> 
>   The errors do look like 'iffy' queries, no errors in PostgreSQL logs
> though.
> 

Hi Brett,

Some my wonderful team mates worked out the problem [1], apparently it is a 
bug in 4.0.6-3 that should be fixed in the next release.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1402401

> On 6 December 2016 at 13:28, Alexander Wels  wrote:
> > On Monday, December 5, 2016 8:49:20 PM EST Maton, Brett wrote:
> > > Sure here you go:
> > > 
> > > [image: Inline images 1]
> > > Close the dialogs and the dashboard fades in, Virtual Machines tab
> > 
> > doesn't
> > 
> > > (or I get fed up of closing dialogs before it does)
> > > 
> > > [image: Inline images 2]
> > 
> > Interesting, those aren't actually UI failures, those appear to be
> > failures
> > from backend requests. As in, get me some data, and the query fails for
> > some
> > reason, there should be something in the engine log. Let me dig up the
> > ones
> > you posted again and take a closer look.
> > 
> > > On 5 December 2016 at 20:11, Alexander Wels  wrote:
> > > > On Monday, December 5, 2016 7:11:52 PM EST Maton, Brett wrote:
> > > > > Yup those are the logs from the hosted engine,
> > > > > 
> > > > >   ui.log is still empty, all very very odd...
> > > > 
> > > > Can you send me a screenshot of what you are seeing? As it makes no
> > 
> > sense
> > 
> > > > that
> > > > the UI.log is empty, since the exception handler tries to write to the
> > > > backend
> > > > UI log.
> > > > 
> > > > > On 5 December 2016 at 18:12, Alexander Wels 
> > 
> > wrote:
> > > > > > On Monday, December 5, 2016 5:41:59 PM EST Maton, Brett wrote:
> > > > > > > Logs are here
> > > > > > >  > > > > > 
> > > > > > 7a4ccbeab673dfda8aa0c38676063b
> > > > > > 
> > > > > > > 7a=11138>
> > > > > > 
> > > > > > Are you sure those are the correct logs? The UI.log is empty and
> > 
> > the
> > 
> > > > other
> > > > 
> > > > > > logs don't have much of anything in them.
> > > > > > 
> > > > > > > On 5 December 2016 at 16:57, Alexander Wels 
> > > > 
> > > > wrote:
> > > > > > > > On Monday, December 5, 2016 4:55:19 PM EST Maton, Brett wrote:
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > >   I tried restarting the browser and clearing the cache but
> > > > > > > > >   I
> > > > 
> > > > still
> > > > 
> > > > > > have
> > > > > > 
> > > > > > > > > the same problem.
> > > > > > > > > 
> > > > > > > > >   Symbol maps it is then
> > > > > > > > 
> > > > > > > > To install the symbol maps do the following on the ENGINE:
> > > > > > > > 
> > > > > > > > 1. yum install ovirt-engine-webadmin-portal-debuginfo
> > > > > > > > 2. restart engine
> > > > > > > > 3. Reproduce the problem.
> > > > > > > > 4. Send me the UI.log from the engine machine.
> > > > > > > > 
> > > > > > > > > On 5 December 2016 at 16:00, Alexander Wels <
> > 
> > aw...@redhat.com>
> > 
> > > > > > wrote:
> > > > > > > > > > On Sunday, December 4, 2016 5:57:50 PM EST Maton, Brett
> > 
> > wrote:
> > > > > > > > > > > Hi Oved,
> > > > > > > > > > > 
> > > > > > > > > > >   I've upload the logs here
> > > > > > > > > > > 
> > > > > > > > > > >  > > > > > > > > > 
> > > > > > > > > > bd24f303b23c2cd393676f0da5c323
> > > > > > > > > > 
> > > > > > > > > > > d8=10263>
> > > > > > > > > > > 
> > > > > > > > > > > On 4 December 2016 at 12:25, Oved Ourfali <
> > > > 
> > > > oourf...@redhat.com>
> > > > 
> > > > > > > > wrote:
> > > > > > > > > > > > Please attach complete logs.
> > > > > > > > > > > > Engine, server and ui logs.
> > > > > > > > > > > > 
> > > > > > > > > > > > Thanks,
> > > > > > > > > > > > Oved
> > > > > > > > > > > > 
> > > > > > > > > > > > On Dec 4, 2016 13:45, "Maton, Brett" <
> > > > 
> > > > mat...@ltresources.co.uk
> > > > 
> > > > > > > > wrote:
> > > > > > > > > > > >> Since I upgraded to 4.0.6-3 I've been having problems
> > > > > > > > > > > >> with
> > > > > > 
> > > > > > the UI
> > > > > > 
> > > > > > > > > > > >> When I login the dash board presents a bunch of
> > 
> > Operation
> > 
> > > > > > > > > > > >> Canceled
> > > > > > > > > > > >> dialogs,
> > > > > > > > > > > >> 
> > > > > > > > > > > >> 
> > > > > > > > > > > >> ! Operation canceled
> > > > > > > > > > > >> 
> > > > > > > > > > > >> Error while executing query: null
> > > > > > > > > > > >> 
> > > > > > > > > > > >> 
> > > > > > > > > > > >> 
> > > > > > > > > > > >> ! Operation canceled
> > > > > > > > > > > >> 
> > > > > > > > > > > >> Error while executing action: A Request to the Server
> > > > 
> > > > failed:
> > > > > > > > > > > >> java.lang.reflect.InvocationTargetException
> > > > > > > > > > > >> 
> > > > > > > > > > > >> 
> > > > > > > > > > > >> The only error I see in 

Re: [ovirt-users] hosted-engine --deploy hanging, vm not responding

[Mark Steckel]

- Yedidyah Bar David  wrote:
> On Wed, Dec 7, 2016 at 4:46 PM, Mark Steckel  wrote:
> > Log attached.
> >
> > - Yedidyah Bar David  wrote:
> >> On Wed, Dec 7, 2016 at 4:36 PM, Mark Steckel  wrote:
> >> > Folks,
> >> >
> >> > I executed "hosted-engine --deploy" on a fresh CentOS 7.2 install. 
> >> > Before executing the cmd I also installed the he-appliance. (Also ran 
> >> > yum update, installed a few packages and rebooted before doing the 
> >> > hosted engine deploy.)
> >> >
> >> > The process seems to go well but then it hangs here:
> >> >
> >> >   The VM has been started.
> >> >   To continue please install OS and shutdown or reboot the VM.
> >> >
> >> >   Make a selection from the options below:
> >> >   (1) Continue setup - OS installation is complete
> >> >   (2) Abort setup
> >> >   (3) Power off and restart the VM
> >> >   (4) Destroy VM and abort setup
> >> >
> >> >   (1, 2, 3, 4)[1]: 1
> >> >
> >> >   Please reboot or shutdown the VM.
> >> >
> >> >   Verifying shutdown...
> >> >
> >> > From another terminal window I tried accessing the console but received 
> >> > the following:
> >> >
> >> > # hosted-engine --console
> 
> IIRC this now connects you to a serial console, not graphical.

Which is what I was expecting and am comfortable with. (I've very comfortable 
with using kickstart, virsh, virt-install, et al and and a serial console, but 
totally new to OVirt and cloud init.)

> It also told you:
> 
> You can also graphically connect to the VM from your system with the
> following command:
> remote-viewer vnc://dev-vm-host:5900
> 
> Did you try this?

In a previous iteration but without success.


> See also:
> 
> http://www.ovirt.org/documentation/admin-guide/hosted-engine-console/
> 
> However, if this is your first installation, with simple/standard needs,
> it's much simpler to use the appliance. Install the package
> 'ovirt-engine-appliance',
> then choose to boot from 'disk'.

Ah I did install the ovirt-engine-appliance, but choose cdrom and pointed 
it to a Centos 7.2 iso.

Let me reset and try again using the appliance and 'disk'.

My needs are simple, so hopefully this will do the trick.

Thanks
Mark



> 
> Best,
> -- 
> Didi

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

Re: [ovirt-users] hosted-engine --deploy hanging, vm not responding

[Yedidyah Bar David]

On Wed, Dec 7, 2016 at 4:46 PM, Mark Steckel  wrote:
> Log attached.
>
> - Yedidyah Bar David  wrote:
>> On Wed, Dec 7, 2016 at 4:36 PM, Mark Steckel  wrote:
>> > Folks,
>> >
>> > I executed "hosted-engine --deploy" on a fresh CentOS 7.2 install. Before 
>> > executing the cmd I also installed the he-appliance. (Also ran yum update, 
>> > installed a few packages and rebooted before doing the hosted engine 
>> > deploy.)
>> >
>> > The process seems to go well but then it hangs here:
>> >
>> >   The VM has been started.
>> >   To continue please install OS and shutdown or reboot the VM.
>> >
>> >   Make a selection from the options below:
>> >   (1) Continue setup - OS installation is complete
>> >   (2) Abort setup
>> >   (3) Power off and restart the VM
>> >   (4) Destroy VM and abort setup
>> >
>> >   (1, 2, 3, 4)[1]: 1
>> >
>> >   Please reboot or shutdown the VM.
>> >
>> >   Verifying shutdown...
>> >
>> > From another terminal window I tried accessing the console but received 
>> > the following:
>> >
>> > # hosted-engine --console

IIRC this now connects you to a serial console, not graphical.

It also told you:

You can also graphically connect to the VM from your system with the
following command:
remote-viewer vnc://dev-vm-host:5900

Did you try this?

See also:

http://www.ovirt.org/documentation/admin-guide/hosted-engine-console/

However, if this is your first installation, with simple/standard needs,
it's much simpler to use the appliance. Install the package
'ovirt-engine-appliance',
then choose to boot from 'disk'.

Best,
-- 
Didi
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] hosted-engine --deploy hanging, vm not responding

[Mark Steckel]

Folks,

I executed "hosted-engine --deploy" on a fresh CentOS 7.2 install. Before 
executing the cmd I also installed the he-appliance. (Also ran yum update, 
installed a few packages and rebooted before doing the hosted engine deploy.)

The process seems to go well but then it hangs here:

  The VM has been started.
  To continue please install OS and shutdown or reboot the VM.

  Make a selection from the options below:
  (1) Continue setup - OS installation is complete
  (2) Abort setup
  (3) Power off and restart the VM
  (4) Destroy VM and abort setup

  (1, 2, 3, 4)[1]: 1

  Please reboot or shutdown the VM.

  Verifying shutdown...

>From another terminal window I tried accessing the console but received the 
>following:

# hosted-engine --console
The engine VM is running on this host
Connected to domain HostedEngine
Escape character is ^]
error: internal error: character device console0 is not using a PTY

I've also tried option 3 above, but then it comes back with 

Checking for oVirt-Engine status at hosted-engine-1.example.com...
[ INFO  ] Engine is still unreachable
oVirt-Engine health status page is not yet reachable.

I am admittedly mystified at this point.

Any ideas?

Thanks
Mark

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

Re: [ovirt-users] [Call for feedback] anybody gave 4.1 beta a try?

[Gianluca Cecchi]

On Tue, Dec 6, 2016 at 9:38 AM, Sandro Bonazzola 
wrote:

> Hi,
> any feedback on 4.1 beta we released last week?
> Thanks,
>
>
>
I see that in storage tab the NFS domain is marked as V4, while in 4.0.5 is
marked as V3.
The nfs mount from host is still v3, but I think it is not related and
instead V4 refers to functionalities of storage domain itself...
In this case, where to find V3 vs V4 storage domain features?

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

Re: [ovirt-users] [Call for feedback] anybody gave 4.1 beta a try?

[Joop]

On 6-12-2016 9:38, Sandro Bonazzola wrote:
> Hi,
> any feedback on 4.1 beta we released last week?
> Thanks,
>
> -
I upgraded from 4.0 to 4.1pre yesterday and had a couple of problems
that I think are of my own doing.
I'm running hosted-engine on my laptop with a NFS data domain (I know
about the deadlock possibility)
Host OS was FC23 and needed to be upped to FC24 and the engine is
running Centos-7.2 so no changes.
Updated the engine first and then updated my fedora version. That went
well except that it complained about I think vdsm needing a version that
conflicted with an existing one (libvirt-client).
After allowing the update to erase the problematic packages I ended up
with another slight problem but fixed that by deinstalling the
problematic packages and reinstalling hosted-engine. I ofcourse lost the
configuration files but they are all saved as *.rpmsave.
Finding those files and moving them back into place and reinstalling
hosted-engine-ha-setup and hosted-engine-ha fixed most of not all
problems (systemd autostarting services). Restarting my system and
everything came backup up :-)
Next up is testing all those shiny new items.

Joop

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

Re: [ovirt-users] Renaming hosted engine

[Nikolai Sednev]

No, I did not tested that. 
I did not renamed my HE. 



Thanks in advance. 

Best regards, 
Nikolai 
 
Nikolai Sednev 
Senior Quality Engineer at Compute team 
Red Hat Israel 
34 Jerusalem Road, 
Ra'anana, Israel 43501 

Tel: +972 9 7692043 
Mobile: +972 52 7342734 
Email: nsed...@redhat.com 
IRC: nsednev 

- Original Message -

From: "Yedidyah Bar David"  
To: "Luca 'remix_tj' Lorenzetto" , "Nikolai Sednev" 
 
Cc: "users"  
Sent: Wednesday, December 7, 2016 1:06:00 PM 
Subject: Re: [ovirt-users] Renaming hosted engine 

On Wed, Dec 7, 2016 at 12:20 PM, Luca 'remix_tj' Lorenzetto 
 wrote: 
> Hello, 
> 
> On Wed, Dec 7, 2016 at 10:53 AM, Yedidyah Bar David  wrote: 
> [cut] 
>> 
>> If you have another host, you can migrate all VMs to the other host, 
>> move current to maintenance, remove it, then add it with the new name 
>> you want. You might have to also clean up the shared meta-data, see: 
>> 
>> https://www.ovirt.org/documentation/how-to/hosted-engine/#remove-old-host-from-the-metadata-whiteboard
>>  
>> 
> 
> from your response i understood that i was using the wrong terms for 
> explaining my need. 
> 
> What i'm willing to change the fqdn of the engine vm running on hosted 
> engine. I've seen that the deployment procedure asked for it, so i 
> think somewhere this value is used for configurations. 

Indeed. I do not think we have a tested procedure for renaming 
a hosted-engine. 

The rename tool [1] will not handle this. 

Nikolai - IIRC we discussed this some months ago. Did you eventually 
test this? 

You can run the tool, but then ha-agent will fail to connect to the engine 
to see that it's alive. 

To answer your question: This is saved in a file called hosted-engine.conf, 
as 'fqdn='. Until 3.5, this file was only saved locally on each host in 
/etc/hosted-engine. Since 3.6, it's also saved in the shared storage. 
You can try extracting it from the shared storage, edit, then update. 
See e.g. [2] for how to do this, but that one is for a different file 
(the answer file, also saved in both /etc and the shared storage). 

I now read parts of the relevant code, and AFAICT we do not use fqdn 
from the shared storage, only from the one in /etc. So it might be 
enough to change there (although you risk that this will change in 
a future version). 

Please open a bug about this. If you try the above, please tell us if 
it worked or not and what problems/errors you got. Thanks! 

[1] 
https://www.ovirt.org/documentation/how-to/networking/changing-engine-hostname/ 
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1366879#c23 

> 
> Thank you anyway for the link, 
> 
> Luca 
> 
> -- 
> "E' assurdo impiegare gli uomini di intelligenza eccellente per fare 
> calcoli che potrebbero essere affidati a chiunque se si usassero delle 
> macchine" 
> Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716) 
> 
> "Internet è la più grande biblioteca del mondo. 
> Ma il problema è che i libri sono tutti sparsi sul pavimento" 
> John Allen Paulos, Matematico (1945-vivente) 
> 
> Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , 
>  



-- 
Didi 

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

Re: [ovirt-users] Fwd: web-ui issues

[Oved Ourfali]

We are looking into the issue.
>From what I saw this is specific in the VMs tab, so we're trying to
understand what might have caused it.

Thanks,
Oved


On Wed, Dec 7, 2016 at 1:21 PM, Maton, Brett 
wrote:

> This didn't get sent to the list...
>
> -- Forwarded message --
> From: Alexander Wels 
> Date: 6 December 2016 at 16:43
> Subject: Re: [ovirt-users] web-ui issues
> To: "Maton, Brett" 
>
>
> On Tuesday, December 6, 2016 4:41:35 PM EST you wrote:
> > Not odd at all, but yes it does work for awhile before 'dying' again
> >
>
> Great, then I have a system here that is reproducing your issue that I can
> mess with. I will let you know if I find a solution.
>
> > On 6 December 2016 at 16:13, Alexander Wels  wrote:
> > > On Tuesday, December 6, 2016 2:49:55 PM EST you wrote:
> > > > No change...
> > > >
> > > > The 'portal' welcome page does say:
> > > >
> > > > Welcome to Open Virtualization Manager Version 4.0.6.2-1.el7.centos
> > > >
> > > > I would have expected it to have moved to 4.0.6.3
> > > > I've run engine-setup ( a few times ) and yum upgrade isn't finding
> any
> > >
> > > new
> > >
> > > > packages
> > >
> > > Another odd question, if you restart the engine (systemctl restart
> ovirt-
> > > engine) and immediately log back in, does that 'fix' the issue for a
> few
> > > minutes and does it re-appear after that? Or a restart never fixes it
> at
> > > all?
> > >
> > > > On 6 December 2016 at 14:40, Alexander Wels 
> wrote:
> > > > > On Tuesday, December 6, 2016 2:29:39 PM EST you wrote:
> > > > > > I'm not holding my breath as I had the problem before installing
> > >
> > > symbol
> > >
> > > > > > maps, but it might explain why ui.log is empty
> > > > >
> > > > > Well the bugzilla is basically the following scenario:
> > > > >
> > > > > 1. You have oVirt version X and you have the matching debug symbols
> > > > > installed.
> > > > > 2. You upgrade oVirt version to X+1. This doesn't upgrade the debug
> > > > > symbols.
> > > > > 3. You get the interrupted message on your screen.
> > > > >
> > > > > So uninstalling the debug symbols should fix that scenario, if
> yours
> > >
> > > was
> > >
> > > > > not
> > > > > that scenario then you are right it won't change anything. But it
> > > > > can't
> > > > > hurt
> > > > > either.
> > > > >
> > > > > > On 6 December 2016 at 14:26, Alexander Wels 
> > >
> > > wrote:
> > > > > > > On Tuesday, December 6, 2016 2:22:38 PM EST you wrote:
> > > > > > > > I 'bumped' from 4.0.6-2 to 4.0.6-3 ( yum upgrade )
> > > > > > >
> > > > > > > So someone just opened a bugzilla with a sympton that looks
> > > > >
> > > > > suspiciously
> > > > >
> > > > > > > like
> > > > > > > yours, and the resolution to that bugzilla was to REMOVE the
> > > > > > > symbolMaps
> > > > > > > because they were out of sync with the main application (and
> doing
> > >
> > > a
> > >
> > > > > yum
> > > > >
> > > > > > > update isn't automatically updating the symbol maps).
> > > > > > >
> > > > > > > try this:
> > > > > > >
> > > > > > > yum remove ovirt-engine-webadmin-portal-debuginfo
> > > > > > >
> > > > > > > And restart the engine, see if that solves your issue.
> > > > > > >
> > > > > > > > On 6 December 2016 at 14:21, Alexander Wels <
> aw...@redhat.com>
> > > > >
> > > > > wrote:
> > > > > > > > > On Tuesday, December 6, 2016 1:42:33 PM EST you wrote:
> > > > > > > > > > Ok thanks.
> > > > > > > > > >
> > > > > > > > > >   I've restarted the ui a few times today, still nothing
> (
> > > > > > > > > >   at
> > > > >
> > > > > all )
> > > > >
> > > > > > > in
> > > > > > >
> > > > > > > > > > ui.log
> > > > > > > > > >
> > > > > > > > > >   The errors do look like 'iffy' queries, no errors in
> > > > > > > > > >   PostgreSQL
> > > > > > >
> > > > > > > logs
> > > > > > >
> > > > > > > > > > though.
> > > > > > > > >
> > > > > > > > > Strange question, did you recently upgrade from a previous
> > >
> > > version
> > >
> > > > > of
> > > > >
> > > > > > > > > oVirt?
> > > > > > > > >
> > > > > > > > > > On 6 December 2016 at 13:28, Alexander Wels <
> > >
> > > aw...@redhat.com>
> > >
> > > > > > > wrote:
> > > > > > > > > > > On Monday, December 5, 2016 8:49:20 PM EST Maton, Brett
> > >
> > > wrote:
> > > > > > > > > > > > Sure here you go:
> > > > > > > > > > > >
> > > > > > > > > > > > [image: Inline images 1]
> > > > > > > > > > > > Close the dialogs and the dashboard fades in, Virtual
> > > > >
> > > > > Machines
> > > > >
> > > > > > > tab
> > > > > > >
> > > > > > > > > > > doesn't
> > > > > > > > > > >
>
> > > > > > > > > > > > (or I get fed up of closing dialogs before it does)
> > > > > > > > > > > >
> > > > > > > > > > > > [image: Inline images 2]
> > > > > > > > > > >
> > > > > > > > > > > Interesting, those aren't actually UI failures, those
> > >
> > > appear
> > >
> > > > > to be
> > > > >
> > > > > > > > > > > failures

[ovirt-users] Fwd: web-ui issues

[Maton, Brett]

This didn't get sent to the list...

-- Forwarded message --
From: Alexander Wels 
Date: 6 December 2016 at 16:43
Subject: Re: [ovirt-users] web-ui issues
To: "Maton, Brett" 


On Tuesday, December 6, 2016 4:41:35 PM EST you wrote:
> Not odd at all, but yes it does work for awhile before 'dying' again
>

Great, then I have a system here that is reproducing your issue that I can
mess with. I will let you know if I find a solution.

> On 6 December 2016 at 16:13, Alexander Wels  wrote:
> > On Tuesday, December 6, 2016 2:49:55 PM EST you wrote:
> > > No change...
> > >
> > > The 'portal' welcome page does say:
> > >
> > > Welcome to Open Virtualization Manager Version 4.0.6.2-1.el7.centos
> > >
> > > I would have expected it to have moved to 4.0.6.3
> > > I've run engine-setup ( a few times ) and yum upgrade isn't finding
any
> >
> > new
> >
> > > packages
> >
> > Another odd question, if you restart the engine (systemctl restart
ovirt-
> > engine) and immediately log back in, does that 'fix' the issue for a few
> > minutes and does it re-appear after that? Or a restart never fixes it at
> > all?
> >
> > > On 6 December 2016 at 14:40, Alexander Wels  wrote:
> > > > On Tuesday, December 6, 2016 2:29:39 PM EST you wrote:
> > > > > I'm not holding my breath as I had the problem before installing
> >
> > symbol
> >
> > > > > maps, but it might explain why ui.log is empty
> > > >
> > > > Well the bugzilla is basically the following scenario:
> > > >
> > > > 1. You have oVirt version X and you have the matching debug symbols
> > > > installed.
> > > > 2. You upgrade oVirt version to X+1. This doesn't upgrade the debug
> > > > symbols.
> > > > 3. You get the interrupted message on your screen.
> > > >
> > > > So uninstalling the debug symbols should fix that scenario, if yours
> >
> > was
> >
> > > > not
> > > > that scenario then you are right it won't change anything. But it
> > > > can't
> > > > hurt
> > > > either.
> > > >
> > > > > On 6 December 2016 at 14:26, Alexander Wels 
> >
> > wrote:
> > > > > > On Tuesday, December 6, 2016 2:22:38 PM EST you wrote:
> > > > > > > I 'bumped' from 4.0.6-2 to 4.0.6-3 ( yum upgrade )
> > > > > >
> > > > > > So someone just opened a bugzilla with a sympton that looks
> > > >
> > > > suspiciously
> > > >
> > > > > > like
> > > > > > yours, and the resolution to that bugzilla was to REMOVE the
> > > > > > symbolMaps
> > > > > > because they were out of sync with the main application (and
doing
> >
> > a
> >
> > > > yum
> > > >
> > > > > > update isn't automatically updating the symbol maps).
> > > > > >
> > > > > > try this:
> > > > > >
> > > > > > yum remove ovirt-engine-webadmin-portal-debuginfo
> > > > > >
> > > > > > And restart the engine, see if that solves your issue.
> > > > > >
> > > > > > > On 6 December 2016 at 14:21, Alexander Wels 
> > > >
> > > > wrote:
> > > > > > > > On Tuesday, December 6, 2016 1:42:33 PM EST you wrote:
> > > > > > > > > Ok thanks.
> > > > > > > > >
> > > > > > > > >   I've restarted the ui a few times today, still nothing (
> > > > > > > > >   at
> > > >
> > > > all )
> > > >
> > > > > > in
> > > > > >
> > > > > > > > > ui.log
> > > > > > > > >
> > > > > > > > >   The errors do look like 'iffy' queries, no errors in
> > > > > > > > >   PostgreSQL
> > > > > >
> > > > > > logs
> > > > > >
> > > > > > > > > though.
> > > > > > > >
> > > > > > > > Strange question, did you recently upgrade from a previous
> >
> > version
> >
> > > > of
> > > >
> > > > > > > > oVirt?
> > > > > > > >
> > > > > > > > > On 6 December 2016 at 13:28, Alexander Wels <
> >
> > aw...@redhat.com>
> >
> > > > > > wrote:
> > > > > > > > > > On Monday, December 5, 2016 8:49:20 PM EST Maton, Brett
> >
> > wrote:
> > > > > > > > > > > Sure here you go:
> > > > > > > > > > >
> > > > > > > > > > > [image: Inline images 1]
> > > > > > > > > > > Close the dialogs and the dashboard fades in, Virtual
> > > >
> > > > Machines
> > > >
> > > > > > tab
> > > > > >
> > > > > > > > > > doesn't
> > > > > > > > > >
> > > > > > > > > > > (or I get fed up of closing dialogs before it does)
> > > > > > > > > > >
> > > > > > > > > > > [image: Inline images 2]
> > > > > > > > > >
> > > > > > > > > > Interesting, those aren't actually UI failures, those
> >
> > appear
> >
> > > > to be
> > > >
> > > > > > > > > > failures
> > > > > > > > > > from backend requests. As in, get me some data, and the
> >
> > query
> >
> > > > > > > > > > fails
> > > > > > > > > > for
> > > > > > > > > > some
> > > > > > > > > > reason, there should be something in the engine log. Let
> > > > > > > > > > me
> > > >
> > > > dig up
> > > >
> > > > > > the
> > > > > >
> > > > > > > > > > ones
> > > > > > > > > > you posted again and take a closer look.
> > > > > > > > > >
> > > > > > > > > > > On 5 December 2016 at 20:11, Alexander Wels <
> > > >
> > > > aw...@redhat.com>
> > > >
> > 

Re: [ovirt-users] web-ui issues

[Pavel Gashev]

I see exactly the same issue in ovirt-engine-4.0.6.2-1
Please note the issue produces no logs in /var/log/ovirt-engine/*log


From:  on behalf of "Maton, Brett" 

Date: Tuesday 6 December 2016 at 16:42
To: Alexander Wels 
Cc: Ovirt Users 
Subject: Re: [ovirt-users] web-ui issues

Ok thanks.
  I've restarted the ui a few times today, still nothing ( at all ) in ui.log
  The errors do look like 'iffy' queries, no errors in PostgreSQL logs though.

On 6 December 2016 at 13:28, Alexander Wels 
> wrote:
On Monday, December 5, 2016 8:49:20 PM EST Maton, Brett wrote:
> Sure here you go:
>
> [image: Inline images 1]
> Close the dialogs and the dashboard fades in, Virtual Machines tab doesn't
> (or I get fed up of closing dialogs before it does)
>
> [image: Inline images 2]
>

Interesting, those aren't actually UI failures, those appear to be failures
from backend requests. As in, get me some data, and the query fails for some
reason, there should be something in the engine log. Let me dig up the ones
you posted again and take a closer look.

> On 5 December 2016 at 20:11, Alexander Wels 
> > wrote:
> > On Monday, December 5, 2016 7:11:52 PM EST Maton, Brett wrote:
> > > Yup those are the logs from the hosted engine,
> > >
> > >   ui.log is still empty, all very very odd...
> >
> > Can you send me a screenshot of what you are seeing? As it makes no sense
> > that
> > the UI.log is empty, since the exception handler tries to write to the
> > backend
> > UI log.
> >
> > > On 5 December 2016 at 18:12, Alexander Wels 
> > > > wrote:
> > > > On Monday, December 5, 2016 5:41:59 PM EST Maton, Brett wrote:
> > > > > Logs are here
> > > > >  > > >
> > > > 7a4ccbeab673dfda8aa0c38676063b
> > > >
> > > > > 7a=11138>
> > > >
> > > > Are you sure those are the correct logs? The UI.log is empty and the
> >
> > other
> >
> > > > logs don't have much of anything in them.
> > > >
> > > > > On 5 December 2016 at 16:57, Alexander Wels 
> > > > > >
> >
> > wrote:
> > > > > > On Monday, December 5, 2016 4:55:19 PM EST Maton, Brett wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > >   I tried restarting the browser and clearing the cache but I
> >
> > still
> >
> > > > have
> > > >
> > > > > > > the same problem.
> > > > > > >
> > > > > > >   Symbol maps it is then
> > > > > >
> > > > > > To install the symbol maps do the following on the ENGINE:
> > > > > >
> > > > > > 1. yum install ovirt-engine-webadmin-portal-debuginfo
> > > > > > 2. restart engine
> > > > > > 3. Reproduce the problem.
> > > > > > 4. Send me the UI.log from the engine machine.
> > > > > >
> > > > > > > On 5 December 2016 at 16:00, Alexander Wels 
> > > > > > > >
> > > >
> > > > wrote:
> > > > > > > > On Sunday, December 4, 2016 5:57:50 PM EST Maton, Brett wrote:
> > > > > > > > > Hi Oved,
> > > > > > > > >
> > > > > > > > >   I've upload the logs here
> > > > > > > > >
> > > > > > > > >  > > > > > > >
> > > > > > > > bd24f303b23c2cd393676f0da5c323
> > > > > > > >
> > > > > > > > > d8=10263>
> > > > > > > > >
> > > > > > > > > On 4 December 2016 at 12:25, Oved Ourfali <
> >
> > oourf...@redhat.com>
> >
> > > > > > wrote:
> > > > > > > > > > Please attach complete logs.
> > > > > > > > > > Engine, server and ui logs.
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > > Oved
> > > > > > > > > >
> > > > > > > > > > On Dec 4, 2016 13:45, "Maton, Brett" <
> >
> > mat...@ltresources.co.uk
> >
> > > > > > wrote:
> > > > > > > > > >> Since I upgraded to 4.0.6-3 I've been having problems
> > > > > > > > > >> with
> > > >
> > > > the UI
> > > >
> > > > > > > > > >> When I login the dash board presents a bunch of Operation
> > > > > > > > > >> Canceled
> > > > > > > > > >> dialogs,
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >> ! Operation canceled
> > > > > > > > > >>
> > > > > > > > > >> Error while executing query: null
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >> ! Operation canceled
> > > > > > > > > >>
> > > > > > > > > >> Error while executing action: A Request to the Server
> >
> > failed:
> > > > > > > > > >> java.lang.reflect.InvocationTargetException
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >> The only error I see in engine.log is
> > > > > > > > > >>
> > > > > > > > > >> 2016-12-04 11:34:07,945 INFO
> >
> > [org.ovirt.engine.docs.utils.s
> >
> > > > > > > > > >> ervlet.ContextSensitiveHelpMappingServlet] (default
> >
> > task-1)
> >
> > > > []
> > > >
> > > > > > > > > >> Context-sensitive help is not installed. Manual directory

Re: [ovirt-users] Hosted-engine --deploy FQDN questions

[Yedidyah Bar David]

On Wed, Dec 7, 2016 at 12:26 PM, Mark Steckel  wrote:
> Yedidyah - very helpful! Thanks.
>
> A follow-up question re the FQDN for the hosted engine: My understanding is 
> that the FQDN must be resolvable when "hosted-engine --deploy" is executed. 
> However, should the IP that the FQDN resolves to also be assigned/up when 
> "hosted-engine --deploy" is executed?

When deploying the first host, this IP can't be up, as the engine vm
does not exist yet.

And, BTW, it indeed needs to be resolvable, but you can change the address
between this prompt and the actual point where we try to connect to it. So
if you can't control the address (say, you use dhcp, and either do not
control it or do not want to use static reservations), you can do something
like this:

1. Choose a fqdn for the engine, add it to /etc/hosts with a fake address
2. Start deploy
3. When the engine vm is up, and got an IP address, edit /etc/hosts on
the host to point to this address
4. Continue as usual.

No need for this if you do control dhcp - you can choose a MAC address,
add a static reservation for it, and supply it when prompted.

>
>
>
> - Yedidyah Bar David  wrote:
>> On Wed, Dec 7, 2016 at 11:36 AM, Mark Steckel  wrote:
>> > Marcin,
>> >
>> > - Marcin Mirecki  wrote:
>> >> Mark,
>> >>
>> >> >   Enter the name which will be used to identify this host 
>> >> > inside the
>> >> >   Administrator Portal [hosted_engine_1]:
>> >>
>> >> This is the name used for the host inside the Administrator Portal, so 
>> >> basically
>> >> the name of the VM inside the system.
>> >> This does not have to be the hostname, but there are also no objection 
>> >> for it.
>> >>
>> >>
>> >> >   Engine FQDN:  []:
>> >> Yes, you are correct. This must be the FQDN of the host, resolvable to IP.
>> >> This fqdn will be used to access the administration portal.
>> >
>> > If I understand you correctly, both questions apply to the hosted engine 
>> > vm. Correct?
>>
>> No.
>>
>> The first question is about the host, but not about its address or dns name.
>> It's about the name it will have in the engine, the one you see in the admin 
>> ui,
>> in "Hosts", as "Name". After too many questions about this question, we 
>> decided
>> to remove it, and in 4.1 it will simply default to the hostname. You'll 
>> still be
>> able to set it by manually editing the answer file or passing otopi
>> env, but will
>> not be prompted for it.
>>
>> The second question is indeed about the name that will be used to access
>> the engine vm.
>>
>> Then there is a third item, which we do not ask about: The name that the
>> engine should use to access the host. This is what you see in the admin ui,
>> in "Hostname/IP". This item is determined the following way, for the first
>> host: You are prompted for a NIC to use for the management bridge, we check
>> the IP address of this NIC, then do a reverse-lookup (gethostbyaddr) on this
>> address, and use the result. So you should make sure that this nic has an
>> IP address, that this address has a name (in /etc/hosts or dns), and that
>> this name will also be resolvable and point to the host, when used inside
>> the engine vm (again, by either using dns or manually setting it in
>> /etc/hosts there).
>>
>> >
>> > (If so, I'm glad I asked, because I initially and incorrectly thought that 
>> > the first question referred to the bare metal machine that hosts the 
>> > hosted engine vm.)
>>
>> Hopefully the above clarifies this. Please do not hesitate to ask if
>> there are still questions. Also, suggestions for better texts, to make
>> this simpler for the admin, are more than welcome! :-)
>>
>> Best,
>>
>> >
>> > Thanks
>> > Mark
>> >
>> >
>> >
>> >>
>> >> Marcin
>> >>
>> >>
>> >> - Original Message -
>> >> > From: "Mark Steckel" 
>> >> > To: users@ovirt.org
>> >> > Sent: Wednesday, December 7, 2016 6:08:38 AM
>> >> > Subject: [ovirt-users] Hosted-engine --deploy FQDN questions
>> >> >
>> >> > Folks,
>> >> >
>> >> > I'm an OVirt newbie having troubles setting up my first Hosted Engine 
>> >> > and am
>> >> > stumbling. In this case I think it may be because of the following two
>> >> > set-up questions.
>> >> >
>> >> >   Enter the name which will be used to identify this host 
>> >> > inside the
>> >> >   Administrator Portal [hosted_engine_1]:
>> >> >   Please provide the FQDN for the engine you would like to use.
>> >> >   This needs to match the FQDN that you will use for the engine
>> >> >   installation within the VM.
>> >> >   Note: This will be the FQDN of the VM you are now going to 
>> >> > create,
>> >> >   it should not point to the base host or to any other existing
>> >> >   machine.
>> >> >   Engine FQDN:  []:
>> >> >
>> >> > My read of this is that the first question is asking for the name of the
>> >> > host, while the second question 

Re: [ovirt-users] Renaming hosted engine

[Yedidyah Bar David]

On Wed, Dec 7, 2016 at 12:20 PM, Luca 'remix_tj' Lorenzetto
 wrote:
> Hello,
>
> On Wed, Dec 7, 2016 at 10:53 AM, Yedidyah Bar David  wrote:
> [cut]
>>
>> If you have another host, you can migrate all VMs to the other host,
>> move current to maintenance, remove it, then add it with the new name
>> you want. You might have to also clean up the shared meta-data, see:
>>
>> https://www.ovirt.org/documentation/how-to/hosted-engine/#remove-old-host-from-the-metadata-whiteboard
>>
>
> from your response i understood that i was using the wrong terms for
> explaining my need.
>
> What i'm willing to change the fqdn of the engine vm running on hosted
> engine. I've seen that the deployment procedure asked for it, so i
> think somewhere  this value is used for configurations.

Indeed. I do not think we have a tested procedure for renaming
a hosted-engine.

The rename tool [1] will not handle this.

Nikolai - IIRC we discussed this some months ago. Did you eventually
test this?

You can run the tool, but then ha-agent will fail to connect to the engine
to see that it's alive.

To answer your question: This is saved in a file called hosted-engine.conf,
as 'fqdn='. Until 3.5, this file was only saved locally on each host in
/etc/hosted-engine. Since 3.6, it's also saved in the shared storage.
You can try extracting it from the shared storage, edit, then update.
See e.g. [2] for how to do this, but that one is for a different file
(the answer file, also saved in both /etc and the shared storage).

I now read parts of the relevant code, and AFAICT we do not use fqdn
from the shared storage, only from the one in /etc. So it might be
enough to change there (although you risk that this will change in
a future version).

Please open a bug about this. If you try the above, please tell us if
it worked or not and what problems/errors you got. Thanks!

[1] 
https://www.ovirt.org/documentation/how-to/networking/changing-engine-hostname/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1366879#c23

>
> Thank you anyway for the link,
>
> Luca
>
> --
> "E' assurdo impiegare gli uomini di intelligenza eccellente per fare
> calcoli che potrebbero essere affidati a chiunque se si usassero delle
> macchine"
> Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716)
>
> "Internet è la più grande biblioteca del mondo.
> Ma il problema è che i libri sono tutti sparsi sul pavimento"
> John Allen Paulos, Matematico (1945-vivente)
>
> Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , 
> 



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

Re: [ovirt-users] [Call for feedback] anybody gave 4.1 beta a try?

[Gianluca Cecchi]

On Tue, Dec 6, 2016 at 9:51 PM, Gianluca Cecchi 
wrote:

>
>
> Here the HostedEngine.log generated under /var/log/libvirt/qemu
>
> https://drive.google.com/file/d/0BwoPbcrMv8mvZ0V5RTFBZXJfMzA/
> view?usp=sharing
>
> I see at the end of it the line
>
> warning: host doesn't support requested feature: CPUID.07H:EBX.erms [bit 9]
>
>
>
It seems this second problem was due to qemu-kvm 2.6 too restrictive
So I reverted to 2.3:

Downgrading:
 qemu-img-ev  x86_64   10:2.3.0-31.el7_2.21.1
ovirt-4.1-pre   791 k
 qemu-kvm-common-ev   x86_64   10:2.3.0-31.el7_2.21.1
ovirt-4.1-pre   449 k
 qemu-kvm-ev  x86_64   10:2.3.0-31.el7_2.21.1
ovirt-4.1-pre   2.1 M
 qemu-kvm-tools-evx86_64   10:2.3.0-31.el7_2.21.1
ovirt-4.1-pre   250 k


clean done with (my env is single host providing nfs export):

umount /rhev/data-center/mnt/_var_lib_ovirt-hosted-engine-setup_tmpBrbRge
umount /rhev/data-center/mnt/ovirt41\:_SHE__DOMAIN/
rm -rf /SHE_DOMAIN/*
hosted-engine --vm-poweroff (vm was actually already down but the setup
claimed it was up...)
re-run host-deploy and completed successfully...

[ INFO  ] Engine is still not reachable, waiting...
[ INFO  ] Engine replied: DB Up!Welcome to Health Status!
[ INFO  ] Acquiring internal CA cert from the engine
[ INFO  ] The following CA certificate is going to be used, please
immediately interrupt if not correct:
[ INFO  ] Issuer: C=US, O=localdomain.local,
CN=ovirt41she.localdomain.local.40445, Subject: C=US, O=localdomain.local,
CN=ovirt41she.localdomain.local.40445, Fingerprint (SHA-1):
744EDCF02EC8AC74E4C5E549AC464B1EC939D7DC
[ INFO  ] Connecting to the Engine
[ INFO  ] Waiting for the host to become operational in the engine. This
may take several minutes...
[ INFO  ] Still waiting for VDSM host to become operational...
[ INFO  ] The VDSM Host is now operational
[ INFO  ] Saving hosted-engine configuration on the shared storage domain
[ INFO  ] Shutting down the engine VM
[ INFO  ] Enabling and starting HA services
[ INFO  ] Stage: Clean up
[ INFO  ] Generating answer file
'/var/lib/ovirt-hosted-engine-setup/answers/answers-20161207111416.conf'
[ INFO  ] Generating answer file '/etc/ovirt-hosted-engine/answers.conf'
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination
[ INFO  ] Hosted Engine successfully deployed
[root@ovirt41 ~]#


Now going to test ... ;-)
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [Feture discussion] Full vacuum tool

[Yaniv Kaul]

On Wed, Dec 7, 2016 at 10:57 AM, Roy Golan  wrote:

> Hi all,
>
> This is a discussion on the RFE[1] to provide a tool to perform full
> vacuum on our DBs.
>
> First if you are not familiar with vacuum please read this [2]
>
> # Backgroud
> ovirt 'engine' DB have several busy table with 2 differnt usage patten.
> One is audit_log and the others are the 'v*_statistics' tables and the
> difference between them is mostly inserts vs mostly hot updates.
> Tables with tons of updates creates garbage or 'dead' records that should
> be removed, and for this postgres have the aforementioned autovacuum
> cleaner. It will make the db reuse its already allocated space to perform
> future updates/inserts and so on.
> Autovacuum is essential for a db to function optimally and tweaking it is
> out of the scope of the feature.
>
> Full vacuum is designed to reclaim the disk space and reset the table
> statistics. It is a heavy maintenance task, it takes an exclusive lock on
> the table and may take seconds to minutes. In some situations it is
> effectively a downtime due to the long table lock and should not be running
> when the engine is running.
>
> # Critiria
> Provide a way to reclaim disk space claimed by the garbage created over
> time by the engine db and dwh.
>
> # Usage
> Either use it as part of the upgrade procedure (after all dbscipts
> execution)
> or just provide the tool and admin will run in on demand
> - engine db credentials read from /etc/ovirt-engine/engine.conf.d/
> - invocation:
>  ```
>  tool: [dbname(default engine)] [table: (default all)]
>  ```
> - if we invoke it on upgrade than an installation plugin should be added
> to invoke with default, no interaction
> - since VACUUM ANALYZE is consider a recommended maintenance task we can
> to it by default and ask the user for FULL.
>

Will the user know to answer intelligently if vacuum is needed or not?
Except for 'yes, you need it', we cannot even provide a time estimate (I
assume a disk space estimate is available!)
I would suggest to run ANALYZE for sure and provide an option at the end of
installation, to run the required command line - so make it as accessible
as possible, but not part of the flow.

I'm wondering if the community can run ANALYZE on their database, and we
can estimate how many are in dire need for full vacuum already.
Y.

- remote db is supported as well, doesn't have to be local
>
> # Questions
>  - Will remote dwh have the credentials under
> /etc/ovirt-engine/engine.conf.d?
>  - Should  AAA schema be taken into account as well?
>
> Please review, thanks
> Roy
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1388430
> [2] https://www.postgresql.org/docs/9.2/static/runtime-
> config-autovacuum.html
> [3] https://www.postgresql.org/docs/devel/static/sql-vacuum.html
>
> ___
> 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] Hosted-engine --deploy FQDN questions

[Mark Steckel]

Yedidyah - very helpful! Thanks.

A follow-up question re the FQDN for the hosted engine: My understanding is 
that the FQDN must be resolvable when "hosted-engine --deploy" is executed. 
However, should the IP that the FQDN resolves to also be assigned/up when 
"hosted-engine --deploy" is executed?



- Yedidyah Bar David  wrote:
> On Wed, Dec 7, 2016 at 11:36 AM, Mark Steckel  wrote:
> > Marcin,
> >
> > - Marcin Mirecki  wrote:
> >> Mark,
> >>
> >> >   Enter the name which will be used to identify this host inside 
> >> > the
> >> >   Administrator Portal [hosted_engine_1]:
> >>
> >> This is the name used for the host inside the Administrator Portal, so 
> >> basically
> >> the name of the VM inside the system.
> >> This does not have to be the hostname, but there are also no objection for 
> >> it.
> >>
> >>
> >> >   Engine FQDN:  []:
> >> Yes, you are correct. This must be the FQDN of the host, resolvable to IP.
> >> This fqdn will be used to access the administration portal.
> >
> > If I understand you correctly, both questions apply to the hosted engine 
> > vm. Correct?
> 
> No.
> 
> The first question is about the host, but not about its address or dns name.
> It's about the name it will have in the engine, the one you see in the admin 
> ui,
> in "Hosts", as "Name". After too many questions about this question, we 
> decided
> to remove it, and in 4.1 it will simply default to the hostname. You'll still 
> be
> able to set it by manually editing the answer file or passing otopi
> env, but will
> not be prompted for it.
> 
> The second question is indeed about the name that will be used to access
> the engine vm.
> 
> Then there is a third item, which we do not ask about: The name that the
> engine should use to access the host. This is what you see in the admin ui,
> in "Hostname/IP". This item is determined the following way, for the first
> host: You are prompted for a NIC to use for the management bridge, we check
> the IP address of this NIC, then do a reverse-lookup (gethostbyaddr) on this
> address, and use the result. So you should make sure that this nic has an
> IP address, that this address has a name (in /etc/hosts or dns), and that
> this name will also be resolvable and point to the host, when used inside
> the engine vm (again, by either using dns or manually setting it in
> /etc/hosts there).
> 
> >
> > (If so, I'm glad I asked, because I initially and incorrectly thought that 
> > the first question referred to the bare metal machine that hosts the hosted 
> > engine vm.)
> 
> Hopefully the above clarifies this. Please do not hesitate to ask if
> there are still questions. Also, suggestions for better texts, to make
> this simpler for the admin, are more than welcome! :-)
> 
> Best,
> 
> >
> > Thanks
> > Mark
> >
> >
> >
> >>
> >> Marcin
> >>
> >>
> >> - Original Message -
> >> > From: "Mark Steckel" 
> >> > To: users@ovirt.org
> >> > Sent: Wednesday, December 7, 2016 6:08:38 AM
> >> > Subject: [ovirt-users] Hosted-engine --deploy FQDN questions
> >> >
> >> > Folks,
> >> >
> >> > I'm an OVirt newbie having troubles setting up my first Hosted Engine 
> >> > and am
> >> > stumbling. In this case I think it may be because of the following two
> >> > set-up questions.
> >> >
> >> >   Enter the name which will be used to identify this host inside 
> >> > the
> >> >   Administrator Portal [hosted_engine_1]:
> >> >   Please provide the FQDN for the engine you would like to use.
> >> >   This needs to match the FQDN that you will use for the engine
> >> >   installation within the VM.
> >> >   Note: This will be the FQDN of the VM you are now going to 
> >> > create,
> >> >   it should not point to the base host or to any other existing
> >> >   machine.
> >> >   Engine FQDN:  []:
> >> >
> >> > My read of this is that the first question is asking for the name of the
> >> > host, while the second question is asking for the name (FQDN) of the 
> >> > guest
> >> > vm which will be the hosted-engine. Is this correct?
> >> >
> >> > I'm also presuming that a) the first question should be the hostname of 
> >> > the
> >> > host, and b) that both the host and guest hostnames should resolve to IP
> >> > addresses.
> >> >
> >> > Thanks
> >> > Mark
> >> > ___
> >> > 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
> 
> 
> 
> -- 
> Didi

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

Re: [ovirt-users] Renaming hosted engine

[Luca 'remix_tj' Lorenzetto]

Hello,

On Wed, Dec 7, 2016 at 10:53 AM, Yedidyah Bar David  wrote:
[cut]
>
> If you have another host, you can migrate all VMs to the other host,
> move current to maintenance, remove it, then add it with the new name
> you want. You might have to also clean up the shared meta-data, see:
>
> https://www.ovirt.org/documentation/how-to/hosted-engine/#remove-old-host-from-the-metadata-whiteboard
>

from your response i understood that i was using the wrong terms for
explaining my need.

What i'm willing to change the fqdn of the engine vm running on hosted
engine. I've seen that the deployment procedure asked for it, so i
think somewhere  this value is used for configurations.

Thank you anyway for the link,

Luca

-- 
"E' assurdo impiegare gli uomini di intelligenza eccellente per fare
calcoli che potrebbero essere affidati a chiunque se si usassero delle
macchine"
Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716)

"Internet è la più grande biblioteca del mondo.
Ma il problema è che i libri sono tutti sparsi sul pavimento"
John Allen Paulos, Matematico (1945-vivente)

Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , 
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [Feture discussion] Full vacuum tool

[Piotr Kliczewski]

On Wed, Dec 7, 2016 at 9:57 AM, Roy Golan  wrote:
> Hi all,
>
> This is a discussion on the RFE[1] to provide a tool to perform full vacuum
> on our DBs.
>
> First if you are not familiar with vacuum please read this [2]
>
> # Backgroud
> ovirt 'engine' DB have several busy table with 2 differnt usage patten. One
> is audit_log and the others are the 'v*_statistics' tables and the
> difference between them is mostly inserts vs mostly hot updates.
> Tables with tons of updates creates garbage or 'dead' records that should be
> removed, and for this postgres have the aforementioned autovacuum cleaner.
> It will make the db reuse its already allocated space to perform future
> updates/inserts and so on.
> Autovacuum is essential for a db to function optimally and tweaking it is
> out of the scope of the feature.
>
> Full vacuum is designed to reclaim the disk space and reset the table
> statistics. It is a heavy maintenance task, it takes an exclusive lock on
> the table and may take seconds to minutes. In some situations it is
> effectively a downtime due to the long table lock and should not be running
> when the engine is running.
>
> # Critiria
> Provide a way to reclaim disk space claimed by the garbage created over time
> by the engine db and dwh.

What about not storing this data in db? Do we need it all the time or
just for some amount of time?

>
> # Usage
> Either use it as part of the upgrade procedure (after all dbscipts
> execution)
> or just provide the tool and admin will run in on demand
> - engine db credentials read from /etc/ovirt-engine/engine.conf.d/
> - invocation:
>  ```
>  tool: [dbname(default engine)] [table: (default all)]
>  ```
> - if we invoke it on upgrade than an installation plugin should be added to
> invoke with default, no interaction
> - since VACUUM ANALYZE is consider a recommended maintenance task we can to
> it by default and ask the user for FULL.
> - remote db is supported as well, doesn't have to be local
>
> # Questions
>  - Will remote dwh have the credentials under
> /etc/ovirt-engine/engine.conf.d?
>  - Should  AAA schema be taken into account as well?
>
> Please review, thanks
> Roy
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1388430
> [2]
> https://www.postgresql.org/docs/9.2/static/runtime-config-autovacuum.html
> [3] https://www.postgresql.org/docs/devel/static/sql-vacuum.html
>
> ___
> 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] Hosted-engine --deploy FQDN questions

[Marcin Mirecki]

Mark,

hosted_engine_1 is of course the name of the host in the system.
Sorry for the confusion.

Marcin

- Original Message -
> From: "Mark Steckel" 
> To: "Marcin Mirecki" 
> Cc: users@ovirt.org
> Sent: Wednesday, December 7, 2016 10:36:58 AM
> Subject: Re: [ovirt-users] Hosted-engine --deploy FQDN questions
> 
> Marcin,
> 
> - Marcin Mirecki  wrote:
> > Mark,
> > 
> > >   Enter the name which will be used to identify this host inside
> > >   the
> > >   Administrator Portal [hosted_engine_1]:
> > 
> > This is the name used for the host inside the Administrator Portal, so
> > basically
> > the name of the VM inside the system.
> > This does not have to be the hostname, but there are also no objection for
> > it.
> > 
> > 
> > >   Engine FQDN:  []:
> > Yes, you are correct. This must be the FQDN of the host, resolvable to IP.
> > This fqdn will be used to access the administration portal.
> 
> If I understand you correctly, both questions apply to the hosted engine vm.
> Correct?
> 
> (If so, I'm glad I asked, because I initially and incorrectly thought that
> the first question referred to the bare metal machine that hosts the hosted
> engine vm.)
> 
> Thanks
> Mark
> 
> 
> 
> > 
> > Marcin
> > 
> > 
> > - Original Message -
> > > From: "Mark Steckel" 
> > > To: users@ovirt.org
> > > Sent: Wednesday, December 7, 2016 6:08:38 AM
> > > Subject: [ovirt-users] Hosted-engine --deploy FQDN questions
> > > 
> > > Folks,
> > > 
> > > I'm an OVirt newbie having troubles setting up my first Hosted Engine and
> > > am
> > > stumbling. In this case I think it may be because of the following two
> > > set-up questions.
> > > 
> > >   Enter the name which will be used to identify this host inside
> > >   the
> > >   Administrator Portal [hosted_engine_1]:
> > >   Please provide the FQDN for the engine you would like to use.
> > >   This needs to match the FQDN that you will use for the engine
> > >   installation within the VM.
> > >   Note: This will be the FQDN of the VM you are now going to
> > >   create,
> > >   it should not point to the base host or to any other existing
> > >   machine.
> > >   Engine FQDN:  []:
> > > 
> > > My read of this is that the first question is asking for the name of the
> > > host, while the second question is asking for the name (FQDN) of the
> > > guest
> > > vm which will be the hosted-engine. Is this correct?
> > > 
> > > I'm also presuming that a) the first question should be the hostname of
> > > the
> > > host, and b) that both the host and guest hostnames should resolve to IP
> > > addresses.
> > > 
> > > Thanks
> > > Mark
> > > ___
> > > 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] Renaming hosted engine

[Yedidyah Bar David]

2016-12-07 10:27 GMT+02:00 Luca 'remix_tj' Lorenzetto
:
> Hello,
>
> i did a deploy of hosted engine with an hostname that i'm willing to
> change now. Is there any procedure to do this?

I don't think so.

If you have another host, you can migrate all VMs to the other host,
move current to maintenance, remove it, then add it with the new name
you want. You might have to also clean up the shared meta-data, see:

https://www.ovirt.org/documentation/how-to/hosted-engine/#remove-old-host-from-the-metadata-whiteboard

>
> Luca
>
> --
> "E' assurdo impiegare gli uomini di intelligenza eccellente per fare
> calcoli che potrebbero essere affidati a chiunque se si usassero delle
> macchine"
> Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716)
>
> "Internet è la più grande biblioteca del mondo.
> Ma il problema è che i libri sono tutti sparsi sul pavimento"
> John Allen Paulos, Matematico (1945-vivente)
>
> Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , 
> 
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users



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

Re: [ovirt-users] Hosted-engine --deploy FQDN questions

[Yedidyah Bar David]

On Wed, Dec 7, 2016 at 11:36 AM, Mark Steckel  wrote:
> Marcin,
>
> - Marcin Mirecki  wrote:
>> Mark,
>>
>> >   Enter the name which will be used to identify this host inside 
>> > the
>> >   Administrator Portal [hosted_engine_1]:
>>
>> This is the name used for the host inside the Administrator Portal, so 
>> basically
>> the name of the VM inside the system.
>> This does not have to be the hostname, but there are also no objection for 
>> it.
>>
>>
>> >   Engine FQDN:  []:
>> Yes, you are correct. This must be the FQDN of the host, resolvable to IP.
>> This fqdn will be used to access the administration portal.
>
> If I understand you correctly, both questions apply to the hosted engine vm. 
> Correct?

No.

The first question is about the host, but not about its address or dns name.
It's about the name it will have in the engine, the one you see in the admin ui,
in "Hosts", as "Name". After too many questions about this question, we decided
to remove it, and in 4.1 it will simply default to the hostname. You'll still be
able to set it by manually editing the answer file or passing otopi
env, but will
not be prompted for it.

The second question is indeed about the name that will be used to access
the engine vm.

Then there is a third item, which we do not ask about: The name that the
engine should use to access the host. This is what you see in the admin ui,
in "Hostname/IP". This item is determined the following way, for the first
host: You are prompted for a NIC to use for the management bridge, we check
the IP address of this NIC, then do a reverse-lookup (gethostbyaddr) on this
address, and use the result. So you should make sure that this nic has an
IP address, that this address has a name (in /etc/hosts or dns), and that
this name will also be resolvable and point to the host, when used inside
the engine vm (again, by either using dns or manually setting it in
/etc/hosts there).

>
> (If so, I'm glad I asked, because I initially and incorrectly thought that 
> the first question referred to the bare metal machine that hosts the hosted 
> engine vm.)

Hopefully the above clarifies this. Please do not hesitate to ask if
there are still questions. Also, suggestions for better texts, to make
this simpler for the admin, are more than welcome! :-)

Best,

>
> Thanks
> Mark
>
>
>
>>
>> Marcin
>>
>>
>> - Original Message -
>> > From: "Mark Steckel" 
>> > To: users@ovirt.org
>> > Sent: Wednesday, December 7, 2016 6:08:38 AM
>> > Subject: [ovirt-users] Hosted-engine --deploy FQDN questions
>> >
>> > Folks,
>> >
>> > I'm an OVirt newbie having troubles setting up my first Hosted Engine and 
>> > am
>> > stumbling. In this case I think it may be because of the following two
>> > set-up questions.
>> >
>> >   Enter the name which will be used to identify this host inside 
>> > the
>> >   Administrator Portal [hosted_engine_1]:
>> >   Please provide the FQDN for the engine you would like to use.
>> >   This needs to match the FQDN that you will use for the engine
>> >   installation within the VM.
>> >   Note: This will be the FQDN of the VM you are now going to 
>> > create,
>> >   it should not point to the base host or to any other existing
>> >   machine.
>> >   Engine FQDN:  []:
>> >
>> > My read of this is that the first question is asking for the name of the
>> > host, while the second question is asking for the name (FQDN) of the guest
>> > vm which will be the hosted-engine. Is this correct?
>> >
>> > I'm also presuming that a) the first question should be the hostname of the
>> > host, and b) that both the host and guest hostnames should resolve to IP
>> > addresses.
>> >
>> > Thanks
>> > Mark
>> > ___
>> > 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



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

Re: [ovirt-users] Hosted-engine --deploy FQDN questions

[Mark Steckel]

Marcin,

- Marcin Mirecki  wrote:
> Mark,
> 
> >   Enter the name which will be used to identify this host inside the
> >   Administrator Portal [hosted_engine_1]:
> 
> This is the name used for the host inside the Administrator Portal, so 
> basically
> the name of the VM inside the system.
> This does not have to be the hostname, but there are also no objection for it.
> 
> 
> >   Engine FQDN:  []:
> Yes, you are correct. This must be the FQDN of the host, resolvable to IP.
> This fqdn will be used to access the administration portal.

If I understand you correctly, both questions apply to the hosted engine vm. 
Correct?

(If so, I'm glad I asked, because I initially and incorrectly thought that the 
first question referred to the bare metal machine that hosts the hosted engine 
vm.)

Thanks
Mark



> 
> Marcin
> 
> 
> - Original Message -
> > From: "Mark Steckel" 
> > To: users@ovirt.org
> > Sent: Wednesday, December 7, 2016 6:08:38 AM
> > Subject: [ovirt-users] Hosted-engine --deploy FQDN questions
> > 
> > Folks,
> > 
> > I'm an OVirt newbie having troubles setting up my first Hosted Engine and am
> > stumbling. In this case I think it may be because of the following two
> > set-up questions.
> > 
> >   Enter the name which will be used to identify this host inside the
> >   Administrator Portal [hosted_engine_1]:
> >   Please provide the FQDN for the engine you would like to use.
> >   This needs to match the FQDN that you will use for the engine
> >   installation within the VM.
> >   Note: This will be the FQDN of the VM you are now going to create,
> >   it should not point to the base host or to any other existing
> >   machine.
> >   Engine FQDN:  []:
> > 
> > My read of this is that the first question is asking for the name of the
> > host, while the second question is asking for the name (FQDN) of the guest
> > vm which will be the hosted-engine. Is this correct?
> > 
> > I'm also presuming that a) the first question should be the hostname of the
> > host, and b) that both the host and guest hostnames should resolve to IP
> > addresses.
> > 
> > Thanks
> > Mark
> > ___
> > Users mailing list
> > Users@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
> > 

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

[ovirt-users] [Feture discussion] Full vacuum tool

[Roy Golan]

Hi all,

This is a discussion on the RFE[1] to provide a tool to perform full vacuum
on our DBs.

First if you are not familiar with vacuum please read this [2]

# Backgroud
ovirt 'engine' DB have several busy table with 2 differnt usage patten. One
is audit_log and the others are the 'v*_statistics' tables and the
difference between them is mostly inserts vs mostly hot updates.
Tables with tons of updates creates garbage or 'dead' records that should
be removed, and for this postgres have the aforementioned autovacuum
cleaner. It will make the db reuse its already allocated space to perform
future updates/inserts and so on.
Autovacuum is essential for a db to function optimally and tweaking it is
out of the scope of the feature.

Full vacuum is designed to reclaim the disk space and reset the table
statistics. It is a heavy maintenance task, it takes an exclusive lock on
the table and may take seconds to minutes. In some situations it is
effectively a downtime due to the long table lock and should not be running
when the engine is running.

# Critiria
Provide a way to reclaim disk space claimed by the garbage created over
time by the engine db and dwh.

# Usage
Either use it as part of the upgrade procedure (after all dbscipts
execution)
or just provide the tool and admin will run in on demand
- engine db credentials read from /etc/ovirt-engine/engine.conf.d/
- invocation:
 ```
 tool: [dbname(default engine)] [table: (default all)]
 ```
- if we invoke it on upgrade than an installation plugin should be added to
invoke with default, no interaction
- since VACUUM ANALYZE is consider a recommended maintenance task we can to
it by default and ask the user for FULL.
- remote db is supported as well, doesn't have to be local

# Questions
 - Will remote dwh have the credentials under
/etc/ovirt-engine/engine.conf.d?
 - Should  AAA schema be taken into account as well?

Please review, thanks
Roy

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1388430
[2]
https://www.postgresql.org/docs/9.2/static/runtime-config-autovacuum.html
[3] https://www.postgresql.org/docs/devel/static/sql-vacuum.html
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] can not migrate vm

[Yedidyah Bar David]

On Tue, Dec 6, 2016 at 8:48 PM, Marcelo Leandro  wrote:
> sorry, this is correct src-vdsm.log

Perhaps try to edit the VM, choose Host tab, and tweak migration options.
You can set policy to Legacy, and a high-enough "custom migration downtime".

See also e.g.:

http://lists.ovirt.org/pipermail/users/2016-April/039313.html

Best,

>
>
> Thanks
>
>
> 2016-12-06 15:44 GMT-03:00 Marcelo Leandro :
>>
>> Hello,
>> Logs Attached.
>> Started migration = 3:03 PM
>> Falied migration = 3:12PM
>> Thanks.
>>
>> 2016-12-06 13:14 GMT-03:00 Yedidyah Bar David :
>>>
>>> On Tue, Dec 6, 2016 at 5:25 PM, Marcelo Leandro 
>>> wrote:
>>> > I am not sure when the problem start because i was in vacation.
>>> > I have only logs of the last try.
>>>
>>> The logs you attached did not include relevant time intervals.
>>> Are you sure you do not have logs that contain the snippet
>>> you included in-line?
>>>
>>> Anyway, you can always try again, and if it still fails, attach the
>>> new logs.
>>>
>>> Best,
>>>
>>> > Very thanks.
>>> >
>>> > Marcelo Leandro
>>>
>>>
>>>
>>> --
>>> Didi
>>
>>
>



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

[ovirt-users] Renaming hosted engine

[Luca 'remix_tj' Lorenzetto]

Hello,

i did a deploy of hosted engine with an hostname that i'm willing to
change now. Is there any procedure to do this?

Luca

-- 
"E' assurdo impiegare gli uomini di intelligenza eccellente per fare
calcoli che potrebbero essere affidati a chiunque se si usassero delle
macchine"
Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716)

"Internet è la più grande biblioteca del mondo.
Ma il problema è che i libri sono tutti sparsi sul pavimento"
John Allen Paulos, Matematico (1945-vivente)

Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , 
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Hosted-engine --deploy FQDN questions

[Marcin Mirecki]

Mark,

>   Enter the name which will be used to identify this host inside the
>   Administrator Portal [hosted_engine_1]:

This is the name used for the host inside the Administrator Portal, so basically
the name of the VM inside the system.
This does not have to be the hostname, but there are also no objection for it.


>   Engine FQDN:  []:
Yes, you are correct. This must be the FQDN of the host, resolvable to IP.
This fqdn will be used to access the administration portal.

Marcin


- Original Message -
> From: "Mark Steckel" 
> To: users@ovirt.org
> Sent: Wednesday, December 7, 2016 6:08:38 AM
> Subject: [ovirt-users] Hosted-engine --deploy FQDN questions
> 
> Folks,
> 
> I'm an OVirt newbie having troubles setting up my first Hosted Engine and am
> stumbling. In this case I think it may be because of the following two
> set-up questions.
> 
>   Enter the name which will be used to identify this host inside the
>   Administrator Portal [hosted_engine_1]:
>   Please provide the FQDN for the engine you would like to use.
>   This needs to match the FQDN that you will use for the engine
>   installation within the VM.
>   Note: This will be the FQDN of the VM you are now going to create,
>   it should not point to the base host or to any other existing
>   machine.
>   Engine FQDN:  []:
> 
> My read of this is that the first question is asking for the name of the
> host, while the second question is asking for the name (FQDN) of the guest
> vm which will be the hosted-engine. Is this correct?
> 
> I'm also presuming that a) the first question should be the hostname of the
> host, and b) that both the host and guest hostnames should resolve to IP
> addresses.
> 
> Thanks
> Mark
> ___
> 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