- Users - oVirt List Archives

Can't restart hosted-engine installation: vdsm did not start
by gregor 17 Oct '16

17 Oct '16

Hi, after a failed hosted-engine installation I removed all the ovirt and vdsm packages, rebooted the system and started from scratch. But when I run "hosted-engine --deploy" it stuck's during starting vdsm. The logfile /var/log/vdsm/supervdsm.log gives me the following ... MainThread::DEBUG::2016-10-16 20:54:42,065::storage_log::69::blivet::(log_exception_info) IGNORED: Caught exception, continuing. MainThread::DEBUG::2016-10-16 20:54:42,065::storage_log::72::blivet::(log_exception_info) IGNORED: Problem description: failed to get initiator name from iscsi firmware MainThread::DEBUG::2016-10-16 20:54:42,065::storage_log::73::blivet::(log_exception_info) IGNORED: Begin exception details. MainThread::DEBUG::2016-10-16 20:54:42,066::storage_log::76::blivet::(log_exception_info) IGNORED: Traceback (most recent call last): MainThread::DEBUG::2016-10-16 20:54:42,066::storage_log::76::blivet::(log_exception_info) IGNORED: File "/usr/lib/python2.7/site-packages/blivet/iscsi.py", line 142, in __init__ MainThread::DEBUG::2016-10-16 20:54:42,066::storage_log::76::blivet::(log_exception_info) IGNORED: initiatorname = libiscsi.get_firmware_initiator_name() MainThread::DEBUG::2016-10-16 20:54:42,066::storage_log::76::blivet::(log_exception_info) IGNORED: IOError: Unknown error MainThread::DEBUG::2016-10-16 20:54:42,066::storage_log::77::blivet::(log_exception_info) IGNORED: End exception details. ... Can anybody help? I found a old are close again like so many other bug reports with "CLOSED CURRENTRELEASE": https://bugzilla.redhat.com/show_bug.cgi?id=1238239 cheers gregor

2 4

ovirt list's smtp on blacklist?
by Jiří Sléžka 17 Oct '16

17 Oct '16

This is a cryptographically signed message in MIME format. --------------ms050204090703000502050305 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello, it looks like mailserver which serving users(a)ovirt.org is on blacklist. line from our smtp server log... Oct 17 15:31:25 hermes postfix/smtpd[14082]: NOQUEUE: reject: RCPT from=20 lists.ovirt.org[2600:3c01::f03c:91ff:fe93:4b0d]: 554 5.7.1 Service=20 unavailable; Client host [2600:3c01::f03c:91ff:fe93:4b0d] blocked using=20 sbl.spamhaus.org; https://www.spamhaus.org/sbl/query/SBLCSS;=20 from=3D<users-bounces(a)ovirt.org> to=3D<jiri.slezka(a)slu.cz> proto=3DESMTP = helo=3D<lists.ovirt.org> Cheers, Jiri --------------ms050204090703000502050305 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CWcwggScMIIDhKADAgECAhEAuOSLPwlcx/l5IqBlguM0fDANBgkqhkiG9w0BAQUFADA7MQsw CQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwg Q0EwHhcNMTQxMTEwMDAwMDAwWhcNMTYxMTA5MjM1OTU5WjBlMQswCQYDVQQGEwJDWjElMCMG A1UECgwcU2xlenNrw6EgdW5pdmVyeml0YSB2IE9wYXbEmzEYMBYGA1UEAwwPSmnFmcOtIFNs w6nFvmthMRUwEwYJKoZIhvcNAQkCFgZzbGV6a2EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDNcPHUXg4ZfD3shn/1zeMf8tyn/ZplDk1756hc+PVHYNO2VRP2p1HKRdtcfj1i 2V87na0EfMmfxM77dJJklSnAsCXrs0by2eHzdCz746vErs5VkSnZ1nhOWH7FViKadiyxmAv+ zXL+jkzb678GHsT2jPWdHjfhgQXAzd0hE5AqkQ3sRGRspsfruRmfgStEoE2+Ubq4jC69pBYW i80zdAUOc+9Kl5Zfolfo/TpFViXIo4i1FMgDRNYZAhBKpHz70zN/7VUqTl/7x9z3a6ytNC8J TbbMdj8SdWhRV0oyOOhYlFHL+1ZS0KtQ0iz5yWs9dCkq77LrTXCXaWSGBRlQ8H/5AgMBAAGj ggFvMIIBazAfBgNVHSMEGDAWgBRjTUNaGUg/xEbBArq/7g7lgrdmpjAdBgNVHQ4EFgQUNHjX Vei/P0DdklwoP8A3Tkq0XTYwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBgGA1UdIAQRMA8wDQYLKwYBBAGyMQECAh0wPwYD VR0fBDgwNjA0oDKgMIYuaHR0cDovL2NybC50Y3MudGVyZW5hLm9yZy9URVJFTkFQZXJzb25h bENBLmNybDByBggrBgEFBQcBAQRmMGQwOgYIKwYBBQUHMAKGLmh0dHA6Ly9jcnQudGNzLnRl cmVuYS5vcmcvVEVSRU5BUGVyc29uYWxDQS5jcnQwJgYIKwYBBQUHMAGGGmh0dHA6Ly9vY3Nw LnRjcy50ZXJlbmEub3JnMB0GA1UdEQQWMBSBEmppcmkuc2xlemthQHNsdS5jejANBgkqhkiG 9w0BAQUFAAOCAQEAJy6bixJ53paigwWwnXfipRly2TTkICwf4PtXw9hOBoYC17PbPpAoGBtT Dvz6pQW4woSJ4JbkkD9JKGPlZXt0fQgZKgbfQ7sRFQ54goOhvJYm+CFJUPiSXrZ/i1CUzI40 U3kXYbWOq99yKid5aUEaIub9E6cJY6fybt7ireTV2IKVNIm/AXWjjf6jxGVavQ1QzTxmRvfE sXpQis5jgCeJjRHhZ4BhwRChkIThLYfWTSYId9rbtuj3yjLjtJipDhHJEuIckgV8sCDbjbyt xo0WNLQmfL0KUVxvpfMfdZ3McGKwn7nQiqBcpsGI3+9pfmHkMzy4+rDGZCHkeyNNxEUpLDCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMDkwNTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEP MA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpD m/5bsbC/tFfcdYBBS2Qa9ttPb4/QJUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5Y M38i+/j/7Oa+264KZSUih9pvhItG6ECGKD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyh bp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51WJFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZ UcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSbA/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V 0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRu fTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYDVR0PAQH/BAQDAgEGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTBYBgNVHR8EUTBPME2g S6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRo ZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYBBQUHMAKGLGh0 dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzAB hhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lTLxPc XDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxs H0+pAMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/ HaWWWr3QyxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXc J4bkOjtSWherqQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYIDGjCCAxYCAQEwUDA7MQswCQYD VQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EC EQC45Is/CVzH+XkioGWC4zR8MA0GCWCGSAFlAwQCAQUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEwMTcxOTI3MjRaMC8GCSqGSIb3DQEJBDEi BCDzCEKI4itJBteemb5K3JGUkH8KzqDGSO5VWkoYQpCf9zBfBgkrBgEEAYI3EAQxUjBQMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQQIRALjkiz8JXMf5eSKgZYLjNHwwYQYLKoZIhvcNAQkQAgsxUqBQMDsxCzAJBgNVBAYT Ak5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBDQQIRALjk iz8JXMf5eSKgZYLjNHwwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUD BAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQASqcTQh1MmiMVxkQWB+hPZp1HB CtKl723HIo0ZUlor4RRFN22J2kgkKea7i1WP31sAKvSVVzjCHLdGYze1gGbjRpJx2x8nVS67 Iflr/zsR65pXaVJN5JFHtahAsgEbja2KMlIYF4RnXjxL1kE7jHey0yfn/svOqpTW+arWjXWQ jh0dZ8m66MGZtdWO8Cd7PeB+ZCpqiwM8KfnoB6U71Ty2g+6eLO1o97KJpxtDnV/9FaMaPgjH XyoycahgGDYkTlAVm9TL6CwvuTpsT7awyK1btlhzeyTEOj+xXzAhRYlAPYc8g/D/41hzec1y AV0M2yrSsMNOBPp/Sq46KtUguBUhAAAAAAAA --------------ms050204090703000502050305--

