Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1412594 - Listing VMs from KVM fails with error "java.lang.NumberFormatException" if one of the VM is having non-existent disk
Summary: Listing VMs from KVM fails with error "java.lang.NumberFormatException" if on...
Status: CLOSED DUPLICATE of bug 1405058
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.0.6
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Nobody
QA Contact: meital avital
Depends On:
TreeView+ depends on / blocked
Reported: 2017-01-12 11:56 UTC by nijin ashok
Modified: 2020-02-14 18:32 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-01-18 08:14:28 UTC
oVirt Team: Virt
Target Upstream Version:

Attachments (Terms of Use)
log.tar.xz (910.00 KB, application/x-tar)
2017-01-12 11:59 UTC, nijin ashok
no flags Details

Description nijin ashok 2017-01-12 11:56:31 UTC
Description of problem:

If any of the VMs in the source KVM host has disk entry which doesn't exist in the server, then GetVmsFromExternalProviderVDSCommand fails with error "java.lang.NumberFormatException".  vdsm will show below error.

jsonrpc.Executor/1::ERROR::2017-01-12 09:47:54,049::v2v::934::root::(_add_disk_info) Error getting disk size
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/vdsm/v2v.py", line 931, in _add_disk_info
    vol = conn.storageVolLookupByPath(disk['alias'])
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 4765, in storageVolLookupByPath
    if ret is None:raise libvirtError('virStorageVolLookupByPath() failed', conn=self)
libvirtError: Storage volume not found: no storage vol with matching path

The vdsm will be return the image information without  "capacity" and "allocation" info as expected.

Return 'Host.getExternalVMs' in bridge with [{'status': 'Down', 'graphics': 'vnc', 'arch': 'x86_64', 'disks': [{'alias': '/var/lib/libvirt/images/new_testing.img', 'type': 'disk', 'dev': 'vda', 'format': 'RAW'},

However this is not correctly handled in the engine side and we will get below error in the engine side.

2017-01-12 06:20:23,033 ERROR [org.ovirt.engine.core.bll.GetVmsFromExternalProviderQuery] (default task-3) [] Query 'GetVmsFromExternalProviderQuery' failed: EngineException: java.lang.NumberFormatException: null (Failed with error ENGINE and code 5001)
2017-01-12 06:20:23,033 ERROR [org.ovirt.engine.core.bll.GetVmsFromExternalProviderQuery] (default task-3) [] Exception: org.ovirt.engine.core.common.errors.EngineException: EngineException: java.lang.NumberFormatException: null (Failed with error ENGINE and code 5001)

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:

1. In a KVM host, give a random disk image  to one of the VM which is not in the server.

2. Listing KVM VMs from the RHEV-M fails with error "java.lang.NumberFormatException"

Actual results:

Listing KVM VMs from the RHEV-M fails with error "java.lang.NumberFormatException" if any of the VM contains non-existent disk .

Expected results:

It will not be possible to convert any of the KVM VMs if one of the VM is having non-existent disk. I think we should ignore this particular VM from showing in the RHEV-M portal and show other VMs by providing a meaningful warning message to user.

Additional info:

Comment 1 nijin ashok 2017-01-12 11:59:46 UTC
Created attachment 1239862 [details]

Comment 2 Tomas Jelinek 2017-01-16 12:53:45 UTC
@Tomas: is this duplicate of 1405058

Comment 3 Tomáš Golembiovský 2017-01-16 14:57:32 UTC
No the issue is different. From the logs it seems the customer is trying to import KVM machine with block devices. This should be available in 4.1: https://bugzilla.redhat.com/show_bug.cgi?id=1378340

Nijin, can you verify that the VMs in question contain drives with block devices? Or can you provide us dump of libvirt XML?

Comment 4 nijin ashok 2017-01-16 15:47:10 UTC
The logs which I have uploaded is from my test environment to replicate the customer's issue. It's not using block devices. Also customer is not using block devices for VM disks. Load VMs was failing with NumberFormatException if any of the VM  contains a disk which is not accessible.

I think this is similar to  bug 1405058 which Tomas Jelinek have mentioned. I have applied https://gerrit.ovirt.org/#/c/69139/ in my test setup  which fixed the issue. vdsm ignores the VM  which is having inaccessible disk and this VM information is not passed to engine .

Comment 5 Tomáš Golembiovský 2017-01-16 20:41:56 UTC
I reviewed the logs again. It really is a duplicate of bug 1405058.

Comment 6 Tomas Jelinek 2017-01-18 08:14:28 UTC
Thank you! Marking as duplicate.

*** This bug has been marked as a duplicate of bug 1405058 ***

Note You need to log in before you can comment on or make changes to this bug.