Yeah, that looks like the fix Red Hat GSS came up with. Note that is only
online snapshots that we've seen the problem with, never offline but YMMV.
What version of oVirt are you running? We're running RHEV 3.5.7 in prod
and test environments but 3.6.5 in dev and we've not had a re-occurrence of
Hi,
I solved my problem, here are the steps but be carefully if you don't
know what the commands did and how to restore from backup don't follow this:
- ssh to the host
- systemctl stop ovirt-engine
- backup the database with "engine-backup"
- navigate to the image files
- backup the images: sudo
Hi,
The host are marked as up with two "Action Items":
- A new version is available.
- Power Management is not configured for this Host
The update information seems wrong, because lately I installed updates
with engine-setup and after this I updated yum like my other host. On
the other host there
Thanks for sharing the information's, I check the file structure and
database entries. I had problems with too long names during coding a
oVirt backup tool [1]. Here is a limitations list [2]. There was the
problem that a Windows VM name can only be 15 characters long, others
can named with 64 char
Sound's bad. Recreating the VM is no way because this is a productive
VM. During testing I need to recreate it more than once. oVirt works
perfect which Linux VM's but when it comes to Windows VM's we get lots
of problems.
Which OS you used on the problematic VM?
cheers
gregor
On 11/06/16 19:22,
Hi,
could you please share server.log/engine.log? And what's the status of the
host reported in webadmin?
Thanks
Martin Perina
On Sat, Jun 11, 2016 at 5:06 PM, gregor wrote:
> Hi,
>
> during inspecting the engine.log I found this entry:
>
> -
> [org.ovirt.engine.core.uutils.ssh.
6 matches
Mail list logo