[ovirt-users] 4.2 downgrade

[Ryan Mahoney]

Accidentally upgraded a 4.0 environment to 4.2 (didn't realize the "master"
repo was development repo).  What's my chances/best way if possible to roll
back to 4.0 (or 4.1 for that matter).
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Help with Power Management network

[~Stack~]

On 09/29/2017 05:31 PM, Dan Yasny wrote:
> You need more than one host for power management
> 

Seriously?? I didn't see anything like that in the docs...Maybe I just
missed it.

Also, why wouldn't it still validate? It should still be able to talk to
the interface over the BMC/IPMI network. The fact that I can run the
equivalent test on the command line makes it seem like it should at
least be able to check via the test. Obviously, it would be silly for it
to try to manage itself, but it could at least verify that the
configuration is valid, right?

I have more hosts that I'm going to add, I was just hoping to do those
via the Foreman integration instead of manually building them. Since I'm
not quite ready for that, I will just build a second host on Monday and
report back.

Thanks for the feedback. I would have never guess that as a possibility. :-)

~Stack~



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

Re: [ovirt-users] Help with Power Management network

[Dan Yasny]

You need more than one host for power management

On Sep 29, 2017 4:25 PM, "~Stack~"  wrote:

> Greetings,
>
> I hit up the IRC earlier, but only crickets. Guess no one wants to stick
> around late on a Friday night. :-D
>
> I'm an ovirt newb here. I've been going through the docs setting up 4.1
> on Scientific Linux 7.4. For the most part everything is going well once
> I learn how to do it. I'm, however, stuck on power management.
>
> I have multiple networks:
> 192.168.1.x is my BMC/ilo network. The security team wants as few entry
> points into this as possible and wants as much segregation as possible.
>
> 192.168.2.x is my "management" access network. For my other machines on
> this network this means admin-SSH/rsyslog/SaltStack configuration
> management/ect.
>
> 192.168.3.x is my high speed network where my NFS storage sits and
> applications that need the bandwidth do their thing.
>
> 10.10.86.x is my "public" access
>
> All networks are configured on the Host network settings. Mostly
> confident I got it right...at least each network/IP matches the right
> interface. ;-)
>
> Right now I only have the engine server and one hyper-visor. On either
> host I can ssh into the command line and run fence_ipmilan -a
> 192.168.1.x -l USER -p PASS -o status -v -P" it works, all is good.
> However, when I try to add it in the ovirt interface I get an error. :-/
>
> Edit Host -> Power Management:
> Address: 192.168.1.14
> User Name: root
> Password: SorryCantTellYou
> Type: ipmilan
> Options: 
>
> Test
>
> Test failed: Failed to run fence status-check on host '192.168.2.14'. No
> other host was available to serve as proxy for the operation.
>
> Yes, same host because I only have one right now. :-)
>
> Any help or guidance would be much appreciated. In the meantime I'm
> going back to the docs to poke at a few other things I need to figure
> out. :-)
>
> Thanks!
> ~Stack~
>
>
> ___
> 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] Help with Power Management network

[~Stack~]

Greetings,

I hit up the IRC earlier, but only crickets. Guess no one wants to stick
around late on a Friday night. :-D

I'm an ovirt newb here. I've been going through the docs setting up 4.1
on Scientific Linux 7.4. For the most part everything is going well once
I learn how to do it. I'm, however, stuck on power management.

I have multiple networks:
192.168.1.x is my BMC/ilo network. The security team wants as few entry
points into this as possible and wants as much segregation as possible.

192.168.2.x is my "management" access network. For my other machines on
this network this means admin-SSH/rsyslog/SaltStack configuration
management/ect.

192.168.3.x is my high speed network where my NFS storage sits and
applications that need the bandwidth do their thing.

10.10.86.x is my "public" access

All networks are configured on the Host network settings. Mostly
confident I got it right...at least each network/IP matches the right
interface. ;-)

Right now I only have the engine server and one hyper-visor. On either
host I can ssh into the command line and run fence_ipmilan -a
192.168.1.x -l USER -p PASS -o status -v -P" it works, all is good.
However, when I try to add it in the ovirt interface I get an error. :-/

Edit Host -> Power Management:
Address: 192.168.1.14
User Name: root
Password: SorryCantTellYou
Type: ipmilan
Options: 

Test

Test failed: Failed to run fence status-check on host '192.168.2.14'. No
other host was available to serve as proxy for the operation.

Yes, same host because I only have one right now. :-)

Any help or guidance would be much appreciated. In the meantime I'm
going back to the docs to poke at a few other things I need to figure
out. :-)

Thanks!
~Stack~



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

[ovirt-users] Metrics store doc page link broken?

[Gianluca Cecchi]

Hello,
I was just giving an eye to what in subject here:

https://www.ovirt.org/develop/release-management/features/metrics/metrics-store-installation/

But it seems that the main link to
"Metrics store setup on top of openshift"
Is broken...
Any other point to begin to see the expected workflow for it?
Thanks
Gianluca
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] DR with oVirt: no data on OVF_STORE

[Luca 'remix_tj' Lorenzetto]

Hello,

i'm experimenting a DR architecture that involves block storage
replication from the storage side (EMC VNX 8000).

Our idea is to import the replicated data storage domain on another
datacenter, managed by another engine, with the option "Import Domain"
and then import all the vms contained.

The idea works, but we encountered an issue that we don't want to have
again: we imported an SD and *no* vm were listed in the tab "VM
Import". Disks were available, but no VM informations.

What we did:
 - on storage side: split the replica between the main disk in Site A
and the secondary disk Site B
 - on storage side: added the disk to the storage group of the
"recovery" cluster
 - from engine UI: Imported storage domain, confirming that i want to
activate even if seems to be attached to another DC
 - from engine UI: move out from maintenance the storage domain and
click on the "VM Import" tab of the new SD.

What happened: *no* vm were listed

To identify better what's happening, I've found here some indications
on how lvm for block storage works and I identified the command on how
to find and read the OVF_STORE.
Looking inside the OVF_STORE has shown why no vm were listed: it was
empty (no .ovf file listed with tar tvf)

So, without the possibility import vms, i did a rollback, detaching
the storage domain and re-establishing the replication between the
main site and the DR site.

Then, after a day of replications (secondary volume is  aligned every
30 minutes), i tried again and i've been able to import also vms
(OVF_STORE was populated).

So my question is: how to i force to have OVF_STORE to be aligned at
least as frequent as the replication? I want to have the VM disks
replicated to the remote site along with VM OVF informations.

Is possible to have OVF_STORE informations aligned when a VM is
created/edited or with a scheduled task? Is this so I/O expensive?

Thank you,


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] changing ip of host and its ovirtmgmt vlan

[Gianluca Cecchi]

On Thu, Sep 28, 2017 at 5:25 PM, Alona Kaplan  wrote:

>
>
>> And if I decide to start from scratch with this new cluster CLC on
>> VLAN30, can I retain my old 3 hostnames (resolving to their new IPs)? How?
>>
>
> You can -
>


