I have found the place where the error occurs preventing iSCSI
storagedomain creation.
The error is:
FAILED: <err> = ' WARNING: This metadata update is NOT backed up\n Not
activating c59dcf20-2de2-44c6-858d-c4e9ec018f91/metadata since it does
not pass activation filter.\n Failed to activate new LV.\n WARNING:
This metadata update is NOT backed up\n'; <rc> = 5
Probably the reason is in lvm mechanism on backuping metadata, but I'm
not sure.
Do you have any thoughts about it?
Here is a part of log:
Thread-161377::DEBUG::2013-02-24
22:58:14,217::BindingXMLRPC::161::vds::(wrapper) [192.168.0.22]
Thread-161377::DEBUG::2013-02-24
22:58:14,218::task::568::TaskManager.Task::(_updateState)
Task=`9bc26f2d-0ee7-4afa-8159-59883f6d98d6`::moving from state init ->
state preparing
Thread-161377::INFO::2013-02-24
22:58:14,218::logUtils::41::dispatcher::(wrapper) Run and protect:
createStorageDomain(storageType=3,
sdUUID='c59dcf20-2de2-44c6-858d-c4e9ec018f91', domainName='OS',
typeSpecificArg='Ecc2t6-uLUq-BNHq-Yjmx-d4w8-HqV6-Na88Cd', domClass=1,
domVersion='3', options=None)
Thread-161377::INFO::2013-02-24
22:58:14,220::blockSD::463::Storage.StorageDomain::(create)
sdUUID=c59dcf20-2de2-44c6-858d-c4e9ec018f91 domainName=OS domClass=1
vgUUID=Ecc2t6-uLUq-BNHq-Yjmx-d4w8-HqV6-Na88Cd storageType=3 version=3
Thread-161377::DEBUG::2013-02-24
22:58:14,221::lvm::368::OperationMutex::(_reloadvgs) Operation 'lvm
reload operation' got the operation mutex
Thread-161377::DEBUG::2013-02-24
22:58:14,222::misc::84::Storage.Misc.excCmd::(<lambda>) '/usr/bin/sudo
-n /sbin/lvm vgs --config " devices { preferred_names =
[\\"^/dev/mapper/\\"] ignore_suspended_devices=1 write_cache_state=0
disable_after_error_count=3 filter = [
\\"a%36000eb35f449ac1c000000000000005d|36000eb35f449ac1c000000000000008c%\\",
\\"r%.*%\\" ] } global { locking_type=1 prioritise_write_locks=1
wait_for_locks=1 } backup { retain_min = 50 retain_days = 0 } "
--noheadings --units b --nosuffix --separator | -o
uuid,name,attr,size,free,extent_size,extent_count,free_count,tags,vg_mda_size,vg_mda_free'
(cwd None)
Thread-161377::DEBUG::2013-02-24
22:58:14,470::misc::84::Storage.Misc.excCmd::(<lambda>) SUCCESS: <err> =
''; <rc> = 0
Thread-161377::DEBUG::2013-02-24
22:58:14,474::lvm::397::OperationMutex::(_reloadvgs) Operation 'lvm
reload operation' released the operation mutex
Thread-161377::DEBUG::2013-02-24
22:58:14,474::lvm::409::OperationMutex::(_reloadlvs) Operation 'lvm
reload operation' got the operation mutex
Thread-161377::DEBUG::2013-02-24
22:58:14,475::misc::84::Storage.Misc.excCmd::(<lambda>) '/usr/bin/sudo
-n /sbin/lvm lvs --config " devices { preferred_names =
[\\"^/dev/mapper/\\"] ignore_suspended_devices=1 write_cache_state=0
disable_after_error_count=3 filter = [
\\"a%36000eb35f449ac1c000000000000005d|36000eb35f449ac1c000000000000008c%\\",
\\"r%.*%\\" ] } global { locking_type=1 prioritise_write_locks=1
wait_for_locks=1 } backup { retain_min = 50 retain_days = 0 } "
--noheadings --units b --nosuffix --separator | -o
uuid,name,vg_name,attr,size,seg_start_pe,devices,tags
c59dcf20-2de2-44c6-858d-c4e9ec018f91' (cwd None)
Thread-161377::DEBUG::2013-02-24
22:58:14,702::misc::84::Storage.Misc.excCmd::(<lambda>) SUCCESS: <err> =
''; <rc> = 0
Thread-161377::DEBUG::2013-02-24
22:58:14,703::lvm::442::OperationMutex::(_reloadlvs) Operation 'lvm
reload operation' released the operation mutex
Thread-161377::DEBUG::2013-02-24
22:58:14,704::lvm::334::OperationMutex::(_reloadpvs) Operation 'lvm
reload operation' got the operation mutex
Thread-161377::DEBUG::2013-02-24
22:58:14,705::misc::84::Storage.Misc.excCmd::(<lambda>) '/usr/bin/sudo
-n /sbin/lvm pvs --config " devices { preferred_names =
[\\"^/dev/mapper/\\"] ignore_suspended_devices=1 write_cache_state=0
disable_after_error_count=3 filter = [
\\"a%36000eb35f449ac1c000000000000005d|36000eb35f449ac1c000000000000008c%\\",
\\"r%.*%\\" ] } global { locking_type=1 prioritise_write_locks=1
wait_for_locks=1 } backup { retain_min = 50 retain_days = 0 } "
--noheadings --units b --nosuffix --separator | -o
uuid,name,size,vg_name,vg_uuid,pe_start,pe_count,pe_alloc_count,mda_count,dev_size
/dev/mapper/36000eb35f449ac1c000000000000008c' (cwd None)
Thread-161377::DEBUG::2013-02-24
22:58:14,889::misc::84::Storage.Misc.excCmd::(<lambda>) SUCCESS: <err> =
''; <rc> = 0
Thread-161377::DEBUG::2013-02-24
22:58:14,890::lvm::359::OperationMutex::(_reloadpvs) Operation 'lvm
reload operation' released the operation mutex
Thread-161377::INFO::2013-02-24
22:58:14,890::blockSD::448::Storage.StorageDomain::(metaSize) size 512
MB (metaratio 262144)
Thread-161377::DEBUG::2013-02-24
22:58:14,891::misc::84::Storage.Misc.excCmd::(<lambda>) '/usr/bin/sudo
-n /sbin/lvm lvcreate --config " devices { preferred_names =
[\\"^/dev/mapper/\\"] ignore_suspended_devices=1 write_cache_state=0
disable_after_error_count=3 filter = [
\\"a%36000eb35f449ac1c000000000000005d|36000eb35f449ac1c000000000000008c%\\",
\\"r%.*%\\" ] } global { locking_type=1 prioritise_write_locks=1
wait_for_locks=1 } backup { retain_min = 50 retain_days = 0 } "
--autobackup n --contiguous n --size 512m --name metadata
c59dcf20-2de2-44c6-858d-c4e9ec018f91' (cwd None)
Thread-161377::DEBUG::2013-02-24
22:58:15,152::misc::84::Storage.Misc.excCmd::(<lambda>) FAILED: <err> =
' WARNING: This metadata update is NOT backed up\n Not activating
c59dcf20-2de2-44c6-858d-c4e9ec018f91/metadata since it does not pass
activation filter.\n Failed to activate new LV.\n WARNING: This
metadata update is NOT backed up\n'; <rc> = 5
Thread-161377::ERROR::2013-02-24
22:58:15,155::task::833::TaskManager.Task::(_setError)
Task=`9bc26f2d-0ee7-4afa-8159-59883f6d98d6`::Unexpected error
Thread-161377::DEBUG::2013-02-24
22:58:15,171::task::852::TaskManager.Task::(_run)
Task=`9bc26f2d-0ee7-4afa-8159-59883f6d98d6`::Task._run:
9bc26f2d-0ee7-4afa-8159-59883f6d98d6 (3,
'c59dcf20-2de2-44c6-858d-c4e9ec018f91', 'OS',
'Ecc2t6-uLUq-BNHq-Yjmx-d4w8-HqV6-Na88Cd', 1, '3') {} failed - stopping task
----- Original Message -----
I did the following right now to be sure:
- rotated logs
- deleted the LUN from Storage and created new one (so LUN is unused)
- rebooted the server
- opened oVirt Engine Web Administration
- Storage -> New Domain
- checked my newly created LUN
--> Error
- pressed button "OK" one more time - Another Error
I have no other iSCSI storage domains on my installaion. I tried to
create another LUN on SAN with smaller size, but result is the same.
Thanks in advance. I hope this information will help to find out
what's wrong...
----- Original Message -----
We would also like to know whether the first creation of the iscsi
storage domain succeeded and only the latter ones failed.
Whether you possibly tried to create a storage domain with a already
used lun, and specifically - do you have any iscsi storage domain at
all that you can see on the webadmin?
Regards,
Vered
----- Original Message -----
From: "Eduardo Warszawski" <[email protected]>
To: "Vered Volansky" <[email protected]>
Cc: [email protected]
Sent: Thursday, February 21, 2013 11:57:09 AM
Subject: Re: [Users] HELP! Errors creating iSCSI Storage Domain
----- Original Message -----
Hi,
Please add engine and vdsm full logs.
Regards,
Vered
----- Original Message -----
From: "Кочанов Иван" <[email protected]>
To: [email protected]
Sent: Thursday, February 21, 2013 4:26:14 AM
Subject: [Users] HELP! Errors creating iSCSI Storage Domain
LUN info:
# iscsiadm -m discovery -t st -p 172.16.20.1
172.16.20.1:3260,1
iqn.2003-10.com.lefthandnetworks:mg-dcak-p4000:134:vol-os-virtualimages
# pvs
PV VG Fmt Attr PSize PFree
/dev/mapper/36000eb35f449ac1c0000000000000086
db260c45-8dd2-4397-a5bf-fd577bbbe0d4 lvm2 a-- 1023.62g 1023.62g
The PV already belongs to VG db260c45-8dd2-4397-a5bf-fd577bbbe0d4.
This VG was very probably created by ovirt and is part of a
StorageDomain.
(Then you already succeeded.)
If you are sure that no valuable info is in this VG you can use the
"force" thick.
Anyway I suggest you to look for the SDUUID:
db260c45-8dd2-4397-a5bf-fd577bbbe0d4
and removing this StorageDomain from the system or use this already
created SD.
vdsm and engine logs will be very valuable, as Vered said.
Please include them since you started, in order to confirm to which
SD the lun belongs.
Best regards,
E.
--
Sysadmin DCAK [email protected]
_______________________________________________
Users mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/users
--
С уважением,
системный администратор КГБУЗ "ДЦАК"
Кочанов Иван Александрович
mailto:[email protected]
_______________________________________________
Users mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/users
