Re: [Users] (no subject)
On Wed 02 Apr 2014 04:48:12 PM IDT, Stefan Wendler wrote:
On Wednesday 02 April 2014 16:16:34 Roy Golan wrote:
an upgrade to 3.3 should have run an upgrade script [1] and update all vms with 6 to 0 (the new internal id of other)
can you run this sql [2] to see if it did ran?
[1] 03_03_0660_alter_os_type_unassigned_to_other.sql [2] psql engine engine -c "select * from schema_version where script ilike '%unassigned%';"
The query [2] returns "0 rows"
this upgrade is from 3.3.4 to 3.4 i think. did you ever upgraded from 3.2 to 3.3? if yes then we need that upgrade log. more directions - did you anytime override the osinfo files or added some custom ones? please paste the content of /etc/ovirt-engine/osinfo.conf.d and /usr/share/ovirt-engine/conf/osinfo-defaults.properties if non of this has relevant results than its totally safe to run the script above mentioned [1]
On Wed 02 Apr 2014 04:48:12 PM IDT, Stefan Wendler wrote:
On Wednesday 02 April 2014 16:16:34 Roy Golan wrote:
an upgrade to 3.3 should have run an upgrade script [1] and update all vms with 6 to 0 (the new internal id of other)
can you run this sql [2] to see if it did ran?
[1] 03_03_0660_alter_os_type_unassigned_to_other.sql [2] psql engine engine -c "select * from schema_version where script ilike '%unassigned%';"
The query [2] returns "0 rows"
this upgrade is from 3.3.4 to 3.4 i think. did you ever upgraded from 3.2 to 3.3? if yes then we need that upgrade log. AFAIR we started with 3.3 on our production environment. Yes this is from 3.3.4 to 3.4. We had 3.3.0 before and I upgraded to 3.3.4 before going to 3.4
more directions - did you anytime override the osinfo files or added some custom ones? please paste the content of /etc/ovirt-engine/osinfo.conf.d and /usr/share/ovirt-engine/conf/osinfo-defaults.properties /usr/share/ovirt-engine/conf/osinfo-defaults.properties of the centos rpm with
On Thursday 03 April 2014 13:05:36 Roy Golan wrote: the one from the current sources. But it didn't work before that. I just replaced them to check if this would fix it. Until then I never heard of this osinfo file so I never changed/replaced it before.
if non of this has relevant results than its totally safe to run the script above mentioned [1]
This is the distribution of "os-types" in our database: engine=# select count(*), os from vm_static group by os order by os; count | os -------+------ 5 | 0 3 | 1 1 | 4 46 | 5 1 | 11 1 | 12 1 | 16 1 | 1501 (8 rows) So it wouldn't make much sense to execute the "03_03_0660_alter_os_type_unassigned_to_other.sql" ? Regarding the config I send you a link to the tgz with all files. I don't want to put the link public because it is my private server with not so much bandwith ;) Cheers, Stefan
On 04/03/2014 01:37 PM, Stefan Wendler wrote:
On Wednesday 02 April 2014 16:16:34 Roy Golan wrote:
an upgrade to 3.3 should have run an upgrade script [1] and update all vms with 6 to 0 (the new internal id of other)
can you run this sql [2] to see if it did ran?
[1] 03_03_0660_alter_os_type_unassigned_to_other.sql [2] psql engine engine -c "select * from schema_version where script ilike '%unassigned%';" The query [2] returns "0 rows"
On Wed 02 Apr 2014 04:48:12 PM IDT, Stefan Wendler wrote: this upgrade is from 3.3.4 to 3.4 i think. did you ever upgraded from 3.2 to 3.3? if yes then we need that upgrade log. AFAIR we started with 3.3 on our production environment. Yes this is from 3.3.4 to 3.4. We had 3.3.0 before and I upgraded to 3.3.4 before going to 3.4 more directions - did you anytime override the osinfo files or added some custom ones? please paste the content of /etc/ovirt-engine/osinfo.conf.d and /usr/share/ovirt-engine/conf/osinfo-defaults.properties /usr/share/ovirt-engine/conf/osinfo-defaults.properties of the centos rpm with
On Thursday 03 April 2014 13:05:36 Roy Golan wrote: the one from the current sources. But it didn't work before that. I just replaced them to check if this would fix it. Until then I never heard of this osinfo file so I never changed/replaced it before.
if non of this has relevant results than its totally safe to run the script above mentioned [1] This is the distribution of "os-types" in our database:
engine=# select count(*), os from vm_static group by os order by os; count | os -------+------ 5 | 0 3 | 1 1 | 4 46 | 5 1 | 11 1 | 12 1 | 16 1 | 1501 (8 rows)
So it wouldn't make much sense to execute the "03_03_0660_alter_os_type_unassigned_to_other.sql" ? of course not I forgot you already removed the VM with os id 6.
Regarding the config I send you a link to the tgz with all files. I don't want to put the link public because it is my private server with not so much bandwith ;)
Cheers, Stefan
----- Original Message -----
From: "Roy Golan" <rgolan@redhat.com> To: "Stefan Wendler" <stefan.wendler@tngtech.com> Cc: users@ovirt.org Sent: Thursday, April 3, 2014 1:05:36 PM Subject: Re: [Users] (no subject)
On Wed 02 Apr 2014 04:48:12 PM IDT, Stefan Wendler wrote:
On Wednesday 02 April 2014 16:16:34 Roy Golan wrote:
an upgrade to 3.3 should have run an upgrade script [1] and update all vms with 6 to 0 (the new internal id of other)
can you run this sql [2] to see if it did ran?
[1] 03_03_0660_alter_os_type_unassigned_to_other.sql [2] psql engine engine -c "select * from schema_version where script ilike '%unassigned%';"
The query [2] returns "0 rows"
IMO we need to investigate why this script was not running , any chance to get the DB backup before this upgrade for analysis ?
this upgrade is from 3.3.4 to 3.4 i think. did you ever upgraded from 3.2 to 3.3? if yes then we need that upgrade log.
If this is the case, upgrade is supported first from 3.2 to 3.3 and just after this is completed to 3.4 AFAIK
more directions - did you anytime override the osinfo files or added some custom ones? please paste the content of /etc/ovirt-engine/osinfo.conf.d and /usr/share/ovirt-engine/conf/osinfo-defaults.properties
if non of this has relevant results than its totally safe to run the script above mentioned [1]
This may solve the specific issue but we should understand why this script was not run at the first place in order to fix any potential problem.
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
participants (3)
-
Eli Mesika -
Roy Golan -
Stefan Wendler