I decided to go this way above and it seems I was able to reach the desired
target. These below my steps. Eventually I will be more precise with
another host for which I have to do the same

Host host1 is in cluster CLA and original mgmt network in CLA is ovirtmgmt
on vlan167
>From host point of view the original ovirtmgmt is a bridge on top of
bond0.167

I have to put host1 into cluster CLB where the mgmt network is
ovirtmgmntZ2Z3 on vlan68
This cluster CLB has already one host in it and the ovirtmgmt network is
not checked as "required"
(if I select setup networks for the host host2 in CLB I see it in the right
end side)



> 1. remove the host from the original clusters
>

Put host host1 into maintenance and then removed



> 2. remove all the network from the host using Petr's vdsm tool (
> https://gerrit.ovirt.org/#/c/79495/)
>

Actually I compared my 4.1.6 version of the python scripts involved in the
tool and they seems quite different from their 4.2.0 version in the
gerrit...so I didn't follow this way.
Instead. as I have to retain all networks but the management one I:

a) connect to host via ssh

b) create an ifcfg-bond0.68 so that:
# diff ifcfg-bond0.68 ifcfg-bond0.167
2c2
< DEVICE=bond0.68
---
> DEVICE=bond0.167
4c4
< BRIDGE=ovirtmgmntZ2Z3
---
> BRIDGE=ovirtmgmt

c) create an ifcfg-ovirtmgmntZ2Z3 so that:

# diff ifcfg-ovirtmgmntZ2Z3 ifcfg-ovirtmgmt
2c2
< DEVICE=ovirtmgmntZ2Z3
---
> DEVICE=ovirtmgmt
7,9c7,9
< IPADDR=10.4.192.33
< NETMASK=255.255.255.0
< GATEWAY=10.4.192.254

< IPADDR=10.4.167.84
< NETMASK=255.255.255.0
< GATEWAY=10.4.167.254

d) ask network guys to configure vlan 68 on the trunk network ports of the
switch ports of the blade

e) activate the new interfaces on host1
ifup bond0.68
ifup ovirtmgmntZ2Z3




> 3. change the dns setting to resolve to the new IPs.
>

Done this and also for more safety I put a static entry with the new ip of
host1 inside /etc/hosts of engine and of the other host host2 of the target
cluster
Verify that host1 is reachable from engine and host2

4. Add the host to the new cluster.
>
>
>>
>>
Done.
I get all the "Installing... " steps and then
Sep 29, 2017 2:36:12 PM Status of host host1 was set to NonOperational.
Sep 29, 2017 2:36:12 PM Host host1 does not comply with the cluster CLB
networks, the following networks are missing on host: 'ovirtmgmntZ2Z3'
Sep 29, 2017 2:36:08 PM Host host1 installation failed. Failed to configure
management network on the host.
Sep 29, 2017 2:36:08 PM Host host1 installation failed. Failed to configure
management network on the host.
Sep 29, 2017 2:36:05 PM Installing Host host1. Stage: Termination.


5. I select host1 and go into setup networks page
I cannot remove the ovirtmgmt network, so I simply edit it and set its
protocol to none
Also I drag and drop the available ovirtmgmntZ2Z3 network from the right to
the side of bond0 (under ovirtmgmt square) and edit it

Please note that I don't find how to set default route. It seems automatic.
It is for this reason that I have to remove the static configuration of
ovirtmgmt, otherwise when saving I get

VDSM host1 command HostSetupNetworksVDS failed: Only a singe default route
network is allowed.

Possibly I miss something here about default route...

I leave checked both options:
Verify connectivity between Host and Engine
and
Save network configuration

The host then is able to save and activate its new configuration. In events
pane I have this:

Sep 29, 2017 2:45:08 PM Status of host host1 was set to Up.
Sep 29, 2017 2:44:35 PM Managed to sync all host host1 networks.
Sep 29, 2017 2:44:35 PM (1/1): Successfully applied changes on host host1.
(User: g.cecchi@internal-authz)
Sep 29, 2017 2:44:35 PM (1/1): Applying network's changes on host host1.
(User: g.cecchi@internal-authz)
Sep 29, 2017 2:42:41 PM Network changes were saved on host host1

In /var/lib/vdsm/persistence I have:
[root@host1 network-scripts]# ll /var/lib/vdsm/persistence/netconf/nets/
total 32
-rw-r--r--. 1 root root 270 Sep 29 14:42 iscsi1
-rw-r--r--. 1 root root 253 Sep 29 14:42 iscsi2
-rw-r--r--. 1 root root 371 Sep 29 14:42 ovirtmgmntZ2Z3
-rw-r--r--. 1 root root 229 Sep 29 14:42 ovirtmgmt
-rw-r--r--. 1 root root 225 Sep 29 14:42 vlan162
-rw-r--r--. 1 root root 271 Sep 29 14:42 vlan187
-rw-r--r--. 1 root root 229 Sep 29 14:42 vlan65
-rw-r--r--. 1 root root 224 Sep 29 14:42 vlan98
[root@host1 network-scripts]#

that seems correct in terms of timestamps and contents.
I put host1 into maintenance and reboot it via ssh management --> restart
And it seems all has been maintained:

[g.cecchi@host1 ~]$ netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags   MSS Window  irtt
Iface
0.0.0.0 10.4.192.2540.0.0.0 UG0 0  0
ovir

Re: [ovirt-users] Host cannot connect to hosted storage domain

[Alexander Witte]

Hi Sandro,

Thanks so much for the reply.

Yeah I ended up reinstalling the Engine referencing the FQDN in the storage 
path.  Fixed all the issues.

Thanks a lot for the Hyperconverged link- at first glance it almost looks like 
the exact setup I am creating and might suit our needs exactly.

Thanks!

Alex Witte
Technology Specialist
Office:  647-349-8484
Mobile: 647-880-7048
www.baicanada.com

[cid:image001.gif@01D0D506.FAB96B00]

On Sep 29, 2017, at 2:21 AM, Sandro Bonazzola 
mailto:sbona...@redhat.com>> wrote:



2017-09-28 2:32 GMT+02:00 Alexander Witte 
mailto:alexander.wi...@baicanada.com>>:
Hi!

Question hopefully someone can help me out with:

In my Self Hosted Engine environment, the local storage domain DATA (NFS) that 
was created with the self engine installation has been configured as 
localhost:/shares


So it seems you're trying to do an Hyperconverged setup on local NFS. Please 
note this is not a supported configuration.
If you need to have the storage on the hosts you use for running Self Hosted 
Engine and other VMs, I would suggest to follow 
https://ovirt.org/documentation/gluster-hyperconverged/Gluster_Hyperconverged_Guide/



I suspect this is preventing me from adding any additional hosts to the oVirt 
Datacenter as I am receiving a VDSM error that I cannot mount that domain.  I 
think since the domain is set as localhost it cannot be resolved correct by any 
additional hosts...?

You are correct, being the NFS export referenced as localhost:// it is not 
accessible by other hosts.


 The ISO, Data(Master) and EXPORT domains are set as FQDN:/shares/iso and I am 
not seeing problems specific to them.

