- Users - oVirt List Archives

Weird yum depencency problem upgtading host 3.4.3
by Daniel Helgenberger 25 Jul '14

25 Jul '14

--=-xBZU0tRm0TJDUQp8tADG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, I am in the process updating my 2 node HE cluster to oVirt 3.4.3. The engine and node one is already updaded without any problems (great work on fixing the ha-agend subsystem locked issue!). Now, yum updating node two - immediately after node one - : Error: Package: ovirt-hosted-engine-ha-1.2.1-0.2.master.20140723134021.el6.noarch (ovirt-3.4-stable) Requires: vdsm-python >=3D 4.16.0 Removing: vdsm-python-4.14.9-0.el6.x86_64 (@ovirt-3.4-stable) vdsm-python =3D 4.14.9-0.el6 Updated By: vdsm-python-4.14.11.2-0.el6.x86_64 (ovirt-3.4-stable) vdsm-python =3D 4.14.11.2-0.el6 Available: vdsm-python-4.12.1-2.el6.i686 (ovirt-3.3-stable) vdsm-python =3D 4.12.1-2.el6 Available: vdsm-python-4.12.1-4.el6.i686 (ovirt-3.3-stable) vdsm-python =3D 4.12.1-4.el6 Available: vdsm-python-4.13.0-9.el6.i686 (ovirt-3.3-stable) vdsm-python =3D 4.13.0-9.el6 Available: vdsm-python-4.13.0-11.el6.i686 (ovirt-3.3-stable) vdsm-python =3D 4.13.0-11.el6 Available: vdsm-python-4.13.2-1.el6.i686 (ovirt-3.3-stable) vdsm-python =3D 4.13.2-1.el6 Available: vdsm-python-4.13.3-2.el6.i686 (ovirt-3.3-stable) vdsm-python =3D 4.13.3-2.el6 Available: vdsm-python-4.13.3-3.el6.i686 (ovirt-3.3-stable) vdsm-python =3D 4.13.3-3.el6 Available: vdsm-python-4.13.3-4.el6.i686 (ovirt-3.3-stable) vdsm-python =3D 4.13.3-4.el6 Available: vdsm-python-4.13.4-0.el6.i686 (ovirt-3.3-stable) vdsm-python =3D 4.13.4-0.el6 Available: vdsm-python-4.14.6-0.el6.i686 (ovirt-3.4-stable) vdsm-python =3D 4.14.6-0.el6 Available: vdsm-python-4.14.8.1-0.el6.i686 (ovirt-3.4-stable) vdsm-python =3D 4.14.8.1-0.el6 Available: vdsm-python-4.14.11-0.el6.i686 (ovirt-3.4-stable) vdsm-python =3D 4.14.11-0.el6 Error: Package: ovirt-hosted-engine-ha-1.2.1-0.2.master.20140723134021.el6.noarch (ovirt-3.4-stable) Requires: vdsm-cli >=3D 4.16.0 Removing: vdsm-cli-4.14.9-0.el6.noarch (@ovirt-3.4-stable) vdsm-cli =3D 4.14.9-0.el6 Updated By: vdsm-cli-4.14.11.2-0.el6.noarch (ovirt-3.4-stable) vdsm-cli =3D 4.14.11.2-0.el6 Available: vdsm-cli-4.12.0-1.el6.noarch (ovirt-3.3-stable) vdsm-cli =3D 4.12.0-1.el6 Available: vdsm-cli-4.12.1-2.el6.noarch (ovirt-3.3-stable) vdsm-cli =3D 4.12.1-2.el6 Available: vdsm-cli-4.12.1-4.el6.noarch (ovirt-3.3-stable) vdsm-cli =3D 4.12.1-4.el6 Available: vdsm-cli-4.13.0-9.el6.noarch (ovirt-3.3-stable) vdsm-cli =3D 4.13.0-9.el6 Available: vdsm-cli-4.13.0-11.el6.noarch (ovirt-3.3-stable) vdsm-cli =3D 4.13.0-11.el6 Available: vdsm-cli-4.13.2-1.el6.noarch (ovirt-3.3-stable) vdsm-cli =3D 4.13.2-1.el6 Available: vdsm-cli-4.13.3-2.el6.noarch (ovirt-3.3-stable) vdsm-cli =3D 4.13.3-2.el6 Available: vdsm-cli-4.13.3-3.el6.noarch (ovirt-3.3-stable) vdsm-cli =3D 4.13.3-3.el6 Available: vdsm-cli-4.13.3-4.el6.noarch (ovirt-3.3-stable) vdsm-cli =3D 4.13.3-4.el6 Available: vdsm-cli-4.13.4-0.el6.noarch (ovirt-3.3-stable) vdsm-cli =3D 4.13.4-0.el6 Available: vdsm-cli-4.14.6-0.el6.noarch (ovirt-3.4-stable) vdsm-cli =3D 4.14.6-0.el6 Available: vdsm-cli-4.14.8.1-0.el6.noarch (ovirt-3.4-stable) vdsm-cli =3D 4.14.8.1-0.el6 Available: vdsm-cli-4.14.11-0.el6.noarch (ovirt-3.4-stable) vdsm-cli =3D 4.14.11-0.el6 Error: Package: ovirt-hosted-engine-ha-1.2.1-0.2.master.20140723134021.el6.noarch (ovirt-3.4-stable) Requires: vdsm >=3D 4.16.0 Removing: vdsm-4.14.9-0.el6.x86_64 (@ovirt-3.4-stable) vdsm =3D 4.14.9-0.el6 Updated By: vdsm-4.14.11.2-0.el6.x86_64 (ovirt-3.4-stable) vdsm =3D 4.14.11.2-0.el6 Available: vdsm-4.12.1-2.el6.i686 (ovirt-3.3-stable) vdsm =3D 4.12.1-2.el6 Available: vdsm-4.12.1-4.el6.i686 (ovirt-3.3-stable) vdsm =3D 4.12.1-4.el6 Available: vdsm-4.13.0-9.el6.i686 (ovirt-3.3-stable) vdsm =3D 4.13.0-9.el6 Available: vdsm-4.13.0-11.el6.i686 (ovirt-3.3-stable) vdsm =3D 4.13.0-11.el6 Available: vdsm-4.13.2-1.el6.i686 (ovirt-3.3-stable) vdsm =3D 4.13.2-1.el6 Available: vdsm-4.13.3-2.el6.i686 (ovirt-3.3-stable) vdsm =3D 4.13.3-2.el6 Available: vdsm-4.13.3-3.el6.i686 (ovirt-3.3-stable) vdsm =3D 4.13.3-3.el6 Available: vdsm-4.13.3-4.el6.i686 (ovirt-3.3-stable) vdsm =3D 4.13.3-4.el6 Available: vdsm-4.13.4-0.el6.i686 (ovirt-3.3-stable) vdsm =3D 4.13.4-0.el6 Available: vdsm-4.14.6-0.el6.i686 (ovirt-3.4-stable) vdsm =3D 4.14.6-0.el6 Available: vdsm-4.14.8.1-0.el6.i686 (ovirt-3.4-stable) vdsm =3D 4.14.8.1-0.el6 Available: vdsm-4.14.11-0.el6.i686 (ovirt-3.4-stable) vdsm =3D 4.14.11-0.el6 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest You have new mail in /var/spool/mail/root The other host upgraded to vdsm 4.14.11 .... Thanks, Daniel --=20 Daniel Helgenberger=20 m box bewegtbild GmbH=20 P: +49/30/2408781-22 F: +49/30/2408781-10 ACKERSTR. 19=20 D-10115 BERLIN=20 www.m-box.de www.monkeymen.tv=20 Gesch=C3=A4ftsf=C3=BChrer: Martin Retschitzegger / Michaela G=C3=B6llner Handeslregister: Amtsgericht Charlottenburg / HRB 112767=20 --=-xBZU0tRm0TJDUQp8tADG Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN9zCCBFcw ggM/oAMCAQICCwQAAAAAAS9O4TFGMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYD VQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT aWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcNMTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25h bFNpZ24gMiBDQSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwWtB+TXs+BJ9 3SJRaV+3uRNGJ3cUO+MTgW8+5HQXfgy19CzkDI1T1NwwICi/bo4R/mYR5FEWx91//eE0ElC/89iY 7GkL0tDasmVx4TOXnrqrsziUcxEPPqHRE8x4NhtBK7+8o0nsMIJMA1gyZ2FA5To2Ew1BBuvovvDJ +Nua3qOCNBNu+8A+eNpJlVnlu/qB7+XWaPXtUMlsIikxD+gREFVUgYE4VzBuLa2kkg0VLd09XkE2 ceRDm6YgRATuDk6ogUyX4OLxCGIJF8yi6Z37M0wemDA6Uff0EuqdwDQd5HwG/rernUjt1grLdAxq 8BwywRRg0eFHmE+ShhpyO3Fi+wIDAQABo4IBJTCCASEwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB /wQIMAYBAf8CAQAwHQYDVR0OBBYEFD8V0m18L+cxnkMKBqiUbCw7xe5lMEcGA1UdIARAMD4wPAYE VR0gADA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5 LzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QuY3JsMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AuZ2xvYmFsc2lnbi5jb20vcm9v dHIxMB8GA1UdIwQYMBaAFGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQDI WOF8oQHpI41wO21cUvjE819juuGa05F5yK/ESqW+9th9vfhG92eaBSLViTIJV7gfCFbt11WexfK/ 44NeiJMfi5wX6sK7Xnt8QIK5lH7ZX1Wg/zK1cXjrgRaYUOX/MA+PmuRm4gWV0zFwYOK2uv4OFgaM mVr+8en7K1aQY2ecI9YhEaDWOcSGj6SN8DvzPdE4G4tBk4/aIsUged9sGDqRYweKla3LTNjXPps1 Y+zsVbgHLtjdOIB0YZ1hrlAQcY2L/b+V+Yyoi7CMdOtmm1Rm6Jh5ILbwQTjlUCkgu5yVdfs9LDKc M0SPeCldkjfaGVSd+nURMOUy3hfxsMVux9+FMIIEyjCCA7KgAwIBAgIRAJZpZsDepakv5CafojXo PKcwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIDIgQ0EgLSBHMjAeFw0xMzA4Mjcx NjU3NThaFw0xNjA4MjcxNjU3NThaMFgxCzAJBgNVBAYTAkRFMRwwGgYDVQQDExNEYW5pZWwgSGVs Z2VuYmVyZ2VyMSswKQYJKoZIhvcNAQkBFhxkYW5pZWwuaGVsZ2VuYmVyZ2VyQG0tYm94LmRlMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzgFDm8+SeTU4Yt3WopJQgqZAuuNxyMlxiPuq 0C0D581goXz2nVVjhTCIVwX2MqWYD1Dyjy1hLHXothgWgZaiQ1EB4oVdmIFmIfIjR6SkR/Gjw3lx MwJzEpxJhZXyyrOYE8Kgw2maJWgLx5zw2/lKpcffhVW0OY0t+JWWxPKiYFcAmQnb+fleonM8sUZZ ZES08uRVVL67jbq+3+E2xCLlqQ2iJ1h5ej3wlyuZ4CkUnfMHYrG8zOIfHwsPirWACX026a1flgts Kl1Yv0CRZ1c5qujcP3OPpDovIbBr9RBStl2DcFdzTuGMdmfp32963VLOlvKpClPMzrfJeJfWZ4Qy UwIDAQABo4IBkTCCAY0wDgYDVR0PAQH/BAQDAgWgMEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQw MgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMCcGA1Ud EQQgMB6BHGRhbmllbC5oZWxnZW5iZXJnZXJAbS1ib3guZGUwCQYDVR0TBAIwADAdBgNVHSUEFjAU BggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC5nbG9iYWxz aWduLmNvbS9ncy9nc3BlcnNvbmFsc2lnbjJnMi5jcmwwVQYIKwYBBQUHAQEESTBHMEUGCCsGAQUF BzAChjlodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3BlcnNvbmFsc2lnbjJn Mi5jcnQwHQYDVR0OBBYEFLw0UD+6l35aKnDaePxEP8K35HYZMB8GA1UdIwQYMBaAFD8V0m18L+cx nkMKBqiUbCw7xe5lMA0GCSqGSIb3DQEBBQUAA4IBAQBdVOm7h+E4sRMBbTN1tCIjAEgxmB5U0mdZ XcawzEHLJxTrc/5YFBMGX2qPju8cuZV14XszMfRBJdlJz1Od+voJggianIhnFEAakCxaa1l/cmJ5 EDT6PgZAkXbMB5rU1dhegb35lJJkcFLEpR2tF1V0TfbSe5UZNPYeMQjYsRhs69pfKLoeGm4dSLK7 gsPT5EhPd+JPyNSIootOwClMP4CTxIsXQgRI5IDqG2Ku/r2YMMLsqWD11PtAE87t2mgohQ6V1XdW FqGd1V+wN98oPumRRS8bld+1gRA7GVYMnO5MF6p//iHFcy3MVT05ojqgomMt+voH5cFzrHA61z80 xaZ6MIIEyjCCA7KgAwIBAgIRAJZpZsDepakv5CafojXoPKcwDQYJKoZIhvcNAQEFBQAwVDELMAkG A1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24g UGVyc29uYWxTaWduIDIgQ0EgLSBHMjAeFw0xMzA4MjcxNjU3NThaFw0xNjA4MjcxNjU3NThaMFgx CzAJBgNVBAYTAkRFMRwwGgYDVQQDExNEYW5pZWwgSGVsZ2VuYmVyZ2VyMSswKQYJKoZIhvcNAQkB FhxkYW5pZWwuaGVsZ2VuYmVyZ2VyQG0tYm94LmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAzgFDm8+SeTU4Yt3WopJQgqZAuuNxyMlxiPuq0C0D581goXz2nVVjhTCIVwX2MqWYD1Dy jy1hLHXothgWgZaiQ1EB4oVdmIFmIfIjR6SkR/Gjw3lxMwJzEpxJhZXyyrOYE8Kgw2maJWgLx5zw 2/lKpcffhVW0OY0t+JWWxPKiYFcAmQnb+fleonM8sUZZZES08uRVVL67jbq+3+E2xCLlqQ2iJ1h5 ej3wlyuZ4CkUnfMHYrG8zOIfHwsPirWACX026a1flgtsKl1Yv0CRZ1c5qujcP3OPpDovIbBr9RBS tl2DcFdzTuGMdmfp32963VLOlvKpClPMzrfJeJfWZ4QyUwIDAQABo4IBkTCCAY0wDgYDVR0PAQH/ BAQDAgWgMEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3 Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMCcGA1UdEQQgMB6BHGRhbmllbC5oZWxnZW5iZXJn ZXJAbS1ib3guZGUwCQYDVR0TBAIwADAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYD VR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9nc3BlcnNvbmFsc2ln bjJnMi5jcmwwVQYIKwYBBQUHAQEESTBHMEUGCCsGAQUFBzAChjlodHRwOi8vc2VjdXJlLmdsb2Jh bHNpZ24uY29tL2NhY2VydC9nc3BlcnNvbmFsc2lnbjJnMi5jcnQwHQYDVR0OBBYEFLw0UD+6l35a KnDaePxEP8K35HYZMB8GA1UdIwQYMBaAFD8V0m18L+cxnkMKBqiUbCw7xe5lMA0GCSqGSIb3DQEB BQUAA4IBAQBdVOm7h+E4sRMBbTN1tCIjAEgxmB5U0mdZXcawzEHLJxTrc/5YFBMGX2qPju8cuZV1 4XszMfRBJdlJz1Od+voJggianIhnFEAakCxaa1l/cmJ5EDT6PgZAkXbMB5rU1dhegb35lJJkcFLE pR2tF1V0TfbSe5UZNPYeMQjYsRhs69pfKLoeGm4dSLK7gsPT5EhPd+JPyNSIootOwClMP4CTxIsX QgRI5IDqG2Ku/r2YMMLsqWD11PtAE87t2mgohQ6V1XdWFqGd1V+wN98oPumRRS8bld+1gRA7GVYM nO5MF6p//iHFcy3MVT05ojqgomMt+voH5cFzrHA61z80xaZ6MYIC5zCCAuMCAQEwaTBUMQswCQYD VQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQ ZXJzb25hbFNpZ24gMiBDQSAtIEcyAhEAlmlmwN6lqS/kJp+iNeg8pzAJBgUrDgMCGgUAoIIBUzAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA3MjQxNjIzMDlaMCMG CSqGSIb3DQEJBDEWBBT6i7l0yHWCZaStlhmMrBhZ97a/jjB4BgkrBgEEAYI3EAQxazBpMFQxCzAJ BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWdu IFBlcnNvbmFsU2lnbiAyIENBIC0gRzICEQCWaWbA3qWpL+Qmn6I16DynMHoGCyqGSIb3DQEJEAIL MWugaTBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMh R2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMiBDQSAtIEcyAhEAlmlmwN6lqS/kJp+iNeg8pzANBgkq hkiG9w0BAQEFAASCAQBKkY1xImSPMK4whqROcGG8+WvrwqFNZsvkY8/eUNug5RuRupVvxNvP4hBU 5GWS1zxbSLIqCh57rhW82WNwIUENEWkC7kZ9dCL7VENtc6oLob92qM+KtZ7fJgKU92apVDNipQgD aoFVxg7ph45CGIMbf1ZEB6BXLMzBscrEl37K1VktW818Pd3xLxme99Zwu/Lnt6V5F4RQYg12ju2Y E7lWYizficVWzKKKKt4yYdd3ij5JeIE+VV6iuwgp3n3g2196rLBbMt8Vnz4o+IR1sEg4xXBUum33 2IiVnZpoJaxLm8QQMvPHnie7qeTmWD5umqrIFyEMkbbqZHhVGLy20EQGAAAAAAAA --=-xBZU0tRm0TJDUQp8tADG--

