Hi,
Thanks, but I couldn't wait and didn't anticipate that there would be
anything I could do to repair the database manually. I have nuked my old
engine configuration and created a new one.
It would be great if we could update the bug report with an actual
diagnosis and description of what operations can lead to corruption of
the engine database. I mistakenly assumed (from the synopsis
ImportVmTemplateParameters fails") that it only stemmed from Template
imports, but it seems to affect VM imports as well (I discovered after
corrupting two subsequent engine databases).
Is there going to be a backport of this bug to ovirt-stable, or will we
need to wait for 3.1.1? What is the timeframe for 3.1.1 final release?
Thanks,
Bob
On 11/14/2013 04:31 AM, Roy Golan wrote:
On 12/11/13 10:52 PM, Bob Doolittle wrote:
> Well, this looks to me like an instance of
>
https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=996005
>
> That bug has not been updated in almost 3 months, however. The last
> note says "Working on CI". Does that mean Code Integration? It looks
> like maybe it was fixed in version "is10", whatever that is, and is
> currently Verified by QA. Is that right?
>
> Unfortunately that bug report has no description whatsoever of what
> the underlying problem was. I would like to know:
> 1. Is there any workaround?
> 2. Can I start again by re-installing Engine and importing, or is the
> issue with the exported VMs and/or template so I'd just hit the
> problem again?
>
> It sort of looks like the problem was with a template
> (org.ovirt.engine.core.common.action.ImportVmTemplateParameters). If
> so, can I import the VMs and avoid the Templates? Or am I perhaps
> misinterpreting that message?
>
> Shouldn't bug reports always contain some sort of diagnostic
> information about the underlying cause and/or workarounds?
>
> Thanks,
> Bob
>
> On 11/12/2013 03:08 PM, Bob Doolittle wrote:
>> Hi,
>>
>> I had a working engine, using 3.3.0 on Fedora 19. I rebooted my
>> engine, and JBoss AS won't come back up. I get the attached errors
>> from server.log.
>>
>> Has anyone seen this before? Any suggestions on how to recover?
>>
>> How I got here:
>>
>> I had a working Engine (mach1 F19) and Host (mach2 F19), but needed
>> to play some musical chairs with my hardware to utilize a 3rd
>> machine (mach3 RH6). My goal is to have mach2 become Engine, and
>> mach3 Host.
>>
>> I did the following:
>> 1. Created an NFS share on mach3, and used it as NFS Export Storage
>> from mach2.
>> 2. Exported my VMs and templates to the Export storage.
>> 3. Removed mach2 from my Datacenter
>> 4. Shut down mach1
>> 5. Installed fresh F19 on mach2 (my old host), and installed Engine
>> 3.3.0 on it
>> 6. Added mach3 as Host
>> 7. Imported my VMs and Templates from the Export Storage
>>
>> At this point all looked well. I rebooted mach2, but it won't come
>> back up.
>>
>> I'd appreciate any insight.
>>
>> Thanks,
>> Bob
>>
>
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
>
http://lists.ovirt.org/mailman/listinfo/users
Hi Bob and thanks for the feedback
indeed there is no diagnose in the bug and that will be fixed.
Now let see if we can get this working - in the async task table
there is a JSON structure with an attribute describing disks - diskMap
problem is that its missing a concrete java type java.util.HashMap
please paste the output of:
psql ovirt postgres -x -c 'select task_parameters from async_tasks;'
| grep -i diskmap
Roy
its missing a we can try to modify it
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users