[ovirt-users] can't import vm from KVM host

Tue Nov 8 09:58:54 UTC 2016

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 at redhat.com>
To: "Nelson Lameiras" <nelson.lameiras at lyra-network.com>, "Tomas Golembiovsky" <tgolembi at redhat.com>
Cc: "Michal Skrivanek" <michal.skrivanek at redhat.com>, users at 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 at redhat.com>
> To: "Tomas Golembiovsky" <tgolembi at redhat.com>
> Cc: "Nelson Lameiras" <nelson.lameiras at lyra-network.com>, users at 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 at redhat.com> wrote:
> > 
> > Hi,
> > 
> > On Mon, 10 Oct 2016 12:21:47 +0200 (CEST)
> > Nelson Lameiras <nelson.lameiras at 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 at redhat.com>
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users