I am curious what the correct procedure is to change this hosted engine storage 
domain path from localhost:/shares to FQDN:/shares ?  I have attempted this:

1) Put hosted engine in Global Maintenance Mode
2) Shutdown hosted engine
3) edit the /etc/ovirt-hosted-engine/hosted-engine.conf file file and change:
storage=10.0.0.223:/shares   to
storage=menmaster.traindemo.local:/shares
4) Restart hosted engine


If this is a fresh install, I would suggest to restart from scratch following 
the Hyperconverged guide.


Although I’m not having any luck restarting the hosted engine after and running 
a journalctl -u on the overt-ha-agent service is giving me this:

Sep 27 20:17:19 menmaster.traindemo.local ovirt-ha-agent[2052]: ovirt-ha-agent 
ovirt_hosted_engine_ha.agent.agent.Agent ERROR Traceback (most recent call 
last):
  File 
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", line 
191, in _run_agent
return 
action(he)
  File 
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", line 
64, in action_proper
return 
he.start_monitoring()
  File 
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py",
 line 409, in start_monitoring

self._initialize_storage_images(force=True)
  File 
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py",
 line 651, in _initialize_storage_images

img.teardown_images()
  File 
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/image.py", line 
218, in teardown_images

volumeID=volUUID,
  File 
"/usr/lib/python2.7/site-packages/vdsm/jsonrpcvdscli.py", line 155, in 
_callMethod

(methodName, args, e))
Exception: 
Attempt to call function: teardownImage with arguments: () error: 
'teardownImage'
Sep 27 20:17:19 menmaster.traindemo.local ovirt-ha-agent[2052]: ovirt-ha-agent 
ovirt_hosted_engine_ha.agent.agent.Agent ERROR Trying to restart agent
Sep 27 20:17:24 menmaster.traindemo.local ovirt-ha-agent[2052]: ovirt-ha-agent 
ovirt_hosted_engine_ha.agent.agent.Agent ERROR Too many errors occurred, giving 
up. Please review the log and consider filing
Sep 27 20:17:24 menmaster.traindemo.local systemd[1]: ovirt-ha-agent.service: 
main process exited, code=exited, status=157/n/a
Sep 27 20:17:24 menmaster.traindemo.local systemd[1]: Unit 
ovirt-ha-agent.service entered failed state.
Sep 27 20:17:24 menmaster.traindemo.local systemd[1]: ovirt-ha-agent.service 
failed.
Sep 27 20:17:25 menmaster.trainde

Re: [ovirt-users] oVirt 4.2 alpha upgrade failed

[Greg Sheremeta]

On Fri, Sep 29, 2017 at 2:30 AM, Sandro Bonazzola 
wrote:

>
>
> 2017-09-28 21:38 GMT+02:00 Maton, Brett :
>
>> , it was the hosted engine itself.
>>
>>   RAM 4096
>>   Max RAM 0
>>
>>   I don't think I've touched the system settings on the hosted engine vm
>> itself though.
>>
>> This (testlab) cluster was originally installed with 4.0 (I think) and
>> gets constantly upgraded with the pre-releases...
>>
>
> Thanks for running oVirt pre-releases in your testlab! Simone, Martin, can
> you please follow up on this?
>
>
>>
>>
> After a bit of faffing around to clean up leftovers of the failed upgrade,
>> I'm now running v4.2.0 and it's certianly different :)
>>
>
> Great to see you managed to upgrade to 4.2.0 alpha!
>
>
>>
>>   I did have one firefox browser that refused to load the dashboard
>> reporting 500 errors, but that appears to have been down to cached content
>> (on OS X).
>>
>
> Greg. any clue? If I understood it correctly, you've been able to access
> the dashboard from some browser but failed on one firefox instance right?
>

Perhaps we should advise in Release Notes to clear cache.


>
>
>
>>
>>   I look forward to playing with the new UI.
>>
>
>
>
>
>
>>
>> Thanks,
>> Brett
>>
>> On 28 September 2017 at 19:29, Maton, Brett 
>> wrote:
>>
>>> Thanks Tomas,
>>>
>>>   I'm restoring backup at the moment, I'll let you know how it goes when
>>> on the next attempt.
>>>
>>> On 28 September 2017 at 18:46, Tomas Jelinek 
>>> wrote:
>>>
 Hey Brett,

 That is strange - it looks like you have some VM which has memory size
 larger than the max memory size.

 You need to go over your VMs / templates to find which one has this
 wrong config and change it.
 Alternatively, to find it faster if you have many vms/templates, you
 could run this SQL query against your engine database:
 select vm_name from vm_static where mem_size_mb > max_memory_size_mb;

 Tomas

 On Thu, Sep 28, 2017 at 6:07 PM, Maton, Brett >>> > wrote:

> Upgrading from oVirt 4.1.7
>
> hosted-engine VM:
> 4GB RAM
>
> hosted-engine setup failed, setup log shows this error:
>
> Running upgrade sql script '/usr/share/ovirt-engine/dbscr
> ipts/upgrade/04_02_0140_add_max_memory_constraint.sql'...
>
> 2017-09-28 16:56:22,951+0100 DEBUG 
> otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema
> plugin.execute:926 execute-output: 
> ['/usr/share/ovirt-engine/dbscripts/schema.sh',
> '-s', 'localhost', '-p', '5432', '-u', 'engine', '-d', 'engine', '-l',
> '/var/log/ovirt-engine/setup/ovirt-engine-setup-20170928164338-0rkilb.log',
> '-c', 'apply'] stderr:
> psql:/usr/share/ovirt-engine/dbscripts/upgrade/04_02_0140_add_max_memory_constraint.sql:2:
> ERROR:  check constraint "vm_static_max_memory_size_lower_bound" is
> violated by some row
> FATAL: Cannot execute sql command: --file=/usr/share/ovirt-engine
> /dbscripts/upgrade/04_02_0140_add_max_memory_constraint.sql
>
> 2017-09-28 16:56:22,951+0100 ERROR 
> otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema
> schema._misc:374 schema.sh: FATAL: Cannot execute sql command:
> --file=/usr/share/ovirt-engine/dbscripts/upgrade/04_02_0140_
> add_max_memory_constraint.sql
> 2017-09-28 16:56:22,952+0100 DEBUG otopi.context
> context._executeMethod:143 method exception
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/otopi/context.py", line 133,
> in _executeMethod
> method['method']()
>   File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-s
> etup/ovirt-engine/db/schema.py", line 376, in _misc
> raise RuntimeError(_('Engine schema refresh failed'))
> RuntimeError: Engine schema refresh failed
>
>
>
> What's the minimum RAM required now ?
>
> Regards,
> Brett
>
> ___
> 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
>>
>>
>
>
> --
>
> SANDRO BONAZZOLA
>
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
>
> Red Hat EMEA 
> 
> TRIED. TESTED. TRUSTED. 
> 
>



-- 

GREG SHEREMETA

SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX

Red Hat NA



gsher...@redhat.comIRC: gshereme

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

Re: [ovirt-users] Real Noob question- setting a static IP on host