1 0

oVirt AD integration problems
by cmc 17 Oct '16

17 Oct '16

Hi, I'm trying to use the directory services provided by the ovirt-engine-extension-aaa-ldap, and I can get it to successfully login when I run the tests in the setup script, but when I login via the GUI, it gives me: unexpected error was encountered during validation processing: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated' and fails login. It looks a bit like it is expecting to already be joined to the domain, so I tried doing that manually via realmd and sssd. It involved installing a lot of packages, such as kerberos and samba, which I am nervous about on an engine host. Anyway, once I was joined, it still gives me the same 'peer not authenticated' message. Does it need to be separately bound to the domain, i.e., do you need all the other stuff installed and running for it to work, or is the ovirt-engine-extension-aaa-ldap package all that is needed? Anyway, I ran the ovirt-engine-extensions-tool --log-level=FINEST --log-file=/tmp/aaa.log aaa search --extension-name=domain-authz command suggested in an earlier post, and it only gave me one exception, which was: 2016-09-28 16:08:15 SEVERE Extension domain-authz could not be found 2016-09-28 16:08:15 FINE Exception: org.ovirt.engine.core.extensions.mgr.ConfigurationException: Extension domain-authz could not be found Thanks for any help, Cam

2 9

Re: [ovirt-users] oVirt AD integration problems
by Karli Sjöberg 14 Oct '16

14 Oct '16

