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

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