[Dan Kenigsberg]

On Fri, Sep 29, 2017 at 9:13 AM, Sandro Bonazzola 
wrote:

>
>
> 2017-09-18 18:13 GMT+02:00 Alexander Witte 
> :
>
>> I am incredibly sorry over this noob question but I am really bashing my
>> head trying to simply change an IP address on an Ovirt host.  oVirt was
>> pushed to this host through the server web interface.  It is running on top
>> of Centos 7.
>>
>> From the docs it says to log into the host and edit the ifcfg-ovirtmgmt
>> file
>>
>
Which docs exactly? I am asking because the ifcfg is autogenerated and
would be rewritten on boot based on /var/lib/vdsm/persistence

and I have done and here are the latest settings:
>>
>> #Generated by VDSM version 4.19.28-1.e17.centos
>> DEVICE:ovirtmgmt
>> TYPE:Bridge
>> DELAY=0
>> STP=off
>> ONBOOT=yes
>> BOOTPROTO=none
>> MTU=1500
>> DEFROUTE=yes
>> NM_CONTROLLED=no
>> IPV6INIT=yes
>> IPV6_AUTOCONF=yes
>> IPADDR=10.0.0.226
>> GATEWAY=10.0.0.1
>> PREFIX=13
>> DNS1=10.0.0.9
>> DNS2=8.8.8.8
>>
>> The server can reach everything on the network fine.  Although it cannot
>> be reached through the oVirt web interface and the host is in a
>> “connecting” status.  In the oVirt web interface if I attempt to edit the
>> NIC settings from DHCP to Static to reflect the changes Ive made above I
>> run into this error:
>>
>>
>>- Cannot setup Networks. Another Setup Networks or Host Refresh
>>process in progress on the host. Please try later.
>>
>> Dan, Marcin can you help here?
>

I am afraid that there is no reliable way to change the management network
address of a host. Well, if you've added the host via its fqdn, you could
modify its DNS entry in parallel to modifying its local address, but that
is not fun either.

I'd suggest to remove the host from Engine, remove on-host network
configuration (in ovirt-4.2 that would be possible to be done via
`vdsm-tool remove-nets`. At the moment, you'd have to edit ifcfg and not
reboot), and re-add the host via a new address.

I hope that helps. If anybody has a smarter way to improve this process,
please speak up.



>

>
>>
>> What is the correct procedure to change a host management IP from DHCP to
>> STATIC?  Should I make these changes manually on the host or through the
>> NIC settings in the oVirt web interface (when I tried this it just seemed
>> to hang..)
>>
>
> The administration guide related to host management is here:
> https://ovirt.org/documentation/admin-guide/chap-Hosts/
> but it doesn't cover the change of the host network configuration.
> Dan and Marcin or some other sysadmin in this list may correct me, but I
> think the correct procedure here is:
> - Put the host to maintenance in the ovirt interface
> - change the nic settings in ovirt web interface
> - activate the host
>
> Derek, we should probably ensure this case is covered in the Admin guide.
>
>
>
>>
>> Any help is greatly appreciated.
>>
>> Thanks!!
>>
>>
>> Alex
>>
>>
>>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
>
>
> --
>
> SANDRO BONAZZOLA
>
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
>
> Red Hat EMEA 
> 
> TRIED. TESTED. TRUSTED. 
> 
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] oVirt 4.2 alpha upgrade failed

[Sandro Bonazzola]

2017-09-29 11:21 GMT+02:00 Maton, Brett :

> Ah ok,
>
>   So assuming there was enough space the rollback should have put the
> engine back to it's previous state.
>

Yes, it should have worked.


>
> On 29 September 2017 at 09:38, Sandro Bonazzola 
> wrote:
>
>>
>>
>> 2017-09-29 9:58 GMT+02:00 Maton, Brett :
>>
>>> That log appears to be the only one I have, the more recent ones are the
>>> restore and then successful install of 4.2.
>>>
>>> I just checked yum.conf and no, keepcache is off (0)
>>>
>>> I didn't see any errors when engine-setup downloaded the packages, it
>>> failed/stopped during the db migration / upgrade.
>>>
>>
>> Yes, sorry, the out of space error is happening in the rollback from the
>> failure during the database migration.
>>
>>
>>
>>>
>>>
>>> Brett
>>>
>>> On 29 September 2017 at 08:41, Sandro Bonazzola 
>>> wrote:
>>>


 2017-09-29 9:29 GMT+02:00 Maton, Brett :

> It all got a bit messy, but that's probably down to me.
>
>   I removed the 'old' ovirt repo definitions after I installed the 4.2
> pre release repo (simply because yum was complaining about multiple
> definitions).
>
>   I also allowed the installer to clean-up the old database directory,
> which it did.
>   The updated PostgreSQL server stayed up and running which stopped
> 4.1 from starting the version of PostgreSQL that it wanted running (port 
> in
> use I expect) etc etc etc
>
> So no in this particular case roll back failed, but there are a bunch
> of warnings issued but engine-setup that that would probably happen.
>
> I've attached the engine-setup-log as requested.
>

 Thanks!
 I see that the failure is:
 YumDownloadError:
 Errors were encountered while downloading packages.
 ovirt-engine-wildfly-10.1.0-1.el7.x86_64: Insufficient space in
 download directory /var/cache/yum/x86_64/7/ovirt-4.1/packages
 * free   67 M
 * needed 130 M

 We may consider to run "yum clean packages" before starting rollback to
 free space there.
 Did you have keepcache=1 in your yum.conf?



>
> Best regards,
> Brett
>
> On 29 September 2017 at 07:24, Sandro Bonazzola 
> wrote:
>
>>
>>
>> 2017-09-28 20:29 GMT+02:00 Maton, Brett :
>>
>>> Thanks Tomas,
>>>
>>>   I'm restoring backup at the moment, I'll let you know how it goes
>>> when on the next attempt.
>>>
>>
>> Didn't the setup rollback automatically? Can you please share the
>> setup logs?
>>
>>
>>
>>
>>>
>>> On 28 September 2017 at 18:46, Tomas Jelinek 
>>> wrote:
>>>
 Hey Brett,

 That is strange - it looks like you have some VM which has memory
 size larger than the max memory size.

 You need to go over your VMs / templates to find which one has this
 wrong config and change it.
 Alternatively, to find it faster if you have many vms/templates,
 you could run this SQL query against your engine database:
 select vm_name from vm_static where mem_size_mb >
 max_memory_size_mb;

 Tomas

 On Thu, Sep 28, 2017 at 6:07 PM, Maton, Brett <
 mat...@ltresources.co.uk> wrote:

