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

On 18.11.16 09:34, Nelson Lameiras wrote: > Hello Shahar, > > I've rebuild my test system and installed recently released ovirt 4.0.5 + gerrit patch => still no luck. vdsm always gives me same error : Hi, yes once you have the alias you are half way there. but your alias path looks wrong, it starts with white-space: '/ var/lib/libvirt/images/rhel7.1.img' check it via 'virsh -r dumpxml <vmnam>' and look if the white space are there two regarding the pool you can check it too via virsh virsh pool-list and all pool-* commands (to create one), if you have problems building pool let me know. Shahar. > > " > jsonrpc.Executor/6::ERROR::2016-11-17 16:38:56,320::v2v::934::root::(_add_disk_info) Error getting disk size > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/vdsm/v2v.py", line 931, in _add_disk_info > vol = conn.storageVolLookupByPath(disk['alias']) > File "/usr/lib64/python2.7/site-packages/libvirt.py", line 4596, in storageVolLookupByPath > if ret is None:raise libvirtError('virStorageVolLookupByPath() failed', conn=self) > libvirtError: Volume de stockage introuvable : no storage vol with matching path '/dev/sdc' > jsonrpc.Executor/6::DEBUG::2016-11-17 16:38:56,325::__init__::555::jsonrpc.JsonRpcServer::(_handle_request) Return 'Host.getExternalVMs' in bridge with [{'status': 'Down', 'graphics': 'spice', 'arch': 'x86_64', 'disks': [ {'capacity': '8589934592', 'format': 'RAW', 'dev': 'hdd', 'allocation': '8589942784', 'alias': '/ var/lib/libvirt/images/rhel7.1.img', 'type': 'disk'}, {'alias': '/dev/sdc', 'type': 'disk', 'dev': 'hdb', 'format': 'RAW'}], 'vmId': 'd0ddc4f6-a208-4286-a665-fb9e54d14bef', 'smp': 1, 'has_snapshots': False, 'video': 'qxl', 'memSize': 1 024, 'vmName': 'rhel7.1', 'networks': [{'model': 'virtio', 'macAddr': '52:54:00:00:d7:76', 'type': 'network'}]}] > " > > FYI I added a normal disk (file based) to the VM ir order to try to understand what's happening. As expected, this disk is seen by the oVirt (without patch) > > I do reckon something in the above log : > > 'disks': [ > {'capacity': '8589934592', 'format': 'RAW', 'dev': 'hdd', 'allocation': '8589942784', 'alias': '/ var/lib/libvirt/images/rhel7.1.img', 'type': 'disk'}, > {'alias': '/dev/sdc', 'type': 'disk', 'dev': 'hdb', 'format': 'RAW'} > ], > > the "alias" line is clearly new since it did not appear before de patch! something is working ;) > > I confirm that when I created the test VM (via virt-manager), I gave directly the path to the device (/dev/sdc), so there is no "pool" to be addressed defined on libvirt! > I read https://gerrit.ovirt.org/#/c/64272/4/ and I agree with Tomas findings : Currently the conversion process is expecting a volume on a pool and it's not able to use a block device directly. > > So I'm hopping a solution can be found to this problem. We have a few hundreds VM waiting to be migrated in production and we don't have a NFS server, so this is our only option so far. > > I'm able to test any patch quickly if needed, do not hesitate. > > 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; > Cc: "Tomas Golembiovsky" <tgolembi(a)redhat.com&gt;, "Michal Skrivanek" <michal.skrivanek(a)redhat.com&gt;, users(a)ovirt.org > Sent: Tuesday, November 8, 2016 12:16:55 PM > Subject: Re: [ovirt-users] can't import vm from KVM host > > 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" <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