- Users - oVirt List Archives

Update of ovirt-guest-agent for Debian Jessie
by Christophe TREFOIS 04 Apr '17

04 Apr '17

--Apple-Mail=_1C9D631E-5E5D-46F7-879C-F91E31E19962 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Could you update ovirt-guest-agent as latest is 1.0.13 but on Debain = mirror it is 1.0.10? Thanks, Christophe= --Apple-Mail=_1C9D631E-5E5D-46F7-879C-F91E31E19962 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKUjCCBQAw ggPooAMCAQICEANL7hcft+EGNy/UckJAvSowDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTE0MTExODEyMDAwMFoXDTI0MTExODEy MDAwMFowaTELMAkGA1UEBhMCTkwxFjAUBgNVBAgTDU5vb3JkLUhvbGxhbmQxEjAQBgNVBAcTCUFt c3RlcmRhbTEPMA0GA1UEChMGVEVSRU5BMR0wGwYDVQQDExRURVJFTkEgUGVyc29uYWwgQ0EgMzCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMalux9VgvSlNHIUcmWbX9XqoGjYm4KJT1Ni nHuMzg7a1DIOrxuMy6br2+DrAzSUwYd+UyCoHvkbF4p9AWYSV2heLZwuKyGoVS9TZwl4zdJpGwuT YGy4KBPOH02xiCatRfrQoc6rt5gpVnFs8VYkXacw4G4xc27aoFdMZIt4tcec28bevtMvMaDWgDm1 4DFAToSjzJJJ4hds/vBkHvq6vCWHnU8huslmOQON1BUQuHs6VM/VY7pP8d/oGwR94VymhrV74xb+ XDRV61M88dDXkdgpg/ZZiiEfHMOIL5BTATtRlUGWn1xcinAe4PNKJtzlEbfPSf+PZJALHQOTkUwB QSsCAwEAAaOCAaYwggGiMBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMHkGCCsG AQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMGCCsGAQUF BzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRB c3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNl cnRBc3N1cmVkSURSb290Q0EuY3JsMD0GA1UdIAQ2MDQwMgYEVR0gADAqMCgGCCsGAQUFBwIBFhxo dHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMB0GA1UdDgQWBBTwIelJd3Ofha4YO+hScBQG7ULu yjAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsFAAOCAQEAOsIb K/5j3rthtLlHqPx8BbEmICJRm8g9+fXFWB6wXqOynAJBjzEaf8wbTh34mH3sjwj9d/Hb0kQQWrat CbDg/GI71GINnvGgPE13iutENHuOu04pA/wn6j5qHS9I4/raGcP/M9Ls1Ey0jJVLYbbvsoAvl8hH raeCv3zh+YmCEO/RuyMYCZ67cQ/TGFSwMlPrUigAagoGfEE8B6DdZex1Kbgaftu3K9qR7IW1h5uv YqY4FJrbw9GoZIO6vnppmEmgzZ4zNzqmua8bDC0DNGxzm3Y6wpG4dZXo7dqc/YrbuMZlHZuLVVfU 1BS8hulU1O7COb5dxm2xr8AAkX0oaQSx4DCCBUowggQyoAMCAQICEAbOAJ+Ec9btisckDi20mtow DQYJKoZIhvcNAQELBQAwaTELMAkGA1UEBhMCTkwxFjAUBgNVBAgTDU5vb3JkLUhvbGxhbmQxEjAQ BgNVBAcTCUFtc3RlcmRhbTEPMA0GA1UEChMGVEVSRU5BMR0wGwYDVQQDExRURVJFTkEgUGVyc29u YWwgQ0EgMzAeFw0xNzAzMTAwMDAwMDBaFw0xODAzMTAxMjAwMDBaMH0xCzAJBgNVBAYTAkxVMRMw EQYDVQQIEwpMdXhlbWJvdXJnMRkwFwYDVQQHExBFc2NoLXN1ci1BbHpldHRlMSEwHwYDVQQKExhV bml2ZXJzaXR5IG9mIEx1eGVtYm91cmcxGzAZBgNVBAMTEkNocmlzdG9waGUgVFJFRk9JUzCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANMliC5A438/QPwe9tp30XBB7iJzjF+Yxl/HiBzO rMOdNwEVbrGdtAuKaPY61yhv8dMzDYAHmmY7aBlFw/5ynohdLhRNNZ64d08lXxI4UCFnOtj+yJE7 ScvsvyOiORa+bdnRTSnSE2JDcB3Vlk2dUXIQ86+pc0J6zPBeCDTXUvqw2y7znrXm1reksJl8fMUL R+LWX12hN6z2MRKgDZL3CswOIzocl+bmBnYqUnU2iDcv31QOKy6AGqGdV2t+1bAbJgZEqgkerSsf YpHeezMej2vH5E6/IlwnHVnG7c54bGD1AumloDdEjCysqdlcEq/dc7Bb9qFrjg/Rby5iGxUtbhUC AwEAAaOCAdgwggHUMB8GA1UdIwQYMBaAFPAh6Ul3c5+Frhg76FJwFAbtQu7KMB0GA1UdDgQWBBTI hivrWIlnKOLxQ9wYwCGuiJFoezAMBgNVHRMBAf8EAjAAMCQGA1UdEQQdMBuBGWNocmlzdG9waGUu dHJlZm9pc0B1bmkubHUwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEF BQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu ZGlnaWNlcnQuY29tL0NQUzB1BgNVHR8EbjBsMDSgMqAwhi5odHRwOi8vY3JsMy5kaWdpY2VydC5j b20vVEVSRU5BUGVyc29uYWxDQTMuY3JsMDSgMqAwhi5odHRwOi8vY3JsNC5kaWdpY2VydC5jb20v VEVSRU5BUGVyc29uYWxDQTMuY3JsMHMGCCsGAQUFBwEBBGcwZTAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuZGlnaWNlcnQuY29tMD0GCCsGAQUFBzAChjFodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5j b20vVEVSRU5BUGVyc29uYWxDQTMuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQC59zmhjgRb56qtSBn6 a3cA8FGq1pQyOmNRZtCHlMN/LuAdHBxteXrbVzPDrGl27lHVvgoAcFPxo093R3Z0qNjE/qOSro8e i5PfQBEGbRwbWi6cHDOHT9y+OIq23wQdlnhV6gcdirfc5YXSD/0U573DDzW+MfloIRVA03EsXb+v nZEgp6ajNtYL/cYMch5oQa3s2H27K0WVk0l+R38ChSJazkpchWZb7TvH+h2LHDZLRlvmuFHNACWJ zSusO3o/N95pUnUS4uwnAmavXN3ZZWVqlTX5qyQin68dYZPkQJY0agX+T27Y+VFs/llOUmNw6X2m e7G8PVBBx6cxvPaJ9tKMMYIDJTCCAyECAQEwfTBpMQswCQYDVQQGEwJOTDEWMBQGA1UECBMNTm9v cmQtSG9sbGFuZDESMBAGA1UEBxMJQW1zdGVyZGFtMQ8wDQYDVQQKEwZURVJFTkExHTAbBgNVBAMT FFRFUkVOQSBQZXJzb25hbCBDQSAzAhAGzgCfhHPW7YrHJA4ttJraMAkGBSsOAwIaBQCgggF9MBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MDQwNDE1MTg1NFowIwYJ KoZIhvcNAQkEMRYEFNpwjCgjvyHvU2g2GmL2kOQ4MOULMIGMBgkrBgEEAYI3EAQxfzB9MGkxCzAJ BgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzAN BgNVBAoTBlRFUkVOQTEdMBsGA1UEAxMUVEVSRU5BIFBlcnNvbmFsIENBIDMCEAbOAJ+Ec9btisck Di20mtowgY4GCyqGSIb3DQEJEAILMX+gfTBpMQswCQYDVQQGEwJOTDEWMBQGA1UECBMNTm9vcmQt SG9sbGFuZDESMBAGA1UEBxMJQW1zdGVyZGFtMQ8wDQYDVQQKEwZURVJFTkExHTAbBgNVBAMTFFRF UkVOQSBQZXJzb25hbCBDQSAzAhAGzgCfhHPW7YrHJA4ttJraMA0GCSqGSIb3DQEBAQUABIIBAEVF 6lrKjUHmahOb7aw5ceki/XTMgV/86cvPXQSGVdyakxdRer89jToNS1QV/HRPP8yaEPcHbqDGKMXl ajOb5ThwSyTDAuo9fJQXDYW7YEIltdUBALTVo6HQOz6vSuk1FdpWaSRwZPrF1BLQ+JO4QWFqx/oV cyHDUSKshYMdqcgfo8aTtlUx814WHLi7G1tKgjA5JtIkD2L92et5Vu89YPiWy456BCqHomNH/lWQ +46h615VEwYRIM5J0GR7GYQcGMzbrmoIUZfzOZGkBz/Hy+t9n1hi2C4A9pj2rygVjkY4IqmV1y+o yymh8gIFDcVDNh+DPRQQunM9iEQuYhyjT78AAAAAAAA= --Apple-Mail=_1C9D631E-5E5D-46F7-879C-F91E31E19962--