--_000_ae004950fd40475d99b4ac034352c4b2exch24sluse_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpEZW4gMTQgb2t0LiAyMDE2IDQ6MzAgZW0gc2tyZXYgY21jIDxpdWNvdW51QGdtYWlsLmNvbT46 DQo+DQo+IEhpIE9uZHJhLA0KPg0KPiBJdCBtYW5hZ2VzIHRvIGF1dGhlbnRpY2F0ZSwgYnV0IGFw cGVuZHMgdGhlIGRvbWFpbiBhZ2FpbiBvbmNlIEknbSBsb2dnZWQgaW4sIGZvciBpbnN0YW5jZSwg aWYgSSBsb2cgaW4gYXMgdXNlciAnY2FtJywgaXQgd2lsbCBsb2cgbWUgaW4sDQo+IGFuZCBkaXNw bGF5IHRoZSBsb2dpbiBuYW1lIGluIHRoZSB0b3AgcmlnaHQgY29ybmVyIGFzICdjYW1AZG9tYWlu LmNvbUBkb21haW4uY29tJyAodGhpcyBzaG93cyB1cCBpbiB0aGUgbG9nIGFzIHdlbGw6IGl0IHNo b3dzIG1lDQo+IGxvZ2dpbmcgaW4gYXMgY2FtQGRvbWFpbi5jb20sIGJ1dCB0aGVuIHJldHVybnMg YW4gZXJyb3IgYXMgdXNlciAgY2FtQGRvbWFpbi5jb21AZG9tYWluLmNvbSBpcyBub3QgYXV0aG9y aXplZCkuIE15IHRob3VnaHQgd2FzDQo+IHRoYXQgc29tZXRoaW5nIGRvbmUgZWFybGllciB3aGVu IEkgd2FzIHBsYXlpbmcgYXJvdW5kIHdpdGggc3NzZCwga2VyYmVyb3MgYW5kIEFEIGlzIGRvaW5n IHRoaXMsIHRob3VnaCBJIGhhdmUgcmVtb3ZlZCB0aGVzZSBwYWNrYWdlcw0KPiBhbmQgcnVuIGF1 dGhjb25maWcgdG8gcmVtb3ZlIHNzc2QuIEFueSBpZGVhcz8NCg0KQ2FuJ3Qgc2F5IHdoeSwgYnV0 IGl0J3MgdGhlIHNhbWUgZm9yIHVzLiBJdCdzIHVuc2lnaHRseSwga2luZGx5IHB1dC4NCg0KL0sN Cg0KPg0KPiBDaGVlcnMsDQo+DQo+IENhbQ0KPg0KPiBPbiBUaHUsIE9jdCAxMywgMjAxNiBhdCAy OjA0IFBNLCBjbWMgPGl1Y291bnVAZ21haWwuY29tPiB3cm90ZToNCj4+DQo+PiBIaSBPbmRyYSwN Cj4+DQo+PiBUaGF0IGlzIGdvb2QgdG8ga25vdyB0aGF0IHdlIGRvbid0IG5lZWQgS2VyYmVyb3Mg LSBpdCBjb21wbGljYXRlcyB0aGluZ3MgYSBsb3QuDQo+Pg0KPj4gSSB0aGluayB0aGUgZXJyb3Jz IG1pZ2h0IGJlIHRoZSBvcHRpb25zIEknZCBzZWxlY3RlZCBkdXJpbmcgdGhlIHNldHVwLiBJIHdh cyB0aHJvd24gYSBiaXQgdGhhdA0KPj4gaXQgcGFzc2VkIGFsbCB0aGUgaW50ZXJuYWwgdGVzdHMg cHJvdmlkZWQgYnkgdGhlIHNldHVwIHNjcmlwdCwgYnV0IGZhaWxlZCBvbiB0aGUgd2ViIEdVSS4g V2hlbg0KPj4gSSd2ZSBzZWVuICd1bnNwZWNpZmllZCBHU1MgZmFpbHVyZScgYW5kICdwZWVyIG5v dCBhdXRoZW50aWNhdGVkJyBpdCdzIHVzdWFsbHkgYmVlbiBkdWUgdG8NCj4+IEtlcmJlcm9zICh0 aG91Z2ggYWRtaXR0ZWRseSB0aGVzZSBhcmUganVzdCBnZW5lcmljIGVycm9ycykuIFNvIEkgdHJp ZWQgdGhlIFJlZGhhdCBndWlkZSBmb3IgU1NPIGF0Og0KPj4NCj4+IGh0dHBzOi8vYWNjZXNzLnJl ZGhhdC5jb20vZG9jdW1lbnRhdGlvbi9lbi1VUy9SZWRfSGF0X0VudGVycHJpc2VfVmlydHVhbGl6 YXRpb24vMy42L2h0bWwvQWRtaW5pc3RyYXRpb25fR3VpZGUvQ29uZmlndXJpbmdfTERBUF9hbmRf S2VyYmVyb3NfZm9yX1NpbmdsZV9TaWduLW9uLmh0bWwNCj4+DQo+PiB3aGljaCB1c2VzIEtlcmJl cm9zIChpbiBvdmlydC1zc28uY29uZikgSSBoYWQgdG8gcmVtb3ZlIHRoZSBzeW1saW5rIHRvIHRo ZSBBcGFjaGUNCj4+IGNvbmZpZyBpdCBzYXlzIHRvIGNyZWF0ZSwgYXMgaXQgcmVzdWx0cyBpbiBp bnRlcm5hbCBzZXJ2ZXIgZXJyb3JzIGluIEFwYWNoZS4gSXQgdXNlcyBhbiBTUE4gZm9yDQo+PiBB cGFjaGUgaW4gdGhlIGtleXRhYi4NCj4+DQo+PiBOb3cgdGhhdCB5b3UndmUgY29uZmlybWVkIHRo YXQgaXQgY2FuIGFjdHVhbGx5IHdvcmsgd2l0aG91dCBhbnkgbmVlZCBmb3IgdGhlIEtlcmJlcm9z IHN0dWZmLA0KPj4gSSB3aWxsIHN0YXJ0IGFmcmVzaCBmcm9tIGEgY2xlYW4gc2V0dXAgYW5kIGFw cGx5IHdoYXQgSSd2ZSBsZWFybnQgZHVyaW5nIHRoaXMgcHJvY2Vzcy4NCj4+DQo+PiBJJ2xsIHRy eSBpdCBvdXQgYW5kIGxldCB5b3Uga25vdyBlaXRoZXIgd2F5Lg0KPj4NCj4+IE1hbnkgdGhhbmtz IGZvciBhbGwgdGhlIGhlbHAhDQo+Pg0KPj4gS2luZCByZWdhcmRzLA0KPj4NCj4+IENhbQ0KPj4N Cj4+DQo+Pj4NCj4+PiBZZXMsIHlvdSByZWFsbHkgZG8gbm90IG5lZWQgYW55dGhpbmcga2VyYmVy b3MgcmVsYXRlZCB0byBzZWN1cmVseSBiaW5kDQo+Pj4gdG8gQUQgdmlhIExEQVAgc2ltcGxlIGJp bmQgb3ZlciBUTFMvU1NMLiBUaGlzIGlzIHJlYWxseSBzdHJhbmdlIHRvIG1lDQo+Pj4gd2hhdCBl cnJvcnMgeW91IGFyZSBnZXR0aW5nLCBidXQgeW91IHByb2JhYmx5IGNvbmZpZ3VyZWQgYXBhY2hl IChvcg0KPj4+IHNvbWV0aGluZyBlbHNlPykgdG8gcmVxdWlyZSBrZXl0YWIsIGJ1dCB5b3UgZG9u J3QgaGF2ZSB0bywgYW5kIHlvdSBjYW4NCj4+PiByZW1vdmUgdGhhdCBjb25maWd1cmF0aW9uLg0K Pj4+DQo+Pj4+DQo+Pj4+IFRoYW5rcywNCj4+Pj4NCj4+Pj4gQ2FtDQo+Pj4+DQo+Pj4+DQo+Pj4+ DQo+Pj4+DQo+Pj4+ICAgICAgICAgVGhhbmtzLA0KPj4+Pg0KPj4+PiAgICAgICAgIENhbQ0KPj4+ Pg0KPj4+PiAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+Pj4+DQo+Pj4+ICAgICAgICAgICAgICAgICBVc2VycyBtYWlsaW5nIGxpc3QNCj4+ Pj4gICAgICAgICAgICAgICAgIFVzZXJzQG92aXJ0Lm9yZyA8bWFpbHRvOlVzZXJzQG92aXJ0Lm9y Zz4NCj4+Pj4gICAgICAgICA8bWFpbHRvOlVzZXJzQG92aXJ0Lm9yZyA8bWFpbHRvOlVzZXJzQG92 aXJ0Lm9yZz4+DQo+Pj4+ICAgICAgICAgICAgICAgICBodHRwOi8vbGlzdHMub3ZpcnQub3JnL21h aWxtYW4vbGlzdGluZm8vdXNlcnMNCj4+Pj4gICAgICAgICA8aHR0cDovL2xpc3RzLm92aXJ0Lm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzPg0KPj4+PiAgICAgICAgICAgICAgICAgPGh0dHA6Ly9s aXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2Vycw0KPj4+PiAgICAgICAgIDxodHRw Oi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGluZm8vdXNlcnM+Pg0KPj4+Pg0KPj4+Pg0K Pj4+Pg0KPj4NCj4NCg== --_000_ae004950fd40475d99b4ac034352c4b2exch24sluse_ Content-Type: text/html; charset="utf-8" Content-ID: <C9AD4240A2DFAF4C92BCD8DA27CCC9CD(a)ad.slu.se> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pjxicj4NCkRlbiAxNCBva3QuIDIwMTYgNDozMCBlbSBza3JldiBjbWMgJmx0O2l1Y291bnVAZ21h aWwuY29tJmd0Ozo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBIaSBPbmRyYSw8YnI+DQomZ3Q7PGJyPg0K Jmd0OyBJdCBtYW5hZ2VzIHRvIGF1dGhlbnRpY2F0ZSwgYnV0IGFwcGVuZHMgdGhlIGRvbWFpbiBh Z2FpbiBvbmNlIEknbSBsb2dnZWQgaW4sIGZvciBpbnN0YW5jZSwgaWYgSSBsb2cgaW4gYXMgdXNl ciAnY2FtJywgaXQgd2lsbCBsb2cgbWUgaW4sPGJyPg0KJmd0OyBhbmQgZGlzcGxheSB0aGUgbG9n aW4gbmFtZSBpbiB0aGUgdG9wIHJpZ2h0IGNvcm5lciBhcyAnY2FtQGRvbWFpbi5jb21AZG9tYWlu LmNvbScgKHRoaXMgc2hvd3MgdXAgaW4gdGhlIGxvZyBhcyB3ZWxsOiBpdCBzaG93cyBtZTxicj4N CiZndDsgbG9nZ2luZyBpbiBhcyBjYW1AZG9tYWluLmNvbSwgYnV0IHRoZW4gcmV0dXJucyBhbiBl cnJvciBhcyB1c2VyJm5ic3A7IGNhbUBkb21haW4uY29tQGRvbWFpbi5jb20gaXMgbm90IGF1dGhv cml6ZWQpLiBNeSB0aG91Z2h0IHdhczxicj4NCiZndDsgdGhhdCBzb21ldGhpbmcgZG9uZSBlYXJs aWVyIHdoZW4gSSB3YXMgcGxheWluZyBhcm91bmQgd2l0aCBzc3NkLCBrZXJiZXJvcyBhbmQgQUQg aXMgZG9pbmcgdGhpcywgdGhvdWdoIEkgaGF2ZSByZW1vdmVkIHRoZXNlIHBhY2thZ2VzPGJyPg0K Jmd0OyBhbmQgcnVuIGF1dGhjb25maWcgdG8gcmVtb3ZlIHNzc2QuIEFueSBpZGVhcz88L3A+DQo8 cCBkaXI9Imx0ciI+Q2FuJ3Qgc2F5IHdoeSwgYnV0IGl0J3MgdGhlIHNhbWUgZm9yIHVzLiBJdCdz IHVuc2lnaHRseSwga2luZGx5IHB1dC48L3A+DQo8cCBkaXI9Imx0ciI+L0s8L3A+DQo8cCBkaXI9 Imx0ciI+Jmd0Ozxicj4NCiZndDsgQ2hlZXJzLDxicj4NCiZndDs8YnI+DQomZ3Q7IENhbTxicj4N CiZndDs8YnI+DQomZ3Q7IE9uIFRodSwgT2N0IDEzLCAyMDE2IGF0IDI6MDQgUE0sIGNtYyAmbHQ7 aXVjb3VudUBnbWFpbC5jb20mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg SGkgT25kcmEsPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGF0IGlzIGdvb2QgdG8ga25v dyB0aGF0IHdlIGRvbid0IG5lZWQgS2VyYmVyb3MgLSBpdCBjb21wbGljYXRlcyB0aGluZ3MgYSBs b3QuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJIHRoaW5rIHRoZSBlcnJvcnMgbWlnaHQg YmUgdGhlIG9wdGlvbnMgSSdkIHNlbGVjdGVkIGR1cmluZyB0aGUgc2V0dXAuIEkgd2FzIHRocm93 biBhIGJpdCB0aGF0PGJyPg0KJmd0OyZndDsgaXQgcGFzc2VkIGFsbCB0aGUgaW50ZXJuYWwgdGVz dHMgcHJvdmlkZWQgYnkgdGhlIHNldHVwIHNjcmlwdCwgYnV0IGZhaWxlZCBvbiB0aGUgd2ViIEdV SS4gV2hlbg0KPGJyPg0KJmd0OyZndDsgSSd2ZSBzZWVuICd1bnNwZWNpZmllZCBHU1MgZmFpbHVy ZScgYW5kICdwZWVyIG5vdCBhdXRoZW50aWNhdGVkJyBpdCdzIHVzdWFsbHkgYmVlbiBkdWUgdG8N Cjxicj4NCiZndDsmZ3Q7IEtlcmJlcm9zICh0aG91Z2ggYWRtaXR0ZWRseSB0aGVzZSBhcmUganVz dCBnZW5lcmljIGVycm9ycykuIFNvIEkgdHJpZWQgdGhlIFJlZGhhdCBndWlkZSBmb3IgU1NPIGF0 Ojxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgaHR0cHM6Ly9hY2Nlc3MucmVkaGF0LmNvbS9k b2N1bWVudGF0aW9uL2VuLVVTL1JlZF9IYXRfRW50ZXJwcmlzZV9WaXJ0dWFsaXphdGlvbi8zLjYv aHRtbC9BZG1pbmlzdHJhdGlvbl9HdWlkZS9Db25maWd1cmluZ19MREFQX2FuZF9LZXJiZXJvc19m b3JfU2luZ2xlX1NpZ24tb24uaHRtbDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgd2hpY2gg dXNlcyBLZXJiZXJvcyAoaW4gb3ZpcnQtc3NvLmNvbmYpIEkgaGFkIHRvIHJlbW92ZSB0aGUgc3lt bGluayB0byB0aGUgQXBhY2hlPGJyPg0KJmd0OyZndDsgY29uZmlnIGl0IHNheXMgdG8gY3JlYXRl LCBhcyBpdCByZXN1bHRzIGluIGludGVybmFsIHNlcnZlciBlcnJvcnMgaW4gQXBhY2hlLiBJdCB1 c2VzIGFuIFNQTiBmb3I8YnI+DQomZ3Q7Jmd0OyBBcGFjaGUgaW4gdGhlIGtleXRhYi48YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE5vdyB0aGF0IHlvdSd2ZSBjb25maXJtZWQgdGhhdCBpdCBj YW4gYWN0dWFsbHkgd29yayB3aXRob3V0IGFueSBuZWVkIGZvciB0aGUgS2VyYmVyb3Mgc3R1ZmYs DQo8YnI+DQomZ3Q7Jmd0OyBJIHdpbGwgc3RhcnQgYWZyZXNoIGZyb20gYSBjbGVhbiBzZXR1cCBh bmQgYXBwbHkgd2hhdCBJJ3ZlIGxlYXJudCBkdXJpbmcgdGhpcyBwcm9jZXNzLjxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgSSdsbCB0cnkgaXQgb3V0IGFuZCBsZXQgeW91IGtub3cgZWl0aGVy IHdheS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE1hbnkgdGhhbmtzIGZvciBhbGwgdGhl IGhlbHAhPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBLaW5kIHJlZ2FyZHMsPGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyBDYW08YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IFllcywgeW91IHJlYWxseSBkbyBub3QgbmVl ZCBhbnl0aGluZyBrZXJiZXJvcyByZWxhdGVkIHRvIHNlY3VyZWx5IGJpbmQ8YnI+DQomZ3Q7Jmd0 OyZndDsgdG8gQUQgdmlhIExEQVAgc2ltcGxlIGJpbmQgb3ZlciBUTFMvU1NMLiBUaGlzIGlzIHJl YWxseSBzdHJhbmdlIHRvIG1lPGJyPg0KJmd0OyZndDsmZ3Q7IHdoYXQgZXJyb3JzIHlvdSBhcmUg Z2V0dGluZywgYnV0IHlvdSBwcm9iYWJseSBjb25maWd1cmVkIGFwYWNoZSAob3I8YnI+DQomZ3Q7 Jmd0OyZndDsgc29tZXRoaW5nIGVsc2U/KSB0byByZXF1aXJlIGtleXRhYiwgYnV0IHlvdSBkb24n dCBoYXZlIHRvLCBhbmQgeW91IGNhbjxicj4NCiZndDsmZ3Q7Jmd0OyByZW1vdmUgdGhhdCBjb25m aWd1cmF0aW9uLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyBDYW08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGhhbmtzLDxicj4NCiZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBDYW08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IFVzZXJzIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBVc2Vyc0BvdmlydC5vcmcg Jmx0O21haWx0bzpVc2Vyc0BvdmlydC5vcmcmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O21haWx0bzpVc2Vyc0BvdmlydC5vcmcgJmx0O21h aWx0bzpVc2Vyc0BvdmlydC5vcmcmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBodHRwOi8v bGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGluZm8vdXNlcnM8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7aHR0cDovL2xpc3RzLm92aXJ0Lm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzJmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7aHR0 cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O2h0dHA6Ly9saXN0cy5vdmly dC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2VycyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7PGJyPg0KPC9wPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_ae004950fd40475d99b4ac034352c4b2exch24sluse_--

