On Thu, Mar 9, 2017 at 1:01 PM, Fred Rolland <frolland@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@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

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@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@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@ope46 ~]$ cat travaso | ssh root@c7service"gunzip | dd bs=1024k of=/dev/sdb"

(at the end I will have

root@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@ovmsrv06 "time dd if=/dev/mapper/3600a0b80002999020000d2d358c2564b bs=1024k | gzip " | dd bs=1024k of=travaso

root@ovmsrv06 password: