11:34 a.m.
Hello Shahar,
I've rebuild my test system and installed recently released ovirt 4.0.5 + gerrit patch
=> still no luck. vdsm always gives me same error :
"
jsonrpc.Executor/6::ERROR::2016-11-17 16:38:56,320::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 4596, in
storageVolLookupByPath
if ret is None:raise libvirtError('virStorageVolLookupByPath() failed',
conn=self)
libvirtError: Volume de stockage introuvable : no storage vol with matching path
'/dev/sdc'
jsonrpc.Executor/6::DEBUG::2016-11-17
16:38:56,325::__init__::555::jsonrpc.JsonRpcServer::(_handle_request) Return
'Host.getExternalVMs' in bridge with [{'status': 'Down',
'graphics': 'spice', 'arch': 'x86_64', 'disks': [
{'capacity': '8589934592', 'format': 'RAW', 'dev':
'hdd', 'allocation': '8589942784', 'alias': '/
var/lib/libvirt/images/rhel7.1.img', 'type': 'disk'},
{'alias': '/dev/sdc', 'type': 'disk', 'dev':
'hdb', 'format': 'RAW'}], 'vmId':
'd0ddc4f6-a208-4286-a665-fb9e54d14bef', 'smp': 1, 'has_snapshots':
False, 'video': 'qxl', 'memSize': 1 024, 'vmName':
'rhel7.1', 'networks': [{'model': 'virtio',
'macAddr': '52:54:00:00:d7:76', 'type': 'network'}]}]
"
FYI I added a normal disk (file based) to the VM ir order to try to understand what's
happening. As expected, this disk is seen by the oVirt (without patch)
I do reckon something in the above log :
'disks': [
{'capacity': '8589934592', 'format': 'RAW',
'dev': 'hdd', 'allocation': '8589942784', 'alias':
'/ var/lib/libvirt/images/rhel7.1.img', 'type': 'disk'},
{'alias': '/dev/sdc', 'type': 'disk', 'dev':
'hdb', 'format': 'RAW'}
],
the "alias" line is clearly new since it did not appear before de patch!
something is working ;)
I confirm that when I created the test VM (via virt-manager), I gave directly the path to
the device (/dev/sdc), so there is no "pool" to be addressed defined on libvirt!
I read https://gerrit.ovirt.org/#/c/64272/4/ and I agree with Tomas findings : Currently
the conversion process is expecting a volume on a pool and it's not able to use a
block device directly.
So I'm hopping a solution can be found to this problem. We have a few hundreds VM
waiting to be migrated in production and we don't have a NFS server, so this is our
only option so far.
I'm able to test any patch quickly if needed, do not hesitate.
cordialement, regards,
Nelson LAMEIRAS
Lyra Network
Service Projets et Processus
Tel : +33 (0) 5 32 09 09 70
109 rue de l’innovation
31670 Labège - France
www.lyra-network.com
----- Original Message -----
From: "Shahar Havivi" <shavivi(a)redhat.com>
To: "Nelson Lameiras" <nelson.lameiras(a)lyra-network.com>
Cc: "Tomas Golembiovsky" <tgolembi(a)redhat.com>, "Michal
Skrivanek" <michal.skrivanek(a)redhat.com>, users(a)ovirt.org
Sent: Tuesday, November 8, 2016 12:16:55 PM
Subject: Re: [ovirt-users] can't import vm from KVM host
On 08.11.16 10:58, Nelson Lameiras wrote:
Hi Shahar,
We try to prioritise vm behaviour predictability over ressources consumption, so
"thin provisionning" is not a option for us. "Preallocated" is always
selected over default behaviour.
Nevertheless, while trying to import a KVM vm (from another host), I get a 0 disk count
on the VM, which means I do not event get to the point where I can chose allocation policy
(usually next screen).
This is true with or without patch proposed below (assuming it has not changed since sept
29).
I assume that this line is failing:
vol = conn.storageVolLookupByPath(disk['alias'])
it may be the reason that the storage is not part of a pool.
(look at pool-xxx commands via virsh)
If it doesn't work it may be related to a different API that we will need to
implement as Tomas suggested in the gerrit patch.
Can I give you any more information?
cordialement, regards,
Nelson LAMEIRAS
Lyra Network
Service Projets et Processus
Tel : +33 (0) 5 32 09 09 70
109 rue de l’innovation
31670 Labège - France
www.lyra-network.com
----- Original Message -----
From: "Shahar Havivi" <shavivi(a)redhat.com>
To: "Nelson Lameiras" <nelson.lameiras(a)lyra-network.com>, "Tomas
Golembiovsky" <tgolembi(a)redhat.com>
Cc: "Michal Skrivanek" <michal.skrivanek(a)redhat.com>, users(a)ovirt.org
Sent: Monday, November 7, 2016 1:58:34 PM
Subject: Re: [ovirt-users] can't import vm from KVM host
Hi Nelson,
Sorry for the long wait (I was on PTO).
I just test the patch with the following disk xml:
<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='none'
io='native'/>
<source dev='/dev/disk/by-path/...lun0'/>
<target dev='vda' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x07' function='0x0'/>
</disk>
I did manage to see the disk with its actual size,
I was able to import the VM as well when I choose:
"Allocation Policy": "Preallocated"
(not the "Thin Provision" as is the default.
Currently we need to pre allocated kvm block disk and cannot use the thin
provision (we may need to disable it in the UI).
Did you try that?
It may related to the reason that the dev path you have is a /dev/mapper/ and
this is the reason that libvirt not returning the disk size? (Tomas?)
Shahar.
On 20.10.16 14:10, Nelson Lameiras wrote:
> Hello,
>
> Any update on this issue?
> Can I do anything to help?
>
> cordialement, regards,
> Nelson LAMEIRAS
>
> Lyra Network
> Service Projets et Processus
> Tel : +33 (0) 5 32 09 09 70
> 109 rue de l’innovation
> 31670 Labège - France
> www.lyra-network.com
>
> ----- Original Message -----
> From: "Michal Skrivanek" <michal.skrivanek(a)redhat.com>
> To: "Tomas Golembiovsky" <tgolembi(a)redhat.com>
> Cc: "Nelson Lameiras" <nelson.lameiras(a)lyra-network.com>,
users(a)ovirt.org
> Sent: Tuesday, October 11, 2016 4:11:36 PM
> Subject: Re: [ovirt-users] can't import vm from KVM host
>
> > On 11 Oct 2016, at 16:01, Tomáš Golembiovský <tgolembi(a)redhat.com>
wrote:
> >
> > Hi,
> >
> > On Mon, 10 Oct 2016 12:21:47 +0200 (CEST)
> > Nelson Lameiras <nelson.lameiras(a)lyra-network.com> wrote:
> >
> >> hello michal,
> >>
> >> Yes, both paths are correct and working on the source host since the VM
starts and works correctly on source host. Nevertheless I have checked with fdisk and
mount to assure that these devices are indeed reachable.
> >>
> >> Please understand that my setup is the following:
> >> source host : KVM (hosting the VM to migrate)
> >> target host : oVirt 4.0.4 (patched)
> >>
> >> The error "no storage vol with matching path '/dev/sdc'"
is returned by the target host script /usr/lib/python2.7/site-packages/vdsm/v2v.py.
> >> This almost seems normal since the device /dev/sdc is not mounted on target
host (where script is running) but only on source host.
> >>
> >> Can this be the source of the error ?
> >
> > To me this looks more like a bug in the engine, not in VDSM.
> >
> > The exception in the VDSM log is OK and it is not fatal. It is actually
> > to be expected for block devices. VDSM is trying to find out the size of
> > the disk, but the way it does that is tailored for volumes in storage
> > pool. But the block device is not a volume in a storage pool and that is
> > why libvirt complains. We can potentially skip the check for block
> > devices to avoid error in the log, or provide some other logic of
> > getting the size.
> >
> >
> > But the real problem is this error in engine.log:
> >
> >> 2016-09-29 14:13:48,637 ERROR
[org.ovirt.engine.core.bll.GetVmsFromExternalProviderQuery] (default task-30) []
Exception: org.ovirt.engine.core.common.errors.EngineException: EngineException:
java.lang.NumberFormatException: null (Failed with error ENGINE and code 5001)
> >
> > We don't send the size (or rather send null value) for the disk and
> > engine does not like that. I assume engine does not really consider all
> > the optional VM properties as optional.
>
> is it really optional in schema?
> even if it is, indeed it’s wrong:)
>
> the best would be to handle it on v2v.py side first to avoid libvirt err, but i
don’t know if we can get that info via libvirt in any other way:/
>
> >
> >
> >
> > Tomas
> >
> > --
> > Tomáš Golembiovský <tgolembi(a)redhat.com>
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users