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

Shahar Havivi shavivi at redhat.com
Mon Nov 7 12:58:34 UTC 2016


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



More information about the Users mailing list