1 0

info on performance of cloning a snapshot
by Gianluca Cecchi 04 Apr '17

04 Apr '17

Hello, I'm on 4.1.1 environment. Storage domain is iSCSI (with multipath) and able to write at about 200 MBytes/s when making a test inside a VM (100MB x 2) While cloning a snapshot it seems the performace is quite lower... It begins at about 12MB/s (6 x 2) then increases at about 30MB/s (15 x 2) with maximum of 50MB/s (25 x 2), all balanced across the two iSCSI network adapters The related process on hypervisor vdsm 2772 3701 4 15:47 ? 00:00:08 /usr/bin/qemu-img convert -p -t none -T none -f qcow2 /rhev/data-center/ef17cad6-7724-4cd8-96e3-9af6e529db51/94795322-92a7-4904-80c1-83d6b629d38a/images/073519dc-440d-418d-9e0c-a7ac4812ea82/845a9008-8ece-4cf2-9828-f286640b5f0e -O qcow2 -o compat=1.1 /rhev/data-center/mnt/blockSD/94795322-92a7-4904-80c1-83d6b629d38a/images/54c40b95-c0e5-42db-a6ba-c00f8d337fdc/5987e84f-28be-46c4-bc3a-688d5f7fd025 Not a big problem, only to know: is there any limiting/tunable factor in any vdsm/engine parameter? Or is it related to the command "qemu-img convert" itself or anything else? Thanks, Gianluca

1 0

general storage exception ... not using lvmetad
by Gianluca Cecchi 04 Apr '17

04 Apr '17

Hello, on my 4.1 environment sometimes I get this kind of message, typically when I create a snapshot. Please note that the snapshot is correctly created: I get the event between the snapshot creation initiated and completed events VDSM ovmsrv05 command TeardownImageVDS failed: Cannot deactivate Logical Volume: ('General Storage Exception: ("5 [] [\' WARNING: Not using lvmetad because config setting use_lvmetad=0.\', \' WARNING: To avoid corruption, rescan devices to make changes visible (pvscan --cache).\', \' Logical volume 922b5269-ab56-4c4d-838f-49d33427e2ab/79350ec5-eea5-458b-a3ee-ba394d2cda27 in use.\', \' Logical volume 922b5269-ab56-4c4d-838f-49d33427e2ab/3590f38b-1e3b-4170-a901-801ee5d21d59 in use.\']\\n922b5269-ab56-4c4d-838f-49d33427e2ab/[\'3590f38b-1e3b-4170-a901-801ee5d21d59\', \'79350ec5-eea5-458b-a3ee-ba394d2cda27\']",)',) What is the exact meaning and how can I crosscheck to solve the possible anomaly...? What about lvmetad reference inside the message? Is it an option that in oVirt can be configured or not at all for now? Thanks, Gianluca

2 2

VM has been paused due to storage I/O problem
by Gianluca Cecchi 04 Apr '17

04 Apr '17

