[ovirt-users] can't import vm from KVM host
Shahar Havivi
shavivi at redhat.com
Sun Nov 20 08:36:14 UTC 2016
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 at redhat.com>
> To: "Nelson Lameiras" <nelson.lameiras at lyra-network.com>
> Cc: "Tomas Golembiovsky" <tgolembi at redhat.com>, "Michal Skrivanek" <michal.skrivanek at redhat.com>, users at 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 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
More information about the Users
mailing list