[Users] oVirt 3.3 -- Failed to run VM: internal error unexpected address type for ide disk

[Markus Stockhausen]

Hello Chris,

I'm sorry I can't help you here. I'm quite new to this list and just saw some kind
of coincidence between our problems. From my observations I would say that
the engine breaks the settings. At least in my case the webinterface component
that does not fill calls in the background correctly. From my understanding VDSM 
& libvirt should only be fed by the engine. 

My idea would be to have a look at the database table/view vm_device and its
column address. A quick look before and after could show differences. 

> su - postgres
> psql engine postgres -q -n -c "select * from vm_device where type='disk';"

Take care! I could be totally wrong.

Best regards.

Markus

________________________________________
Von: SULLIVAN, Chris (WGK) [Chris.Sullivan at woodgroupkenny.com]
Gesendet: Freitag, 13. September 2013 10:53
An: Markus Stockhausen; users at ovirt.org
Betreff: RE: [Users] oVirt 3.3 -- Failed to run VM: internal error unexpected address type for ide disk

Hi Markus,

Thanks for your email. I followed your instructions (detach/attach virtio disks, also tried detach/remove/add/attach virtio disks as well) however the VMs still fail to start with the same error.

Note that the issue persists after upgrading to oVirt 3.3.0-3 while keeping VDSM/libvirt the same.

I'm not too familiar with the whole VM creation/destruction process - where would the root cause of the problem likely be? Is it ovirt-engine breaking the VM definition file when it records the VM as being shut down, or libvirt/VDSM sending bad information back to the engine during the destruction process, or something else?

Cheers,

Chris



PLEASE CONSIDER THE ENVIRONMENT, DON'T PRINT THIS EMAIL UNLESS YOU REALLY NEED TO.

This email and its attachments may contain information which is confidential and/or legally privileged. If you are not the intended recipient of this e-mail please notify the sender immediately by e-mail and delete this e-mail and its attachments from your computer and IT systems. You must not copy, re-transmit, use or disclose (other than to the sender) the existence or contents of this email or its attachments or permit anyone else to do so.

-----------------------------

-----Original Message-----
From: Markus Stockhausen [mailto:stockhausen at collogia.de]
Sent: Friday, September 13, 2013 4:03 PM
To: SULLIVAN, Chris (WGK); users at ovirt.org
Subject: AW: [Users] oVirt 3.3 -- Failed to run VM: internal error unexpected address type for ide disk

> Von: users-bounces at ovirt.org [users-bounces at ovirt.org]" im
> Auftrag von "SULLIVAN, Chris (WGK)
> [Chris.Sullivan at woodgroupkenny.com]
> Gesendet: Freitag, 13. September 2013 08:00
> An: users at ovirt.org
> Betreff: Re: [Users] oVirt 3.3 -- Failed to run VM: internal error
> unexpected address type for ide disk
>
> Hi,
>
> I am getting the exact same issue with a non-AIO oVirt 3.3.0-2.fc19
> setup. The only workaround I've found so far is to delete the offending VM, recreate, and reattach the disks. The recreated VM will work normally until it  is shutdown, after which it will fail to start with the same error.
>
> Engine and VDSM log excepts below. Versions:
> - Fedora 19 (3.10.10-200)
> - oVirt 3.3.0-2
> - VDSM 4.12.1
> - libvirt 1.1.2-1
> - gluster 3.4.0.8
>
> I'll upgrade to the latest oVirt 3.3 RC to see if the issue persists.
>
> Kind regards,
>
> Chris

Hello,

not so critical but I had a similar error after switching disk from virtio to virtio-scsi.
http://lists.ovirt.org/pipermail/users/2013-September/016256.html. In this case a simple detach/attach process solved the problem permanently.

To check we have no regressions I patched to 3.3.0-2 in my NFS based setup with Virtio-SCSI disks to test your findings. Luckly the "loose your disks after every reboot" does not occur.

Markus
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: InterScan_Disclaimer.txt
URL: <http://lists.ovirt.org/pipermail/users/attachments/20130913/928c465f/attachment-0001.txt>