[ovirt-users] Moving from fc based to iSCSI based

Mon Mar 20 16:56:11 UTC 2017

On Thu, Mar 9, 2017 at 1:01 PM, Fred Rolland <frolland at redhat.com> wrote:

> I don't think it will work.
> We rely heavily on LVM when working with iSCSI and FC and I am not sure
> how LVM will handle this kind of operation.
> A storage domain is a VG that contains PVs (LUNS), and each disk is a LV.
>
>
Actually I executed several times raw "dd" operations to change internal
disks of CentOS servers and in general they did have LVM structures with
PV, VGs, LVs inside....

Finally I had some time to test and it seems it worked without problems.
I created a storage domain of 50Gb with 2 VMs on it and one of them had
also a snapshot.
I was able to import at target a dd-copy of it as an iSCSI domain without
problems.
I also created a template on the source domain, but its import fails: I get
no error message at web admin gui level, but no action executed actually...
on engine log file level I get an error of this type:

2017-03-19 01:37:24,387+01 ERROR
[org.ovirt.engine.core.bll.CommandsFactory] (default task-11)
[b7a5ef2f-694f-4d5a-851b-c52a5b1f0104] An exception has occurred while
trying to create a command object for command
'ImportVmTemplateFromConfiguration' with parameters
'ImportVmTemplateParameters:{commandId='ad3c8e81-4787-46bf-97cb-fe3bfa9f891e',
user='null', commandType='Unknown'}': WELD-000049: Unable to invoke
protected final void org.ovirt.engine.core.bll.CommandBase.postConstruct()
on
org.ovirt.engine.core.bll.exportimport.ImportVmTemplateFromConfigurationCommand at 353de47b
2017-03-19 01:37:24,388+01 ERROR
[org.ovirt.engine.core.bll.PrevalidatingMultipleActionsRunner] (default
task-11) [b7a5ef2f-694f-4d5a-851b-c52a5b1f0104] Failed to execute multiple
actions of type 'ImportVmTemplateFromConfiguration': null
2017-03-19 01:37:24,388+01 ERROR
[org.ovirt.engine.core.bll.PrevalidatingMultipleActionsRunner] (default
task-11) [b7a5ef2f-694f-4d5a-851b-c52a5b1f0104] Exception:
java.lang.NullPointerException
        at
org.ovirt.engine.core.bll.NestedCommandFactory.createWrappedCommand(NestedCommandFactory.java:24)
[bll.jar:]

Does it depend on the method or is there any problem in general in template
import for storage domain import?
See below for details of the approach used.
Full engine logs and vdsm logs on target to crosscheck are here:

vdsm logs
https://drive.google.com/file/d/0BwoPbcrMv8mvUkhtejMxN0QxTUk/view?usp=sharing

engine logs
https://drive.google.com/file/d/0BwoPbcrMv8mvRGpHSU5jOU5IbTQ/view?usp=sharing

Source storage domain consists of a FC LUN of 50Gb
Some details of it
DC
https://drive.google.com/file/d/0BwoPbcrMv8mvN1czUnJXYkR1bVE/view?usp=sharing

General
https://drive.google.com/file/d/0BwoPbcrMv8mvTUM2QmxlQ19wOUk/view?usp=sharing

Disks
https://drive.google.com/file/d/0BwoPbcrMv8mvM0hRV0dkZF83eTA/view?usp=sharing

DisksSnapshots
https://drive.google.com/file/d/0BwoPbcrMv8mvX19HTkdPdnc0V0U/view?usp=sharing

Templates
https://drive.google.com/file/d/0BwoPbcrMv8mvMU1fLWkxVW0yM0E/view?usp=sharing

VMs
https://drive.google.com/file/d/0BwoPbcrMv8mvTHVsRWx5WWNUU0k/view?usp=sharing

I used a nested 4.1 ovirt as a target environment, with:
- one CentOS 7.3 vm for engine
- one CentOS 7.3 vm for host
- one vm for iSCSI target, using NAS4Free (very nice, I didn't know it
before this test...)

- source lun (ovmsrv06)

[root at ovmsrv06 ~]# fdisk -l /dev/mapper/3600a0b80002999020000d2d358c2564b

Disk /dev/mapper/3600a0b80002999020000d2d358c2564b: 53.7 GB, 53687091200
bytes, 104857600 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

- I preliminarily access the target LUN through an helper CentOS 7.3 vm
c7service, with iSCSI initiator utils

[root at c7service log]# fdisk -l /dev/sdb

Disk /dev/sdb: 53.7 GB, 53687091200 bytes, 104857600 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 4096 bytes / 1048576 bytes

- after detaching the source storage domain as described before, as the
source and target luns are not accessible from the same machine, so I use
my client to transfer using a local fifo and compressing the data along the
way (old stye method used in mid '90 to create compressed Oracle exports
when storage constrints was indeed a serious problem.... learnt at that
time from the Unix guru Riccardo Ravelli ;-)

$ mkfifo travaso

- start reading from fifo and writing to target LUN over ssh

[g.cecchi at ope46 ~]$ cat travaso | ssh root at c7service"gunzip | dd bs=1024k
of=/dev/sdb"

(at the end I will have
root at c7service's password:
20133+538064 records in
20133+538064 records out
53687091200 bytes (54 GB) copied, 1981.52 s, 27.1 MB/s
)

- read from source LUN at ovmsrv06 writing to local fifo in gzip format

$ ssh root at ovmsrv06 "time dd
if=/dev/mapper/3600a0b80002999020000d2d358c2564b bs=1024k | gzip " | dd
bs=1024k of=travaso
root at ovmsrv06 password:

(at the end I'll have
51200+0 records in
51200+0 records out
53687091200 bytes (54 GB) copied, 1973.41 s, 27.2 MB/s

real 32m53.418s
user 26m48.461s
sys 3m25.484s
0+1314903 records in
0+1314903 records out
21906833820 bytes (22 GB, 20 GiB) copied, 1975.71 s, 11.1 MB/s
)

- I create the target iSCSI oVirt environment and then select import domain
and give the provided iSCSI LUN.

Some details of what I see now on target

import 1
https://drive.google.com/file/d/0BwoPbcrMv8mvSnpWcS1TWWV5VDg/view?usp=sharing

general
https://drive.google.com/file/d/0BwoPbcrMv8mvQm9yNDFicklfeDg/view?usp=sharing

template import tab
https://drive.google.com/file/d/0BwoPbcrMv8mvU0VHQ1NVWHpmdm8/view?usp=sharing

vm import tab
https://drive.google.com/file/d/0BwoPbcrMv8mvTVhDY01NRUVCMzQ/view?usp=sharing

import vm step
https://drive.google.com/file/d/0BwoPbcrMv8mvUFAweUE4cTk0LWs/view?usp=sharing

disks pre-import
https://drive.google.com/file/d/0BwoPbcrMv8mvVjBmc3RwWXg1ak0/view?usp=sharing

disks after import
https://drive.google.com/file/d/0BwoPbcrMv8mvU3pfTnhxWmROS3M/view?usp=sharing

virtual machines list, after import
https://drive.google.com/file/d/0BwoPbcrMv8mvM1VJcWZBaDA1ckU/view?usp=sharing

snapshot view
https://drive.google.com/file/d/0BwoPbcrMv8mvdGZWWE9CbGR6aEE/view?usp=sharing

events
https://drive.google.com/file/d/0BwoPbcrMv8mvOHVFWEp2a1VnenM/view?usp=sharing

Let me know if further info necessary to debug the template import
problem...

Gianluca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20170320/bb16a57a/attachment.html>