12:58 p.m.
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).
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