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

2017-04-05 Thread Gianluca Cecchi 
On Thu, Mar 23, 2017 at 11:26 AM, Gianluca Cecchi  wrote:

> On Mon, Mar 20, 2017 at 5:56 PM, Gianluca Cecchi <
> gianluca.cec...@gmail.com> wrote:
>
>> On Thu, Mar 9, 2017 at 1:01 PM, Fred Rolland  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
>>
>> Any comment to previous e-mail? Are there any known problems with
> template import?
> Any chance to see the error logs provided?
> Thanks,
> Gianluca
>
>

I confirm that I was able to transfer with the same method my FC based 1Tb
storage domain to an iSCSI LUN and then import it.
I didn't have templates on it so I could not verify if the problem related
to template import that I previously had still present.

Gianluca
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

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

2017-03-23 Thread Gianluca Cecchi 
On Mon, Mar 20, 2017 at 5:56 PM, Gianluca Cecchi 
wrote:

> On Thu, Mar 9, 2017 at 1:01 PM, Fred Rolland  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-49: Unable to invoke
> protected final void org.ovirt.engine.core.bll.CommandBase.postConstruct()
> on org.ovirt.engine.core.bll.exportimport.ImportVmTemplateFromConfigurat
> ionCommand@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
>


Any comment to previous e-mail? Are there any known problems with template
import?
Any chance to see the error logs provided?
Thanks,
Gianluca
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

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

2017-03-20 Thread Gianluca Cecchi 
On Thu, Mar 9, 2017 at 1:01 PM, Fred Rolland  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-49: 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
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@ovmsrv06 ~]# fdisk -l /dev/mapper/3600a0b8000299902d2d358c2564b

Disk /dev/mapper/3600a0b8000299902d2d358c2564b: 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/3600a0b8000299902d2d358c2564b bs=1024k | gzip " | dd
bs=1024k of=travaso
root@ovmsrv06 password:

(at the end I'll have
51200+0 records in
51200+0 records out
53687091200

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

2017-03-09 Thread Fred Rolland 
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.

On Wed, Mar 8, 2017 at 6:02 PM, Gianluca Cecchi 
wrote:

> On Wed, Mar 8, 2017 at 3:33 PM, Fred Rolland  wrote:
>
>> I cannot think of another option other to have an export domain in the
>> middle that can be accessed from all the hosts.
>>
>>
>> On Wed, Mar 8, 2017 at 3:50 PM, Gianluca Cecchi <
>> gianluca.cec...@gmail.com> wrote:
>>
>>> On Wed, Mar 8, 2017 at 1:30 PM, Fred Rolland 
>>> wrote:
>>>
 Hi,

 Storage domains are per Data Center, and all hosts in this DC should be
 able to access the SDs, no matter in which cluster they are...

 Are you sure your hosts are on the same DC ?

 Thanks,

 Freddy


>>> No, my scenario was a planning workflow.
>>> At this moment I only have Host1 and Host2 that are connected to an
>>> FC-SAN.
>>> I have to move data to an iSCSI storage and also oVirt hosts to Host3
>>> and Host4 (yet to be deployed).
>>> So I'm trying to understand if I can do it in pieces bypassing
>>> export/import
>>>
>>> I forgot that it is DC the constraint for SD accessibility.
>>> Any suggestion to accomplish the desired target?
>>>
>>> Thanks,
>>> Gianluca
>>>
>>>
>>
> Is it realistic to think something similar to the workflow described
> below, based on the import storage domain functionality described here:
> http://www.ovirt.org/develop/release-management/features/
> storage/importstoragedomain
>
> and in particular one of its targets:
> Transfer VMs between setups without the need to copy the data into and out
> of the export domain.
>
>
> Prerequisite:
> - Host1 has network connectivity with Host3
> - Host1 is part of a DC that contains an FC based storage domain, composed
> of SAN LUN A of X Tb
> - Host3 is part of another DC and has connection in place with iSCSI LUN B
> of X Tb
>
> Workflow:
> - Stop the VMs that are on the source FC domain
> - Put source storage domain into maintenance
> - Detach source storage domain
> - Clone LUN A to LUN B at low level
> (eg dd command via network
> Similar to when you clone an entire disk from a server to another
> server
> )
> - import domain on DC where Host3 lives giving the correct iSCSI
> parameters...
>
> Do the OVF_STORE disks on the storage domain contain information about the
> fact of it being an FC or an iSCSI storage domain, preventing then a
> possible import operation?
>
> This is a test environment where I would like to transfer 4Tb of data from
> FC SAN in decommission phase to an iSCSI SAN, and if I can by-pass export /
> import phases, even giving some downtime, would be good.
>
> Thanks for reading,
> Gianluca
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

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

2017-03-08 Thread Gianluca Cecchi 
On Wed, Mar 8, 2017 at 3:33 PM, Fred Rolland  wrote:

> I cannot think of another option other to have an export domain in the
> middle that can be accessed from all the hosts.
>
>
> On Wed, Mar 8, 2017 at 3:50 PM, Gianluca Cecchi  > wrote:
>
>> On Wed, Mar 8, 2017 at 1:30 PM, Fred Rolland  wrote:
>>
>>> Hi,
>>>
>>> Storage domains are per Data Center, and all hosts in this DC should be
>>> able to access the SDs, no matter in which cluster they are...
>>>
>>> Are you sure your hosts are on the same DC ?
>>>
>>> Thanks,
>>>
>>> Freddy
>>>
>>>
>> No, my scenario was a planning workflow.
>> At this moment I only have Host1 and Host2 that are connected to an
>> FC-SAN.
>> I have to move data to an iSCSI storage and also oVirt hosts to Host3 and
>> Host4 (yet to be deployed).
>> So I'm trying to understand if I can do it in pieces bypassing
>> export/import
>>
>> I forgot that it is DC the constraint for SD accessibility.
>> Any suggestion to accomplish the desired target?
>>
>> Thanks,
>> Gianluca
>>
>>
>
Is it realistic to think something similar to the workflow described below,
based on the import storage domain functionality described here:
http://www.ovirt.org/develop/release-management/features/storage/importstoragedomain

and in particular one of its targets:
Transfer VMs between setups without the need to copy the data into and out
of the export domain.


Prerequisite:
- Host1 has network connectivity with Host3
- Host1 is part of a DC that contains an FC based storage domain, composed
of SAN LUN A of X Tb
- Host3 is part of another DC and has connection in place with iSCSI LUN B
of X Tb

Workflow:
- Stop the VMs that are on the source FC domain
- Put source storage domain into maintenance
- Detach source storage domain
- Clone LUN A to LUN B at low level
(eg dd command via network
Similar to when you clone an entire disk from a server to another server
)
- import domain on DC where Host3 lives giving the correct iSCSI
parameters...

Do the OVF_STORE disks on the storage domain contain information about the
fact of it being an FC or an iSCSI storage domain, preventing then a
possible import operation?

This is a test environment where I would like to transfer 4Tb of data from
FC SAN in decommission phase to an iSCSI SAN, and if I can by-pass export /
import phases, even giving some downtime, would be good.

Thanks for reading,
Gianluca
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

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

2017-03-08 Thread Fred Rolland 
I cannot think of another option other to have an export domain in the
middle that can be accessed from all the hosts.


On Wed, Mar 8, 2017 at 3:50 PM, Gianluca Cecchi 
wrote:

> On Wed, Mar 8, 2017 at 1:30 PM, Fred Rolland  wrote:
>
>> Hi,
>>
>> Storage domains are per Data Center, and all hosts in this DC should be
>> able to access the SDs, no matter in which cluster they are...
>>
>> Are you sure your hosts are on the same DC ?
>>
>> Thanks,
>>
>> Freddy
>>
>>
> No, my scenario was a planning workflow.
> At this moment I only have Host1 and Host2 that are connected to an FC-SAN.
> I have to move data to an iSCSI storage and also oVirt hosts to Host3 and
> Host4 (yet to be deployed).
> So I'm trying to understand if I can do it in pieces bypassing
> export/import
>
> I forgot that it is DC the constraint for SD accessibility.
> Any suggestion to accomplish the desired target?
>
> Thanks,
> Gianluca
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

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

2017-03-08 Thread Gianluca Cecchi 
On Wed, Mar 8, 2017 at 1:30 PM, Fred Rolland  wrote:

> Hi,
>
> Storage domains are per Data Center, and all hosts in this DC should be
> able to access the SDs, no matter in which cluster they are...
>
> Are you sure your hosts are on the same DC ?
>
> Thanks,
>
> Freddy
>
>
No, my scenario was a planning workflow.
At this moment I only have Host1 and Host2 that are connected to an FC-SAN.
I have to move data to an iSCSI storage and also oVirt hosts to Host3 and
Host4 (yet to be deployed).
So I'm trying to understand if I can do it in pieces bypassing export/import

I forgot that it is DC the constraint for SD accessibility.
Any suggestion to accomplish the desired target?

Thanks,
Gianluca
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

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

2017-03-08 Thread Fred Rolland 
Hi,

Storage domains are per Data Center, and all hosts in this DC should be
able to access the SDs, no matter in which cluster they are...

Are you sure your hosts are on the same DC ?

Thanks,

Freddy

On Wed, Mar 8, 2017 at 12:57 PM, Gianluca Cecchi 
wrote:

> Hello,
> I have to move some VMs from FCP based storage domain to iSCSI based
> storage domain.
> Can I do it offline or online keeping in mind that:
>
> Host1, Host2 have access only to the FCP SD
> Host3, Host4 have access only to the iSCSI SD
>
> They are all managed by the same engine in the same DC but in different
> cluster
>
> I suppose it happens through network, correct?
> Thanks in advance,
> Gianluca
>
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

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

2017-03-08 Thread Gianluca Cecchi 
Hello,
I have to move some VMs from FCP based storage domain to iSCSI based
storage domain.
Can I do it offline or online keeping in mind that:

Host1, Host2 have access only to the FCP SD
Host3, Host4 have access only to the iSCSI SD

They are all managed by the same engine in the same DC but in different
cluster

I suppose it happens through network, correct?
Thanks in advance,
Gianluca
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users