> Upgrading from oVirt 4.1.7
>
> hosted-engine VM:
> 4GB RAM
>
> hosted-engine setup failed, setup log shows this error:
>
> Running upgrade sql script '/usr/share/ovirt-engine/dbscr
> ipts/upgrade/04_02_0140_add_max_memory_constraint.sql'...
>
> 2017-09-28 16:56:22,951+0100 DEBUG 
> otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema
> plugin.execute:926 execute-output: 
> ['/usr/share/ovirt-engine/dbscripts/schema.sh',
> '-s', 'localhost', '-p', '5432', '-u', 'engine', '-d', 'engine', '-l',
> '/var/log/ovirt-engine/setup/ovirt-engine-setup-20170928164338-0rkilb.log',
> '-c', 'apply'] stderr:
> psql:/usr/share/ovirt-engine/dbscripts/upgrade/04_02_0140_add_max_memory_constraint.sql:2:
> ERROR:  check constraint "vm_static_max_memory_size_lower_bound"
> is violated by some row
> FATAL: Cannot execute sql command: --file=/usr/share/ovirt-engine
> /dbscripts/upgrade/04_02_0140_add_max_memory_constraint.sql
>
> 2017-09-28 16:56:22,951+0100 ERROR 
> otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema
> schema._misc:374 schema.sh: FATAL: Cannot execute sql command:
> --file=/usr/share/ovirt-engine/dbscripts/upgrade/04_02_0140_
> add_max_memory_constraint.sql
> 2017-09-28 16:56:22,952+0100 DEBUG otopi.context
> context._executeMethod:143 method exception
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/otopi/context.py", line
> 1

Re: [ovirt-users] oVirt 4.2 alpha upgrade failed

[Maton, Brett]

Ah ok,

  So assuming there was enough space the rollback should have put the
engine back to it's previous state.

On 29 September 2017 at 09:38, Sandro Bonazzola  wrote:

>
>
> 2017-09-29 9:58 GMT+02:00 Maton, Brett :
>
>> That log appears to be the only one I have, the more recent ones are the
>> restore and then successful install of 4.2.
>>
>> I just checked yum.conf and no, keepcache is off (0)
>>
>> I didn't see any errors when engine-setup downloaded the packages, it
>> failed/stopped during the db migration / upgrade.
>>
>
> Yes, sorry, the out of space error is happening in the rollback from the
> failure during the database migration.
>
>
>
>>
>>
>> Brett
>>
>> On 29 September 2017 at 08:41, Sandro Bonazzola 
>> wrote:
>>
>>>
>>>
>>> 2017-09-29 9:29 GMT+02:00 Maton, Brett :
>>>
 It all got a bit messy, but that's probably down to me.

   I removed the 'old' ovirt repo definitions after I installed the 4.2
 pre release repo (simply because yum was complaining about multiple
 definitions).

   I also allowed the installer to clean-up the old database directory,
 which it did.
   The updated PostgreSQL server stayed up and running which stopped 4.1
 from starting the version of PostgreSQL that it wanted running (port in use
 I expect) etc etc etc

 So no in this particular case roll back failed, but there are a bunch
 of warnings issued but engine-setup that that would probably happen.

 I've attached the engine-setup-log as requested.

>>>
>>> Thanks!
>>> I see that the failure is:
>>> YumDownloadError:
>>> Errors were encountered while downloading packages.
>>> ovirt-engine-wildfly-10.1.0-1.el7.x86_64: Insufficient space in
>>> download directory /var/cache/yum/x86_64/7/ovirt-4.1/packages
>>> * free   67 M
>>> * needed 130 M
>>>
>>> We may consider to run "yum clean packages" before starting rollback to
>>> free space there.
>>> Did you have keepcache=1 in your yum.conf?
>>>
>>>
>>>

 Best regards,
 Brett

 On 29 September 2017 at 07:24, Sandro Bonazzola 
 wrote:

>
>
> 2017-09-28 20:29 GMT+02:00 Maton, Brett :
>
>> Thanks Tomas,
>>
>>   I'm restoring backup at the moment, I'll let you know how it goes
>> when on the next attempt.
>>
>
> Didn't the setup rollback automatically? Can you please share the
> setup logs?
>
>
>
>
>>
>> On 28 September 2017 at 18:46, Tomas Jelinek 
>> wrote:
>>
>>> Hey Brett,
>>>
>>> That is strange - it looks like you have some VM which has memory
>>> size larger than the max memory size.
>>>
>>> You need to go over your VMs / templates to find which one has this
>>> wrong config and change it.
>>> Alternatively, to find it faster if you have many vms/templates, you
>>> could run this SQL query against your engine database:
>>> select vm_name from vm_static where mem_size_mb > max_memory_size_mb;
>>>
>>> Tomas
>>>
>>> On Thu, Sep 28, 2017 at 6:07 PM, Maton, Brett <
>>> mat...@ltresources.co.uk> wrote:
>>>
 Upgrading from oVirt 4.1.7

 hosted-engine VM:
 4GB RAM

 hosted-engine setup failed, setup log shows this error:

 Running upgrade sql script '/usr/share/ovirt-engine/dbscr
 ipts/upgrade/04_02_0140_add_max_memory_constraint.sql'...

 2017-09-28 16:56:22,951+0100 DEBUG 
 otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema
 plugin.execute:926 execute-output: 
 ['/usr/share/ovirt-engine/dbscripts/schema.sh',
 '-s', 'localhost', '-p', '5432', '-u', 'engine', '-d', 'engine', '-l',
 '/var/log/ovirt-engine/setup/ovirt-engine-setup-20170928164338-0rkilb.log',
 '-c', 'apply'] stderr:
 psql:/usr/share/ovirt-engine/dbscripts/upgrade/04_02_0140_add_max_memory_constraint.sql:2:
 ERROR:  check constraint "vm_static_max_memory_size_lower_bound"
 is violated by some row
 FATAL: Cannot execute sql command: --file=/usr/share/ovirt-engine
 /dbscripts/upgrade/04_02_0140_add_max_memory_constraint.sql

 2017-09-28 16:56:22,951+0100 ERROR 
 otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema
 schema._misc:374 schema.sh: FATAL: Cannot execute sql command:
 --file=/usr/share/ovirt-engine/dbscripts/upgrade/04_02_0140_
 add_max_memory_constraint.sql
 2017-09-28 16:56:22,952+0100 DEBUG otopi.context
 context._executeMethod:143 method exception
 Traceback (most recent call last):
   File "/usr/lib/python2.7/site-packages/otopi/context.py", line
 133, in _executeMethod
 method['method']()
   File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-s
 etup/ovirt-engine/db/schema.py", line 376, in _misc
 raise RuntimeError(_('Engine schema re

Re: [ovirt-users] Failure while using ovirt-image-template role

[Ondra Machacek]

On Thu, Sep 28, 2017 at 12:23 AM, Marc Seward  wrote:
> Hi,
>
> I'm trying to use the ovirt-image-template role to import a Glance image as
> a template into ovirt and I'm running into this error with
> python-ovirt-engine-sdk4-4.1.6-1.el7ev.x86_64
>
> I'd appreciate any pointers.
>
>
> TASK [ovirt.ovirt-ansible-roles/roles/ovirt-image-template : Find data
> domain]
> 
> task path:
> /etc/ansible/roles/ovirt.ovirt-ansible-roles/roles/ovirt-image-template/tasks/glance_image.yml:21
> fatal: [localhost]: FAILED! => {
> "failed": true,
> "msg": "You need to install \"jmespath\" prior to running json_query
> filter"

What version of Ansible/ovirt-ansible-roles do you use?
Ansible 2.3.2 has a dependency for jmespath, and so ovirt-ansble 1.0.3.

> }
>
> TASK [ovirt.ovirt-ansible-roles/roles/ovirt-image-template : Logout from
> oVirt] ***
>
> ___
> 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] oVirt 4.2 alpha upgrade failed

[Sandro Bonazzola]

2017-09-29 9:58 GMT+02:00 Maton, Brett :

> That log appears to be the only one I have, the more recent ones are the
> restore and then successful install of 4.2.
>
> I just checked yum.conf and no, keepcache is off (0)
>
> I didn't see any errors when engine-setup downloaded the packages, it
> failed/stopped during the db migration / upgrade.
>

Yes, sorry, the out of space error is happening in the rollback from the
failure during the database migration.



>
>
> Brett
>
> On 29 September 2017 at 08:41, Sandro Bonazzola 
> wrote:
>
>>
>>
>> 2017-09-29 9:29 GMT+02:00 Maton, Brett :
>>
>>> It all got a bit messy, but that's probably down to me.
>>>
>>>   I removed the 'old' ovirt repo definitions after I installed the 4.2
>>> pre release repo (simply because yum was complaining about multiple
>>> definitions).
>>>
>>>   I also allowed the installer to clean-up the old database directory,
>>> which it did.
>>>   The updated PostgreSQL server stayed up and running which stopped 4.1
>>> from starting the version of PostgreSQL that it wanted running (port in use
>>> I expect) etc etc etc
>>>
>>> So no in this particular case roll back failed, but there are a bunch of
>>> warnings issued but engine-setup that that would probably happen.
>>>
>>> I've attached the engine-setup-log as requested.
>>>
>>
>> Thanks!
>> I see that the failure is:
>> YumDownloadError:
>> Errors were encountered while downloading packages.
>> ovirt-engine-wildfly-10.1.0-1.el7.x86_64: Insufficient space in download
>> directory /var/cache/yum/x86_64/7/ovirt-4.1/packages
>> * free   67 M
>> * needed 130 M
>>
>> We may consider to run "yum clean packages" before starting rollback to
>> free space there.
>> Did you have keepcache=1 in your yum.conf?
>>
>>
>>
>>>
>>> Best regards,
>>> Brett
>>>
>>> On 29 September 2017 at 07:24, Sandro Bonazzola 
>>> wrote:
>>>


 2017-09-28 20:29 GMT+02:00 Maton, Brett :

> Thanks Tomas,
>
>   I'm restoring backup at the moment, I'll let you know how it goes
> when on the next attempt.
>

 Didn't the setup rollback automatically? Can you please share the setup
 logs?




>
> On 28 September 2017 at 18:46, Tomas Jelinek 
> wrote:
>
>> Hey Brett,
>>
>> That is strange - it looks like you have some VM which has memory
>> size larger than the max memory size.
>>
>> You need to go over your VMs / templates to find which one has this
>> wrong config and change it.
>> Alternatively, to find it faster if you have many vms/templates, you
>> could run this SQL query against your engine database:
>> select vm_name from vm_static where mem_size_mb > max_memory_size_mb;
>>
>> Tomas
>>
>> On Thu, Sep 28, 2017 at 6:07 PM, Maton, Brett <
>> mat...@ltresources.co.uk> wrote:
>>
>>> Upgrading from oVirt 4.1.7
>>>
>>> hosted-engine VM:
>>> 4GB RAM
>>>
>>> hosted-engine setup failed, setup log shows this error:
>>>
>>> Running upgrade sql script '/usr/share/ovirt-engine/dbscr
>>> ipts/upgrade/04_02_0140_add_max_memory_constraint.sql'...
>>>
>>> 2017-09-28 16:56:22,951+0100 DEBUG 
>>> otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema
>>> plugin.execute:926 execute-output: 
>>> ['/usr/share/ovirt-engine/dbscripts/schema.sh',
>>> '-s', 'localhost', '-p', '5432', '-u', 'engine', '-d', 'engine', '-l',
>>> '/var/log/ovirt-engine/setup/ovirt-engine-setup-20170928164338-0rkilb.log',
>>> '-c', 'apply'] stderr:
>>> psql:/usr/share/ovirt-engine/dbscripts/upgrade/04_02_0140_add_max_memory_constraint.sql:2:
>>> ERROR:  check constraint "vm_static_max_memory_size_lower_bound" is
>>> violated by some row
>>> FATAL: Cannot execute sql command: --file=/usr/share/ovirt-engine
>>> /dbscripts/upgrade/04_02_0140_add_max_memory_constraint.sql
>>>
>>> 2017-09-28 16:56:22,951+0100 ERROR 
>>> otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema
>>> schema._misc:374 schema.sh: FATAL: Cannot execute sql command:
>>> --file=/usr/share/ovirt-engine/dbscripts/upgrade/04_02_0140_
>>> add_max_memory_constraint.sql
>>> 2017-09-28 16:56:22,952+0100 DEBUG otopi.context
>>> context._executeMethod:143 method exception
>>> Traceback (most recent call last):
>>>   File "/usr/lib/python2.7/site-packages/otopi/context.py", line
>>> 133, in _executeMethod
>>> method['method']()
>>>   File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-s
>>> etup/ovirt-engine/db/schema.py", line 376, in _misc
>>> raise RuntimeError(_('Engine schema refresh failed'))
>>> RuntimeError: Engine schema refresh failed
>>>
>>>
>>>
>>> What's the minimum RAM required now ?
>>>
>>> Regards,
>>> Brett
>>>
>>> ___
>>> Users mailing list
>>> Users@ovirt.org
>>> http://lists.ovirt.o

Re: [ovirt-users] [ovirt-announce] [ANN] oVirt 4.2.0 First Alpha Release is now available for testing

[Yaniv Kaul]

On Sep 28, 2017 6:23 PM, "Gianluca Cecchi" 
wrote:

On Thu, Sep 28, 2017 at 5:06 PM, Sandro Bonazzola 
wrote:

> The oVirt Project is pleased to announce the availability of the First
> Alpha Release of oVirt 4.2.0, as of September 28th, 2017
>
>
>
Good news!
Any chance of having ISO and Export domains on storage types that are not
NFS in 4.2?


Unlikely for the export domain, which we'd like to deprecate its use.
The ISO domain will work on, not sure for 4.2.
Y.



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

Re: [ovirt-users] oVirt 4.2 alpha upgrade failed

[Maton, Brett]

That log appears to be the only one I have, the more recent ones are the
restore and then successful install of 4.2.

I just checked yum.conf and no, keepcache is off (0)

I didn't see any errors when engine-setup downloaded the packages, it
failed/stopped during the db migration / upgrade.

Brett

On 29 September 2017 at 08:41, Sandro Bonazzola  wrote:

>
>
> 2017-09-29 9:29 GMT+02:00 Maton, Brett :
>
>> It all got a bit messy, but that's probably down to me.
>>
>>   I removed the 'old' ovirt repo definitions after I installed the 4.2
>> pre release repo (simply because yum was complaining about multiple
>> definitions).
>>
>>   I also allowed the installer to clean-up the old database directory,
>> which it did.
>>   The updated PostgreSQL server stayed up and running which stopped 4.1
>> from starting the version of PostgreSQL that it wanted running (port in use
>> I expect) etc etc etc
>>
>> So no in this particular case roll back failed, but there are a bunch of
>> warnings issued but engine-setup that that would probably happen.
>>
>> I've attached the engine-setup-log as requested.
>>
>
> Thanks!
> I see that the failure is:
> YumDownloadError:
> Errors were encountered while downloading packages.
> ovirt-engine-wildfly-10.1.0-1.el7.x86_64: Insufficient space in download
> directory /var/cache/yum/x86_64/7/ovirt-4.1/packages
> * free   67 M
> * needed 130 M
>
> We may consider to run "yum clean packages" before starting rollback to
> free space there.
> Did you have keepcache=1 in your yum.conf?
>
>
>
>>
>> Best regards,
>> Brett
>>
>> On 29 September 2017 at 07:24, Sandro Bonazzola 
>> wrote:
>>
>>>
>>>
>>> 2017-09-28 20:29 GMT+02:00 Maton, Brett :
>>>
 Thanks Tomas,

   I'm restoring backup at the moment, I'll let you know how it goes
 when on the next attempt.

>>>
>>> Didn't the setup rollback automatically? Can you please share the setup
>>> logs?
>>>
>>>
>>>
>>>

 On 28 September 2017 at 18:46, Tomas Jelinek 
 wrote:

> Hey Brett,
>
> That is strange - it looks like you have some VM which has memory size
> larger than the max memory size.
>
> You need to go over your VMs / templates to find which one has this
> wrong config and change it.
> Alternatively, to find it faster if you have many vms/templates, you
> could run this SQL query against your engine database:
> select vm_name from vm_static where mem_size_mb > max_memory_size_mb;
>
> Tomas
>
> On Thu, Sep 28, 2017 at 6:07 PM, Maton, Brett <
> mat...@ltresources.co.uk> wrote:
>
>> Upgrading from oVirt 4.1.7
>>
>> hosted-engine VM:
>> 4GB RAM
>>
>> hosted-engine setup failed, setup log shows this error:
>>
>> Running upgrade sql script '/usr/share/ovirt-engine/dbscr
>> ipts/upgrade/04_02_0140_add_max_memory_constraint.sql'...
>>
>> 2017-09-28 16:56:22,951+0100 DEBUG 
>> otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema
>> plugin.execute:926 execute-output: 
>> ['/usr/share/ovirt-engine/dbscripts/schema.sh',
>> '-s', 'localhost', '-p', '5432', '-u', 'engine', '-d', 'engine', '-l',
>> '/var/log/ovirt-engine/setup/ovirt-engine-setup-20170928164338-0rkilb.log',
>> '-c', 'apply'] stderr:
>> psql:/usr/share/ovirt-engine/dbscripts/upgrade/04_02_0140_add_max_memory_constraint.sql:2:
>> ERROR:  check constraint "vm_static_max_memory_size_lower_bound" is
>> violated by some row
>> FATAL: Cannot execute sql command: --file=/usr/share/ovirt-engine
>> /dbscripts/upgrade/04_02_0140_add_max_memory_constraint.sql
>>
>> 2017-09-28 16:56:22,951+0100 ERROR 
>> otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema
>> schema._misc:374 schema.sh: FATAL: Cannot execute sql command:
>> --file=/usr/share/ovirt-engine/dbscripts/upgrade/04_02_0140_
>> add_max_memory_constraint.sql
>> 2017-09-28 16:56:22,952+0100 DEBUG otopi.context
>> context._executeMethod:143 method exception
>> Traceback (most recent call last):
>>   File "/usr/lib/python2.7/site-packages/otopi/context.py", line
>> 133, in _executeMethod
>> method['method']()
>>   File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-s
>> etup/ovirt-engine/db/schema.py", line 376, in _misc
>> raise RuntimeError(_('Engine schema refresh failed'))
>> RuntimeError: Engine schema refresh failed
>>
>>
>>
>> What's the minimum RAM required now ?
>>
>> Regards,
>> Brett
>>
>> ___
>> 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


>>>
>>>
>>> --
>>>
>>> SANDRO BONAZZOLA
>>>
>>> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTU

Re: [ovirt-users] oVirt 4.2 alpha upgrade failed

[Maton, Brett]

Hmm, let me see if there's another setup log

It was the SQL issue that caused the real problem, running out of space
during yum updates on my 'tiny' hosted engine vm isn't that uncommon...

On 29 September 2017 at 08:41, Sandro Bonazzola  wrote:

>
>
> 2017-09-29 9:29 GMT+02:00 Maton, Brett :
>
>> It all got a bit messy, but that's probably down to me.
>>
>>   I removed the 'old' ovirt repo definitions after I installed the 4.2
>> pre release repo (simply because yum was complaining about multiple
>> definitions).
>>
>>   I also allowed the installer to clean-up the old database directory,
>> which it did.
>>   The updated PostgreSQL server stayed up and running which stopped 4.1
>> from starting the version of PostgreSQL that it wanted running (port in use
>> I expect) etc etc etc
>>
>> So no in this particular case roll back failed, but there are a bunch of
>> warnings issued but engine-setup that that would probably happen.
>>
>> I've attached the engine-setup-log as requested.
>>
>
> Thanks!
> I see that the failure is:
> YumDownloadError:
> Errors were encountered while downloading packages.
> ovirt-engine-wildfly-10.1.0-1.el7.x86_64: Insufficient space in download
> directory /var/cache/yum/x86_64/7/ovirt-4.1/packages
> * free   67 M
> * needed 130 M
>
> We may consider to run "yum clean packages" before starting rollback to
> free space there.
> Did you have keepcache=1 in your yum.conf?
>
>
>
>>
>> Best regards,
>> Brett
>>
>> On 29 September 2017 at 07:24, Sandro Bonazzola 
>> wrote:
>>
>>>
>>>
>>> 2017-09-28 20:29 GMT+02:00 Maton, Brett :
>>>
 Thanks Tomas,

   I'm restoring backup at the moment, I'll let you know how it goes
 when on the next attempt.

>>>
>>> Didn't the setup rollback automatically? Can you please share the setup
>>> logs?
>>>
>>>
>>>
>>>

 On 28 September 2017 at 18:46, Tomas Jelinek 
 wrote:

> Hey Brett,
>
> That is strange - it looks like you have some VM which has memory size
> larger than the max memory size.
>
> You need to go over your VMs / templates to find which one has this
> wrong config and change it.
> Alternatively, to find it faster if you have many vms/templates, you
> could run this SQL query against your engine database:
> select vm_name from vm_static where mem_size_mb > max_memory_size_mb;
>
> Tomas
>
> On Thu, Sep 28, 2017 at 6:07 PM, Maton, Brett <
> mat...@ltresources.co.uk> wrote:
>
>> Upgrading from oVirt 4.1.7
>>
>> hosted-engine VM:
>> 4GB RAM
>>
>> hosted-engine setup failed, setup log shows this error:
>>
>> Running upgrade sql script '/usr/share/ovirt-engine/dbscr
>> ipts/upgrade/04_02_0140_add_max_memory_constraint.sql'...
>>
>> 2017-09-28 16:56:22,951+0100 DEBUG 
>> otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema
>> plugin.execute:926 execute-output: 
>> ['/usr/share/ovirt-engine/dbscripts/schema.sh',
>> '-s', 'localhost', '-p', '5432', '-u', 'engine', '-d', 'engine', '-l',
>> '/var/log/ovirt-engine/setup/ovirt-engine-setup-20170928164338-0rkilb.log',
>> '-c', 'apply'] stderr:
>> psql:/usr/share/ovirt-engine/dbscripts/upgrade/04_02_0140_add_max_memory_constraint.sql:2:
>> ERROR:  check constraint "vm_static_max_memory_size_lower_bound" is
>> violated by some row
>> FATAL: Cannot execute sql command: --file=/usr/share/ovirt-engine
>> /dbscripts/upgrade/04_02_0140_add_max_memory_constraint.sql
>>
>> 2017-09-28 16:56:22,951+0100 ERROR 
>> otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema
>> schema._misc:374 schema.sh: FATAL: Cannot execute sql command:
>> --file=/usr/share/ovirt-engine/dbscripts/upgrade/04_02_0140_
>> add_max_memory_constraint.sql
>> 2017-09-28 16:56:22,952+0100 DEBUG otopi.context
>> context._executeMethod:143 method exception
>> Traceback (most recent call last):
>>   File "/usr/lib/python2.7/site-packages/otopi/context.py", line
>> 133, in _executeMethod
>> method['method']()
>>   File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-s
>> etup/ovirt-engine/db/schema.py", line 376, in _misc
>> raise RuntimeError(_('Engine schema refresh failed'))
>> RuntimeError: Engine schema refresh failed
>>
>>
>>
>> What's the minimum RAM required now ?
>>
>> Regards,
>> Brett
>>
>> ___
>> 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


>>>
>>>
>>> --
>>>
>>> SANDRO BONAZZOLA
>>>
>>> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
>>>
>>> Red Hat EMEA 
>>> 
>>> TRIED. TESTED. 

Re: [ovirt-users] oVirt 4.2 alpha upgrade failed

[Sandro Bonazzola]

2017-09-29 9:29 GMT+02:00 Maton, Brett :

> It all got a bit messy, but that's probably down to me.
>
>   I removed the 'old' ovirt repo definitions after I installed the 4.2 pre
> release repo (simply because yum was complaining about multiple
> definitions).
>
>   I also allowed the installer to clean-up the old database directory,
> which it did.
>   The updated PostgreSQL server stayed up and running which stopped 4.1
> from starting the version of PostgreSQL that it wanted running (port in use
> I expect) etc etc etc
>
> So no in this particular case roll back failed, but there are a bunch of
> warnings issued but engine-setup that that would probably happen.
>
> I've attached the engine-setup-log as requested.
>

Thanks!
I see that the failure is:
YumDownloadError:
Errors were encountered while downloading packages.
ovirt-engine-wildfly-10.1.0-1.el7.x86_64: Insufficient space in download
directory /var/cache/yum/x86_64/7/ovirt-4.1/packages
* free   67 M
* needed 130 M

We may consider to run "yum clean packages" before starting rollback to
free space there.
Did you have keepcache=1 in your yum.conf?



>
> Best regards,
> Brett
>
> On 29 September 2017 at 07:24, Sandro Bonazzola 
> wrote:
>
>>
>>
>> 2017-09-28 20:29 GMT+02:00 Maton, Brett :
>>
>>> Thanks Tomas,
>>>
>>>   I'm restoring backup at the moment, I'll let you know how it goes when
>>> on the next attempt.
>>>
>>
>> Didn't the setup rollback automatically? Can you please share the setup
>> logs?
>>
>>
>>
>>
>>>
>>> On 28 September 2017 at 18:46, Tomas Jelinek 
>>> wrote:
>>>
 Hey Brett,

 That is strange - it looks like you have some VM which has memory size
 larger than the max memory size.

 You need to go over your VMs / templates to find which one has this
 wrong config and change it.
 Alternatively, to find it faster if you have many vms/templates, you
 could run this SQL query against your engine database:
 select vm_name from vm_static where mem_size_mb > max_memory_size_mb;

 Tomas

 On Thu, Sep 28, 2017 at 6:07 PM, Maton, Brett >>> > wrote:

> Upgrading from oVirt 4.1.7
>
> hosted-engine VM:
> 4GB RAM
>
> hosted-engine setup failed, setup log shows this error:
>
> Running upgrade sql script '/usr/share/ovirt-engine/dbscr
> ipts/upgrade/04_02_0140_add_max_memory_constraint.sql'...
>
> 2017-09-28 16:56:22,951+0100 DEBUG 
> otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema
> plugin.execute:926 execute-output: 
> ['/usr/share/ovirt-engine/dbscripts/schema.sh',
> '-s', 'localhost', '-p', '5432', '-u', 'engine', '-d', 'engine', '-l',
> '/var/log/ovirt-engine/setup/ovirt-engine-setup-20170928164338-0rkilb.log',
> '-c', 'apply'] stderr:
> psql:/usr/share/ovirt-engine/dbscripts/upgrade/04_02_0140_add_max_memory_constraint.sql:2:
> ERROR:  check constraint "vm_static_max_memory_size_lower_bound" is
> violated by some row
> FATAL: Cannot execute sql command: --file=/usr/share/ovirt-engine
> /dbscripts/upgrade/04_02_0140_add_max_memory_constraint.sql
>
> 2017-09-28 16:56:22,951+0100 ERROR 
> otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema
> schema._misc:374 schema.sh: FATAL: Cannot execute sql command:
> --file=/usr/share/ovirt-engine/dbscripts/upgrade/04_02_0140_
> add_max_memory_constraint.sql
> 2017-09-28 16:56:22,952+0100 DEBUG otopi.context
> context._executeMethod:143 method exception
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/otopi/context.py", line 133,
> in _executeMethod
> method['method']()
>   File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-s
> etup/ovirt-engine/db/schema.py", line 376, in _misc
> raise RuntimeError(_('Engine schema refresh failed'))
> RuntimeError: Engine schema refresh failed
>
>
>
> What's the minimum RAM required now ?
>
> Regards,
> Brett
>
> ___
> 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
>>>
>>>
>>
>>
>> --
>>
>> SANDRO BONAZZOLA
>>
>> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
>>
>> Red Hat EMEA 
>> 
>> TRIED. TESTED. TRUSTED. 
>> 
>>
>
>


-- 

SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D

Red Hat EMEA 

TRIED. TESTED. TRUSTED. 

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.or