1 0

Could not associate brick
by Davide Ferrari 14 Oct '16

14 Oct '16

Hello I'm seeing several ot these warnings: 2016-10-14 10:49:23,721 WARN [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturnForXmlRpc] (DefaultQuartzScheduler7) [] Could not associate brick 'vm04.storage.billy:/gluster/ssd/data/brick' of volume '23f8f1ae-a3ac-47bf-8223-5b5f7c29e508' with correct network as no gluster network found in cluster '00000002-0002-0002-0002-000000000345' I was reading this May thread http://lists.ovirt.org/pipermail/users/2016-May/040069.html but there is no final answer about how to solve this warning. As the other poster, I created the gluster network before installing ovirt (it's an hosted-engine installation) and I used DNS names to point to the bricks. DNS resolution is working correctly (every host has everthing in /etc/hosts). I also created a non-VM network and assigned it to every host's bond1 (the gluster network) How can I fix this? TIA -- Davide Ferrari Senior Systems Engineer

2 2

Problem with backing-file, how to fix the backing-chain ?
by Claudio Soprano 14 Oct '16

14 Oct '16

Hi all, We run an ovirt environment before with engine v3.6.5 (if remember good) and now with v4.0.4 (we upgraded because we read the bug with backing-file was resolved with v4). We upgraded some of the hosts machines (but not all still) at v4.0.4 too to see if this would fix the problem, but nothing. The problem is that we have several VMs with snapshots, we do daily, weekly and monthly snapshots, keep some of them (usually the fresh ones) and remove the olds (that in the case they are weekly snapshots, they are in the middle of a series of snapshots), this in the time has produced the famous Backing file too long bug. So we upgraded the engine from 3.6.5 to 4.0.4 (latest available). We discovered this bug, when we tried to upgrade an host to v4.0.4, doing so a VM in the host didn't migrate, so we shutdown it and tried to run on another host, but never succeded for the bug. We don't know if we have more VMs in this situation because we upgraded only 2 hosts on 10. Investigating the problem we discovered that the backing file indicated in each of LVM snapshots report a path very long with /dev/storage-domain-id/../image-group-id/ with ../image-group-id/ repeated a lot of times and at the end /parentid. So to understand which was the right path that it would contain, we cloned a VM in the v4.0.4 and then we did 4 snapshots, now the backing file path is /dev/storage-domain-id/parentid Is there a way to modify the path in the backing-file or a way to recover the VM from this state ? Where do reside the informations about the backing-file path ? I attach here all the commands we run On the ovirt manager (host with the engine only) we run ovirt-shell [oVirt shell (connected)]# list disks --parent-vm-name vm1 id : 2df25a13-6958-40a8-832f-9a26ce65de0f name : vm1_Disk2 id : 8cda0aa6-9e25-4b50-ba00-b877232a1983 name : vm1_Disk1 [oVirt shell (connected)]# show disk 8cda0aa6-9e25-4b50-ba00-b877232a1983 id : 8cda0aa6-9e25-4b50-ba00-b877232a1983 name : vm1_Disk1 actual_size : 1073741824 alias : vm1_Disk1 disk_profile-id : 1731f79a-5034-4270-9a87-94d93025deac format : cow image_id : 7b354e2a-2099-4f2a-80b7-fba7d1fd13ee propagate_errors : False provisioned_size : 17179869184 shareable : False size : 17179869184 sparse : True status-state : ok storage_domains-storage_domain-id: 384f9059-ef2f-4d43-a54f-de71c5d589c8 storage_type : image wipe_after_delete : False [root@ovc1mgr ~]# su - postgres Last login: Fri Oct 14 01:02:14 CEST 2016 -bash-4.2$ psql -d engine -U postgres psql (9.2.15) Type "help" for help. engine=#\x on engine=# select * from images where image_group_id = '8cda0aa6-9e25-4b50-ba00-b877232a1983' order by creation_date; -[ RECORD 1 ]---------+------------------------------------- image_guid | 60ba7acf-58cb-475b-b9ee-15b1be99fee6 creation_date | 2016-03-29 15:12:34+02 size | 17179869184 it_guid | 00000000-0000-0000-0000-000000000000 parentid | 00000000-0000-0000-0000-000000000000 imagestatus | 4 lastmodified | 2016-04-21 11:25:59.972+02 vm_snapshot_id | 27c187cd-989f-4f7a-ac05-49c4410de6c2 volume_type | 1 volume_format | 5 image_group_id | 8cda0aa6-9e25-4b50-ba00-b877232a1983 _create_date | 2016-03-29 15:12:31.994065+02 _update_date | 2016-09-04 01:10:08.773649+02 active | f volume_classification | 1 -[ RECORD 2 ]---------+------------------------------------- image_guid | 68d764ec-bc2e-4e1d-b8f2-b44afd9fcb2e creation_date | 2016-07-03 01:01:30+02 size | 17179869184 it_guid | 00000000-0000-0000-0000-000000000000 parentid | 60ba7acf-58cb-475b-b9ee-15b1be99fee6 imagestatus | 1 lastmodified | 2016-07-04 01:03:33.732+02 vm_snapshot_id | 175c2071-a06b-4b0e-a069-5cc4bb236a34 volume_type | 2 volume_format | 4 image_group_id | 8cda0aa6-9e25-4b50-ba00-b877232a1983 _create_date | 2016-07-03 01:01:15.069585+02 _update_date | 2016-09-11 02:06:04.420965+02 active | f volume_classification | 1 -[ RECORD 3 ]---------+------------------------------------- image_guid | 37ca6494-e990-44e5-8597-28845a0a19b5 creation_date | 2016-08-07 01:06:15+02 size | 17179869184 it_guid | 00000000-0000-0000-0000-000000000000 parentid | 68d764ec-bc2e-4e1d-b8f2-b44afd9fcb2e imagestatus | 1 lastmodified | 2016-08-08 01:00:03.778+02 vm_snapshot_id | 4c0e5ac0-2ef3-4996-b3e9-7fd566d97b1a volume_type | 2 volume_format | 4 image_group_id | 8cda0aa6-9e25-4b50-ba00-b877232a1983 _create_date | 2016-08-07 01:06:01.777156+02 _update_date | 2016-09-25 01:55:54.090026+02 active | f volume_classification | 1 I removed other 10 snapshot infos from the list to easily read all On a host running v4.0.4 we run root@ovc2n06 ~]# lvchange -aey -pr 384f9059-ef2f-4d43-a54f-de71c5d589c8/60ba7acf-58cb-475b-b9ee-15b1be99fee6 Logical volume "60ba7acf-58cb-475b-b9ee-15b1be99fee6" changed. This is the base image infact it doesn't contain a backing-file [root@ovc2n06 ~]# qemu-img info --backing-chain /dev/384f9059-ef2f-4d43-a54f-de71c5d589c8/60ba7acf-58cb-475b-b9ee-15b1be99fee6 image: /dev/384f9059-ef2f-4d43-a54f-de71c5d589c8/60ba7acf-58cb-475b-b9ee-15b1be99fee6 file format: raw virtual size: 16G (17179869184 bytes) disk size: 0 [root@ovc2n06 ~]# lvchange -aey -pr 384f9059-ef2f-4d43-a54f-de71c5d589c8/68d764ec-bc2e-4e1d-b8f2-b44afd9fcb2e Logical volume "68d764ec-bc2e-4e1d-b8f2-b44afd9fcb2e" changed. [root@ovc2n06 ~]# qemu-img info --backing-chain /dev/384f9059-ef2f-4d43-a54f-de71c5d589c8/68d764ec-bc2e-4e1d-b8f2-b44afd9fcb2e qemu-img: Could not open '/dev/384f9059-ef2f-4d43-a54f-de71c5d589c8/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/60ba7acf-58cb-475b-b9ee-15b1be99fee6': Could not open '/dev/384f9059-ef2f-4d43-a54f-de71c5d589c8/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/60ba7acf-58cb-475b-b9ee-15b1be99fee6': No such file or directory To fix this problem we made a link [root@ovc2n06 ~]# lvchange -aey -pr 384f9059-ef2f-4d43-a54f-de71c5d589c8/68d764ec-bc2e-4e1d-b8f2-b44afd9fcb2e Logical volume "68d764ec-bc2e-4e1d-b8f2-b44afd9fcb2e" changed. [root@ovc2n06 ~]# qemu-img info --backing-chain /dev/384f9059-ef2f-4d43-a54f-de71c5d589c8/68d764ec-bc2e-4e1d-b8f2-b44afd9fcb2e qemu-img: Could not open '/dev/384f9059-ef2f-4d43-a54f-de71c5d589c8/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/60ba7acf-58cb-475b-b9ee-15b1be99fee6': Could not open '/dev/384f9059-ef2f-4d43-a54f-de71c5d589c8/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/60ba7acf-58cb-475b-b9ee-15b1be99fee6': No such file or directory [root@ovc2n06 ~]# ln -s /dev/384f9059-ef2f-4d43-a54f-de71c5d589c8 /dev/8cda0aa6-9e25-4b50-ba00-b877232a1983 [root@ovc2n06 ~]# qemu-img info --backing-chain /dev/384f9059-ef2f-4d43-a54f-de71c5d589c8/68d764ec-bc2e-4e1d-b8f2-b44afd9fcb2e image: /dev/384f9059-ef2f-4d43-a54f-de71c5d589c8/68d764ec-bc2e-4e1d-b8f2-b44afd9fcb2e file format: qcow2 virtual size: 16G (17179869184 bytes) disk size: 0 cluster_size: 65536 backing file: ../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/60ba7acf-58cb-475b-b9ee-15b1be99fee6 (actual path: /dev/384f9059-ef2f-4d43-a54f-de71c5d589c8/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/60ba7acf-58cb-475b-b9ee-15b1be99fee6) backing file format: raw Format specific information: compat: 0.10 refcount bits: 16 image: /dev/384f9059-ef2f-4d43-a54f-de71c5d589c8/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/60ba7acf-58cb-475b-b9ee-15b1be99fee6 file format: raw virtual size: 16G (17179869184 bytes) disk size: 0 We moved to the next snapshot [root@ovc2n06 ~]# lvchange -aey -pr 384f9059-ef2f-4d43-a54f-de71c5d589c8/37ca6494-e990-44e5-8597-28845a0a19b5 Logical volume "37ca6494-e990-44e5-8597-28845a0a19b5" changed. And now the error from the bug qemu-img info --backing-chain /dev/384f9059-ef2f-4d43-a54f-de71c5d589c8/37ca6494-e990-44e5-8597-28845a0a19b5 qemu-img: Could not open '/dev/384f9059-ef2f-4d43-a54f-de71c5d589c8/37ca6494-e990-44e5-8597-28845a0a19b5': Backing file name too long Any snapshot starting from this snapshot is not usable, the VM was running ok up to we did shutdown it, it never starts again. How you can see the path of the backing-file is wrong and too long already in the previous snapshots, is there a way to fix it or to edit it manually ? Obviously we tried to clone, export, create a qcow2 image, from all the snapshot later 07-august but the operation didn't complete, we can recover only from the snapshot of 7-august that is missing 2 months of new data. Please if you have a workaround or a solution, can you write the commands we need to run with examples, we searched a lot about backing-file but only the manual of the qemu-img command was found with no examples on how to recover or change it. Thanks again Claudio Soprano -- / | / _____/ / | / _____/ | / / / | / / / / | / / / | / / / | / ___/ _____/ / / | / ___/ / | / / / | / / / / | / / / | / ______/ _/ __/ _/ _/ _/ __/ _/ _/ __/ Claudio Soprano phone: (+39)-06-9403.2349/2355 Computing Service fax: (+39)-06-9403.2649 LNF-INFN e-mail: Claudio.Soprano(a)lnf.infn.it Via Enrico Fermi, 40 www: http://www.lnf.infn.it/ I-00044 Frascati, Italy