Hello, my test environment is composed by 2 old HP blades BL685c G1 (ovmsrv05 and ovmsrv06) and they are connected in a SAN with FC-switches to an old IBM DS4700 storage array. Apart from being old, they seem all ok from an hw point of view. I have configured oVirt 4.0.6 and an FCP storage domain. The hosts are plain CentOS 7.3 servers fully updated. It is not an hosted engine environment: the manager is a vm outside of the cluster. I have configured power mgmt on both and it works good. I have at the moment only one VM for test and it is doing quite nothing. Starting point: ovmsrv05 is in maintenance (since about 2 days) and the VM is running on ovmsrv06. I update qemu-kvm package on ovmsrv05 and then I restart it from web admin gui: Power Mgmt --> Restart Sequence of events in pane and the problem in subject: Jan 31, 2017 10:29:43 AM Host ovmsrv05 power management was verified successfully. Jan 31, 2017 10:29:43 AM Status of host ovmsrv05 was set to Up. Jan 31, 2017 10:29:38 AM Executing power management status on Host ovmsrv05 using Proxy Host ovmsrv06 and Fence Agent ilo:10.4.192.212. Jan 31, 2017 10:29:29 AM Activation of host ovmsrv05 initiated by admin@internal-authz. Jan 31, 2017 10:28:05 AM VM ol65 has recovered from paused back to up. Jan 31, 2017 10:27:55 AM VM ol65 has been paused due to storage I/O problem. Jan 31, 2017 10:27:55 AM VM ol65 has been paused. Jan 31, 2017 10:25:52 AM Host ovmsrv05 was restarted by admin@internal-authz. Jan 31, 2017 10:25:52 AM Host ovmsrv05 was started by admin@internal-authz. Jan 31, 2017 10:25:52 AM Power management start of Host ovmsrv05 succeeded. Jan 31, 2017 10:25:50 AM Executing power management status on Host ovmsrv05 using Proxy Host ovmsrv06 and Fence Agent ilo:10.4.192.212. Jan 31, 2017 10:25:37 AM Executing power management start on Host ovmsrv05 using Proxy Host ovmsrv06 and Fence Agent ilo:10.4.192.212. Jan 31, 2017 10:25:37 AM Power management start of Host ovmsrv05 initiated. Jan 31, 2017 10:25:37 AM Auto fence for host ovmsrv05 was started. Jan 31, 2017 10:25:37 AM All VMs' status on Non Responsive Host ovmsrv05 were changed to 'Down' by admin@internal-authz Jan 31, 2017 10:25:36 AM Host ovmsrv05 was stopped by admin@internal-authz. Jan 31, 2017 10:25:36 AM Power management stop of Host ovmsrv05 succeeded. Jan 31, 2017 10:25:34 AM Executing power management status on Host ovmsrv05 using Proxy Host ovmsrv06 and Fence Agent ilo:10.4.192.212. Jan 31, 2017 10:25:15 AM Executing power management stop on Host ovmsrv05 using Proxy Host ovmsrv06 and Fence Agent ilo:10.4.192.212. Jan 31, 2017 10:25:15 AM Power management stop of Host ovmsrv05 initiated. Jan 31, 2017 10:25:12 AM Executing power management status on Host ovmsrv05 using Proxy Host ovmsrv06 and Fence Agent ilo:10.4.192.212. Watching the timestamps, the culprit seems the reboot time of ovmsrv05 that detects some LUNs in owned state and other ones in unowned Full messages of both hosts here: https://drive.google.com/file/d/0BwoPbcrMv8mvekZQT1pjc0NMRlU/view?usp=shari… and https://drive.google.com/file/d/0BwoPbcrMv8mvcjBCYVdFZWdXTms/view?usp=shari… At this time there are 4 LUNs globally seen by the two hosts but only 1 of them is currently configured as the only storage domain in oVirt cluster. [root@ovmsrv05 ~]# multipath -l | grep ^36 3600a0b8000299aa80000d08b55014119 dm-5 IBM ,1814 FAStT 3600a0b80002999020000cd3c5501458f dm-3 IBM ,1814 FAStT 3600a0b80002999020000ccf855011198 dm-2 IBM ,1814 FAStT 3600a0b8000299aa80000d08955014098 dm-4 IBM ,1814 FAStT the configured one: [root@ovmsrv05 ~]# multipath -l 3600a0b8000299aa80000d08b55014119 3600a0b8000299aa80000d08b55014119 dm-5 IBM ,1814 FAStT size=4.0T features='0' hwhandler='1 rdac' wp=rw |-+- policy='service-time 0' prio=0 status=active | |- 0:0:1:3 sdl 8:176 active undef running | `- 2:0:1:3 sdp 8:240 active undef running `-+- policy='service-time 0' prio=0 status=enabled |- 0:0:0:3 sdd 8:48 active undef running `- 2:0:0:3 sdi 8:128 active undef running In mesages of booting node, arounf the problem registered by the storage: [root@ovmsrv05 ~]# grep owned /var/log/messages Jan 31 10:27:38 ovmsrv05 kernel: scsi 0:0:0:1: rdac: LUN 1 (RDAC) (owned) Jan 31 10:27:38 ovmsrv05 kernel: scsi 0:0:0:2: rdac: LUN 2 (RDAC) (owned) Jan 31 10:27:38 ovmsrv05 kernel: scsi 0:0:0:3: rdac: LUN 3 (RDAC) (unowned) Jan 31 10:27:38 ovmsrv05 kernel: scsi 2:0:0:1: rdac: LUN 1 (RDAC) (owned) Jan 31 10:27:38 ovmsrv05 kernel: scsi 0:0:0:4: rdac: LUN 4 (RDAC) (unowned) Jan 31 10:27:38 ovmsrv05 kernel: scsi 2:0:0:2: rdac: LUN 2 (RDAC) (owned) Jan 31 10:27:38 ovmsrv05 kernel: scsi 0:0:1:1: rdac: LUN 1 (RDAC) (unowned) Jan 31 10:27:38 ovmsrv05 kernel: scsi 2:0:0:3: rdac: LUN 3 (RDAC) (unowned) Jan 31 10:27:38 ovmsrv05 kernel: scsi 2:0:0:4: rdac: LUN 4 (RDAC) (unowned) Jan 31 10:27:38 ovmsrv05 kernel: scsi 0:0:1:2: rdac: LUN 2 (RDAC) (unowned) Jan 31 10:27:38 ovmsrv05 kernel: scsi 2:0:1:1: rdac: LUN 1 (RDAC) (unowned) Jan 31 10:27:38 ovmsrv05 kernel: scsi 0:0:1:3: rdac: LUN 3 (RDAC) (owned) Jan 31 10:27:38 ovmsrv05 kernel: scsi 2:0:1:2: rdac: LUN 2 (RDAC) (unowned) Jan 31 10:27:38 ovmsrv05 kernel: scsi 0:0:1:4: rdac: LUN 4 (RDAC) (owned) Jan 31 10:27:38 ovmsrv05 kernel: scsi 2:0:1:3: rdac: LUN 3 (RDAC) (owned) Jan 31 10:27:39 ovmsrv05 kernel: scsi 2:0:1:4: rdac: LUN 4 (RDAC) (owned) I don't know exactly the meaning of owned/unowned in the output above.. Possibly it detects the 0:0:1:3 and 2:0:1:3 paths (those of the active group) as "owned" and this could have created problems with the active node? On active node strangely I don't loose all the paths, but the VM has been paused anyway [root@ovmsrv06 log]# grep "remaining active path" /var/log/messages Jan 31 10:27:48 ovmsrv06 multipathd: 3600a0b8000299aa80000d08b55014119: remaining active paths: 3 Jan 31 10:27:49 ovmsrv06 multipathd: 3600a0b8000299aa80000d08b55014119: remaining active paths: 2 Jan 31 10:27:56 ovmsrv06 multipathd: 3600a0b8000299aa80000d08b55014119: remaining active paths: 3 Jan 31 10:27:56 ovmsrv06 multipathd: 3600a0b8000299aa80000d08b55014119: remaining active paths: 2 Jan 31 10:27:56 ovmsrv06 multipathd: 3600a0b8000299aa80000d08b55014119: remaining active paths: 1 Jan 31 10:27:57 ovmsrv06 multipathd: 3600a0b8000299aa80000d08b55014119: remaining active paths: 2 Jan 31 10:28:01 ovmsrv06 multipathd: 3600a0b8000299aa80000d08b55014119: remaining active paths: 3 Jan 31 10:28:01 ovmsrv06 multipathd: 3600a0b8000299aa80000d08b55014119: remaining active paths: 4 I'm not an expert of this storage array in particular, and of the rdac hardware handler in general. What I see is that multipath.conf on both nodes: # VDSM REVISION 1.3 defaults { polling_interval 5 no_path_retry fail user_friendly_names no flush_on_last_del yes fast_io_fail_tmo 5 dev_loss_tmo 30 max_fds 4096 } devices { device { # These settings overrides built-in devices settings. It does not apply # to devices without built-in settings (these use the settings in the # "defaults" section), or to devices defined in the "devices" section. # Note: This is not available yet on Fedora 21. For more info see # https://bugzilla.redhat.com/1253799 all_devs yes no_path_retry fail } } beginning of /proc/scsi/scsi [root@ovmsrv06 ~]# cat /proc/scsi/scsi Attached devices: Host: scsi1 Channel: 01 Id: 00 Lun: 00 Vendor: HP Model: LOGICAL VOLUME Rev: 1.86 Type: Direct-Access ANSI SCSI revision: 05 Host: scsi0 Channel: 00 Id: 00 Lun: 01 Vendor: IBM Model: 1814 FAStT Rev: 0916 Type: Direct-Access ANSI SCSI revision: 05 ... To get default acquired config for this storage: multpathd -k > show config I can see: device { vendor "IBM" product "^1814" product_blacklist "Universal Xport" path_grouping_policy "group_by_prio" path_checker "rdac" features "0" hardware_handler "1 rdac" prio "rdac" failback immediate rr_weight "uniform" no_path_retry "fail" } and defaults { verbosity 2 polling_interval 5 max_polling_interval 20 reassign_maps "yes" multipath_dir "/lib64/multipath" path_selector "service-time 0" path_grouping_policy "failover" uid_attribute "ID_SERIAL" prio "const" prio_args "" features "0" path_checker "directio" alias_prefix "mpath" failback "manual" rr_min_io 1000 rr_min_io_rq 1 max_fds 4096 rr_weight "uniform" no_path_retry "fail" queue_without_daemon "no" flush_on_last_del "yes" user_friendly_names "no" fast_io_fail_tmo 5 dev_loss_tmo 30 bindings_file "/etc/multipath/bindings" wwids_file /etc/multipath/wwids log_checker_err always find_multipaths no retain_attached_hw_handler no detect_prio no hw_str_match no force_sync no deferred_remove no ignore_new_boot_devs no skip_kpartx no config_dir "/etc/multipath/conf.d" delay_watch_checks no delay_wait_checks no retrigger_tries 3 retrigger_delay 10 missing_uev_wait_timeout 30 new_bindings_in_boot no } Any hint on how to tune multipath.conf so that a powering on server doesn't create problems to running VMs? Thanks in advance, Gianluca

