This is a multi-part message in MIME format.
------=_NextPartTM-000-5802def7-8591-46cf-8b94-a356fc728609
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hello Chris,=0A=
=0A=
I'm sorry I can't help you here. I'm quite new to this list and just saw so=
me kind=0A=
of coincidence between our problems. From my observations I would say that=
=0A=
the engine breaks the settings. At least in my case the webinterface compon=
ent=0A=
that does not fill calls in the background correctly. From my understanding=
VDSM =0A=
& libvirt should only be fed by the engine. =0A=
=0A=
My idea would be to have a look at the database table/view vm_device and it=
s=0A=
column address. A quick look before and after could show differences. =0A=
=0A=
su - postgres=0A=
psql engine postgres -q -n -c "select * from vm_device where type=3D'disk=
';"=0A=
=0A=
Take care! I could be totally wrong.=0A=
=0A=
Best regards.=0A=
=0A=
Markus=0A=
=0A=
________________________________________=0A=
Von: SULLIVAN, Chris (WGK) [Chris.Sullivan(a)woodgroupkenny.com]=0A=
Gesendet: Freitag, 13. September 2013 10:53=0A=
An: Markus Stockhausen; users(a)ovirt.org=0A=
Betreff: RE: [Users] oVirt 3.3 -- Failed to run VM: internal error unexpect=
ed address type for ide disk=0A=
=0A=
Hi Markus,=0A=
=0A=
Thanks for your email. I followed your instructions (detach/attach virtio d=
isks, also tried detach/remove/add/attach virtio disks as well) however the=
VMs still fail to start with the same error.=0A=
=0A=
Note that the issue persists after upgrading to oVirt 3.3.0-3 while keeping=
VDSM/libvirt the same.=0A=
=0A=
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 libvi=
rt/VDSM sending bad information back to the engine during the destruction p=
rocess, or something else?=0A=
=0A=
Cheers,=0A=
=0A=
Chris=0A=
=0A=
=0A=
=0A=
PLEASE CONSIDER THE ENVIRONMENT, DON'T PRINT THIS EMAIL UNLESS YOU REALLY N=
EED TO.=0A=
=0A=
This email and its attachments may contain information which is confidentia=
l 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-mai=
l 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 c=
ontents of this email or its attachments or permit anyone else to do so.=0A=
=0A=
-----------------------------=0A=
=0A=
-----Original Message-----=0A=
From: Markus Stockhausen [mailto:stockhausen@collogia.de]=0A=
Sent: Friday, September 13, 2013 4:03 PM=0A=
To: SULLIVAN, Chris (WGK); users(a)ovirt.org=0A=
Subject: AW: [Users] oVirt 3.3 -- Failed to run VM: internal error unexpect=
ed address type for ide disk=0A=
=0A=
Von: users-bounces(a)ovirt.org [users-bounces(a)ovirt.org]"
im=0A=
Auftrag von "SULLIVAN, Chris (WGK)=0A=
[Chris.Sullivan(a)woodgroupkenny.com]=0A=
Gesendet: Freitag, 13. September 2013 08:00=0A=
An: users(a)ovirt.org=0A=
Betreff: Re: [Users] oVirt 3.3 -- Failed to run VM: internal error=0A=
unexpected address type for ide disk=0A=
=0A=
Hi,=0A=
=0A=
I am getting the exact same issue with a non-AIO oVirt 3.3.0-2.fc19=0A=
setup. The only workaround I've found so far is to delete the offending V=
M,
recreate, and reattach the disks. The recreated VM will work normally un=
til it is shutdown, after which it will fail to start with the same error.=
=0A=
=0A=
Engine and VDSM log excepts below. Versions:=0A=
- Fedora 19 (3.10.10-200)=0A=
- oVirt 3.3.0-2=0A=
- VDSM 4.12.1=0A=
- libvirt 1.1.2-1=0A=
- gluster 3.4.0.8=0A=
=0A=
I'll upgrade to the latest oVirt 3.3 RC to see if the issue persists.=0A=
=0A=
Kind regards,=0A=
=0A=
Chris=0A=
=0A=
Hello,=0A=
=0A=
not so critical but I had a similar error after switching disk from virtio =
to virtio-scsi.=0A=
http://lists.ovirt.org/pipermail/users/2013-September/016256.html. In this =
case a simple detach/attach process solved the problem permanently.=0A=
=0A=
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.=0A=
=0A=
Markus=0A=
------=_NextPartTM-000-5802def7-8591-46cf-8b94-a356fc728609
Content-Type: text/plain;
name="InterScan_Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="InterScan_Disclaimer.txt"
****************************************************************************
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser Mail ist nicht gestattet.
Über das Internet versandte E-Mails können unter fremden Namen erstellt oder
manipuliert werden. Deshalb ist diese als E-Mail verschickte Nachricht keine
rechtsverbindliche Willenserklärung.
Collogia
Unternehmensberatung AG
Ubierring 11
D-50678 Köln
Vorstand:
Kadir Akin
Dr. Michael Höhnerbach
Vorsitzender des Aufsichtsrates:
Hans Kristian Langva
Registergericht: Amtsgericht Köln
Registernummer: HRB 52 497
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
e-mails sent over the internet may have been written under a wrong name or
been manipulated. That is why this message sent as an e-mail is not a
legally binding declaration of intention.
Collogia
Unternehmensberatung AG
Ubierring 11
D-50678 Köln
executive board:
Kadir Akin
Dr. Michael Höhnerbach
President of the supervisory board:
Hans Kristian Langva
Registry office: district court Cologne
Register number: HRB 52 497
****************************************************************************
------=_NextPartTM-000-5802def7-8591-46cf-8b94-a356fc728609--