1 0

Replication between storage domains
by Anantha Raghava 13 Oct '16

13 Oct '16

This is a multi-part message in MIME format. --------------8A5BBB261C1AC062725312E9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello... I am trying to setup a DC & DR with oVirt with two sets of rack servers and two Storage Boxes. In DC, I have FC storage and in DR I have iSCSI storage. Now the question is can I replicate the VM disks and data between these dissimilar storage domains at say 15 min interval? -- Thanks & Regards, Anantha Raghava eXza Technology Consulting & Services --------------8A5BBB261C1AC062725312E9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hello... I am trying to setup a DC & DR with oVirt with two sets of rack servers and two Storage Boxes. In DC, I have FC storage and in DR I have iSCSI storage. Now the question is can I replicate the VM disks and data between these dissimilar storage domains at say 15 min interval? <div class="moz-signature">-- Thanks & Regards, <address style="line-height: 100%">Anantha Raghava</address> <address style="line-height: 100%">eXza Technology Consulting & Services</address> </div> </body> </html> --------------8A5BBB261C1AC062725312E9--

1 0

unable to get hosted-engine to start
by Francois Brochu 13 Oct '16

13 Oct '16

Thanks in advance for your enlightenment - somehow i may have missed a step when I try to backup - and that's when it stopped working the current situation is ALL my VM are up and running EXCEPT hostedengine - oVirt is running on a single node - ovirt-release40-4.0.4-1.noarch - Centos 7.2 hosted-engine --vm-start - did not generate error message at the console - log were complaining of lock and out of space (but now it's gone) - got rid off VM DOWN - got rid of sanlock without a process ID vdsClient does not show HostedEngine as UP (use to show DOWN - but I used poweroff) root@vmhost2 ~]# vdsClient -s 0 list table 01d78c9b-01e9-4dc3-b047-c809f82ae327 141203 GitRepo Up 5b4be6a8-2d94-440b-a221-7396f400ebf7 83717 jetbrains Up 393e28ed-6d11-4651-b367-dd0718ee40c7 126065 turing2 Up 5481665c-9a93-49c6-b7e7-b81495d00a9f 193259 vmcentosdebut Up 439c18db-9f5d-4983-9cd4-38a5ec9f57a6 79098 ecemail Up 844cfa3c-dcff-41a7-b96a-c680a83e4901 146694 vmwinchoco Up dd15556f-a290-4cc8-87d1-d311d1298caf 35974 newWds1 Up 9596a5cf-73ae-4c32-9f35-afbc4dd3cb39 5702 ipmi5 Up [root@vmhost2 ~]# sanlock client status (used to show "s hosted-engine:1:/var/run/vdsm/storage/fd533c44-09f0..." - but I used --reinitialize-lockspace [--force] ) daemon d29562f4-46e1-4838-ad70-666cbcaf1ce3.vmhost2.ec p -1 helper p -1 listener p -1 status p 141203 GitRepo p 126065 turing2 p 146694 vmwinchoco p 193259 vmcentosdebut p 5702 ipmi5 p 79098 ecemail p 35974 newWds1 p 83717 jetbrains AND when I look inside at my backup db is empty [root@vmhost2 ~]# tar -tvf /backup/oVirt.20161012/ovirtBackup drwxr-xr-x root/root 0 2016-10-11 14:52 ./ drwxr-xr-x root/root 0 2016-10-11 14:52 ./db/ -rw-r--r-- root/root 3160 2016-10-11 14:52 ./files -rw-r--r-- root/root 8 2016-10-11 14:52 ./version -rw-r--r-- root/root 8 2016-10-11 14:52 ./os_version -rw-r--r-- root/root 150 2016-10-11 14:52 ./config -rw-r--r-- root/root 168 2016-10-11 14:52 ./md5sum I also try hosted-engine --vm-start --vm-conf=/etc/ovirt-hosted-engine/hosted-engine.conf all I get is a console message "Unexpected exception" cannot find anything else What can I do to get the hosted-engine started? - and not loose any of my currently running VM -- *Francois Brochu* System Administrator/ IT Team Leader Electrical & Computer Engineering University of Alberta francois.brochu(a)ualberta.ca Tel: (780) 492-2010