6 22

ovirt ugrade to 4.1.1 problem with ovirt-engine-notifier.service
by Kapetanakis Giannis 04 Apr '17

04 Apr '17

Hi, Centos 7 (no self hosted). Trying to upgrade from 4.1.0 to 4.1.1 he setup fails to start ovirt-engine-notifier.service ● ovirt-engine-notifier.service - oVirt Engine Notifier Loaded: loaded (/usr/lib/systemd/system/ovirt-engine-notifier.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Tue 2017-04-04 15:21:28 EEST; 30s ago Process: 4489 ExecStart=/usr/share/ovirt-engine/services/ovirt-engine-notifier/ovirt-engine-notifier.py --redirect-output --systemd=notify $EXTRA_ARGS start (code=exited, status=1/FAILURE) Main PID: 4489 (code=exited, status=1/FAILURE) Apr 04 15:21:28 vmgr.cc.uoc.gr ovirt-engine-notifier.py[4489]: stderr: at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198) Apr 04 15:21:28 vmgr.cc.uoc.gr ovirt-engine-notifier.py[4489]: stderr: at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363) Apr 04 15:21:28 vmgr.cc.uoc.gr ovirt-engine-notifier.py[4489]: stderr: at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351) Apr 04 15:21:28 vmgr.cc.uoc.gr ovirt-engine-notifier.py[4489]: stderr: at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93) Apr 04 15:21:28 vmgr.cc.uoc.gr ovirt-engine-notifier.py[4489]: stderr: ... 7 more Apr 04 15:21:28 vmgr.cc.uoc.gr ovirt-engine-notifier.py[4489]: Validation failed returncode is 1: Apr 04 15:21:28 vmgr.cc.uoc.gr systemd[1]: ovirt-engine-notifier.service: main process exited, code=exited, status=1/FAILURE Apr 04 15:21:28 vmgr.cc.uoc.gr systemd[1]: Failed to start oVirt Engine Notifier. Apr 04 15:21:28 vmgr.cc.uoc.gr systemd[1]: Unit ovirt-engine-notifier.service entered failed state. Apr 04 15:21:28 vmgr.cc.uoc.gr systemd[1]: ovirt-engine-notifier.service failed. >From installation log: 2017-04-04 15:07:48 DEBUG otopi.context context._executeMethod:128 Stage closeup METHOD otopi.plugins.ovirt_engine_common.base.system.hostile_services.Plugin._closeup 2017-04-04 15:07:48 DEBUG otopi.plugins.otopi.services.systemd systemd.exists:73 check if service ovirt-engine-notifier exists 2017-04-04 15:07:48 DEBUG otopi.plugins.otopi.services.systemd plugin.executeRaw:813 execute: ('/bin/systemctl', 'show', '-p', 'LoadState', 'ovirt-engine-notifier.service'), executable='None', cwd='None', env=None 2017-04-04 15:07:48 DEBUG otopi.plugins.otopi.services.systemd plugin.executeRaw:863 execute-result: ('/bin/systemctl', 'show', '-p', 'LoadState', 'ovirt-engine-notifier.service'), rc=0 2017-04-04 15:07:48 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:921 execute-output: ('/bin/systemctl', 'show', '-p', 'LoadState', 'ovirt-engine-notifier.service') stdout: LoadState=loaded 2017-04-04 15:07:48 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:926 execute-output: ('/bin/systemctl', 'show', '-p', 'LoadState', 'ovirt-engine-notifier.service') stderr: 2017-04-04 15:07:48 DEBUG otopi.plugins.otopi.services.systemd systemd.state:130 starting service ovirt-engine-notifier 2017-04-04 15:07:48 DEBUG otopi.plugins.otopi.services.systemd plugin.executeRaw:813 execute: ('/bin/systemctl', 'start', 'ovirt-engine-notifier.service'), executable='None', cwd='None', env=None 2017-04-04 15:07:49 DEBUG otopi.plugins.otopi.services.systemd plugin.executeRaw:863 execute-result: ('/bin/systemctl', 'start', 'ovirt-engine-notifier.service'), rc=1 2017-04-04 15:07:49 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:921 execute-output: ('/bin/systemctl', 'start', 'ovirt-engine-notifier.service') stdout: 2017-04-04 15:07:48 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:926 execute-output: ('/bin/systemctl', 'show', '-p', 'LoadState', 'ovirt-engine-notifier.service') stderr: 2017-04-04 15:07:48 DEBUG otopi.plugins.otopi.services.systemd systemd.state:130 starting service ovirt-engine-notifier 2017-04-04 15:07:48 DEBUG otopi.plugins.otopi.services.systemd plugin.executeRaw:813 execute: ('/bin/systemctl', 'start', 'ovirt-engine-notifier.service'), executable='None', cwd='None', env=None 2017-04-04 15:07:49 DEBUG otopi.plugins.otopi.services.systemd plugin.executeRaw:863 execute-result: ('/bin/systemctl', 'start', 'ovirt-engine-notifier.service'), rc=1 2017-04-04 15:07:49 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:921 execute-output: ('/bin/systemctl', 'start', 'ovirt-engine-notifier.service') stdout: 2017-04-04 15:07:49 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:926 execute-output: ('/bin/systemctl', 'start', 'ovirt-engine-notifier.service') stderr: Job for ovirt-engine-notifier.service failed because the control process exited with error code. See "systemctl status ovirt-engine-notifier.service" and "journalctl -xe" for details. 2017-04-04 15:07:49 DEBUG otopi.context context._executeMethod:142 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 132, in _executeMethod method['method']() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-common/base/system/hostile_services.py", line 104, in _closeup state=True File "/usr/share/otopi/plugins/otopi/services/systemd.py", line 141, in state service=name, RuntimeError: Failed to start service 'ovirt-engine-notifier' 2017-04-04 15:07:49 ERROR otopi.context context._executeMethod:151 Failed to execute stage 'Closing up': Failed to start service 'ovirt-engine-notifier' G