5 7

Migration of CentOS 6.5 VMs causes kernel panic after upgrading to oVirt 3.4.3
by s k 25 Jul '14

25 Jul '14

--_1dcf94f6-d452-406c-89e4-63c2a6074ed7_ Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Hello=2C I upgraded oVirt yesterday from 3.4.2 to 3.4.3 and performed a yum upgrade = on all ovirt nodes as well without rebooting any of them. After completing the upgrade=2C I tried to perform manual migration of VMs = to a different host. The result was that all Windows 2003/2008 and CentOS = 5 VMs were migrated successfully without any issues but all CentOS 6.5 VMs = crashed although migration was completed successfully. By looking the console of the CentOS 6.5 VMs I noticed that a few seconds a= fter migration was complete=2C all the processes were killed=2C many out of= memory errors were thrown as well as messages like "virtio_balloon virtio3= : Out of puff! Cant' get 256 pages" and the VM ended up in kernel panic so = I had to perform a manual poweroff and start the VM again. Any ideas of what might be the cause? I have opened an urgent Bug for this = (https://bugzilla.redhat.com/show_bug.cgi?id=3D1123274) Thank you=2C Sokratis = --_1dcf94f6-d452-406c-89e4-63c2a6074ed7_ Content-Type: text/html; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable <html> <head> <style></style></head> <body class=3D'hmmessage'><div dir=3D'ltr'>Hello=2C<div><br></div><div><br>= </div><div>I upgraded oVirt yesterday from 3.4.2 to 3.4.3 and performed a y= um upgrade on all ovirt nodes as well without rebooting any of them.</div><= div><br></div><div><br></div><div>After completing the upgrade=2C I tried t= o perform manual migration of VMs to a different host. The result was that = all Windows 2003/2008 &nbsp=3Band CentOS 5 VMs were migrated successfully w= ithout any issues but all CentOS 6.5 VMs crashed although migration was com= pleted successfully.</div><div><br></div><div><br></div><div>By looking the= console of the CentOS 6.5 VMs I noticed that a few seconds after migration= was complete=2C all the processes were killed=2C many out of memory errors= were thrown as well as messages like "virtio_balloon virtio3: Out of puff!= Cant' get 256 pages" and the VM ended up in kernel panic so I had to perfo= rm a manual poweroff and start the VM again.</div><div><br></div><div><br><= /div><div>Any ideas of what might be the cause? I have opened an urgent Bug= for this (<a href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D1123274= " target=3D"_blank" style=3D"font-size: 12pt=3B">https://bugzilla.redhat.co= m/show_bug.cgi?id=3D1123274</a>)</div><div><br></div><div><br></div><div>Th= ank you=2C</div><div><br></div><div><br></div><div>Sokratis</div><div><br><= /div><div><br></div><div><br></div><div><br></div><div><br></div> = </div></body> </html>= --_1dcf94f6-d452-406c-89e4-63c2a6074ed7_--

1 0

Call for Papers Reminder: KVM Forum
by Brian Proffitt 25 Jul '14

25 Jul '14

This is a reminder to everyone that the CFP for KVM Forum is coming up very soon. All submissions must be received[1] before midnight (PDT) on July 27, 2014. This event will be an excellent opportunity to show off the new work being done around oVirt, and will also be hosting of a new oVirt Workshop. Get your submittals in as soon as you can! [1] http://events.linuxfoundation.org/events/kvm-forum/program/cfp BKP -- Brian Proffitt oVirt Community Manager Project Atomic Community Lead Open Source and Standards, Red Hat - http://community.redhat.com Phone: +1 574 383 9BKP IRC: bkp @ OFTC

1 0

Disk migration eats all CPU, vms running in SPM become unresponsive
by Federico Alberto Sayd 24 Jul '14

24 Jul '14

Hello: I am experiencing some troubles with ovirt nodes: When a node is selected as SPM and I move a disk between storage domains, it seems that migration process eats all CPU and some VMs (running on the SPM) hang, others lose network connectivity. The events tab at Ovirt Engine reports the CPU exceeding the defined threshold and then reports that VMs in such host (SPM) are not responding. How can I debug this? Why do the VMs become unresponsive or lost network connectivity when the host CPU goes too high? I have attached a screenshot of the ovirt-engine events, and the relevant engine.log My setup: oVirt Engine Version: 3.4.0-1.el6 (Centos 6.5) Nodes: Centos 6.5 vdsm-4.14.6-0.el6 libvirt-0.10.2-29.el6_5.9 KVM: 0.12.1.2 - 2.415.el6_5.10 (jenkins build) Regards Federico

2 1

planning ovirt for production
by Demeter Tibor 24 Jul '14

24 Jul '14

------=_Part_27854792_967363234.1405525563715 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, We have a production environment with KVM+centos6 and we want to switch to ovirt. At this moment we have 12 VM on three independent server. This VMs uses the local disks of servers, we don't have a central storage. currently we have for ovirt - Two Dell R710 with 128 gigs of ram. - A third dell server for ovirt-engine. - four 1 gb/sec NICs/ server. - Smart GB switch we would like make an ovirt environment with - clusterized, redundant filesystem, data loss protection - If a host goes to down the VMs could made a restart on the remain host - LACP/bonding (mode 6) for fast I/O beetwen gluster hosts, we don't have 10Gbe nics - 8 TB of disk capacity for VMs we don't want: - using hw raid on servers, because we need free disk tray for more capacity My questions. - Which glusterfs method is the best for us for performance? - Can I make a real "performance" disk i/o by 4-4 NICs ? Or I need 10 Gbe nic for this? - How much disk need for good redundancy/performance? 4/server or 2/server ? - What will the weak point our project? Thanks in advance. Tibor ------=_Part_27854792_967363234.1405525563715 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"font-family: times new roman, new york, times, se= rif; font-size: 12pt; color: #000000"><div>Hi,</div><div><br></div><div>We = have a production environment with KVM+centos6 and we want to switch to ovi= rt.</div><div>At this moment we have 12 VM on three independent server.&nbs= p;</div><div>This VMs uses the local disks of servers, we don't have a cent= ral storage.</div><div><br></div><div>currently we have for ovirt</div><div= ><br></div><div>- Two Dell R710 with 128 gigs of ram.</div><div><span style= =3D"font-size: 12pt;">- A third dell server for ovirt-engine.</span></div><= div><span style=3D"font-size: 12pt;">- four 1 gb/sec NICs/ server.</span></= div><div><span style=3D"font-size: 12pt;">- Smart GB switch</span></div><di= v><br></div><div>we would like make an ovirt environment with</div><div><br= ></div><div>- clusterized, redundant filesystem, data loss protection</div>= <div>- If a host goes to down the VMs could made a restart on the remain ho= st</div><div>- LACP/bonding (mode 6) for fast I/O beetwen gluster hosts, we= don't have 10Gbe nics</div><div>- 8 TB of disk capacity for VMs</div><div>= <br></div><div>we don't want:</div><div><br></div><div>- using hw raid on s= ervers, because we need free disk tray for more capacity</div><div><br></di= v><div>My questions.</div><div><br></div><div>- Which glusterfs method is t= he best for us for performance?</div><div>- Can I make a real "performance"= disk i/o  by 4-4 NICs  ? Or I need 10 Gbe nic for this?</div><di= v>- How much disk need for good redundancy/performance? 4/server or 2/serve= r ? </div><div>- What will the weak point our project?</div><div><br><= /div><div>Thanks in advance.</div><div><br></div><div>Tibor</div><div><br><= /div><div><br></div><div><br></div><div><br></div><div><br></div></div></bo= dy></html> ------=_Part_27854792_967363234.1405525563715--

3 3

[QE][ACTION NEEDED] oVirt 3.5.0 RC status
by Sandro Bonazzola 24 Jul '14

24 Jul '14

Hi, We're going to compose oVirt 3.5.0 RC on Mon * 2014-08-04 08:00 UTC*. Maintainers: - Please be sure that 3.5 snapshot allow to create VMs before *2014-08-03 15:00 UTC* - Please be sure that no pending patches are going to block the release before *2014-08-03 15:00 UTC* - If any patch must block the RC release please raise the issue as soon as possible. The bug tracker [1] shows the following proposed blockers to be reviewed: Bug ID Whiteboard Status Summary 1121694 infra POST Missing rmlink in ioprocess 1115044 infra POST Host stuck in "Unassinged" state when using jsonrpc and disconnection from pool failed 1114987 network ASSIGNED Cannot start VM | The host did not satisfy internal filter Network because network(s) are missing. Feature freeze is now effective, and branch has been created. All new patches must be backported to 3.5 branch too. Features completed are marked in green on Features Status Table [2] There are still 387 bugs [3] targeted to 3.5.0. Excluding node and documentation bugs we still have 338 bugs [4] targeted to 3.5.0. Maintainers / Assignee: - Please check ensure that completed features are marked in green on Features Status Table [2] - Please remember to rebuild your packages before *2014-08-03 15:00* if needed, otherwise nightly snapshot will be taken. - If you find a blocker bug please remember to add it to the tracker [1] - Please fill release notes, the page has been created here [5] - Please review and add test cases to oVirt 3.5 Second Test Day [6] Community: - save the date for second test day scheduled on 2014-07-29! - You're welcome to join us testing next beta release and getting involved in oVirt Quality Assurance[7]! [1] http://bugzilla.redhat.com/1073943 [2] http://bit.ly/17qBn6F [3] http://red.ht/1pVEk7H [4] http://red.ht/1rLCJwF [5] http://www.ovirt.org/OVirt_3.5_Release_Notes [6] http://www.ovirt.org/OVirt_3.5_TestDay [7] http://www.ovirt.org/OVirt_Quality_Assurance Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Can we debug some truths/myths/facts about hosted-engine and gluster?
by Andrew Lau 24 Jul '14

24 Jul '14

Hi all, As most of you have got hints from previous messages, hosted engine won't work on gluster . A quote from BZ1097639 "Using hosted engine with Gluster backed storage is currently something we really warn against. I think this bug should be closed or re-targeted at documentation, because there is nothing we can do here. Hosted engine assumes that all writes are atomic and (immediately) available for all hosts in the cluster. Gluster violates those assumptions. " Until the documentation gets updated, I hope this serves as a useful notice at least to save people some of the headaches I hit like hosted-engine starting up multiple VMs because of above issue. Now my question, does this theory prevent a scenario of perhaps something like a gluster replicated volume being mounted as a glusterfs filesystem and then re-exported as the native kernel NFS share for the hosted-engine to consume? It could then be possible to chuck ctdb in there to provide a last resort failover solution. I have tried myself and suggested it to two people who are running a similar setup. Now using the native kernel NFS server for hosted-engine and they haven't reported as many issues. Curious, could anyone validate my theory on this? Thanks, Andrew

6 14

Build ovirt-node problem
by yangtao 23 Jul '14

23 Jul '14

------=_Part_130101_313380573.1405050631495 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 RGVhciAgR3V5cywKCkZpcnN0bHksIHNvcnJ5IHRvIHRvdWJsZSB5b3UhICBJIG1lZXQgb25lIHBy b2JsZW0gd2hlbiBJIGJ1aWxkIHRoZSBvdmlydC1ub2RlIGFzIElTTyBpbWFnZS4KSSBkbyBpdCBz dGVwIGJ5IHN0ZXAgYWNjb3JkaW5nIHRvIHRoZSBOb2UgQnVpbGRpbmcgaW4gdGhlIG92aXJ0IHdl YnNpdGUuIEhvd2V2ZXIsIFRoZSBJU08gaW1hZ2UKdGhhdCBpcyBidWlsdCBieSBtZSBkb2Vzbid0 IHdvcmsuIAoKQ291bGQgYW55b25lIGdpdmUgbWUgc29tZSBzdWdnZXN0aW9uIGFib3V0IGhvdyB0 byBidWxkIHRoZSBvdmlydC1ub2RlIGFzIElTTyBpbWFnZT8gVGhhbmtzIQoKQmVzdCBSZWdhcmRz IQpUYW8gICAg ------=_Part_130101_313380573.1405050631495 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6QXJpYWwiPjxkaXY+RGVhciZuYnNwOyBHdXlzLDxicj48YnI+Rmlyc3RseSwg c29ycnkgdG8gdG91YmxlIHlvdSEmbmJzcDsgSSBtZWV0IG9uZSBwcm9ibGVtIHdoZW4gSSBidWls ZCB0aGUgb3ZpcnQtbm9kZSBhcyBJU08gaW1hZ2UuPGJyPkkgZG8gaXQgc3RlcCBieSBzdGVwIGFj Y29yZGluZyB0byB0aGUgTm9lIEJ1aWxkaW5nIGluIHRoZSBvdmlydCB3ZWJzaXRlLiBIb3dldmVy LCBUaGUgSVNPIGltYWdlPGJyPnRoYXQgaXMgYnVpbHQgYnkgbWUgZG9lc24ndCB3b3JrLiZuYnNw OyA8YnI+PGJyPkNvdWxkIGFueW9uZSBnaXZlIG1lIHNvbWUgc3VnZ2VzdGlvbiBhYm91dCBob3cg dG8gYnVsZCB0aGUgb3ZpcnQtbm9kZSBhcyBJU08gaW1hZ2U/IFRoYW5rcyE8YnI+PGJyPkJlc3Qg UmVnYXJkcyE8YnI+VGFvJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvZGl2PjwvZGl2Pjxicj48 YnI+PHNwYW4gdGl0bGU9Im5ldGVhc2Vmb290ZXIiPjxzcGFuIGlkPSJuZXRlYXNlX21haWxfZm9v dGVyIj48L3NwYW4+PC9zcGFuPg== ------=_Part_130101_313380573.1405050631495--

2 4

Ovirt nodes lose up status
by Fabien CARRE 23 Jul '14

23 Jul '14

Hello, I am experiencing an issue with on my current ovirt DC. The setup is 2 machines running Ovit Nodes connected to a LaCie 12big Rack Fibre 8, the nodes are connected to both controllers.. This configuration has worked fine for a couple of weeks. Recently the nodes go from Up status to Non Operational. When I activate them back they don't last more than 2 minutes. /var/logl/messages on both nodes shows the same errors : Jul 23 15:14:58 localhost kernel: device-mapper: table: 253:0: adding target device sdc caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=170496, start=0 Jul 23 15:14:58 localhost kernel: device-mapper: table: 253:0: adding target device sdc caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=170496, start=0 Jul 23 15:14:58 localhost kernel: device-mapper: table: 253:1: adding target device sdd caused an alignment inconsistency: physical_block_size=262144, logical_block_size=512, alignment_offset=16384, start=0 Jul 23 15:14:58 localhost kernel: device-mapper: table: 253:1: adding target device sdd caused an alignment inconsistency: physical_block_size=262144, logical_block_size=512, alignment_offset=16384, start=0 Jul 23 15:15:58 localhost vdsm scanDomains WARNING Metadata collection for domain path /rhev/data-center/mnt/rhevm:_opt_exports_export timedout#012Traceback (most recent call last):#012 File "/usr/share/vdsm/storage/fileSD.py", line 662, in collectMetaFiles#012 sd.DOMAIN_META_DATA))#012 File "/usr/share/vdsm/storage/remoteFileHandler.py", line 297, in callCrabRPCFunction#012 *args, **kwargs)#012 File "/usr/share/vdsm/storage/remoteFileHandler.py", line 184, in callCrabRPCFunction#012 rawLength = self._recvAll(LENGTH_STRUCT_LENGTH, timeout)#012 File "/usr/share/vdsm/storage/remoteFileHandler.py", line 150, in _recvAll#012 raise Timeout()#012Timeout Jul 23 15:16:00 localhost vdsm scanDomains WARNING Metadata collection for domain path /rhev/data-center/mnt/rhevm:_opt_exports_export timedout#012Traceback (most recent call last):#012 File "/usr/share/vdsm/storage/fileSD.py", line 662, in collectMetaFiles#012 sd.DOMAIN_META_DATA))#012 File "/usr/share/vdsm/storage/remoteFileHandler.py", line 297, in callCrabRPCFunction#012 *args, **kwargs)#012 File "/usr/share/vdsm/storage/remoteFileHandler.py", line 184, in callCrabRPCFunction#012 rawLength = self._recvAll(LENGTH_STRUCT_LENGTH, timeout)#012 File "/usr/share/vdsm/storage/remoteFileHandler.py", line 150, in _recvAll#012 raise Timeout()#012Timeout Jul 23 15:16:09 localhost vdsm scanDomains WARNING Metadata collection for domain path /rhev/data-center/mnt/rhevm:_opt_exports_export timedout#012Traceback (most recent call last):#012 File "/usr/share/vdsm/storage/fileSD.py", line 662, in collectMetaFiles#012 sd.DOMAIN_META_DATA))#012 File "/usr/share/vdsm/storage/remoteFileHandler.py", line 297, in callCrabRPCFunction#012 *args, **kwargs)#012 File "/usr/share/vdsm/storage/remoteFileHandler.py", line 184, in callCrabRPCFunction#012 rawLength = self._recvAll(LENGTH_STRUCT_LENGTH, timeout)#012 File "/usr/share/vdsm/storage/remoteFileHandler.py", line 150, in _recvAll#012 raise Timeout()#012Timeout Has anyone met such a problem ? Thank you Fabien Carré

2 2

oVirt Weekly Sync Meeting Minutes: July 23, 2014
by Brian Proffitt 23 Jul '14

23 Jul '14

========================= #ovirt: oVirt Weekly Sync ========================= Meeting started by bkp at 14:05:20 UTC. The full logs are available at http://ovirt.org/meetings/ovirt/2014/ovirt.2014-07-23-14.05.log.html . Meeting summary --------------- * Agenda and Roll Call (bkp, 14:05:48) * infra update (bkp, 14:07:35) * 3.4.z updates (bkp, 14:07:35) * 3.5 status (bkp, 14:07:35) * conferences and workshops (bkp, 14:07:35) * other topics (bkp, 14:07:35) * infra update (bkp, 14:07:43) * infra Cabling in place for the lab in phx2, migration should be faster (bkp, 14:12:09) * infra Multiple tickets closed. (bkp, 14:12:37) * infra Tickets solved in last month link: http://goo.gl/Gc3jwJ (bkp, 14:13:09) * 3.4.z updates (bkp, 14:13:38) * 3.4.z updates oVirt 3.4.4 in development. General availability: 2014-09-16, RC Build: 2014-09-09. (bkp, 14:14:08) * 3.4.z updates 3.4.4 released (bkp, 14:14:39) * 3.4.z updates Some issues with 3.4.3 vdsm, will respin (bkp, 14:15:26) * 3.4.z updates AMEND Some issues with 3.4.3 vdsm, already respun (bkp, 14:18:27) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1121999#c2 (danken, 14:19:51) * 3.5 status (bkp, 14:20:04) * 3.5 status integration repo composed and it passed basic sanity on bare metal, will be released soon. (bkp, 14:23:04) * 3.5 status integration Test Day 2 should be delayed until July 29 (bkp, 14:23:04) * ACTION: Test Day 2 for 3.5 Beta to be delayed until 29/7/14 (bkp, 14:23:34) * 3.5 status integration Two blockers remain, both in POST status. (bkp, 14:24:04) * 3.5 status network Bug 1114987 added today, since it became clear it was a network issue. POST status misleading, since primary issue not addressed in fix. Complete fix ETA: a couple of days. (bkp, 14:29:23) * 3.5 status network All other blockers closed. (bkp, 14:29:23) * 3.5 status infra Bug 1115044 blocker in POST. Estimated time to fix: Sometime this week. (bkp, 14:36:14) * LINK: https://bugzilla.redhat.com/1120721 (danken, 14:37:48) * 3.5 status virt No updates this week. (bkp, 14:42:33) * 3.5 status storage gpadgett and alitke are closing gaps on live-merge (mostly active-layer handling and negative flows) (bkp, 14:45:50) * 3.5 status storage Just dealing with the normal inflow of bugs (bkp, 14:45:50) * 3.5 status node Some instabilities with the appliance builds. Estimated time to fix: Couple of days (bkp, 14:48:25) * 3.5 status node Some clarification needed on generic registration. Estimated time to fix: Couple of days (bkp, 14:48:26) * 3.5 status sla iotunes bug (1085049) we need reviews for the engine part and I haven't been able to get any QE to verify the vdsm part till today. gklein has indicated dev CI testing, as soon as a build is running there. ETA indeterminate. (bkp, 15:02:17) * 3.5 status sla qos and numa ui are not in (bkp, 15:02:17) * 3.5 status sla Hosted engine is good, optimizer is good, but pending some infrastructure tickets for jenkins (bkp, 15:02:17) * 3.5 status msivak will be working to push CI testing through (bkp, 15:02:17) * 3.5 status ux GUI sorting: all main tabs are in 3.5, including Volumes (gluster). Sub-tabs sorting within 'virt' main tabs is still in progress. full status is in: https://docs.google.com/spreadsheets/d/1S3qDYqv9OK5ruI41RpFpRAsLaojpGL-W6WY… (bkp, 15:08:34) * 3.5 status ux Italian translation in progress; currently still in ~30% completion, hopefully will increase soon (a couple more translators may contribute additional translations) (bkp, 15:08:34) * Conferences and Workshops (bkp, 15:08:52) * Conferences and Workshops We will be participating in a Day 0 enterprise Linux day at Fossetcon on Sept 11. oVirt will have lots of room for tutorials. (bkp, 15:09:00) * Conferences and Workshops OSCON is going well and we are having good discussions on oVirt. (bkp, 15:09:00) * Conferences and Workshops We need submissions for KVM Forum, and (now) oVirt Workshop. Talk to bazulay or bkp for more details. (bkp, 15:10:11) * Other Topics (bkp, 15:10:21) Meeting ended at 15:14:50 UTC. Action Items ------------ * Test Day 2 for 3.5 Beta to be delayed until 29/7/14 Action Items, by person ----------------------- * **UNASSIGNED** * Test Day 2 for 3.5 Beta to be delayed until 29/7/14 People Present (lines said) --------------------------- * bkp (99) * danken (23) * sbonazzo (19) * msivak (14) * lvernia (12) * fabiand (8) * awels (7) * pkliczew (7) * eedri (7) * gklein (6) * amureini (6) * dcaro (3) * YamakasY (2) * Wermwud (2) * misc (2) * bazulay (2) * ovirtbot (2) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- Brian Proffitt oVirt Community Manager Project Atomic Community Lead Open Source and Standards, Red Hat - http://community.redhat.com Phone: +1 574 383 9BKP IRC: bkp @ OFTC

1 0