1 0

VM pauses/hangs after migration
by Davide Ferrari 13 Oct '16

13 Oct '16

Hello trying to migrate a VM from one host to another, a big VM with 96GB of RAM, I found that when the migration completes, the VM goes to a paused satte and cannot be resumed. The libvirt/qemu log it gives is this: 2016-09-28T12:18:15.679176Z qemu-kvm: error while loading state section id 2(ram) 2016-09-28T12:18:15.680010Z qemu-kvm: load of migration failed: Input/output error 2016-09-28 12:18:15.872+0000: shutting down 2016-09-28 12:22:21.467+0000: starting up libvirt version: 1.2.17, package: 13.el7_2.5 (CentOS BuildSystem <http://bugs.centos.org>, 2016-06-23-14:23:27, worker1.bsys.centos.org) qemu version: 2.3.0 (qemu-kvm-ev-2.3.0-31.el7.16.1) LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=spice /usr/libexec/qemu-kvm -name front04.billydomain.com -S -machine pc-i440fx-rhel7.2.0,accel=kvm,usb=off -cpu Haswell-noTSX -m size=100663296k,slots=16,maxmem=4294967296k -realtime mlock=off -smp 32,sockets=16,cores=1,threads=2 -numa node,nodeid=0,cpus=0-31,mem=98304 -uuid 4511d1c0-6607-418f-ae75-34f605b2ad68 -smbios type=1,manufacturer=oVirt,product=oVirt Node,version=7-2.1511.el7.centos.2.10,serial=4C4C4544-004A-3310-8054-B2C04F474432,uuid=4511d1c0-6607-418f-ae75-34f605b2ad68 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/ domain-front04.billydomain.com/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=2016-09-28T14:22:21,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x7 -device virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x4 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/rhev/data-center/00000001-0001-0001-0001-0000000003e3/ba2bd397-9222-424d-aecc-eb652c0169d9/images/b5b49d5c-2378-4639-9469-362e37ae7473/24fd0d3c-309b-458d-9818-4321023afacf,if=none,id=drive-virtio-disk0,format=qcow2,serial=b5b49d5c-2378-4639-9469-362e37ae7473,cache=none,werror=stop,rerror=stop,aio=threads -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/rhev/data-center/00000001-0001-0001-0001-0000000003e3/ba2bd397-9222-424d-aecc-eb652c0169d9/images/f02ac1ce-52cd-4b81-8b29-f8006d0469e0/ff4e49c6-3084-4234-80a1-18a67615c527,if=none,id=drive-virtio-disk1,format=raw,serial=f02ac1ce-52cd-4b81-8b29-f8006d0469e0,cache=none,werror=stop,rerror=stop,aio=threads -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk1,id=virtio-disk1 -netdev tap,fd=30,id=hostnet0,vhost=on,vhostfd=31 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:16:01:56,bus=pci.0,addr=0x3 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/4511d1c0-6607-418f-ae75-34f605b2ad68.com.redhat.rhevm.vdsm,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm -chardev socket,id=charchannel1,path=/var/lib/libvirt/qemu/channels/4511d1c0-6607-418f-ae75-34f605b2ad68.org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 -chardev spicevmc,id=charchannel2,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=3,chardev=charchannel2,id=channel2,name=com.redhat.spice.0 -vnc 192.168.10.225:1,password -k es -spice tls-port=5902,addr=192.168.10.225,x509-dir=/etc/pki/vdsm/libvirt-spice,tls-channel=default,tls-channel=main,tls-channel=display,tls-channel=inputs,tls-channel=cursor,tls-channel=playback,tls-channel=record,tls-channel=smartcard,tls-channel=usbredir,seamless-migration=on -k es -device qxl-vga,id=video0,ram_size=67108864,vram_size=8388608,vgamem_mb=16,bus=pci.0,addr=0x2 -incoming tcp:0.0.0.0:49156 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -msg timestamp=on Domain id=5 is tainted: hook-script red_dispatcher_loadvm_commands: KVM: entry failed, hardware error 0x8 RAX=00000000ffffffed RBX=ffff8817ba00c000 RCX=0100000000000000 RDX=0000000000000000 RSI=0000000000000000 RDI=0000000000000046 RBP=ffff8817ba00fe98 RSP=ffff8817ba00fe98 R8 =0000000000000000 R9 =0000000000000000 R10=0000000000000000 R11=0000000000000000 R12=0000000000000006 R13=ffff8817ba00c000 R14=ffff8817ba00c000 R15=0000000000000000 RIP=ffffffff81058e96 RFL=00010286 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0000 0000000000000000 ffffffff 00000000 CS =0010 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] SS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] DS =0000 0000000000000000 ffffffff 00000000 FS =0000 0000000000000000 ffffffff 00000000 GS =0000 ffff8817def80000 ffffffff 00000000 LDT=0000 0000000000000000 ffffffff 00000000 TR =0040 ffff8817def93b80 00002087 00008b00 DPL=0 TSS64-busy GDT= ffff8817def89000 0000007f IDT= ffffffffff529000 00000fff CR0=80050033 CR2=00000000ffffffff CR3=00000017b725b000 CR4=001406e0 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 EFER=0000000000000d01 Code=89 e5 fb 5d c3 66 0f 1f 84 00 00 00 00 00 55 48 89 e5 fb f4 <5d> c3 0f 1f 84 00 00 00 00 00 55 48 89 e5 f4 5d c3 66 0f 1f 84 00 00 00 00 00 55 49 89 ca KVM: entry failed, hardware error 0x8 RAX=00000000ffffffed RBX=ffff8817ba008000 RCX=0100000000000000 RDX=0000000000000000 RSI=0000000000000000 RDI=0000000000000046 RBP=ffff8817ba00be98 RSP=ffff8817ba00be98 R8 =0000000000000000 R9 =0000000000000000 R10=0000000000000000 R11=0000000000000000 R12=0000000000000005 R13=ffff8817ba008000 R14=ffff8817ba008000 R15=0000000000000000 RIP=ffffffff81058e96 RFL=00010286 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0000 0000000000000000 ffffffff 00000000 CS =0010 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] SS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] DS =0000 0000000000000000 ffffffff 00000000 FS =0000 0000000000000000 ffffffff 00000000 GS =0000 ffff8817def40000 ffffffff 00000000 LDT=0000 0000000000000000 ffffffff 00000000 TR =0040 ffff8817def53b80 00002087 00008b00 DPL=0 TSS64-busy GDT= ffff8817def49000 0000007f IDT= ffffffffff529000 00000fff CR0=80050033 CR2=00000000ffffffff CR3=00000017b3c9a000 CR4=001406e0 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 EFER=0000000000000d01 Code=89 e5 fb 5d c3 66 0f 1f 84 00 00 00 00 00 55 48 89 e5 fb f4 <5d> c3 0f 1f 84 00 00 00 00 00 55 48 89 e5 f4 5d c3 66 0f 1f 84 00 00 00 00 00 55 49 89 ca KVM: entry failed, hardware error 0x80000021 If you're running a guest on an Intel machine without unrestricted mode support, the failure can be most likely due to the guest entering an invalid state for Intel VT. For example, the guest maybe running in big real mode which is not supported on less recent Intel processors. EAX=ffffffed EBX=ba020000 ECX=00000000 EDX=00000000 ESI=00000000 EDI=00000046 EBP=ba023e98 ESP=ba023e98 EIP=81058e96 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0000 00000000 0000ffff 00009300 DPL=0 DS [-WA] CS =f000 ffff0000 0000ffff 00009b00 DPL=0 CS16 [-RA] SS =0000 00000000 0000ffff 00009300 DPL=0 DS [-WA] DS =0000 00000000 0000ffff 00009300 DPL=0 DS [-WA] FS =0000 00000000 0000ffff 00009300 DPL=0 DS [-WA] GS =0000 00000000 0000ffff 00009300 DPL=0 DS [-WA] LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS64-busy GDT= 0000000000000000 0000ffff IDT= 0000000000000000 0000ffff CR0=80050033 CR2=00007fd826ac20a0 CR3=000000003516c000 CR4=00140060 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 EFER=0000000000000d01 Code=?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? <??> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? Searching for errors like this I found some bug report about kernel issues but I don't think it's the case, other VMs spawned from the same image migrate without any issue. I have toi say that the original host running the VM has some RAM problem (ECC multibit fault in one DIMM). Maybe that's the problem? How can I properly read this error log? Thanks -- Davide Ferrari Senior Systems Engineer

3 8

Multi cluster question with regards to storage
by David Gossage 13 Oct '16

13 Oct '16

I've not yet found a clean concise answer and so I wanted to ask before I start trying to play with things in my test setup and waste a bunch of time maybe. If I have 2 clusters in one data center each running different cpu types (amd/intel) can they both access the same shared storage domain(gluster in my case)? I'm not interested in live migration between the clusters really, though stopping and starting on another would be nice. I've tried looking at various threads and list emails and I've found some mentions of it, but usually as an aside while discussing other matters so I could never quite say for certain it was working or not. *David Gossage* *Carousel Checks Inc. | System Administrator* *Office* 708.613.2284

2 2