1 1

ovirt-guest-agent logs is this normal behavior
by rob cousins 04 Apr '17

04 Apr '17

After installing ovirt-guest-agent on ubuntu 16.04 following these instructions https://www.ovirt.org/documentation/how-to/guest-agent/install-the-guest-ag… i get the following messages in syslog is this normal behavior ? Apr 3 14:25:36 ubuntu python[1521]: #015Reading package lists... 0%#015#015Reading package lists... 100%#015#015Reading package lists... Done Apr 3 14:25:37 ubuntu python[1521]: #015Building dependency tree... 0%#015#015Building dependency tree... 0%#015#015Building dependency tree... 50%#015#015Building dependency tree... 50%#015#015Building dependency tree Apr 3 14:25:37 ubuntu python[1521]: #015Reading state information... 0%#015#015Reading state information... 0%#015#015Reading state information... Done Thanks Rob.

2 1

Re: [ovirt-users] iSCSI Discovery cannot detetect LUN
by Lukáš Kaplan 04 Apr '17

04 Apr '17

I did following steps: - delete target on all initiators (ovirt nodes) iscsiadm -m node -T iqn.2017-03.cz.dragon.ovirt.fuvs-sn1:10T -p 10.53.1.201:3260 -u iscsiadm -m node -T iqn.2017-03.cz.dragon.ovirt.fuvs-sn1:10T -p 10.53.1.201:3260 -o delete - stop tgtd on target - fill storage by zeroes (dd if=/dev/zero of=/dev/md125 bs=4096 status=progress) - start tgtd - tried to connect to ovirt (Discovery=ok, Login=ok, but can not see any LUN). === After that I ran this commands on one node: === [root@fudi-cn1 ~]# iscsiadm -m session -o show tcp: [1] 10.53.0.10:3260,1 iqn.2017-03.cz.dragon.ovirt:ovirtengine (non-flash) tcp: [11] 10.53.0.201:3260,1 iqn.2017-03.cz.dragon.ovirt.fudi-sn1:10T (non-flash) tcp: [12] 10.53.1.201:3260,1 iqn.2017-03.cz.dragon.ovirt.fuvs-sn1:10T (non-flash) [root@fudi-cn1 ~]# iscsiadm -m discoverydb -P1 SENDTARGETS: DiscoveryAddress: 10.53.0.201,3260 Target: iqn.2017-03.cz.dragon.ovirt:ovirtengine Portal: 10.53.0.201:3260,1 Iface Name: default iSNS: No targets found. STATIC: Target: iqn.2017-03.cz.dragon.ovirt.fuvs-sn1:10T Portal: 10.53.1.201:3260,1 Iface Name: default Target: iqn.2017-03.cz.dragon.ovirt:ovirtengine Portal: 10.53.0.10:3260,1 Iface Name: default Target: iqn.2017-03.cz.dragon.ovirt.fudi-sn1:10T Portal: 10.53.0.201:3260,1 Iface Name: default FIRMWARE: No targets found. === On iscsi target: === [root@fuvs-sn1 ~]# cat /proc/mdstat Personalities : [raid1] [raid6] [raid5] [raid4] md125 : active raid6 sdl1[11] sdk1[10] sdj1[9] sdi1[8] sdh1[7] sdg1[6] sdf1[5] sde1[4] sdd1[3] sdc1[2] sdb1[1] sda1[0] 9766302720 blocks super 1.2 level 6, 512k chunk, algorithm 2 [12/12] [UUUUUUUUUUUU] bitmap: 0/8 pages [0KB], 65536KB chunk ...etc... [root@fuvs-sn1 ~]# cat /etc/tgt/targets.conf default-driver iscsi <target iqn.2017-03.cz.dragon.ovirt.fuvs-sn1:10T> # provided devicce as a iSCSI target backing-store /dev/md125 # iSCSI Initiator's IP address you allow to connect #initiator-address 10.53.0.0/23 </target> -- Lukas Kaplan 2017-03-25 12:36 GMT+01:00 Lukas Kaplan <lkaplan(a)dragon.cz>: > Co muze myslet tim mappingem? > > Jinak muzu zkusit ddckem celou storage prepsat nulami. > > co ty na to? > > Odesláno z iPhonu > > Začátek přeposílané zprávy: > > *Od:* Yaniv Kaul <ykaul(a)redhat.com> > *Datum:* 24. března 2017 23:25:21 SEČ > *Komu:* Lukáš Kaplan <lkaplan(a)dragon.cz> > *Kopie:* users <users(a)ovirt.org> > *Předmět:* *Re: [ovirt-users] iSCSI Discovery cannot detetect LUN* > > > > On Fri, Mar 24, 2017 at 1:34 PM, Lukáš Kaplan <lkaplan(a)dragon.cz> wrote: > >> Hello all, >> >> please do you have some experience with troubleshooting adding of iSCSI >> domain to ovirt 4.1.1? >> >> I am chalenging this issue now: >> >> 1) I have successfuly installed oVirt 4.1.1 environment with self-hosted >> engine, 3 nodes and 3 storages (iSCSI Master domain, iSCSI for hosted >> engine and NFS ISO domain). Everything is working now. >> >> 2) But, when I want to add new iSCSI domain, I can discover it, I can >> login, but I cant see any LUN on that storage. (I had same problem in oVirt >> 4.1.0, so I made upgrade to 4.1.1) >> > > Are you sure mappings are correct? > Can you ensure the LUN is empty? > Y. > > >> >> 3) Then I tryed to add this storage to another oVirt environment (oVirt >> 3.6) and there are no problem. I can see LUN on that storage and I can >> connect it to oVirt. >> >> I tryed to examine vdsm.log, but it is very detailed and unredable for me >> :-/ >> >> Thak you in advance, have a nice day, >> -- >> Lukas Kaplan >> >> >> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users >> >> >

