Ok so two things, one I found this bug report which I believe is
relevant to my issue. *https://bugzilla.redhat.com/show_bug.cgi?id=1497931*
*
*
And secondly I found using a tip from that bug report that I in fact
have two identical LVMs. I need to remove the one that already exists on
the FC, so I can move the one from the iSCSI to the FC.
"*bb20b34d-96b9-4dfe-b122-0172546e51ce*
0e4ca0da-1721-4ea7-92af-25233a8679e0 -wi-a----- 80.00g Fibre Channel
/Un-imported old version of the VM/
*bb20b34d-96b9-4dfe-b122-0172546e51ce*
b9cce591-fed5-4b59-872b-41a9fecb607e -wi------- 80.00g" iSCSI Current
good version of the VM that I would like to move back to FC.
So there must be a manual way to do this? And I would then need to
remove the record of the VM from the FC OVF store? I am having trouble
finding good documentation on how to do this.
On 12/03/2018 01:37 PM, Jacob Green wrote:
I believe I have found the relevant error in the engine.log.
__________________________________________________________________________________________________________________________________________________________
Exception: 'VDSGenericException: VDSErrorException: Failed to
HSMGetAllTasksStatusesVDS, error = Cannot create Logical Volume:
u'vgname=0e4ca0da-1721-4ea7-92af-25233a8679e0
lvname=bb20b34d-96b9-4dfe-b122-0172546e51ce err=[\' /dev/mapp
er/36589cfc0000003413cb667d8cd46ffb8: read failed after 0 of 4096 at
0: Input/output error\', \'
/dev/mapper/36589cfc0000003413cb667d8cd46ffb8: read failed after 0 of
4096 at 858993393664: Input/output error\', \' /dev/mapper/36589cfc00
00003413cb667d8cd46ffb8: read failed after 0 of 4096 at 858993451008:
Input/output error\', \' WARNING: Error counts reached a limit of 3.
Device /dev/mapper/36589cfc0000003413cb667d8cd46ffb8 was disabled\',
\' Logical Volume "bb20b34d-
96b9-4dfe-b122-0172546e51ce" already exists in volume group
"0e4ca0da-1721-4ea7-92af-25233a8679e0"\']', code = 550'
__________________________________________________________________________________________________________________________________________________________
So my question is how do I delete that already existing Logical Volume
safely, so that I can move a disk from my iscsi to the FC. This VM
used to exsist on the FC before I migrated which is how I ended up in
this situation.
On 12/03/2018 01:13 PM, Jacob Green wrote:
>
> Any thoughts on how I remove an un-imported VM from my FIbre
> Channel storage? I cannot move my working VMs back to the FC, and I
> believe it is because the older un-imported version is creating conflict.
>
>
> On 11/29/2018 03:12 PM, Jacob Green wrote:
>>
>> Ok, so here is the situation, before moving/importing our
>> primary storage domain, I exported a few VMs, so they would not need
>> to go down during the "Big migration" however they are now residing
>> on some iscsi storage, now that the Fibre Channel storage is back in
>> place, I cannot move the disks of the VMs to the Fiber channel
>> because their is an unimported version of that VM residing on the
>> Fibre Channel. I need to delete or remove the VM from the Fibre
>> Channel so I can move the working VM back to the Fibre Channel.
>>
>> I hope that makes sense, but essentially I have a current duplicate
>> VM running in iscsi that I need to move to the fibre channel.
>> however because the VM used to exsist on the fibre channel and has
>> the same disk name, I cannot move it to the fibre channel, also it
>> seems odd to me there is no way to clear the VMs from the storage
>> without importing them. There must be a way?
>>
>>
>> Thank you.
>>
>>
>>
>> On 11/28/2018 10:14 PM, Jacob Green wrote:
>>>
>>> Hey wanted to thank you for your reply, and wanted to let you know
>>> that late after I sent this email, my colleuege and I figured out
>>> we needed to enable the FCoE key in the ovirt manager and tell
>>> ovirt that eno51 and eno52 interfaces are FCoE.
>>>
>>>
>>> However I ran into another issue. Now that our Fiber channel is
>>> imported to the new environment and were able to import VMs, we
>>> have some VMs that we will not be importing, however we see no way
>>> to delete them from the storage in the GUI. Or I am just missing it.
>>>
>>>
>>> *TLDR*: How does one delete VMs available for import, without
>>> importing them from the storage domain?
>>>
>>>
>>> Thank you.
>>>
>>>
>>>
>>> On 11/28/2018 01:26 AM, Luca 'remix_tj' Lorenzetto wrote:
>>>> On Wed, Nov 28, 2018 at 6:54 AM Jacob Green<jgreen(a)aasteel.com>
wrote:
>>>>> Any help or insight into fiber channel with ovirt 4.2 would be
greatly
>>>>> appreciated.
>>>>>
>>>> Hello Jacob,
>>>>
>>>> we're running a cluster of 6 HP BL460 G9 with virtual connect without
issues.
>>>>
>>>> [root@kvmsv003 ~]# dmidecode | grep -A3 '^System Information'
>>>> System Information
>>>> Manufacturer: HP
>>>> Product Name: ProLiant BL460c Gen9
>>>> Version: Not Specified
>>>>
>>>> We've, anyway, a different kind of CNA:
>>>>
>>>> [root@kvmsv003 ~]# cat
/sys/class/fc_host/host1/device/scsi_host/host1/modeldesc
>>>> HP FlexFabric 20Gb 2-port 650FLB Adapter
>>>>
>>>> But i see is running the same module you're reporting
>>>>
>>>> [root@kvmsv003 ~]# lsmod | grep bnx
>>>> bnx2fc 103061 0
>>>> cnic 67392 1 bnx2fc
>>>> libfcoe 58854 2 fcoe,bnx2fc
>>>> libfc 116357 3 fcoe,libfcoe,bnx2fc
>>>> scsi_transport_fc 64007 4 fcoe,lpfc,libfc,bnx2fc
>>>> [root@fapikvmpdsv003 ~]#
>>>>
>>>> Since the fcoe connection is managed directly by virtual connect,
i'm
>>>> not having fcoe informations shown with fcoeadm:
>>>>
>>>> [root@kvmsv003 ~]# fcoeadm -i
>>>> [root@kvmsv003 ~]#
>>>>
>>>> Are you sure you set up the right configuration on virtual connect side?
>>>>
>>>> Luca
>>>>
>>>
>>> --
>>> Jacob Green
>>>
>>> Systems Admin
>>>
>>> American Alloy Steel
>>>
>>> 713-300-5690
>>>
>>>
>>> _______________________________________________
>>> Users mailing list --users(a)ovirt.org
>>> To unsubscribe send an email tousers-leave(a)ovirt.org
>>> Privacy
Statement:https://www.ovirt.org/site/privacy-policy/
>>> oVirt Code of
Conduct:https://www.ovirt.org/community/about/community-guidelines/
>>> List
Archives:https://lists.ovirt.org/archives/list/users@ovirt.org/message/PR...
>>
>> --
>> Jacob Green
>>
>> Systems Admin
>>
>> American Alloy Steel
>>
>> 713-300-5690
>>
>>
>> _______________________________________________
>> Users mailing list --users(a)ovirt.org
>> To unsubscribe send an email tousers-leave(a)ovirt.org
>> Privacy
Statement:https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of
Conduct:https://www.ovirt.org/community/about/community-guidelines/
>> List
Archives:https://lists.ovirt.org/archives/list/users@ovirt.org/message/NQ...
>
> --
> Jacob Green
>
> Systems Admin
>
> American Alloy Steel
>
> 713-300-5690
>
>
> _______________________________________________
> Users mailing list --users(a)ovirt.org
> To unsubscribe send an email tousers-leave(a)ovirt.org
> Privacy
Statement:https://www.ovirt.org/site/privacy-policy/
> oVirt Code of
Conduct:https://www.ovirt.org/community/about/community-guidelines/
> List
Archives:https://lists.ovirt.org/archives/list/users@ovirt.org/message/IR...
--
Jacob Green
Systems Admin
American Alloy Steel
713-300-5690
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)ovirt.org
Privacy Statement:
https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/M4W5E4UVT7V...