December 2012 - Devel - oVirt List Archives

[Engine-devel] Trusted Compute Pools
by Wei, Gang 10 Feb '13

10 Feb '13

------=_NextPart_000_0388_01CDC762.DCFD1B70 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, I am an engineer working in Intel Open Source Technology Center, interested in integrating Intel initiated OpenAttestation(OAT) project (https://github.com/OpenAttestation/OpenAttestation.git) into oVirt to provide a way for Administrator to deploy VMs on trusted hosts hardened with H/W-based security features, such as Intel TXT. I made a draft feature page for this: http://wiki.ovirt.org/wiki/Trusted_compute_pools My draft idea is to provide trust_level requirement while doing vm creation like below: curl -v -u "vdcadmin(a)qa.lab.tlv.redhat.com" -H "Content-type: application/xml" -d '<vm><name>my_new_vm</name> <cluster id="99408929-82cf-4dc7-a532-9d998063fa95" /> <template id="00000000-0000-0000-0000-000000000000"/> <trust_level>trusted</trust_level></vm>' 'http://10.35.1.1/rhevm-api/vms' Then oVirt Engine should query attestation server built with OAT via RESTful API to get all trusted hosts and select one to create the VM. Attestation server performs host verification through following steps: 1. Hosts boot with Intel TXT technology enabled 2. The hosts' BIOS, hypervisor and OS are measured 3. These measured data is sent to Attestation server when challenged by attestation server 4. Attestation server verifies those measurements against good/known database to determine hosts' trustworthiness Hosts need to be installed with OAT host agent to report host integrity to attestation server. By far, I am still in process of getting familiar with oVirt code and not get solid idea yet on how the oVirt Engine should be modified to support this feature. Any kind of comments or suggestions will be highly appreciated. Thanks Gang (Jimmy) Wei ------=_NextPart_000_0388_01CDC762.DCFD1B70 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIdxjCCAyAw ggKJoAMCAQICBDXe9M8wDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0Vx dWlmYXgxLTArBgNVBAsTJEVxdWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05 ODA4MjIxNjQxNTFaFw0xODA4MjIxNjQxNTFaME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVp ZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMFdsVhnCGLuoJotHwhtkRRomAoe/toEbxOEYiHD0XzOnwXg uAHwTjTs4oqVBGSs8WtTXwWzy2eAv0ICjv7dAQns4QAUT/z78AzdQ7pbK+EfgHCZFVeTFvEPl2q3 wmgjHMxNWTCsUR47ryvW7mNFe8XZX1DS41APOojnvxT94Me5AgMBAAGjggEJMIIBBTBwBgNVHR8E aTBnMGWgY6BhpF8wXTELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VxdWlmYXgxLTArBgNVBAsTJEVx dWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTENMAsGA1UEAxMEQ1JMMTAaBgNVHRAE EzARgQ8yMDE4MDgyMjE2NDE1MVowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fY IyAQTzOYkJ/UMB0GA1UdDgQWBBRI5mj5K9KylddH2CMgEE8zmJCf1DAMBgNVHRMEBTADAQH/MBoG CSqGSIb2fQdBAAQNMAsbBVYzLjBjAwIGwDANBgkqhkiG9w0BAQUFAAOBgQBYzinq/Pfetc4CuRe1 hdG54+CVzCUxDQCmkm5/tpJjnlCV0Zpv5BHeY4VumO6o/1rI01WyZnFX3sAh6z0qpyNJAQSGQnv8 7n+iFlK1Z2fTQNs7JliyKHc9rhR3Ydb6KmYnoA36p3Nc6nDxlCFlRF/6/O8paKmih3nvee9PrAd3 ODCCAz0wggKmoAMCAQICAwWw/zANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MB4XDTA2MDIxNjE4MDEzMFoXDTE2MDIxOTE4MDEzMFowUjELMAkGA1UEBhMCVVMxGjAYBgNVBAoT EUludGVsIENvcnBvcmF0aW9uMScwJQYDVQQDEx5JbnRlbCBFeHRlcm5hbCBCYXNpYyBQb2xpY3kg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBpd/XOb9QVqEZ8mQ1042TdOIq3ATD IsV2xDyt30yLyMR5Wjtus0bn3B+he89BiNO/LP6+rFzEwlD55PlX+HLGIKeNNG97dqyc30FElEUj ZzTZFq2N4e3kVJ/XAEEgANzV8v9qp7qWwxugPgfc3z9BkYot+CifozexHLb/hEZj+yISCU61kRZv uSQ0E11yYL4dRgcglJeaHo3oX57rvIckaLsYV5/1Aj+R8DM1Ppk965XQAKsHfnyT7C4S50T4lVn4 lz36wOdNZn/zegG1zp41lnoTFfT4KuKVJH5x7YD1p6KbgJCKLovnujGuohquBNfdXKpZkvz6pGv+ iC1HawJdAgMBAAGjgaAwgZ0wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQaxgxKxEdvqNutK/D0 Vgaj7TdUDDA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3Nl Y3VyZWNhLmNybDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTAD AQH/MA0GCSqGSIb3DQEBBQUAA4GBABMQOK2kVKVIlUWwLTdywJ+e2O+PC/uQltK2F3lRyrPfBn69 tOkIP4SgDJOfsxyobIrPLe75kBLw+Dom13OBDp/EMZJZ1CglQfVV8co9mT3aZMjSGGQiMgkJLR3j Mfr900fXZKj5XeqCJ+JP0mEhJGEdVCY+FFlksJjV86fDrq1QMIIFijCCBHKgAwIBAgIKYR6AtwAA AAAABzANBgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9y YXRpb24xJzAlBgNVBAMTHkludGVsIEV4dGVybmFsIEJhc2ljIFBvbGljeSBDQTAeFw0wOTA1MTUx OTI1MTNaFw0xNTA1MTUxOTM1MTNaMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jw b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMGPgGLnOO5IOzlHRfr1XfCVb97V4BR2QVpPZ7Cr cIQ+FGa2KHD/6dPjwxOIrtFTdfW4BYikdFmxUZVBWRWZ5Vye2cCdGzFWqIEOE1e17nNx1jM8Z6GZ EqbDUS+vBuPlBFHKQoVm5BaNIHpyn2XZxqwjV9j5/crIfPrCGstk+2ztUhVS8OHEgzO784PgD9pO gBnnAbZHmEM1FYYmQ6ibS+gVCHzobDYG+YReRiHpFKWBxpUuP+X0WYFw/Ja1JW7N8pELAFDw0UFB WFgiv1QIusdLvSy8mcsLJ5wy050OVcxShqoUxhw/wvyuuoQxvmEPjhRa1C2oSCmGN0003GMhQWMC AwEAAaOCAlwwggJYMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFKoWZq+3PVZTYK4Nwu3z7gfL UWB+MAsGA1UdDwQEAwIBhjASBgkrBgEEAYI3FQEEBQIDAQABMCMGCSsGAQQBgjcVAgQWBBTCKwhT x+hdMsKCgOmWwLgjQsAV+TAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBQa xgxKxEdvqNutK/D0Vgaj7TdUDDCBvQYDVR0fBIG1MIGyMIGvoIGsoIGphk5odHRwOi8vd3d3Lmlu dGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBQb2xpY3kl MjBDQS5jcmyGV2h0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JML0lu dGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNybDCB4wYIKwYBBQUHAQEEgdYw gdMwYwYIKwYBBQUHMAKGV2h0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNh dGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNydDBsBggrBgEFBQcw AoZgaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3NpdG9yeS9jZXJ0aWZpY2F0ZXMv SW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwUG9saWN5JTIwQ0EuY3J0MA0GCSqGSIb3DQEBBQUA A4IBAQCUY/1d0MS6VPTlIcOho1XWh193PD5kJDJSPdphLHQdM1oKA+whMdIBoY1VzTDDK+C+Ey4J cyna7fpC8uVmn/Rz/i9MZtyc7qezPtZTn9UyORvJmddH+Ox/RycGwe3ags8jUdspECorYOkJyZks nDIlTVUvbR7wyY+gGJYqxWXqrcVFEiMsWu8/OIlf7F2gAYMBw1kZ55dn4lWBIM0WqvReWpPvhYeN 7Y+3MKEdSMkQ7TZiNbfdZ5D/8KfWNMTJ4VHltOgCL1lA5tx/F4R1920skpL5eu3Sj650RUe3rOXs aV5NyJzBwB31+1zsmleVdFD0k/Fw9HxXbAQE35ucN/7CMIIFijCCBHKgAwIBAgIKYSCKYgAAAAAA CDANBgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRp b24xJzAlBgNVBAMTHkludGVsIEV4dGVybmFsIEJhc2ljIFBvbGljeSBDQTAeFw0wOTA1MTUxOTI3 MjZaFw0xNTA1MTUxOTM3MjZaMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jwb3Jh dGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQjCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAKQEM1Wn9TU9vc9C+/Tc7KB+eiYElmrcEWE32WUdHvWG +IcQHVQsikTmMyKKojNLw2B5s6Iekc8ivDo/wCfjZzX9JyftMnc+AArc0la87Olybzm8K9jXEfTB vTnUSFSiI9ZYefITdiUgqlAFuljFZEHYKYtLuhrRacpmQfP4mV63NKdc2bT804HRf6YptZFa4k6Y N94zlrGNrBuQQ74WFzz/jLBusbUpEkro6Mu/ZYFOFWQrV9lBhF9Ruk8yN+3N6n9fUo/qBigiF2kE n9xVh1ykl7SCGL2jBUkXx4qgV27a6Si8lRRdgrHGtN/HWnSWlLXTH5l575H4Lq++77OFv38CAwEA AaOCAlwwggJYMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFA7GKvdZsggQkCVvw939imYxMCvF MAsGA1UdDwQEAwIBhjASBgkrBgEEAYI3FQEEBQIDAQABMCMGCSsGAQQBgjcVAgQWBBQ5oFY2ekKQ /5Ktim+VdMeSWb4QWTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBQaxgxK xEdvqNutK/D0Vgaj7TdUDDCBvQYDVR0fBIG1MIGyMIGvoIGsoIGphk5odHRwOi8vd3d3LmludGVs LmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBQb2xpY3klMjBD QS5jcmyGV2h0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JML0ludGVs JTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNybDCB4wYIKwYBBQUHAQEEgdYwgdMw YwYIKwYBBQUHMAKGV2h0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNhdGVz L0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNydDBsBggrBgEFBQcwAoZg aHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3NpdG9yeS9jZXJ0aWZpY2F0ZXMvSW50 ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwUG9saWN5JTIwQ0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IB AQCxtQEHchVQhXyjEqtMVUMe6gkmPsIczHxSeqNbo9dsD+6xbT65JT+oYgpIAtfEsYXeUJu1cChq pb22U5bMAz7eaQcW5bzefufWvA6lg2048B8oczBj/q+5P5NpYrUO8jOmN4jTjfJq3ElZ7yFWpy7r B3Vm/aN6ATYqWfMbS/xfh+JCxmH3droUmMJI0/aZJHsLtjbjFnNsHDNrJZX1vxlM78Lb1hjskTEN PmhbVbfTj5i/ZGnhv4tmI8QZPCNtcegXJrfhRl2D9bWpdTOPrWiLDUqzy1Z6KL7TcOS/PCl8RHCJ XkPau/thTQCpIoDa2+c+3XA++gRTfAQ4svTO260NMIIF+zCCBOOgAwIBAgIKHtX06gABAACWPTAN BgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRpb24x KzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0IwHhcNMTIwNjA4MDgw NTExWhcNMTUwNTE1MTkzNzI2WjA3MRIwEAYDVQQDEwlXZWksIEdhbmcxITAfBgkqhkiG9w0BCQEW Emdhbmcud2VpQGludGVsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALNyfS4y C6aDo3DZ/oId96Dvi8CB5SJyDUcMhpKWZtzqPX2mMOqQNgv4qAtHUjt4ibyPSjGZ+0EM3r63384g GcVR8+uxiuijBIOCkis6oGQ+TmBl1i28KobkE4jNnLCES0keisfNdzO8vAOxIFbT9KxQl1f1Mfvs ZfyGfFYB53gHCh1VxdZ7a2XKaON+l2YYx2p5xGGZtDDb61ajXSGvdHK+qMIfo7LMoZmY42t5Nawg izwcqBPUOLR+JXOtyGGiXZx3wZPeRmZx/eCMPBhSlfewpvUrK8W0kL591Lv0HeUVEJye2bOmlLo1 DeIp6KH9JujFB33KhHXvNsugc9IYUVMCAwEAAaOCAugwggLkMAsGA1UdDwQEAwIHgDA8BgkrBgEE AYI3FQcELzAtBiUrBgEEAYI3FQiGw4x1hJnlUYP9gSiFjp9TgpHACWeB3r05lfBDAgFkAgEIMB0G A1UdDgQWBBQYdG5bBKSgjlBUQ6dpUm2vjlkEKDAfBgNVHSMEGDAWgBQOxir3WbIIEJAlb8Pd/Ypm MTArxTCBzwYDVR0fBIHHMIHEMIHBoIG+oIG7hldodHRwOi8vd3d3LmludGVsLmNvbS9yZXBvc2l0 b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIwQ0ElMjAzQigxKS5j cmyGYGh0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JML0ludGVsJTIw RXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDNCKDEpLmNybDCB9QYIKwYBBQUHAQEE gegwgeUwbAYIKwYBBQUHMAKGYGh0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlm aWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDNCKDEpLmNy dDB1BggrBgEFBQcwAoZpaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3NpdG9yeS9j ZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUyMENBJTIwM0Io MSkuY3J0MB8GA1UdJQQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMCkGCSsGAQQBgjcVCgQcMBow CgYIKwYBBQUHAwQwDAYKKwYBBAGCNwoDDDBBBgNVHREEOjA4oCIGCisGAQQBgjcUAgOgFAwSZ2Fu Zy53ZWlAaW50ZWwuY29tgRJnYW5nLndlaUBpbnRlbC5jb20wDQYJKoZIhvcNAQEFBQADggEBAHuy cX8AxjwfC5zmWDh0QpY8vDSgyLXaUDYKm2+ATDJDn5kALJgxAqaThvqGTH+oz73HQ7L8v7QxM0Yp 1IQd/k5GeqMzhuXEoPM4rcORlOlvRqxBJNZUuYwxvyYaUpLU1W8EsOB2zB31ykzdXH93b6ZpfJk7 8eqZuq00xHxU9mw4PXlWPnn1NDBYD1JH/ufCmpFk6sBE2bBf2u2miBEwHoRUyoH1nbu78aOs4mE6 fRC9NutIriNPI2790R3FAY8dLWl3nrpXs80TrUCptat61uNRJDH06KXe81QCtvDVlBGbZ4gqWR3P ZGsnJKeOLOO38PQvFFm1Xjs4DVYiPVYyCTIwggZCMIIFKqADAgECAgoUmebGAAEAAFPVMA0GCSqG SIb3DQEBBQUAMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jwb3JhdGlvbjErMCkG A1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQTAeFw0xMDEyMDEwOTMxMzla Fw0xMzExMTUwOTMxMzlaMDcxEjAQBgNVBAMTCVdlaSwgR2FuZzEhMB8GCSqGSIb3DQEJARYSZ2Fu Zy53ZWlAaW50ZWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlkDjEHBe0Gg1 dZhmebTYRY4qWGcBCKuEGfp8DuoVXyv3gW6bXc8TcWRSXj0vxL/+/RKObwVc17Cu2XcO0MTU1EOo ohTEl/QDnBvj0qeqKnkZGmAM0cCU7+m07N0ATPEzg0t2gJUA8dVO37iAo1KMQ72ovMJ1LU+x7tno d6PhrgXLmbjkEjQZnHwLvuI2TdiKKDvJtd6xz6DQuIBSPyn4wYsckGQcb5NlEiQCkCaPM/ZtcKcm Kxu0g1TfW7zIWuRhkPIOyin/bsN8RBTTq8lL74yFgTB4ybAMp13wtROVAN5FLYE31CAgJ69EBNix xTBNsLtv+KM6sXsbDccp3H5JwQIDAQABo4IDLzCCAyswCwYDVR0PBAQDAgQwMD0GCSsGAQQBgjcV BwQwMC4GJisGAQQBgjcVCIbDjHWEmeVRg/2BKIWOn1OCkcAJZ4S52UGHhP9OAgFkAgEMMEQGCSqG SIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggq hkiG9w0DBzAdBgNVHQ4EFgQUwmKbKrf26Ot7Acv/+2aZDzj7gaQwHwYDVR0jBBgwFoAUqhZmr7c9 VlNgrg3C7fPuB8tRYH4wgc8GA1UdHwSBxzCBxDCBwaCBvqCBu4ZXaHR0cDovL3d3dy5pbnRlbC5j b20vcmVwb3NpdG9yeS9DUkwvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUyMENB JTIwM0EoMSkuY3JshmBodHRwOi8vY2VydGlmaWNhdGVzLmludGVsLmNvbS9yZXBvc2l0b3J5L0NS TC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIwQ0ElMjAzQSgxKS5jcmwwgfUG CCsGAQUFBwEBBIHoMIHlMGwGCCsGAQUFBzAChmBodHRwOi8vd3d3LmludGVsLmNvbS9yZXBvc2l0 b3J5L2NlcnRpZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIwQ0El MjAzQSgxKS5jcnQwdQYIKwYBBQUHMAKGaWh0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3Jl cG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3Vpbmcl MjBDQSUyMDNBKDEpLmNydDAfBgNVHSUEGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDBDApBgkrBgEE AYI3FQoEHDAaMAoGCCsGAQUFBwMEMAwGCisGAQQBgjcKAwQwQQYDVR0RBDowOKAiBgorBgEEAYI3 FAIDoBQMEmdhbmcud2VpQGludGVsLmNvbYESZ2FuZy53ZWlAaW50ZWwuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQAPFjqbkKIbnvnYwFG/QpKUm2yGzieys9IJny7PU2fVV4ksTL7emcpCfhFtlg7cPEgU 7Rx6gG4hO+ZBx9oojImSGWj44Pj3EzSyRRaN+UK1VVESHgE2HKmETsAnRN/wulP9ahPJNmEOklBg oX6BJg9NYTqp8gDS6m1QBQoh/C2/51MGcmTecM4g5BuEpgmvxovlPDHlnSq390NXwXtdh1lM5qbo V9FBWFCR1Q7mf7n2Y6b/9m9bn9gMzbdwjMrnpYIiC5rN5WBDQtuzAios8OheGSTX0A1npuGZ3cvP NlPbRAoD7TVAdGhr+ZztVLA0+IFYmQqHV2C8q3TybgPnp1/uMYIDhjCCA4ICAQEwZDBWMQswCQYD VQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRpb24xKzApBgNVBAMTIkludGVsIEV4dGVy bmFsIEJhc2ljIElzc3VpbmcgQ0EgM0ICCh7V9OoAAQAAlj0wCQYFKw4DAhoFAKCCAfcwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMTIwMTMwNjA5WjAjBgkqhkiG 9w0BCQQxFgQU+nIzZXq5B+gfhE2gv1mcG8hi2mEwcwYJKwYBBAGCNxAEMWYwZDBWMQswCQYDVQQG EwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRpb24xKzApBgNVBAMTIkludGVsIEV4dGVybmFs IEJhc2ljIElzc3VpbmcgQ0EgM0ECChSZ5sYAAQAAU9UwdQYLKoZIhvcNAQkQAgsxZqBkMFYxCzAJ BgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jwb3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0 ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQQIKFJnmxgABAABT1TCBqwYJKoZIhvcNAQkPMYGdMIGa MAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqG SIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMC GjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASC AQCEJdPLzc141NjrlWdB5U+28z5AxlqYhO5ref55IUvaW/jP1hJJbR6K/qiTraQ5GGq1reH4zs7R vK7QUZRGa4S8dhqJ6fx0uTF7U61uPaPdtzHaafu55Gw6YePRov9IyiJOh5GCKamcLCdyOa3tYG09 9gIp7bWnA7Y/YGgzfwhUWmJKkDl7htOPr0ez4Fy01gFGiCH26n1xHUcG22YgwnoRx/Qih863KGnV kvtvNrj6Iixo4y8ZF3bQmPhZSn6zPzd99mAPUdwuV78bP/Cexy7UyUP00u9gydnr+YkkWnmOHc2E jnVX8aZdhugP/pR0HbNCof4RXTX6UZ1ge0SUKsrzAAAAAAAA ------=_NextPart_000_0388_01CDC762.DCFD1B70--

5 10

[Engine-devel] jpa annotations
by Laszlo Hornyak 31 Jan '13

31 Jan '13

Hi, We have JPA annotations on the backend entity beans, but they have never been actually used as far as I know and now that I looked into VmTemplate for example we do not even have a vm_template table anymore, while VmTemplate still refers to it. Any plans with the JPA? Laszlo

6 8

[Engine-devel] RFC: New Storage API
by Saggi Mizrahi 22 Jan '13

22 Jan '13

I've been throwing a lot of bits out about the new storage API and I think it's time to talk a bit. I will purposefully try and keep implementation details away and concentrate about how the API looks and how you use it. First major change is in terminology, there is no long a storage domain but a storage repository. This change is done because so many things are already called domain in the system and this will make things less confusing for new-commers with a libvirt background. One other changes is that repositories no longer have a UUID. The UUID was only used in the pool members manifest and is no longer needed. connectStorageRepository(repoId, repoFormat, connectionParameters={}): repoId - is a transient name that will be used to refer to the connected domain, it is not persisted and doesn't have to be the same across the cluster. repoFormat - Similar to what used to be type (eg. localfs-1.0, nfs-3.4, clvm-1.2). connectionParameters - This is format specific and will used to tell VDSM how to connect to the repo. disconnectStorageRepository(self, repoId): In the new API there are only images, some images are mutable and some are not. mutable images are also called VirtualDisks immutable images are also called Snapshots There are no explicit templates, you can create as many images as you want from any snapshot. There are 4 major image operations: createVirtualDisk(targetRepoId, size, baseSnapshotId=None, userData={}, options={}): targetRepoId - ID of a connected repo where the disk will be created size - The size of the image you wish to create baseSnapshotId - the ID of the snapshot you want the base the new virtual disk on userData - optional data that will be attached to the new VD, could be anything that the user desires. options - options to modify VDSMs default behavior returns the id of the new VD createSnapshot(targetRepoId, baseVirtualDiskId, userData={}, options={}): targetRepoId - The ID of a connected repo where the new sanpshot will be created and the original image exists as well. size - The size of the image you wish to create baseVirtualDisk - the ID of a mutable image (Virtual Disk) you want to snapshot userData - optional data that will be attached to the new Snapshot, could be anything that the user desires. options - options to modify VDSMs default behavior returns the id of the new Snapshot copyImage(targetRepoId, imageId, baseImageId=None, userData={}, options={}) targetRepoId - The ID of a connected repo where the new image will be created imageId - The image you wish to copy baseImageId - if specified, the new image will contain only the diff between image and Id. If None the new image will contain all the bits of image Id. This can be used to copy partial parts of images for export. userData - optional data that will be attached to the new image, could be anything that the user desires. options - options to modify VDSMs default behavior return the Id of the new image. In case of copying an immutable image the ID will be identical to the original image as they contain the same data. However the user should not assume that and always use the value returned from the method. removeImage(repositoryId, imageId, options={}): repositoryId - The ID of a connected repo where the image to delete resides imageId - The id of the image you wish to delete. ---- getImageStatus(repositoryId, imageId) repositoryId - The ID of a connected repo where the image to check resides imageId - The id of the image you wish to check. All operations return once the operations has been committed to disk NOT when the operation actually completes. This is done so that: - operation come to a stable state as quickly as possible. - In case where there is an SDM, only small portion of the operation actually needs to be performed on the SDM host. - No matter how many times the operation fails and on how many hosts, you can always resume the operation and choose when to do it. - You can stop an operation at any time and remove the resulting object making a distinction between "stop because the host is overloaded" to "I don't want that image" This means that after calling any operation that creates a new image the user must then call getImageStatus() to check what is the status of the image. The status of the image can be either optimized, degraded, or broken. "Optimized" means that the image is available and you can run VMs of it. "Degraded" means that the image is available and will run VMs but it might be a better way VDSM can represent the underlying data. "Broken" means that the image can't be used at the moment, probably because not all the data has been set up on the volume. Apart from that VDSM will also return the last persisted status information which will conatin hostID - the last host to try and optimize of fix the image stage - X/Y (eg. 1/10) the last persisted stage of the fix. percent_complete - -1 or 0-100, the last persisted completion percentage of the aforementioned stage. -1 means that no progress is available for that operation. last_error - This will only be filled if the operation failed because of something other then IO or a VDSM crash for obvious reasons. It will usually be set if the task was manually stopped The user can either be satisfied with that information or as the host specified in host ID if it is still working on that image by checking it's running tasks. checkStorageRepository(self, repositoryId, options={}): A method to go over a storage repository and scan for any existing problems. This includes degraded\broken images and deleted images that have no yet been physically deleted\merged. It returns a list of Fix objects. Fix objects come in 4 types: clean - cleans data, run them to get more space. optimize - run them to optimize a degraded image merge - Merges two images together. Doing this sometimes makes more images ready optimizing or cleaning. The reason it is different from optimize is that unmerged images are considered optimized. mend - mends a broken image The user can read these types and prioritize fixes. Fixes also contain opaque FIX data and they should be sent as received to fixStorageRepository(self, repositoryId, fix, options={}): That will start a fix operation. All major operations automatically start the appropriate "Fix" to bring the created object to an optimize\degraded state (the one that is quicker) unless one of the options is AutoFix=False. This is only useful for repos that might not be able to create volumes on all hosts (SDM) but would like to have the actual IO distributed in the cluster. Other common options is the strategy option: It has currently 2 possible values space and performance - In case VDSM has 2 ways of completing the same operation it will tell it to value one over the other. For example, whether to copy all the data or just create a qcow based of a snapshot. The default is space. You might have also noticed that it is never explicitly specified where to look for existing images. This is done purposefully, VDSM will always look in all connected repositories for existing objects. For very large setups this might be problematic. To mitigate the problem you have these options: participatingRepositories=[repoId, ...] which tell VDSM to narrow the search to just these repositories and imageHints={imgId: repoId} which will force VDSM to look for those image ID just in those repositories and fail if it doesn't find them there.

6 30

[Engine-devel] ovirt-cli 3.2.0.7 released
by Michael Pasternak 13 Jan '13

13 Jan '13

For more details see [1]. [1] http://wiki.ovirt.org/wiki/CLI#Change_Log -- Michael Pasternak RedHat, ENG-Virtualization R&D

1 2

[Engine-devel] ovirt-sdk 3.2.0.5 released
by Michael Pasternak 13 Jan '13

13 Jan '13

For more details see [1]. [1] http://wiki.ovirt.org/wiki/SDK#Change_Log -- Michael Pasternak RedHat, ENG-Virtualization R&D

2 3

[Engine-devel] FW: Querying for and registering unknown disk images on a storage domain
by Morrissey, Christopher 02 Jan '13

02 Jan '13

--_000_D290AD8432118048947689BA3AE8A9B3094E3FDCSACEXCMBX04PRDh_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I've been working on a bit of functionality for the engine that will allow = a user to query a domain for new disk images (GetUnregisteredImagesQuery) f= or which the engine was previously unaware and a separate command to regist= er those images (ImportImageCommand). These commands will be exposed throug= h the REST API. This functionality is needed as we are developing an extension/plugin to oV= irt that will allow a NetApp storage controller to handle cloning the actua= l disks outside of oVirt and need to import them once they are cloned. We'l= l be using other existing APIs to attach the disk to the necessary VM once = the disk is cloned. On the NetApp side, we'll ensure the disk is coalesced = before cloning so as to avoid the issues of registering snapshots. GetUnregisteredImagesQuery will be accessible through the disks resource co= llection on a storage domain. A "disks" resource collection does not yet ex= ist and will need to be added. To access the unregistered images, a paramet= er (maybe "unregistered=3Dtrue") would be passed. So the path to "GET" the = unregistered disk images on a domain would be something like /api/storagedo= mains/f0dbcb33-69d3-4899-9352-8e8a02f01bbd/disks?unregistered=3Dtrue. This = will return a list of disk images that can be each used as input to the Imp= ortImageCommand to get them added to oVirt. ImportImageCommand will be accessible through "POST"ing a disk to /api/disk= s?import=3Dtrue. The disk will be added to the oVirt DB based on the inform= ation supplied and afterward would be available to attach to a VM. When querying for unregistered disk images, the GetUnregisteredImagesQuery = command will use the getImagesList() VDSM command. Currently this only repo= rts the GUIDs of all disk images in a domain. I had been using the getVolum= esList() and getVolumeInfo() VDSM commands to fill in the information so th= at valid disk image objects could be registered in oVirt. It seems these tw= o functions are set to be removed since they are too invasive into the inte= rnal VDSM workings. The VDSM team will need to either return more informati= on about each disk as part of the getImagesList() function or add a new fun= ction getImageInfo() that will give the same information for a given image = GUID. Note that much of this work had originally been submitted under patch http:= //gerrit.ovirt.org/#/c/9603/. After several reviews it was found to be lack= ing in its design and was using deprecated APIs that did not yet have repla= cements. I'm reworking the code now to conform to this design and asking fo= r further input from the VDSM, core, and restapi teams to ensure we can get= this done quickly and correctly as it is needed for the 3.2 release. -Chris Chris Morrissey Software Engineer NetApp Inc. 919.476.4428 --_000_D290AD8432118048947689BA3AE8A9B3094E3FDCSACEXCMBX04PRDh_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> Hi All,<o:p></o:p> <o:p> </o:p> I’ve been working on a bit of functionality fo= r the engine that will allow a user to query a domain for new disk images (= GetUnregisteredImagesQuery) for which the engine was previously unaware and= a separate command to register those images (ImportImageCommand). These commands will be exposed through the REST API.= <o:p></o:p> <o:p> </o:p> This functionality is needed as we are developing an= extension/plugin to oVirt that will allow a NetApp storage controller to h= andle cloning the actual disks outside of oVirt and need to import them onc= e they are cloned. We’ll be using other existing APIs to attach the disk to the necessary VM once the disk i= s cloned. On the NetApp side, we’ll ensure the disk is coalesced befo= re cloning so as to avoid the issues of registering snapshots.<o:p></o:p></= p> <o:p> </o:p> GetUnregisteredImagesQuery will be accessible throug= h the disks resource collection on a storage domain. A “disks” = resource collection does not yet exist and will need to be added. To access= the unregistered images, a parameter (maybe “unregistered=3Dtrue&#82= 21;) would be passed. So the path to “GET” the unregistered disk im= ages on a domain would be something like /api/storagedomains/f0dbcb33-69d3-= 4899-9352-8e8a02f01bbd/disks?unregistered=3Dtrue. This will return a list o= f disk images that can be each used as input to the ImportImageCommand to get them added to oVirt.<o:p></o:p> <o:p> </o:p> ImportImageCommand will be accessible through &#8220= ;POST”ing a disk to /api/disks?import=3Dtrue. The disk will be added = to the oVirt DB based on the information supplied and afterward would be av= ailable to attach to a VM.<o:p></o:p> <o:p> </o:p> When querying for unregistered disk images, the GetU= nregisteredImagesQuery command will use the getImagesList() VDSM command. C= urrently this only reports the GUIDs of all disk images in a domain. I had = been using the getVolumesList() and getVolumeInfo() VDSM commands to fill in the information so that valid dis= k image objects could be registered in oVirt. It seems these two functions = are set to be removed since they are too invasive into the internal VDSM wo= rkings. The VDSM team will need to either return more information about each disk as part of the getImages= List() function or add a new function getImageInfo() that will give the sam= e information for a given image GUID.<o:p></o:p> <o:p> </o:p> Note that much of this work had originally been subm= itted under patch <a href=3D"http://gerrit.ovirt.org/#/c/9603/">http://gerrit.ovirt.org/#/c/9= 603/</a>. After several reviews it was found to be lacking in its design an= d was using deprecated APIs that did not yet have replacements. I’m r= eworking the code now to conform to this design and asking for further input from the VDSM, core, and restapi teams= to ensure we can get this done quickly and correctly as it is needed for t= he 3.2 release.<o:p></o:p> <o:p> </o:p> -Chris<o:p></o:p> <o:p> </o:p> Chris Morrissey<o:p></o:p> Software Engineer<o:p></o:p> NetApp Inc.<o:p></o:p> 919.476.4428<o:p></o:p> <o:p> </o:p> </div> </body> </html> --_000_D290AD8432118048947689BA3AE8A9B3094E3FDCSACEXCMBX04PRDh_--

3 3

[Engine-devel] Patches awaiting review.
by snmishra＠linux.vnet.ibm.com 02 Jan '13

02 Jan '13

Following patches are waiting for review - http://gerrit.ovirt.org/#/c/10072/ http://gerrit.ovirt.org/#/c/10085/ http://gerrit.ovirt.org/#/c/10086/ http://gerrit.ovirt.org/#/c/10087/ http://gerrit.ovirt.org/#/c/10042/ Thanks Sharad Mishra

3 4

[Engine-devel] Error on starting webadmin
by Moti Asayag 01 Jan '13

01 Jan '13

Hi, I get the following error when trying to connect to webadmin: 2012-12-13 11:57:06,689 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/webadmin].[WebAdminDynamicHosting]] (http--0.0.0.0-8700-1) Servlet.service() for servlet WebAdminDynamicHosting threw exception: java.lang.IllegalArgumentException: The property "ENGINE_USR" doesn't have a value. It caused by the PluginDataManager instantiation which requires several variables to be defined. In order to by pass those errors do: 1. create a file /usr/share/ovirt-engine/conf/engine.conf.defaults 2. Add the following properties to the file: ENGINE_USR=username ENGINE_ETC=/etc/ovirt-engine 3. restart Jboss Regards, Moti