6 11

Python-SDK4: Listing template by ID throws exception
by nicolas＠devels.es 04 Apr '17

04 Apr '17

Hi, I'm using ovirt-engine-sdk-python 4.1.3 (ovirt ver is 4.1.0), and in a snippet I'm trying to get a template by its id. For that, I did this: conn = ovirtsdk4.Connection(...) sys_serv = conn.system_service() tpl_serv = sys_serv.templates_service() t = tpl_serv.list(search='id=fedff75f-635f-4790-9bbf-2ac389e14f93') And it throws: Error: Fault reason is "Operation Failed". Fault detail is "statementcallback; bad sql grammar [select * from (select * from vm templates view where ( vmt guid in (select distinct vm templates storage domain.vmt guid from vm templates storage domain where ( vm templates storage domain.cluster name ilike '%id=fedff75f-635f-4790-9bbf-2ac389e14f93%' or vm templates storage domain.description ilike '%id=fedff75f-635f-4790-9bbf-2ac389e14f93%' or vm templates storage domain.free text comment ilike '%id=fedff75f-635f-4790-9bbf-2ac389e14f93%' or vm templates storage domain.name ilike '%id=fedff75f-635f-4790-9bbf-2ac389e14f93%' or vm templates storage domain.quota name ilike '%id=fedff75f-635f-4790-9bbf-2ac389e14f93%' or vm templates storage domain.storage pool name ilike '%id=fedff75f-635f-4790-9bbf-2ac389e14f93%' or vm templates storage domain.template version name,template version number ilike '%id=fedff75f-635f-4790-9bbf-2ac389e14f93%' ) )) order by name asc ) as t1 offset (1 -1) limit 2147483647]; nested exception is org.postgresql.util.psqlexception: error: argument of or must be type boolean, not type character varying position: 737". HTTP response code is 400. I'm sure this template exists and it has this ID. If I search in the webadmin by this ID, the search seems to hang and never returns anything (I have to stop it by pressing the 'X' button). Am I using this call improperly? Thanks.

2 2

Re: [ovirt-users] Memory treshold
by vasily.lamykin 04 Apr '17

04 Apr '17

