Re: [Users] oVirt 3.3 -- Failed to run VM: internal error unexpected address type for ide disk
On Sep 13, 2013, at 18:33 , Jason Brooks jbro...@redhat.com wrote:
I filed a bug: https://bugzilla.redhat.com/show_bug.cgi?id=1007980
Thanks,
we're looking at it but don't know yet if it's on engine side(more likely) or
vdsm
any special setup setting?
gluster doesn't seem to be related
Thanks,
michal
- Original Message -
From: Jason Brooks jbro...@redhat.com
To: users users@ovirt.org
Sent: Thursday, September 12, 2013 1:45:49 PM
Subject: [Users] oVirt 3.3 -- Failed to run VM: internal error unexpected
address type for ide disk
I'm experiencing an issue today on my oVirt 3.3 test setup -- it's an AIO
engine+host setup, with a second node on a separate machine. Both machines
are running F19, both have all current F19 updates and all current ovirt-
beta repo updates.
This is on a GlusterFS domain, hosted from a volume on the AIO machine.
Also, I have the neutron external network provider configured, but these
VMs aren't using one of these networks.
selinux permissive on both machines, firewall down on both as well
(firewall rules for gluster don't appear to be set by the engine)
1. Create a new VM w/ virtio disk
2. VM runs normally
3. Power down VM
4. VM won't start, w/ error msg:
internal error unexpected address type for ide disk
5. Changing disk to IDE, removing and re-adding, VM still won't start
6. If created w/ IDE disk from the beginning, VM runs and restarts as
expected.
Is anyone else experiencing something like this? It appears to render the
Gluster FS domain type totally unusable. I wasn't having this problem last
week...
Here's a chunk from the VDSM log:
Thread-4526::ERROR::2013-09-12 16:02:53,199::vm::2062::vm.Vm::
(_startUnderlyingVm) vmId=`cc86596b-0a69-4f5e-a4c2-e8d8ca18067e`::
The vm start process failed
Traceback (most recent call last):
File /usr/share/vdsm/vm.py, line 2022, in _startUnderlyingVm
self._run()
File /usr/share/vdsm/vm.py, line 2906, in _run
self._connection.createXML(domxml, flags),
File /usr/lib64/python2.7/site-packages/vdsm/libvirtconnection.py,
line 76, in wrapper
ret = f(*args, **kwargs)
File /usr/lib64/python2.7/site-packages/libvirt.py, line 2805, in
createXML
if ret is None:raise libvirtError('virDomainCreateXML() failed',
conn=self)
libvirtError: internal error unexpected address type for ide disk
Regards,
Jason
---
Jason Brooks
Red Hat Open Source and Standards
@jasonbrooks | @redhatopen
http://community.redhat.com
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] oVirt 3.3 -- Failed to run VM: internal error unexpected address type for ide disk
::task::1168::TaskManager.Task::(prepare)
Task=`19501aff-60ce-46f4-b3c6-63cb8b6d8598`::finished: None
Thread-143930::DEBUG::2013-09-12
15:01:22,301::task::579::TaskManager.Task::(_updateState)
Task=`19501aff-60ce-46f4-b3c6-63cb8b6d8598`::moving from state preparing -
state finished
Thread-143930::DEBUG::2013-09-12
15:01:22,301::resourceManager::939::ResourceManager.Owner::(releaseAll)
Owner.releaseAll requests {} resources
{'Storage.e281bd49-bc11-4acb-8634-624eac6d3358': ResourceRef
'Storage.e281bd49-bc11-4acb-8634-624eac6d3358', isValid: 'True' obj: 'None'}
Thread-143930::DEBUG::2013-09-12
15:01:22,301::resourceManager::976::ResourceManager.Owner::(cancelAll)
Owner.cancelAll requests {}
Thread-143930::DEBUG::2013-09-12
15:01:22,302::resourceManager::615::ResourceManager::(releaseResource) Trying
to release resource 'Storage.e281bd49-bc11-4acb-8634-624eac6d3358'
Thread-143930::DEBUG::2013-09-12
15:01:22,302::resourceManager::634::ResourceManager::(releaseResource) Released
resource 'Storage.e281bd49-bc11-4acb-8634-624eac6d3358' (0 active users)
Thread-143930::DEBUG::2013-09-12
15:01:22,302::resourceManager::640::ResourceManager::(releaseResource) Resource
'Storage.e281bd49-bc11-4acb-8634-624eac6d3358' is free, finding out if anyone
is waiting for it.
Thread-143930::DEBUG::2013-09-12
15:01:22,302::resourceManager::648::ResourceManager::(releaseResource) No one
is waiting for resource 'Storage.e281bd49-bc11-4acb-8634-624eac6d3358',
Clearing records.
Thread-143930::DEBUG::2013-09-12
15:01:22,303::task::974::TaskManager.Task::(_decref)
Task=`19501aff-60ce-46f4-b3c6-63cb8b6d8598`::ref 0 aborting False
Thread-143930::WARNING::2013-09-12 15:01:22,303::utils::113::root::(rmFile)
File:
/var/lib/libvirt/qemu/channels/980cb3c8-8af8-4795-9c21-85582d37e042.com.redhat.rhevm.vdsm
already removed
Thread-143930::WARNING::2013-09-12 15:01:22,303::utils::113::root::(rmFile)
File:
/var/lib/libvirt/qemu/channels/980cb3c8-8af8-4795-9c21-85582d37e042.org.qemu.guest_agent.0
already removed
Thread-143930::DEBUG::2013-09-12
15:01:22,304::task::579::TaskManager.Task::(_updateState)
Task=`277b0c74-d3f2-4a8a-aa18-3084bbd591cf`::moving from state init - state
preparing
Thread-143930::INFO::2013-09-12
15:01:22,304::logUtils::44::dispatcher::(wrapper) Run and protect:
inappropriateDevices(thiefId='980cb3c8-8af8-4795-9c21-85582d37e042')
Thread-143930::INFO::2013-09-12
15:01:22,306::logUtils::47::dispatcher::(wrapper) Run and protect:
inappropriateDevices, Return response: None
Thread-143930::DEBUG::2013-09-12
15:01:22,306::task::1168::TaskManager.Task::(prepare)
Task=`277b0c74-d3f2-4a8a-aa18-3084bbd591cf`::finished: None
Thread-143930::DEBUG::2013-09-12
15:01:22,307::task::579::TaskManager.Task::(_updateState)
Task=`277b0c74-d3f2-4a8a-aa18-3084bbd591cf`::moving from state preparing -
state finished
Thread-143930::DEBUG::2013-09-12
15:01:22,307::resourceManager::939::ResourceManager.Owner::(releaseAll)
Owner.releaseAll requests {} resources {}
Thread-143930::DEBUG::2013-09-12
15:01:22,307::resourceManager::976::ResourceManager.Owner::(cancelAll)
Owner.cancelAll requests {}
Thread-143930::DEBUG::2013-09-12
15:01:22,307::task::974::TaskManager.Task::(_decref)
Task=`277b0c74-d3f2-4a8a-aa18-3084bbd591cf`::ref 0 aborting False
Thread-143930::DEBUG::2013-09-12 15:01:22,307::vm::4252::vm.Vm::(deleteVm)
vmId=`980cb3c8-8af8-4795-9c21-85582d37e042`::Total desktops after destroy of
980cb3c8-8af8-4795-9c21-85582d37e042 is 0
Thread-143930::DEBUG::2013-09-12
15:01:22,307::BindingXMLRPC::986::vds::(wrapper) return vmDestroy with
{'status': {'message': 'Machine destroyed', 'code': 0}}
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: users-boun...@ovirt.org [mailto:users-boun...@ovirt.org] On Behalf Of
users-requ...@ovirt.org
Sent: Friday, September 13, 2013 7:03 AM
To: users@ovirt.org
Subject: Users Digest, Vol 24, Issue 54
Message: 5
Date: Thu, 12 Sep 2013 16:45:49 -0400 (EDT)
From: Jason Brooks jbro...@redhat.com
To: users users@ovirt.org
Subject: [Users] oVirt 3.3 -- Failed to run VM: internal error
unexpected address type for ide disk
Message-ID:
1080415344.14385259.1379018749875.javamail.r...@redhat.com
Content-Type: text/plain; charset=utf-8
I'm experiencing an issue today on my oVirt 3.3 test setup -- it's an AIO
engine+host setup, with a second node on a separate machine. Both machines
are running F19, both have all current F19 updates
Re: [Users] oVirt 3.3 -- Failed to run VM: internal error unexpected address type for ide disk
Von: users-boun...@ovirt.org [users-boun...@ovirt.org]quot; im Auftrag von quot;SULLIVAN, Chris (WGK) [chris.sulli...@woodgroupkenny.com] Gesendet: Freitag, 13. September 2013 08:00 An: users@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 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 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
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:stockhau...@collogia.de] Sent: Friday, September 13, 2013 4:03 PM To: SULLIVAN, Chris (WGK); users@ovirt.org Subject: AW: [Users] oVirt 3.3 -- Failed to run VM: internal error unexpected address type for ide disk Von: users-boun...@ovirt.org [users-boun...@ovirt.org]quot; im Auftrag von quot;SULLIVAN, Chris (WGK) [chris.sulli...@woodgroupkenny.com] Gesendet: Freitag, 13. September 2013 08:00 An: users@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 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] oVirt 3.3 -- Failed to run VM: internal error unexpected address type for ide disk
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.sulli...@woodgroupkenny.com] Gesendet: Freitag, 13. September 2013 10:53 An: Markus Stockhausen; users@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:stockhau...@collogia.de] Sent: Friday, September 13, 2013 4:03 PM To: SULLIVAN, Chris (WGK); users@ovirt.org Subject: AW: [Users] oVirt 3.3 -- Failed to run VM: internal error unexpected address type for ide disk Von: users-boun...@ovirt.org [users-boun...@ovirt.org]quot; im Auftrag von quot;SULLIVAN, Chris (WGK) [chris.sulli...@woodgroupkenny.com] Gesendet: Freitag, 13. September 2013 08:00 An: users@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 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
Re: [Users] oVirt 3.3 -- Failed to run VM: internal error unexpected address type for ide disk
I filed a bug: https://bugzilla.redhat.com/show_bug.cgi?id=1007980
- Original Message -
From: Jason Brooks jbro...@redhat.com
To: users users@ovirt.org
Sent: Thursday, September 12, 2013 1:45:49 PM
Subject: [Users] oVirt 3.3 -- Failed to run VM: internal error unexpected
address type for ide disk
I'm experiencing an issue today on my oVirt 3.3 test setup -- it's an AIO
engine+host setup, with a second node on a separate machine. Both machines
are running F19, both have all current F19 updates and all current ovirt-
beta repo updates.
This is on a GlusterFS domain, hosted from a volume on the AIO machine.
Also, I have the neutron external network provider configured, but these
VMs aren't using one of these networks.
selinux permissive on both machines, firewall down on both as well
(firewall rules for gluster don't appear to be set by the engine)
1. Create a new VM w/ virtio disk
2. VM runs normally
3. Power down VM
4. VM won't start, w/ error msg:
internal error unexpected address type for ide disk
5. Changing disk to IDE, removing and re-adding, VM still won't start
6. If created w/ IDE disk from the beginning, VM runs and restarts as
expected.
Is anyone else experiencing something like this? It appears to render the
Gluster FS domain type totally unusable. I wasn't having this problem last
week...
Here's a chunk from the VDSM log:
Thread-4526::ERROR::2013-09-12 16:02:53,199::vm::2062::vm.Vm::
(_startUnderlyingVm) vmId=`cc86596b-0a69-4f5e-a4c2-e8d8ca18067e`::
The vm start process failed
Traceback (most recent call last):
File /usr/share/vdsm/vm.py, line 2022, in _startUnderlyingVm
self._run()
File /usr/share/vdsm/vm.py, line 2906, in _run
self._connection.createXML(domxml, flags),
File /usr/lib64/python2.7/site-packages/vdsm/libvirtconnection.py,
line 76, in wrapper
ret = f(*args, **kwargs)
File /usr/lib64/python2.7/site-packages/libvirt.py, line 2805, in
createXML
if ret is None:raise libvirtError('virDomainCreateXML() failed',
conn=self)
libvirtError: internal error unexpected address type for ide disk
Regards,
Jason
---
Jason Brooks
Red Hat Open Source and Standards
@jasonbrooks | @redhatopen
http://community.redhat.com
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
[Users] oVirt 3.3 -- Failed to run VM: internal error unexpected address type for ide disk
I'm experiencing an issue today on my oVirt 3.3 test setup -- it's an AIO
engine+host setup, with a second node on a separate machine. Both machines
are running F19, both have all current F19 updates and all current ovirt-
beta repo updates.
This is on a GlusterFS domain, hosted from a volume on the AIO machine.
Also, I have the neutron external network provider configured, but these
VMs aren't using one of these networks.
selinux permissive on both machines, firewall down on both as well
(firewall rules for gluster don't appear to be set by the engine)
1. Create a new VM w/ virtio disk
2. VM runs normally
3. Power down VM
4. VM won't start, w/ error msg:
internal error unexpected address type for ide disk
5. Changing disk to IDE, removing and re-adding, VM still won't start
6. If created w/ IDE disk from the beginning, VM runs and restarts as
expected.
Is anyone else experiencing something like this? It appears to render the
Gluster FS domain type totally unusable. I wasn't having this problem last
week...
Here's a chunk from the VDSM log:
Thread-4526::ERROR::2013-09-12 16:02:53,199::vm::2062::vm.Vm::
(_startUnderlyingVm) vmId=`cc86596b-0a69-4f5e-a4c2-e8d8ca18067e`::
The vm start process failed
Traceback (most recent call last):
File /usr/share/vdsm/vm.py, line 2022, in _startUnderlyingVm
self._run()
File /usr/share/vdsm/vm.py, line 2906, in _run
self._connection.createXML(domxml, flags),
File /usr/lib64/python2.7/site-packages/vdsm/libvirtconnection.py,
line 76, in wrapper
ret = f(*args, **kwargs)
File /usr/lib64/python2.7/site-packages/libvirt.py, line 2805, in createXML
if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self)
libvirtError: internal error unexpected address type for ide disk
Regards,
Jason
---
Jason Brooks
Red Hat Open Source and Standards
@jasonbrooks | @redhatopen
http://community.redhat.com
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