10 25

Re: [Engine-devel] [oVirt Jenkins] ovirt_engine_unit_tests - Build # 2971 - Still Unstable!
by Eyal Edri 27 Dec '12

27 Dec '12

fyi, unit tests are failing from yesterday, please check. Eyal Edri. oVirt infra team. ----- Original Message ----- > From: "Jenkins oVirt Server" <jenkins(a)ovirt.org> > To: eedri(a)redhat.com, engine-patches(a)ovirt.org, oliel(a)redhat.com, yzaslavs(a)redhat.com, mkolesni(a)redhat.com > Sent: Thursday, December 27, 2012 9:53:20 AM > Subject: [oVirt Jenkins] ovirt_engine_unit_tests - Build # 2971 - Still Unstable! > > Project: http://jenkins.ovirt.org/job/ovirt_engine_unit_tests/ > Build: http://jenkins.ovirt.org/job/ovirt_engine_unit_tests/2971/ > Build Number: 2971 > Build Status: Still Unstable > Triggered By: Started by upstream project "ovirt_engine" build number > 3,735 > > ------------------------------------- > Changes Since Last Success: > ------------------------------------- > Changes for Build #2969 > > Changes for Build #2970 > [emesika] core:fixing GeneralDbDAOTest > > > Changes for Build #2971 > [mkolesni] engine: Add network command packages to factory > > [mkolesni] engine: Move DC network commands to their package > > [mkolesni] engine: Moved VM NIC commands to their package > > [mkolesni] engine: Move template NIC commands to their package > > [mkolesni] engine: Extract SetNetworkStatus method > > [mkolesni] engine: Move cluster network commands to their package > > [mkolesni] engine: Move host network commands to their package > > > > > ----------------- > Failed Tests: > ----------------- > 2 tests failed. > REGRESSION: > org.ovirt.engine.api.restapi.types.VmMapperTest.testRoundtrip > > Error Message: > expected:<true> but was:<false> > > Stack Trace: > java.lang.AssertionError: expected:<true> but was:<false> > at org.junit.Assert.fail(Assert.java:93) > at org.junit.Assert.failNotEquals(Assert.java:647) > at org.junit.Assert.assertEquals(Assert.java:128) > at org.junit.Assert.assertEquals(Assert.java:147) > at > org.ovirt.engine.api.restapi.types.VmMapperTest.verify(VmMapperTest.java:109) > at > org.ovirt.engine.api.restapi.types.VmMapperTest.verify(VmMapperTest.java:26) > at > org.ovirt.engine.api.restapi.types.AbstractInvertibleMappingTest.testRoundtrip(AbstractInvertibleMappingTest.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47) > at org.junit.rules.RunRules.evaluate(RunRules.java:18) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) > at > org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) > at > org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) > at > org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107) > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68) > > > FAILED: > org.ovirt.engine.api.restapi.types.TemplateMapperTest.testRoundtrip > > Error Message: > expected:<true> but was:<false> > > Stack Trace: > java.lang.AssertionError: expected:<true> but was:<false> > at org.junit.Assert.fail(Assert.java:93) > at org.junit.Assert.failNotEquals(Assert.java:647) > at org.junit.Assert.assertEquals(Assert.java:128) > at org.junit.Assert.assertEquals(Assert.java:147) > at > org.ovirt.engine.api.restapi.types.TemplateMapperTest.verify(TemplateMapperTest.java:71) > at > org.ovirt.engine.api.restapi.types.TemplateMapperTest.verify(TemplateMapperTest.java:12) > at > org.ovirt.engine.api.restapi.types.AbstractInvertibleMappingTest.testRoundtrip(AbstractInvertibleMappingTest.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47) > at org.junit.rules.RunRules.evaluate(RunRules.java:18) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) > at > org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) > at > org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) > at > org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107) > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68) > > > > > ------------------ > Build Log: > ------------------ > [...truncated 4214 lines...] > [INFO] [INFO] Copying > artifact[jar:org.ovirt.engine.core:compat:3.2.0] > to[lib/engine-compat.jar] > [INFO] Copying artifact[jar:org.ovirt.engine.core:dal:3.2.0] > to[lib/engine-dal.jar] > [INFO] Copying artifact[jar:org.ovirt.engine.core:utils:3.2.0] > to[lib/engine-utils.jar] > [INFO] Copying > artifact[jar:org.ovirt.engine.core:engineencryptutils:3.2.0] > to[lib/engine-encryptutils.jar] > > [INFO] Copying artifact[jar:org.ovirt.engine.core:vdsbroker:3.2.0] > to[lib/engine-vdsbroker.jar] > [INFO] Copying artifact[war:org.ovirt.engine.core:root-war:3.2.0] > to[root.war] (unpacked) > [INFO] Copying artifact[war:org.ovirt.engine.ui:rmw-war:3.2.0] > to[ovirtengineweb.war] (unpacked) > [INFO] Copying > artifact[war:org.ovirt.engine.api:restapi-webapp:3.2.0] > to[restapi.war] (unpacked) > [INFO] Copying artifact[war:org.ovirt.engine.ui:userportal:3.2.0] > to[userportal.war] (unpacked) > [INFO] --- maven-ear-plugin:2.6:ear (default-ear) @ engine-server-ear > --- > [INFO] Copying artifact[war:org.ovirt.engine.ui:webadmin:3.2.0] > to[webadmin.war] (unpacked) > [INFO] Copying artifact[ejb:org.ovirt.engine.ui:genericapi:3.2.0] > to[engine-genericapi.jar] (unpacked) > [INFO] Copying artifact[ejb:org.ovirt.engine.core:scheduler:3.2.0] > to[engine-scheduler.jar] (unpacked) > [INFO] Copying artifact[ejb:org.ovirt.engine.core:bll:3.2.0] > to[engine-bll.jar] (unpacked) > [INFO] Copying artifact[jar:commons-codec:commons-codec:1.4] > to[lib/commons-codec-1.4.jar] > [INFO] Copying > artifact[jar:org.hibernate:hibernate-validator:4.0.2.GA] > to[lib/hibernate-validator-4.0.2.GA.jar] > [INFO] Copying artifact[jar:javax.validation:validation-api:1.0.0.GA] > to[lib/validation-api-1.0.0.GA.jar] > [INFO] Copying artifact[jar:org.slf4j:slf4j-api:1.5.6] > to[lib/slf4j-api-1.5.6.jar] > [INFO] Copying artifact[jar:javax.xml.bind:jaxb-api:2.1] > to[lib/jaxb-api-2.1.jar] > [INFO] Copying artifact[jar:javax.xml.stream:stax-api:1.0-2] > to[lib/stax-api-1.0-2.jar] > [INFO] Copying artifact[jar:javax.activation:activation:1.1] > to[lib/activation-1.1.jar] > [INFO] Copying artifact[jar:com.sun.xml.bind:jaxb-impl:2.1.3] > to[lib/jaxb-impl-2.1.3.jar] > [INFO] Copying > artifact[jar:org.hibernate:hibernate-annotations:3.4.0.GA] > to[lib/hibernate-annotations-3.4.0.GA.jar] > [INFO] Copying artifact[jar:org.hibernate:ejb3-persistence:1.0.2.GA] > to[lib/ejb3-persistence-1.0.2.GA.jar] > [INFO] Copying > artifact[jar:org.hibernate:hibernate-commons-annotations:3.1.0.GA] > to[lib/hibernate-commons-annotations-3.1.0.GA.jar] > [INFO] Copying artifact[jar:org.hibernate:hibernate-core:3.3.0.SP1] > to[lib/hibernate-core-3.3.0.SP1.jar] > [INFO] Copying artifact[jar:antlr:antlr:2.7.6] > to[lib/antlr-2.7.6.jar] > [INFO] Copying artifact[jar:dom4j:dom4j:1.6.1] > to[lib/dom4j-1.6.1.jar] > [INFO] Copying artifact[jar:xml-apis:xml-apis:1.0.b2] > to[lib/xml-apis-1.0.b2.jar] > [INFO] Copying > artifact[jar:org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.1_spec:1.0.0.Final] > to[lib/jboss-interceptors-api_1.1_spec-1.0.0.Final.jar] > [INFO] Copying > artifact[jar:org.ovirt.engine.core:engine-tools-common:3.2.0] > to[lib/engine-tools-common-3.2.0.jar] > [INFO] Copying > artifact[jar:commons-beanutils:commons-beanutils:1.8.2] > to[lib/commons-beanutils-1.8.2.jar] > [INFO] Copying artifact[jar:org.apache.mina:mina-core:2.0.1] > to[lib/mina-core-2.0.1.jar] > [INFO] Copying artifact[jar:org.apache.sshd:sshd-core:0.7.0] > to[lib/sshd-core-0.7.0.jar] > [INFO] Copying > artifact[jar:org.ovirt.otopi:otopi:0.0.0-master-20121216.120940-2] > to[lib/otopi-0.0.0-master-SNAPSHOT.jar] > [INFO] Copying > artifact[jar:org.ovirt.ovirt-host-deploy:ovirt-host-deploy:0.0.0-master-20121216.121130-2] > to[lib/ovirt-host-deploy-0.0.0-master-SNAPSHOT.jar] > [INFO] Copying artifact[jar:org.apache.commons:commons-compress:1.3] > to[lib/commons-compress-1.3.jar] > [INFO] Copying artifact[jar:commons-lang:commons-lang:2.4] > to[lib/commons-lang-2.4.jar] > [INFO] Copying artifact[jar:org.apache.xmlrpc:xmlrpc-client:3.1.3] > to[lib/xmlrpc-client-3.1.3.jar] > [INFO] Copying artifact[jar:org.apache.xmlrpc:xmlrpc-common:3.1.3] > to[lib/xmlrpc-common-3.1.3.jar] > [INFO] Copying > artifact[jar:org.apache.ws.commons.util:ws-commons-util:1.0.2] > to[lib/ws-commons-util-1.0.2.jar] > [INFO] Copying > artifact[jar:org.springframework:spring-jdbc:3.1.1.RELEASE] > to[lib/spring-jdbc-3.1.1.RELEASE.jar] > [INFO] Copying > artifact[jar:org.springframework:spring-tx:3.1.1.RELEASE] > to[lib/spring-tx-3.1.1.RELEASE.jar] > [INFO] Copying > artifact[jar:org.springframework.ldap:spring-ldap-core:1.3.1.RELEASE] > to[lib/spring-ldap-core-1.3.1.RELEASE.jar] > [INFO] Copying > artifact[jar:commons-httpclient:commons-httpclient:3.1] > to[lib/commons-httpclient-3.1.jar] > [INFO] Copying > artifact[jar:commons-collections:commons-collections:3.1] > to[lib/commons-collections-3.1.jar] > [INFO] Copying artifact[jar:org.quartz-scheduler:quartz:2.1.2] > to[lib/quartz-2.1.2.jar] > [INFO] Copying artifact[jar:c3p0:c3p0:0.9.1.1] > to[lib/c3p0-0.9.1.1.jar] > [INFO] Copying > artifact[jar:org.ovirt.engine.core:searchbackend:3.2.0] > to[lib/searchbackend-3.2.0.jar] > [INFO] Copying > artifact[jar:org.springframework:spring-core:3.1.1.RELEASE] > to[lib/spring-core-3.1.1.RELEASE.jar] > [INFO] Copying > artifact[jar:org.springframework:spring-asm:3.1.1.RELEASE] > to[lib/spring-asm-3.1.1.RELEASE.jar] > [INFO] Copying > artifact[jar:org.springframework:spring-beans:3.1.1.RELEASE] > to[lib/spring-beans-3.1.1.RELEASE.jar] > [INFO] Copying > artifact[jar:org.springframework:spring-context:3.1.1.RELEASE] > to[lib/spring-context-3.1.1.RELEASE.jar] > [INFO] Copying > artifact[jar:org.springframework:spring-aop:3.1.1.RELEASE] > to[lib/spring-aop-3.1.1.RELEASE.jar] > [INFO] Copying artifact[jar:aopalliance:aopalliance:1.0] > to[lib/aopalliance-1.0.jar] > [INFO] Copying > artifact[jar:org.springframework:spring-expression:3.1.1.RELEASE] > to[lib/spring-expression-3.1.1.RELEASE.jar] > [INFO] Copy ear sources to > /home/jenkins/workspace/ovirt_engine_unit_tests/ear/target/engine > [WARNING] resourcesDir is deprecated. Please use the > earSourceDirectory property instead. > [INFO] Copy ear resources to > /home/jenkins/workspace/ovirt_engine_unit_tests/ear/target/engine > [INFO] Including custom manifest > file[/home/jenkins/workspace/ovirt_engine_unit_tests/ear/target/engine/META-INF/MANIFEST.MF] > [INFO] Building jar: > /home/jenkins/workspace/ovirt_engine_unit_tests/ear/target/engine.ear > mojoSucceeded > org.apache.maven.plugins:maven-ear-plugin:2.6(default-ear) > mojoStarted > org.apache.maven.plugins:maven-dependency-plugin:2.1(copy-quartz-jar) > [INFO] > [INFO] --- maven-dependency-plugin:2.1:copy (copy-quartz-jar) @ > engine-server-ear --- > [INFO] Configured Artifact: org.quartz-scheduler:quartz:2.1.2:jar > mojoSucceeded > org.apache.maven.plugins:maven-dependency-plugin:2.1(copy-quartz-jar)[INFO] > Copying quartz-2.1.2.jar to > /home/jenkins/workspace/ovirt_engine_unit_tests/ear/target/quartz/quartz-2.1.2.jar > > [INFO] Installing > /home/jenkins/workspace/ovirt_engine_unit_tests/ear/target/engine.ear > to > /home/jenkins/workspace/ovirt_engine_unit_tests/.repository/org/ovirt/engine/engine-server-ear/3.2.0/engine-server-ear-3.2.0.ear > mojoStarted > org.apache.maven.plugins:maven-install-plugin:2.3.1(default-install) > [INFO] > [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ > engine-server-ear --- > [INFO] Installing > /home/jenkins/workspace/ovirt_engine_unit_tests/ear/pom.xml to > /home/jenkins/workspace/ovirt_engine_unit_tests/.repository/org/ovirt/engine/engine-server-ear/3.2.0/engine-server-ear-3.2.0.pom > mojoSucceeded > org.apache.maven.plugins:maven-install-plugin:2.3.1(default-install) > projectSucceeded org.ovirt.engine:engine-server-ear:3.2.0 > sessionEnded > [INFO] > ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > [INFO] oVirt Engine Root Project ......................... SUCCESS > [15:29.251s] > [INFO] oVirt Build Tools root ............................ SUCCESS > [26.004s] > [INFO] oVirt checkstyle .................................. SUCCESS > [7:05.769s] > [INFO] oVirt Checkstyle Checks ........................... SUCCESS > [41.919s] > [INFO] oVirt Modules - backend ........................... SUCCESS > [4.686s] > [INFO] oVirt Manager ..................................... SUCCESS > [7.793s] > [INFO] oVirt DB Scripts .................................. SUCCESS > [13.494s] > [INFO] oVirt Modules - manager ........................... SUCCESS > [57.659s] > [INFO] CSharp Compatibility .............................. SUCCESS > [1:24.773s] > [INFO] Encryption Libraries .............................. SUCCESS > [18.381s] > [INFO] oVirt Tools ....................................... SUCCESS > [10.515s] > [INFO] oVirt Tools Common Library ........................ SUCCESS > [15.192s] > [INFO] Common Code ....................................... SUCCESS > [1:18.121s] > [INFO] Common utilities .................................. SUCCESS > [1:51.096s] > [INFO] Data Access Layer ................................. SUCCESS > [1:04.478s] > [INFO] engine beans ...................................... SUCCESS > [1.877s] > [INFO] engine scheduler bean ............................. SUCCESS > [16.919s] > [INFO] Vds broker ........................................ SUCCESS > [32.755s] > [INFO] Search Backend .................................... SUCCESS > [27.715s] > [INFO] Backend Logic @Service bean ....................... SUCCESS > [2:03.757s] > [INFO] oVirt RESTful API Backend Integration ............. SUCCESS > [4.298s] > [INFO] oVirt RESTful API interface ....................... SUCCESS > [1.720s] > [INFO] oVirt Engine API Definition ....................... SUCCESS > [22.018s] > [INFO] oVirt Engine API Commom Parent POM ................ SUCCESS > [1.747s] > [INFO] oVirt Engine API Common JAX-RS .................... SUCCESS > [21.870s] > [INFO] oVirt RESTful API Backend Integration Type Mappers SUCCESS > [1:01.945s] > [INFO] oVirt RESTful API Backend Integration JAX-RS Resources > SUCCESS [2:10.153s] > [INFO] oVirt RESTful API Backend Integration Webapp ...... SUCCESS > [5:14.944s] > [INFO] oVirt Engine Web Root ............................. SUCCESS > [1:17.531s] > [INFO] oVirt Configuration Tool .......................... SUCCESS > [1:53.084s] > [INFO] Notifier Service package .......................... SUCCESS > [1.166s] > [INFO] Notifier Service .................................. SUCCESS > [27.529s] > [INFO] Notifier Service Resources ........................ SUCCESS > [18.911s] > [INFO] oVirt Modules - frontend .......................... SUCCESS > [3.358s] > [INFO] oVirt APIs ........................................ SUCCESS > [20.346s] > [INFO] oVirt generic API ................................. SUCCESS > [1:16.903s] > [INFO] oVirt Modules - webadmin .......................... SUCCESS > [2.160s] > [INFO] oVirt Modules - ui ................................ SUCCESS > [6.200s] > [INFO] Extensions for GWT ................................ SUCCESS > [21.327s] > [INFO] UI Utils Compatibility (for UICommon) ............. SUCCESS > [18.965s] > [INFO] Frontend for GWT UI Projects ...................... SUCCESS > [46.618s] > [INFO] UICommonWeb ....................................... SUCCESS > [2:11.624s] > [INFO] oVirt GWT UI common infrastructure ................ SUCCESS > [1:17.131s] > [INFO] WebAdmin .......................................... SUCCESS > [45.318s] > [INFO] UserPortal ........................................ SUCCESS > [19.200s] > [INFO] oVirt WARs ........................................ SUCCESS > [1.798s] > [INFO] oVirt Web Application Module ...................... SUCCESS > [6.787s] > [INFO] oVirt Server EAR .................................. SUCCESS > [24.517s] > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD SUCCESS > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 58:53.824s > [INFO] Finished at: Thu Dec 27 08:52:59 CET 2012 > [INFO] Final Memory: 213M/612M > [INFO] > ------------------------------------------------------------------------ > Projects to build: [MavenProject: org.ovirt.engine:root:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/pom.xml, > MavenProject: org.ovirt.engine:build-tools-root:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/build-tools-root/pom.xml, > MavenProject: org.ovirt.engine:checkstyles:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/build-tools-root/checkstyles/pom.xml, > MavenProject: org.ovirt.engine:ovirt-checkstyle-extension:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/build-tools-root/ovirt-checkstyle-extension/pom.xml, > MavenProject: org.ovirt.engine.core:backend:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/pom.xml, > MavenProject: org.ovirt.engine.core:manager:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/pom.xml, > MavenProject: org.ovirt.engine.core:dbscripts:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/dbscripts/pom.xml, > MavenProject: org.ovirt.engine.core:manager-modules:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/pom.xml, > MavenProject: org.ovirt.engine.core:compat:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/compat/pom.xml, > MavenProject: org.ovirt.engine.core:engineencryptutils:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/engineencryptutils/pom.xml, > MavenProject: org.ovirt.engine.core:manager-tools:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/pom.xml, > MavenProject: org.ovirt.engine.core:engine-tools-common:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-tools-common/pom.xml, > MavenProject: org.ovirt.engine.core:common:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/common/pom.xml, > MavenProject: org.ovirt.engine.core:utils:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/utils/pom.xml, > MavenProject: org.ovirt.engine.core:dal:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/dal/pom.xml, > MavenProject: org.ovirt.engine.core:beans:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/beans/pom.xml, > MavenProject: org.ovirt.engine.core:scheduler:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/beans/scheduler/pom.xml, > MavenProject: org.ovirt.engine.core:vdsbroker:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/vdsbroker/pom.xml, > MavenProject: org.ovirt.engine.core:searchbackend:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/searchbackend/pom.xml, > MavenProject: org.ovirt.engine.core:bll:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/bll/pom.xml, > MavenProject: org.ovirt.engine.api:restapi-parent:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/pom.xml, > MavenProject: org.ovirt.engine.api:interface:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/pom.xml, > MavenProject: org.ovirt.engine.api:restapi-definition:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/definition/pom.xml, > MavenProject: org.ovirt.engine.api:common-parent:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/common/pom.xml, > MavenProject: org.ovirt.engine.api:interface-common-jaxrs:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/common/jaxrs/pom.xml, > MavenProject: org.ovirt.engine.api:restapi-types:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/types/pom.xml, > MavenProject: org.ovirt.engine.api:restapi-jaxrs:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/jaxrs/pom.xml, > MavenProject: org.ovirt.engine.api:restapi-webapp:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/webapp/pom.xml, > MavenProject: org.ovirt.engine.core:root-war:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/root/pom.xml, > MavenProject: org.ovirt.engine.core:engine-config:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-config/pom.xml, > MavenProject: org.ovirt.engine.core:engine-notifier:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-notifier/pom.xml, > MavenProject: org.ovirt.engine.core:engine-notifier-service:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-notifier/engine-notifier-service/pom.xml, > MavenProject: org.ovirt.engine.core:engine-notifier-resources:3.2.0 > @ > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-notifier/engine-notifier-resources/pom.xml, > MavenProject: org.ovirt.engine.ui:frontend-all:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/pom.xml, > MavenProject: org.ovirt.engine.ui:api:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/api/pom.xml, > MavenProject: org.ovirt.engine.ui:genericapi:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/api/genericapi/pom.xml, > MavenProject: org.ovirt.engine.ui:webadmin-all:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/pom.xml, > MavenProject: org.ovirt.engine.ui:webadmin-modules:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/pom.xml, > MavenProject: org.ovirt.engine.ui:gwt-extension:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/gwt-extension/pom.xml, > MavenProject: org.ovirt.engine.ui:uicompat:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/uicompat/pom.xml, > MavenProject: org.ovirt.engine.ui:frontend:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/frontend/pom.xml, > MavenProject: org.ovirt.engine.ui:uicommonweb:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/uicommonweb/pom.xml, > MavenProject: org.ovirt.engine.ui:gwt-common:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/gwt-common/pom.xml, > MavenProject: org.ovirt.engine.ui:webadmin:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/webadmin/pom.xml, > MavenProject: org.ovirt.engine.ui:userportal:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/userportal-gwtp/pom.xml, > MavenProject: org.ovirt.engine.ui:wars:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/wars/pom.xml, > MavenProject: org.ovirt.engine.ui:rmw-war:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/wars/rmw-war/pom.xml, > MavenProject: org.ovirt.engine:engine-server-ear:3.2.0 @ > /home/jenkins/workspace/ovirt_engine_unit_tests/ear/pom.xml] > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/beans/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/uicommonweb/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/uicommonweb/target/uicommonweb-3.2.0.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/uicommonweb/target/uicommonweb-3.2.0-tests.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/uicommonweb/target/uicommonweb-3.2.0-sources.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/root/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/root/target/root-war-3.2.0.war > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/webapp/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/webapp/target/restapi-webapp-3.2.0.war > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-tools-common/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-tools-common/target/engine-tools-common-3.2.0.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-tools-common/target/engine-tools-common-3.2.0-tests.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-notifier/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/common/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/common/target/common-3.2.0.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/common/target/common-3.2.0-tests.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/common/target/common-3.2.0-sources.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/gwt-common/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/gwt-common/target/gwt-common-3.2.0.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/gwt-common/target/gwt-common-3.2.0-tests.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/wars/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/build-tools-root/checkstyles/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/build-tools-root/checkstyles/target/checkstyles-3.2.0.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/build-tools-root/checkstyles/target/checkstyles-3.2.0-tests.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/beans/scheduler/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/beans/scheduler/target/scheduler-3.2.0.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/beans/scheduler/target/scheduler-3.2.0-client.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-config/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-config/target/engine-config-3.2.0.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-config/target/engine-config-3.2.0-tests.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-notifier/engine-notifier-resources/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-notifier/engine-notifier-resources/target/engine-notifier-resources-3.2.0.zip > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/api/genericapi/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/api/genericapi/target/genericapi-3.2.0.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/api/genericapi/target/genericapi-3.2.0-client.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/api/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/engineencryptutils/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/engineencryptutils/target/engineencryptutils-3.2.0.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/engineencryptutils/target/engineencryptutils-3.2.0-tests.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-notifier/engine-notifier-service/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-notifier/engine-notifier-service/target/engine-notifier-service-3.2.0.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-notifier/engine-notifier-service/target/engine-notifier-service-3.2.0-tests.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/utils/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/utils/target/utils-3.2.0.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/utils/target/utils-3.2.0-tests.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/common/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/definition/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/definition/target/restapi-definition-3.2.0.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/definition/target/restapi-definition-3.2.0-tests.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/types/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/types/target/restapi-types-3.2.0.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/types/target/restapi-types-3.2.0-tests.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/uicompat/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/uicompat/target/uicompat-3.2.0.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/uicompat/target/uicompat-3.2.0-tests.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/build-tools-root/ovirt-checkstyle-extension/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/build-tools-root/ovirt-checkstyle-extension/target/ovirt-checkstyle-extension-3.2.0.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/build-tools-root/ovirt-checkstyle-extension/target/ovirt-checkstyle-extension-3.2.0-tests.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/jaxrs/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/jaxrs/target/restapi-jaxrs-3.2.0.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/jaxrs/target/restapi-jaxrs-3.2.0-tests.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/frontend/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/frontend/target/frontend-3.2.0.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/frontend/target/frontend-3.2.0-tests.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/wars/rmw-war/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/wars/rmw-war/target/rmw-war-3.2.0.war > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/dal/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/dal/target/dal-3.2.0.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/dal/target/dal-3.2.0-tests.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/ear/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/ear/target/engine.ear > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/webadmin/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/webadmin/target/webadmin-3.2.0.war > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/searchbackend/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/searchbackend/target/searchbackend-3.2.0.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/searchbackend/target/searchbackend-3.2.0-tests.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/searchbackend/target/searchbackend-3.2.0-sources.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/gwt-extension/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/gwt-extension/target/gwt-extension-3.2.0.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/gwt-extension/target/gwt-extension-3.2.0-tests.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/gwt-extension/target/gwt-extension-3.2.0-sources.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/build-tools-root/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/compat/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/compat/target/compat-3.2.0.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/compat/target/compat-3.2.0-tests.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/compat/target/compat-3.2.0-sources.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/common/jaxrs/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/common/jaxrs/target/interface-common-jaxrs-3.2.0.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/common/jaxrs/target/interface-common-jaxrs-3.2.0-tests.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/userportal-gwtp/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/userportal-gwtp/target/userportal-3.2.0.war > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/vdsbroker/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/vdsbroker/target/vdsbroker-3.2.0.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/vdsbroker/target/vdsbroker-3.2.0-tests.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/bll/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/bll/target/bll-3.2.0.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/bll/target/bll-3.2.0-client.jar > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/pom.xml > [JENKINS] Archiving disabled - not archiving > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/dbscripts/pom.xml > Waiting for Jenkins to finish collecting data > channel stopped > IRC notifier plugin: Sending notification to: #ovirt-jenkins > Email was triggered for: Unstable > Sending email for trigger: Unstable >