engine-config -s LogMaxPhysicalMemoryUsedThresholdInPercentage=%percent per threshold% Василий Ламыкин Старший инженер по эксплуатации сервисных платформ Эксплуатация сети Столичный филиал ПАО «МегаФон» +7 (926) 500-3308 -----Original Message----- From: users-bounces(a)ovirt.org [mailto:users-bounces@ovirt.org] On Behalf Of users-request(a)ovirt.org Sent: Wednesday, March 29, 2017 1:00 PM To: users(a)ovirt.org Subject: Users Digest, Vol 66, Issue 254 Send Users mailing list submissions to users(a)ovirt.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.ovirt.org/mailman/listinfo/users or, via email, send a message with subject or body 'help' to users-request(a)ovirt.org You can reach the person managing the list at users-owner(a)ovirt.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Users digest..." Today's Topics: 1. Re: VM "hot" RAM memory decrease (Martin Sivak) 2. Memory treshold (vasily.lamykin) 3. Re: iSCSI Discovery cannot detetect LUN (Eduardo Mayoral) ---------------------------------------------------------------------- Message: 1 Date: Wed, 29 Mar 2017 11:50:59 +0200 From: Martin Sivak <msivak(a)redhat.com> To: Nicol?s <nicolas(a)devels.es> Cc: users <users(a)ovirt.org> Subject: Re: [ovirt-users] VM "hot" RAM memory decrease Message-ID: <CAF0zDV5BG9PmzpaTS+73QKYELTv8ThNJcZoiGoySYsEuGV2c9Q(a)mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Hi Nicolas, you are right, the log shows exactly the right values. Those numbers are exactly what is sent to libvirt using currentMemory field in https://libvirt.org/formatdomain.html#elementsMemoryAllocation So if the VM does not have enough memory, we will have to start looking there. Best regards Martin Sivak On Wed, Mar 29, 2017 at 11:04 AM, <nicolas(a)devels.es> wrote: > Hi Martin, > > I do, I'm attaching it. I merged the full day's log into one. > Significant hours start at 11:24:57 (log time). The interesting > machine is called jbaspre01, and as per what I can deduce, the values > in log are correct (it never goes under the threshold of 1GB, which is > its minimum). However, my colleagues and I are 100% sure we saw this > machine having about 600K KiB when running top. > > This machine has: > Memory size: 8196 MB > Minimal guaranteed memory: 1024 MB > > If you need additional information don't hesitate to ask. > > Regards. > > > El 2017-03-29 09:44, Martin Sivak escribi?: >> >> Hi Nicolas, >> >> KiB Mem tells you how much memory the host has. I am actually more >> interested in the VM. Do you still have the mom.log from the time >> this happened? We keep the logs for some time (they are rotated). >> >> Best regards >> >> Martin >> >> On Wed, Mar 29, 2017 at 10:28 AM, <nicolas(a)devels.es> wrote: >>> >>> El 2017-03-28 15:33, Martin Sivak escribi?: >>>>> >>>>> >>>>> min guaranteed should be respected, adding mom maintainer Martin >>>> >>>> >>>> >>>> I can't really help without the mom.log and the virsh dumpxml >>>> output of that VM in the final state (all memory ballooned). >>>> >>>> Min guaranteed should be respected, but the question is how the >>>> physical memory was measured (which number from top was used). >>>> >>>> -- >>>> Martin Sivak >>>> SLA / oVirt >>>> >>> >>> Hi Martin, >>> >>> I tried to reproduce the issue again and I was unable to. I had a >>> host with ~90% of RAM utilization and in mom.log I could see that >>> ballooning was indeed happening, but I couldn't see a VM going under >>> its minimum guaranteed threshold (at least not significantly). >>> >>> On top, I was using the 'KiB Mem' value to compare. I know this is >>> in KiB and that oVirt has its values as MB in the webadmin, but when >>> I sent this message the difference was quite more significant >>> (1024MB of minimum guaranteed and about 640K KiB on the VM). >>> >>> It's also true that meanwhile we upgraded from 4.0.2 to 4.1.1 and >>> this time I couldn't reproduce it anymore. >>> >>> If at some point I am able to reproduce it again, I'll send detailed >>> logs of the issue. >>> >>> Thanks. >>> >>> >>>> On Tue, Mar 28, 2017 at 4:29 PM, Michal Skrivanek >>>> <michal.skrivanek(a)redhat.com> wrote: >>>>> >>>>> >>>>> >>>>>> On 27 Mar 2017, at 23:15, Nicol?s <nicolas(a)devels.es> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I don't really know if this question is suitable on this list, as >>>>>> I doubt it's an oVirt bug, neither I know if it shall be >>>>>> considered a bug. >>>>>> >>>>>> We recently run a VM on a host that was memory over-used (around >>>>>> 80% of usage). The VM booted correctly, then we run "top" and saw >>>>>> how physical RAM started decreasing every two seconds. At first >>>>>> it was 4GB, then less and less until it stabilized at around >>>>>> 600MB. >>>>>> >>>>>> Based on this (correct me if I'm wrong), we believe this is an >>>>>> effect of having this VM with ballooning enabled, as it does >>>>>> exactly this: It adds/removes RAM depending on host decision. >>>>>> Thing is that this VM had a minimal guaranteed RAM of 1GB, so >>>>>> even if this happened due to ballooning, I'm not sure if it >>>>>> should have honored the minimum guaranteed RAM. >>>>>> >>>>>> When this happened, we run a 'ps' to see with what options the >>>>>> qemu process was invoked, and parameters seemed correct (that's >>>>>> why I don't know if it should be posted here or even if it's a >>>>>> bug). >>>>> >>>>> >>>>> >>>>> It does belong here, it?s a different component doing it ?externally? >>>>> to >>>>> the qemu process- mom. >>>>> >>>>>> >>>>>> Is this the expected behavior? >>>>> >>>>> >>>>> >>>>> min guaranteed should be respected, adding mom maintainer Martin >>>>> >>>>> Thanks, >>>>> michal >>>>> >>>>>> >>>>>> Thanks. >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> Users(a)ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/users >>>>>> >>>>>> >>>>> > ------------------------------ Message: 2 Date: Wed, 29 Mar 2017 09:46:18 +0000 From: vasily.lamykin <vasily.lamykin(a)MegaFon.ru> To: "users(a)ovirt.org" <users(a)ovirt.org> Subject: [ovirt-users] Memory treshold Message-ID: <78c01f9d8162434bbebbfe6a92222ba0(a)vlg-ums05.Megafon.ru> Content-Type: text/plain; charset="utf-8" Hi all. Explain please, where I can disable for cluster this threshold: Used memory of host *** [98%] exceeded defined threshold [95%]. ? ??????? ??????? ??????? ??????? ?? ???????????? ????????? ???????? ???????????? ???? ????????? ?????? ??? ????????? +7 (926) 500-3308 [??????? ????+???? ??? B2C] ________________________________ ?????????? ? ???? ????????? ????????????? ????????????? ??? ?????????? ???, ??????? ??? ??????????. ? ????????? ????? ??????????? ???????????????? ??????????, ??????? ?? ????? ???? ???????? ??? ???????????? ???-????, ????? ?????????. ???? ?? ?? ??????? ????? ?????????, ?? ?????????????, ?????????????, ??????????? ??? ??????????????? ?????????? ????????? ??? ??? ????? ????????? ? ?????????. ???? ?? ???????? ??? ????????? ????????, ??????????, ??????????????? ???????? ??????????? ?? ???? ? ??????? ?? ???? ?????????? ???? ????????? ? ????? ????????? ??? ????? ? ??????????. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ovirt.org/pipermail/users/attachments/20170329/5be75efd/attach…> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 2130 bytes Desc: image001.png URL: <http://lists.ovirt.org/pipermail/users/attachments/20170329/5be75efd/attach…> ------------------------------ Message: 3 Date: Wed, 29 Mar 2017 11:59:46 +0200 From: Eduardo Mayoral <emayoral(a)arsys.es> To: Luk?? Kaplan <lkaplan(a)dragon.cz>,users <users(a)ovirt.org> Subject: Re: [ovirt-users] iSCSI Discovery cannot detetect LUN Message-ID: <2e73ca85-6e54-2994-b25f-4a11a03baac4(a)arsys.es> Content-Type: text/plain; charset="utf-8"; Format="flowed" I had a similar problem, in my case this was related to multipath, it was not masking the LUNs correctly, it was seeing it multiple times (one per path), and I could not select the LUNs in the oVirt interface. Once I configured multipath correctly, everything worked like a charm. Best regards, -- Eduardo Mayoral. On 29/03/17 11:30, Luk?? Kaplan wrote: > Hello all, > > I did all steps as I described in previous email, but no change. I > can't see any LUN after discovery and login of new iSCSI storage. > (That storage is ok, if I try to connect it to another and older ovirt > domain, it is working...) > > I tryed it on 3 new iSCSI targets alredy, all have same problem... > > Can somebody help me, please? > > -- > Lukas Kaplan > > > 2017-03-27 16:22 GMT+02:00 Luk?? Kaplan <lkaplan(a)dragon.cz > <mailto:lkaplan@dragon.cz>>: > > I did following steps: > - delete target on all initiators (ovirt nodes) > iscsiadm -m node -T iqn.2017-03.cz.dragon.ovirt.fuvs-sn1:10T -p > 10.53.1.201:3260 <http://10.53.1.201:3260> -u > iscsiadm -m node -T iqn.2017-03.cz.dragon.ovirt.fuvs-sn1:10T -p > 10.53.1.201:3260 <http://10.53.1.201:3260> -o delete > - stop tgtd on target > - fill storage by zeroes (dd if=/dev/zero of=/dev/md125 bs=4096 > status=progress) > - start tgtd > - tried to connect to ovirt (Discovery=ok, Login=ok, but can not > see any LUN). > > === After that I ran this commands on one node: === > > [root@fudi-cn1 ~]# iscsiadm -m session -o show > tcp: [1] 10.53.0.10:3260 <http://10.53.0.10:3260>,1 > iqn.2017-03.cz.dragon.ovirt:ovirtengine (non-flash) > tcp: [11] 10.53.0.201:3260 <http://10.53.0.201:3260>,1 > iqn.2017-03.cz.dragon.ovirt.fudi-sn1:10T (non-flash) > tcp: [12] 10.53.1.201:3260 <http://10.53.1.201:3260>,1 > iqn.2017-03.cz.dragon.ovirt.fuvs-sn1:10T (non-flash) > > [root@fudi-cn1 ~]# iscsiadm -m discoverydb -P1 > SENDTARGETS: > DiscoveryAddress: 10.53.0.201,3260 > Target: iqn.2017-03.cz.dragon.ovirt:ovirtengine > Portal: 10.53.0.201:3260 <http://10.53.0.201:3260>,1 > Iface Name: default > iSNS: > No targets found. > STATIC: > Target: iqn.2017-03.cz.dragon.ovirt.fuvs-sn1:10T > Portal: 10.53.1.201:3260 <http://10.53.1.201:3260>,1 > Iface Name: default > Target: iqn.2017-03.cz.dragon.ovirt:ovirtengine > Portal: 10.53.0.10:3260 <http://10.53.0.10:3260>,1 > Iface Name: default > Target: iqn.2017-03.cz.dragon.ovirt.fudi-sn1:10T > Portal: 10.53.0.201:3260 <http://10.53.0.201:3260>,1 > Iface Name: default > FIRMWARE: > No targets found. > > === On iscsi target: === > [root@fuvs-sn1 ~]# cat /proc/mdstat > Personalities : [raid1] [raid6] [raid5] [raid4] > md125 : active raid6 sdl1[11] sdk1[10] sdj1[9] sdi1[8] sdh1[7] > sdg1[6] sdf1[5] sde1[4] sdd1[3] sdc1[2] sdb1[1] sda1[0] > 9766302720 blocks super 1.2 level 6, 512k chunk, algorithm 2 > [12/12] [UUUUUUUUUUUU] > bitmap: 0/8 pages [0KB], 65536KB chunk > ...etc... > > > [root@fuvs-sn1 ~]# cat /etc/tgt/targets.conf > default-driver iscsi > > <target iqn.2017-03.cz.dragon.ovirt.fuvs-sn1:10T> > # provided devicce as a iSCSI target > backing-store /dev/md125 > # iSCSI Initiator's IP address you allow to connect > #initiator-address 10.53.0.0/23 <http://10.53.0.0/23> > </target> > > -- > Lukas Kaplan > > 2017-03-25 12:36 GMT+01:00 Lukas Kaplan <lkaplan(a)dragon.cz > <mailto:lkaplan@dragon.cz>>: > > Co muze myslet tim mappingem? > > Jinak muzu zkusit ddckem celou storage prepsat nulami. > > co ty na to? > > Odesl?no z iPhonu > > Za??tek p?epos?lan? zpr?vy: > >> *Od:* Yaniv Kaul <ykaul(a)redhat.com <mailto:ykaul@redhat.com>> >> *Datum:* 24. b?ezna 2017 23:25:21 SE? >> *Komu:* Luk?? Kaplan <lkaplan(a)dragon.cz >> <mailto:lkaplan@dragon.cz>> >> *Kopie:* users <users(a)ovirt.org <mailto:users@ovirt.org>> >> *P?edm?t:* *Re: [ovirt-users] iSCSI Discovery cannot detetect >> LUN* >> >> >> >> On Fri, Mar 24, 2017 at 1:34 PM, Luk?? Kaplan >> <lkaplan(a)dragon.cz <mailto:lkaplan@dragon.cz>> wrote: >> >> Hello all, >> >> please do you have some experience with troubleshooting >> adding of iSCSI domain to ovirt 4.1.1? >> >> I am chalenging this issue now: >> >> 1) I have successfuly installed oVirt 4.1.1 environment >> with self-hosted engine, 3 nodes and 3 storages (iSCSI >> Master domain, iSCSI for hosted engine and NFS ISO >> domain). Everything is working now. >> >> 2) But, when I want to add new iSCSI domain, I can >> discover it, I can login, but I cant see any LUN on that >> storage. (I had same problem in oVirt 4.1.0, so I made >> upgrade to 4.1.1) >> >> >> Are you sure mappings are correct? >> Can you ensure the LUN is empty? >> Y. >> >> >> 3) Then I tryed to add this storage to another oVirt >> environment (oVirt 3.6) and there are no problem. I can >> see LUN on that storage and I can connect it to oVirt. >> >> I tryed to examine vdsm.log, but it is very detailed and >> unredable for me :-/ >> >> Thak you in advance, have a nice day, >> -- >> Lukas Kaplan >> >> >> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org <mailto:Users@ovirt.org> >> http://lists.ovirt.org/mailman/listinfo/users >> <http://lists.ovirt.org/mailman/listinfo/users> >> >> > > > > > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ovirt.org/pipermail/users/attachments/20170329/e73ab86f/attach…> ------------------------------ _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users End of Users Digest, Vol 66, Issue 254 ************************************** ________________________________ Информация в этом сообщении предназначена исключительно для конкретных лиц, которым она адресована. В сообщении может содержаться конфиденциальная информация, которая не может быть раскрыта или использована кем-либо, кроме адресатов. Если вы не адресат этого сообщения, то использование, переадресация, копирование или распространение содержания сообщения или его части незаконно и запрещено. Если Вы получили это сообщение ошибочно, пожалуйста, незамедлительно сообщите отправителю об этом и удалите со всем содержимым само сообщение и любые возможные его копии и приложения. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50

1 0

iSCSI Multipathing
by Devin A. Bougie 04 Apr '17

04 Apr '17

We have a new 4.1.1 cluster up and running with OVS switches and an iSCSI hosted_storage and VM data domain (same target, different LUN's). Everything works fine, and I can configure iscsid and multipathd outside of the oVirt engine to ensure redundancy with our iSCSI device. However, if I try to configure iSCSI Multipathing within the engine, all of the hosts get stuck in the "Connecting" status and the Data Center and Storage Domains go down. The hosted engine, however, continues to work just fine. Before I provide excerpts from our logs and more details on what we're seeing, it would be helpful to understand better what the advantages are of configuring iSCSI Bonds within the oVirt engine. Is this mainly a feature for oVirt users that don't have experience configuring and managing iscsid and multipathd directly? Or, is it important to actually setup iSCSI Bonds within the engine instead of directly in the underlying OS? Any advice or links to documentation I've overlooked would be greatly appreciated. Many thanks, Devin

2 3