> On 06 Jul 2016, at 23:15, Matt . wrote:
>
> OK, due some not having done PgSQL for a long time I didn't select the
> engine DB that well.
>
> Thanks, this is a good fix where I already noticed the same snapshot
> ID already by searching through the tables and looking what's going on
> there.
OK, due some not having done PgSQL for a long time I didn't select the
engine DB that well.
Thanks, this is a good fix where I already noticed the same snapshot
ID already by searching through the tables and looking what's going on
there.
2016-07-06 14:41 GMT+02:00 Matt . :
> HI,
>
> Thanks for
- Original Message -
> El 2016-07-06 11:11, nico...@devels.es escribió:
> > Hi Arik,
> >
> > El 2016-07-06 10:27, Arik Hadas escribió:
> >> Hi,
> >>
> >> This is a bit aggressive solution to remove all snapshots with the
> >> memory.
> >>
> >> Can you confirm that a storage domain that
You need to do this in the 'engine' database instead of 'postgres'.
El 2016-07-06 13:41, Matt . escribió:
HI,
Thanks for the solution, I actually get:
postgres=# select vm_name, snapshots.description as snapshot_name,
snapshot_id from snapshots join vm_static on vm_id=vm_guid where
CAST(split_
El 2016-07-06 11:11, nico...@devels.es escribió:
Hi Arik,
El 2016-07-06 10:27, Arik Hadas escribió:
Hi,
This is a bit aggressive solution to remove all snapshots with the
memory.
Can you confirm that a storage domain that was active while creating
the snapshot with memory was removed from t
HI,
Thanks for the solution, I actually get:
postgres=# select vm_name, snapshots.description as snapshot_name,
snapshot_id from snapshots join vm_static on vm_id=vm_guid where
CAST(split_part(memory_volume, ',', 1) AS UUID) not in (select id from
storage_domain_static);
ERROR: relation "snapsho
Hi Arik,
El 2016-07-06 10:27, Arik Hadas escribió:
Hi,
This is a bit aggressive solution to remove all snapshots with the
memory.
Can you confirm that a storage domain that was active while creating
the snapshot with memory was removed from the system?
This is something that was not covered
Hi,
This is a bit aggressive solution to remove all snapshots with the memory.
Can you confirm that a storage domain that was active while creating the
snapshot with memory was removed from the system?
This is something that was not covered and could lead to the reported issue.
Until we come up
Hi,
We have had a similar issue when upgrading, digging into it we found out
that this was caused by snapshots that had the "Save memory" option
enabled. We finally ended up deleting any snapshot that had this option
enabled and then we tried to upgrade, this time the process went smooth.
Ho
OK some update on this.
Removed the db-migrate-script package and reinstalled ovirt-engine and
ovirt-engine-setup.
I still have that error and this is the loggingpart:
CONTEXT: SQL statement "DROP INDEX IF EXISTS
idx_vm_static_template_version_name; CREATE INDEX
idx_vm_static_template_version_
I just found out that the file
04_00_0140_convert_memory_snapshots_to_disks.sql
is not located in:
/usr/share/ovirt-engine/dbscripts/upgrade/
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
Hi,
I'm upgrading to oVirt 4.0 from 3.6.7 and I didn't found any usable
solution for this error and rollback:
[ ERROR ] schema.sh: FATAL: Cannot execute sql command:
--file=/usr/share/ovirt-engine/dbscripts/upgrade/04_00_0140_convert_memory_snapshots_to_disks.sql
[ ERROR ] Failed to execute stage
12 matches
Mail list logo