2 2

[Engine-devel] lastest source from gerrit fails to complete tests successfully.
by snmishra＠linux.vnet.ibm.com 26 Dec '12

26 Dec '12

Hi, I am seeing following test fail - Running org.ovirt.engine.api.restapi.types.VmMapperTest Tests run: 44, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 6.136 sec <<< FAILURE! Results : Failed tests: testRoundtrip(org.ovirt.engine.api.restapi.types.TemplateMapperTest): expected:<true> but was:<false> testRoundtrip(org.ovirt.engine.api.restapi.types.VmMapperTest): expected:<true> but was:<false> Tests run: 101, Failures: 2, Errors: 0, Skipped: 0 *********** started seeing this error in last 24 hours. Was working yesterday. Sharad Mishra

2 1

[Engine-devel] Read Only Disk Feature
by Vered Volansky 24 Dec '12

24 Dec '12

Hi all, This is the wiki page for the new read-only disks feature in the engine: http://www.ovirt.org/Features/Read_Only_Disk Comments are welcome. Thanks, Vered

1 0

[Engine-devel] Problems with ovirt gerrit?
by Yair Zaslavsky 23 Dec '12

23 Dec '12

Hi, I see that git fetch -v (or git fetch) get stuck. I saw Maor and Yaniv Bronheim suffer from same issue Can someone please be of aid and fix this? Yair

