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