2 1

[Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.
by Michael Pasternak 23 Dec '12

23 Dec '12

Hi All, In many cases OSS maintainers not always can be in the loop of different threads what may cause them missing important decisions being taken, As result later on during reviews of the patches they're not accepting (already implemented) features, what is causing not once for feature to be re-designed and/or delayed, what is wrong from the development cycle PoV. Therefore I'd like to suggest establishing dev-rules for the new feature implementation, what will make entire process much more easer for all of us: 1. discuss new feature on the mailing list (requirements/constraints/etc.) 2. summarise feature details in feature-doc 3. send feature-doc to review to: 3.1 ML (engine-devel) 3.2 MG (mailing group of maintainers of the relevant layers) 4. after feature-doc is accepted, 4.1 implement the feature 4.2 send it to gerrit for review to: 4.2.1 lead maintainer/s (they will review/delegate it) NOTE 3.2, 4.2.1 will require defining MGs such as: - engine-devel-core - engine-devel-ui - engine-devel-api - engine-devel-sdk - engine-devel-cli - engine-devel-vdsm ... Thoughts? -- Michael Pasternak RedHat, ENG-Virtualization R&D -- Michael Pasternak RedHat, ENG-Virtualization R&D

3 15

[Engine-devel] CPU Overcommit Feature
by Greg Padgett 20 Dec '12

20 Dec '12

Hi, I've been working on a feature to allow CPU Overcommitment of hosts in a cluster. This first stage allows the engine to consider host cpu threads as cores for the purposes of VM resource allocation. This wiki page has further details, your comments are welcome! http://www.ovirt.org/Features/cpu_overcommit Thanks in advance, Greg

7 18

[Engine-devel] oVirt-Foreman UI plugin
by Oved Ourfalli 20 Dec '12

20 Dec '12

Hey all, I've been working on an oVirt-Foreman UI-plugin recently, using oVirt's new UI-plugin infrastructure. It allows users to see Foreman data on oVirt entities, from inside Webadmin. I wrote a blog post describing this plugin, what can he do, some challenges that I faced and solutions, some screenshots, future work and more. Check it out at: ovedou.blogpost.com I'll be happy to hear your feedback both on the blog and on the plugin itself! If you need help installing the plugin feel free to contact me :-) Cheers, Oved

3 4

[Engine-devel] Proposal to add Shireesh Anjal as maintainer to engine-gluster
by Itamar Heim 20 Dec '12

20 Dec '12

Shireesh has been working on the engine gluster support for the past year, covering patches and leading reviews of the various engine gluster patches. I'd like to propose a new sub-component of the engine for the gluster module, adding shireesh as its maintainer. Thanks, Itamar

5 5

[Engine-devel] LDAP: Add support for simple authentication over SSL
by snmishra＠linux.vnet.ibm.com 19 Dec '12

19 Dec '12

Hi, IBM Tivoli Directory Server (ITDS) supports simple authentication over SSL. What will it take to add this support? I can help with this work item but will need some guidance. Regards Sharad Mishra

2 4

[Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.
by Michael Pasternak 19 Dec '12

19 Dec '12

Hi All, In many cases OSS maintainers not always can be in the loop of different threads what may cause them missing important decisions being taken, As result later on during reviews of the patches they're not accepting (already implemented) features, what is causing not once for feature to be re-designed and/or delayed, what is wrong from the development cycle PoV. Therefore I'd like to suggest establishing dev-rules for the new feature implementation, what will make entire process much more easer for all of us: 1. discuss new feature on the mailing list (requirements/constraints/etc.) 2. summarise feature details in feature-doc 3. send feature-doc to review to: 3.1 ML (engine-devel) 3.2 MG (mailing group of maintainers of the relevant layers) 4. after feature-doc is accepted, 4.1 implement the feature 4.2 send it to gerrit for review to: 4.2.1 lead maintainer/s (they will review/delegate it) NOTE 3.2, 4.2.1 will require defining MGs such as: - engine-devel-core - engine-devel-ui - engine-devel-api - engine-devel-sdk - engine-devel-cli - engine-devel-vdsm ... Thoughts? -- Michael Pasternak RedHat, ENG-Virtualization R&D

1 0

[Engine-devel] Revisiting Java7
by Allon Mureinik 18 Dec '12

18 Dec '12

Hi guys, Earlier today, Java6 compatibility was broken (http://gerrit.ovirt.org/#/c/9430/) This was picked up on pretty quickly, and easily fixed (http://gerrit.ovirt.org/#/c/9666/) However, I think this is a good opportunity to revisit our policy towards Java 7. Currently, we have an "odd" setup, where we recommend running a compiling /with/ Java 7 [1] but comply to Java 6 language level [2] and JDK [3]. Inevitably, mistakes like the that happened today will happen. I know we're holding back due to GWT issues, but looking forward to oVirt 4.0, is Java 7 on our roadmap? -Allon [1] http://wiki.ovirt.org/Building_oVirt_engine#Installing_OpenJDK [2] maven-compiler-plugin section in ${OVIRT_GIT}/pom.xml [3] http://jenkins.ovirt.org/job/ovirt_engine_animal_sniffer_check/ P.S. If you want to check that you aren't breaking Java/JDK 6 compatibility locally without installing java 6, you can run "mvn animal-sniffer:check". Note that animal sniffer analyzes binaries, so this has to be done /after/ the project was built. Of course, you can do this in a single line "mvn install animal-sniffer:check"

7 10

[Engine-devel] [Draft]Task Management API
by Saggi Mizrahi 18 Dec '12

18 Dec '12

Dan rightly suggested I'd be more specific about what the task system is instead of what the task system isn't. The problem is that I'm not completely sure how it's going to work. It also depends on the events mechanism. This is my current working draft: TaskInfo: id string methodName string kwargs json-object (string keys variant values) *filtered to remove sensitive information getRunningTasks(filter string, filterType enum{glob, regexp}) Returns a list of TaskInfo of all tasks that their id's match the filter That's it, not even stopTask() As explained, I would like to offload handling to the subsystems. In order to make things easier for the clients every subsystem can choose a filed of the object to be of type OperationInfo. This is a generic structure that the user has a generic way to track all tasks on all subsystem with a report interface. The extraData field is for subsystem specific data. This is where the storage subsystem would put, for example, imageState (broken, degraded, optimized) data. OperationInfo: operationDescription string - something out of an agreed enum of strings vaguely describing the operation at hand for example "Copying", "Merging", "Deleting", "Configuring", "Stopped", "Paused", .... They must be known to the client so it can in turn translate it in the UI. The also have to remain relatively vague as they are part of the interface meaning that new values will break old clients so they have to be reusable. stageDescription - Similar to operation description in case you want more granularity, optional. stage (int, int) - (5, 10) means 5 out of 10. 1 out of 1 implies the UI to not display stage widgets. percentage - 0-100, -1 means unknown. lastError - (code, message) the same errors that can return for regular calls extraData - json-object For example creatVM will return once the object is created in VDSM. getVmInfo() would return, amongst other things, the operation info. For the case of preparing for launch it will be: {"Creating", "configuring", (2, 4), 40, (0, ""), {state="preparing for launch"}} In the case of VM paused on EIO: {"Paused", "Paused", (1, 1), -1, (123, "Error writing to disks"), {state="paused"}} Migration is a tricky one, it will be reported as a task while it's in progress but all the information is available on the image operationInfo. In the case of Migration: {"Migration", "Configuring", (1, 3), -1, (0, ""), {status="Migrating"}} For StorageConnection this is somewhat already the case but in simplified version. If you want to ask about any other operation I'd be more then happy to write my suggestion for it. Subsystems have complete freedom about how to set up the API. For Storage you have Fixes() to start\stop operations. Gluster is pretty autonomous once operations have been started. Since operations return as soon as they are registered (persisted) or fail to register, it makes synchronous programming a bit clunky. vdsm.pauseVm(vmId) doesn't return when the VM is paused but when VDSM committed it will try to pause it. This means you will have to poll in order to see if the operation finished. For gluster, as an example, this is the only way we can check that the operation finished. For stuff we have a bit more control over vdsm will fire events using json-rpc notifications sent to the clients. The will be in the form of: {"method": "alert", "params": { "alertName": <subsystem>(.<objectType>)?.<object>.(<subobject>., ...), "operationInfo", OperationInfo} } The user can register to recive events using a glob or a regexp. registering to vdsm.VM.* pop every time any VM has changed stage. This means that whenever the task finishes, fails or gains significance progress and VDSM is there to track it, an event will be sent to the client. This means that the general flow is. # Register operation vmID = best_vm host.VM.pauseVM(vmID) while True: opInfo = None try: event = host.waitForEvent("vdsm.VM.best_vm", timeout=10) opInfo = event.opInfo except VdsmDisconnectionError: host.waitForReconnect() host.vm.getVmInfo(vmID) # Double check that we didn't miss the event continue except Timeout: # This is a long operation, poll to see that we didn't miss any event # but more commonly, update percentage in the UI to show progress. vmInfo = host.vm.getVmInfo(vmID) opInfo = vmInfo.operationInfo if opInfo.stage.number != op.stage.total: # Operation in progress updateUI(opInfo) else: # Operation completed # Check that the state is what we expected it to be. if oInfo.extraData.state == "paused": return SUCCESS else: return opInfo.lastError vdsm.waitForEvent(filterm, timeout) is a client side libvdsm helper operation. Clients that access the raw API need to create thir own client side code to filter out events and manage their distribution. I'm open to also defining server side filters but I'm not sure whether it's worth it or just having it be a boolean (all events or none) is sufficient. This is a very simplified example but the general flow is clear. Even if the connection is lost for 1 second or 4 days, the code still works. Further more, the user can wait for multiple operations in the same thread using: host.waitForEvent("vdsm.VM.(best_vm_ever|not_so_good_vm)") This means that the client can wait for a 100 VMs or all VMs (using wildecards) in a mechanism similar "poll()" with minimal overhead. This also means that if The fact that operations are registered means that even if connections is lost due to VDSM crashing or the network crashing, the manager doesn't need to care one the original command returns as it know the operation registered. This doesn't mean that every operation must retry forever. How persistent every method is can and should change between the different operations. Also, it means that manager that didn't initiate an operation track it in the same way as those that did. This makes clustered managers a lot easier to implement as if one goes down a second one can more or less immediately with minimal extra code.

2 1

[Engine-devel] Managing async tasks
by Adam Litke 17 Dec '12

17 Dec '12

On today's vdsm call we had a lively discussion around how asynchronous operations should be handled in the future. In an effort to include more people in the discussion and to better capture the resulting conversation I would like to continue that discussion here on the mailing list. A lot of ideas were thrown around about how 'tasks' should be handled in the future. There are a lot of ways that it can be done. To determine how we should implement it, it's probably best if we start with a set of requirements. If we can first agree on these, it should be easy to find a solution that meets them. I'll take a stab at identifying a first set of POSSIBLE requirements: - Standardized method for determining the result of an operation This is a big one for me because it directly affects the consumability of the API. If each verb has different semantics for discovering whether it has completed successfully, then the API will be nearly impossible to use easily. Sorry. That's my list :) Hopefully others will be willing to add other requirements for consideration. >From my understanding, task recovery (stop, abort, rollback, etc) will not be generally supported and should not be a requirement. -- Adam Litke <agl(a)us.ibm.com> IBM Linux Technology Center

3 7

Re: [Engine-devel] [vdsm] Host bios information
by Barak Azulay 16 Dec '12

16 Dec '12

----- Original Message ----- > From: "Ayal Baron" <abaron(a)redhat.com> > To: "Saggi Mizrahi" <smizrahi(a)redhat.com> > Cc: "VDSM Project Development" <vdsm-devel(a)lists.fedorahosted.org> > Sent: Friday, December 14, 2012 2:07:04 AM > Subject: Re: [vdsm] Host bios information > > > > ----- Original Message ----- > > > > > > ----- Original Message ----- > > > From: "Ayal Baron" <abaron(a)redhat.com> > > > To: "Saggi Mizrahi" <smizrahi(a)redhat.com> > > > Cc: "VDSM Project Development" > > > <vdsm-devel(a)lists.fedorahosted.org>, > > > "Shu Ming" <shuming(a)linux.vnet.ibm.com> > > > Sent: Thursday, December 13, 2012 11:30:56 AM > > > Subject: Re: [vdsm] Host bios information > > > > > > > > > > > > ----- Original Message ----- > > > > I think that for the new current XML-RPC API it's OK to add it > > > > to > > > > the > > > > getVdsCaps() verb. > > > > For the new API I suggest moving it to it's own API. The > > > > smaller > > > > the > > > > APIs the easier they are to deprecate and support. > > > > I quite doubt the fields in getBiosInfo() will change half as > > > > frequently as whatever getVdsCaps() returns. > > > > I also kind of want to throw away getVdsCaps() and split it to > > > > better > > > > named better encapsulated methods. > > > > > > Ack. I just don't understand why not start right now? > > > Any new patch should improve things at least a little. > > > We know getVdsCaps() is wrong so let's put the bios info (and > > > anything in getVdsCaps that makes sense to put with it if > > > relevant) > > > in a separate call. Adding a call in engine to this new method > > > should be a no brainer, I don't think that is a good reason for > > > not > > > doing things properly in vdsm, even if we're talking about the > > > current API. > > Well, from what I know the current overhead per call is too large > > to > > mandate a lot of calls. > > At least that is what I've been told. If that is not an issue, do > > it > > in the XML-RPC API too. > > if you call it every 2 seconds to each host then perhaps, but > getVdsCaps is called in initvdsonup which is pretty rare (hours, > days or more) so avoiding an extra call there seems wrong to me. I totally agree that in the long run it is correct to add a different API on vdsm, However for the initial 6 bios params: 1. Host Manufacturer - Manufacturer of the host's machine and bios' vendor (e.g LENOVO) 2. Host Version - For each host the manufacturer gives a unique name (e.g. Lenovo T420s) 3. Host Product Name - ID of the product - same for all similar products (e.g 4174BH4) 4. Host UUID - Unique ID for each host (e.g E03DD601-5219-11CB-BB3F-892313086897) 5. Host Family - Type of host's CPU - (e.g Core i5) 6. Host Serial Number - Unique ID for host's chassis (e.g R9M4N4G) As Dan stated below, is o.k. for this specific phase to add them to getVdsCaps So I suggest: 1 Adding the above 6 above params to getVdsCaps 2 Add a new API to vdsm to retrieve host bios information - that will eventually return the entire list (current will retrieve the exact 6 params and will use the same underlying implementation) 3 In the future engine will start using the new API Start using the new API now on the engine side will require much more testing as it might have an influence on the host state machine. Thanks Barak Azulay > > > > > > > > > > > > Also, in the json-rpc base model, calls are not only cheaper, > > > > you > > > > also have batch calls. This means you can send multiple > > > > requests > > > > as > > > > one message and have VDSM send you the responses as one message > > > > once > > > > all tasks completed. This makes splitting aggregated methods to > > > > smaller methods painless and with minimal overhead. > > > > > > > > ----- Original Message ----- > > > > > From: "Shu Ming" <shuming(a)linux.vnet.ibm.com> > > > > > To: "ybronhei" <ybronhei(a)redhat.com> > > > > > Cc: "VDSM Project Development" > > > > > <vdsm-devel(a)lists.fedorahosted.org> > > > > > Sent: Thursday, December 13, 2012 11:04:09 AM > > > > > Subject: Re: [vdsm] Host bios information > > > > > > > > > > After a quick review of the wiki page, it was stated that > > > > > dmidecode > > > > > gave > > > > > too much informations. Only five fields will be displayed in > > > > > the > > > > > hardware tab, "Manufactory", "Version", "Family", "UUID" and > > > > > "serial > > > > > number". For "Family", it is mean the CPU core's family. > > > > > And > > > > > it > > > > > confuses me a bit with the "CPU name" and "CPU type" fields > > > > > in > > > > > general > > > > > tab. I think we should chose the best one to characterizethe > > > > > CPU > > > > > type. > > > > > > > > > > > > > > > ybronhei: > > > > > > Today in the Api we display general information about the > > > > > > host > > > > > > that > > > > > > vdsm export by getCapabilities Api. > > > > > > > > > > > > We decided to add bios information as part of the > > > > > > information > > > > > > that > > > > > > is > > > > > > displayed in UI under host's general sub-tab. > > > > > > > > > > > > To summaries the feature - We'll modify General tab to > > > > > > Software > > > > > > Information and add another tab for Hardware Information > > > > > > which > > > > > > will > > > > > > include all the bios data that we'll decide to gather from > > > > > > the > > > > > > host > > > > > > and display. > > > > > > > > > > > > Following this feature page: > > > > > > http://www.ovirt.org/Features/Design/HostBiosInfo for more > > > > > > details. > > > > > > All the parameters that can be displayed are mentioned in > > > > > > the > > > > > > wiki. > > > > > > > > > > > > I would greatly appreciate your comments and questions. > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > > > > > > > -- > > > > > --- > > > > > 舒明 Shu Ming > > > > > Open Virtualization Engineerning; CSTL, IBM Corp. > > > > > Tel: 86-10-82451626 Tieline: 9051626 E-mail: > > > > > shuming(a)cn.ibm.com > > > > > or > > > > > shuming(a)linux.vnet.ibm.com > > > > > Address: 3/F Ring Building, ZhongGuanCun Software Park, > > > > > Haidian > > > > > District, Beijing 100193, PRC > > > > > > > > > > > > > > > _______________________________________________ > > > > > vdsm-devel mailing list > > > > > vdsm-devel(a)lists.fedorahosted.org > > > > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > > > > > > > > _______________________________________________ > > > > vdsm-devel mailing list > > > > vdsm-devel(a)lists.fedorahosted.org > > > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > > > > > > > > > _______________________________________________ > vdsm-devel mailing list > vdsm-devel(a)lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel >

3 2

[Engine-devel] VDSM tasks, the future
by Saggi Mizrahi 16 Dec '12

16 Dec '12

Because I started hinting about how VDSM tasks are going to look going forward I thought it's better I'll just write everything in an email so we can talk about it in context. This is not set in stone and I'm still debating things myself but it's very close to being done. - Everything is asynchronous. The nature of message based communication is that you can't have synchronous operations. This is not really debatable because it's just how TCP\AMQP\<messaging> works. - Task IDs will be decided by the caller. This is how json-rpc works and also makes sense because no the engine can track the task without needing to have a stage where we give it the task ID back. IDs are reusable as long as no one else is using them at the time so they can be used for synchronizing operations between clients (making sure a command is only executed once on a specific host without locking). - Tasks are transient If VDSM restarts it forgets all the task information. There are 2 ways to have persistent tasks: 1. The task creates an object that you can continue work on in VDSM. The new storage does that by the fact that copyImage() returns one the target volume has been created but before the data has been fully copied. From that moment on the stat of the copy can be queried from any host using getImageStatus() and the specific copy operation can be queried with getTaskStatus() on the host performing it. After VDSM crashes, depending on policy, either VDSM will create a new task to continue the copy or someone else will send a command to continue the operation and that will be a new task. 2. VDSM tasks just start other operations track-able not through the task interface. For example Gluster. gluster.startVolumeRebalance() will return once it has been registered with Gluster. glster.getOperationStatuses() will return the state of the operation from any host. Each call is a task in itself. - No task tags. They are silly and the caller can mangle whatever in the task ID if he really wants to tag tasks. - No explicit recovery stage. VDSM will be crash-only, there should be efforts to make everything crash-safe. If that is problematic, in case of networking, VDSM will recover on start without having a task for it. - No clean Task: Tasks can be started by any number of hosts this means that there is no way to own all tasks. There could be cases where VDSM starts tasks on it's own and thus they have no owner at all. The caller needs to continually track the state of VDSM. We will have brodcasted events to mitigate polling. - No revert Impossible to implement safely. - No SPM\HSM tasks SPM\SDM is no longer necessary for all domain types (only for type). What used to be SPM tasks, or tasks that persist and can be restarted on other hosts is talked about in previous bullet points.

4 5

[Engine-devel] Creating New Data-Center and Permission on Network
by Moti Asayag 16 Dec '12

16 Dec '12

Hi, When creating a new data-center, a management network is created for it. By default the created management network is defined as VM network. I'd like to consult from permissions perspective, what is the preferred permission settings for that network. The network is defined as management network, therefore it is designed be used by VMs. However, the admin should grant permissions on that networks to the target users (which one might find tedious). We can grant permission on that network to 'everyone' with role 'NetworkUser', but in case the admin doesn't meant this network to be used, the permission should be removed. In 'Add Logical Network' dialog I've added a new checkbox to allow granting 'everyone' a role for using that network ('NetworkUser'). We can embrace same method in 'Add Data-Center' dialog. Thoughts ? Thanks, Moti

2 1

[Engine-devel] ThreadPoolUtil with 500 threads and no queue?
by Juan Hernandez 16 Dec '12

16 Dec '12

Hello all, What is the reasoning behind the decision to have a pool with a maximum of 500 threads and no job queue (see ThreadPoolUtil.java)? Wouldn't it make more sense to have a much smaller thread pool and a potentially large queue of jobs? Regards, Juan Hernandez -- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.

3 4