February 2013 - 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] Error building ovirt engine rpm.
by snmishra＠linux.vnet.ibm.com 10 Feb '13

10 Feb '13

Hi, I tried building an ovirt engine RPM for the first time on my Fedora17 machine using the wiki instructions. I get the following error - # make rpm sed -e 's/@PACKAGE_VERSION@/3.3.0/g' \ -e 's/@PACKAGE_RELEASE@/0.1.20130208174746/g' packaging/fedora/spec/ ovirt-engine.spec.in > ovirt-engine.spec git ls-files | tar --files-from /proc/self/fd/0 -czf ovirt-engine-3.3.0.tar.gz o virt-engine.spec rm -f ovirt-engine.spec You can use rpmbuild -tb ovirt-engine-3.3.0.tar.gz to produce rpms rm -rf /home/guest/ovirt-engine/tmp.rpmbuild mkdir -p /home/guest/ovirt-engine/tmp.rpmbuild/{SPECS,RPMS,SRPMS,SOURCES,BUILD,B UILDROOT} mkdir -p output rpmbuild -ts --define="_topdir /home/guest/ovirt-engine/tmp.rpmbuild" ovirt-engi ne-3.3.0.tar.gz Wrote: /home/guest/ovirt-engine/tmp.rpmbuild/SRPMS/ovirt-engine-3.3.0-0.1.201302 08174746.fc17.src.rpm mv /home/guest/ovirt-engine/tmp.rpmbuild/SRPMS/*.rpm output rm -rf /home/guest/ovirt-engine/tmp.rpmbuild srpm is ready at output rm -rf /home/guest/ovirt-engine/tmp.rpmbuild mkdir -p /home/guest/ovirt-engine/tmp.rpmbuild/{SPECS,RPMS,SRPMS,SOURCES,BUILD,B UILDROOT} mkdir -p output rpmbuild --define="_topdir /home/guest/ovirt-engine/tmp.rpmbuild" --rebuild out put/ovirt-engine-3.3.0*.src.rpm Installing output/ovirt-engine-3.3.0-0.1.20130208172931.fc17.src.rpm error: Failed build dependencies: ovirt-host-deploy-java is needed by ovirt-engine-3.3.0-0.1.2013020817293 1.fc17.noarch make: *** [rpm] Error 1 -Sharad

2 2

[Engine-devel] Import/snapshots duplicate MAC support
by Mike Kolesnik 10 Feb '13

10 Feb '13

------=_Part_14223209_123477223.1360131191449 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, The current situation dictates that if the configuration value AllowDuplicateMacAddresses is set to false (this is the default setting), then we block import or switching snapshots where a MAC address in one or more of the snapshot/ovf's virtual NICs is already used. Given that we don't currently give the admin any option to select otherwise, I'm not sure that's a very robust behaviour.. First of all the MAC address should be unique per network and not in the whole system (like it is currently). Furthermore, as long as in the same network there are no two virtual NIC s running with the same address, it is not such a bad situation. Therefore, I would like to propose a couple of solutions (from backend perspective): 1. Keep blocking. 2. Keep blocking but fix the mac pools to be per network basis. 3. Don't block, and allow duplicate MACs in these scenarios, but block on activating a NIC with duplicate MAC address. Warn the user that the NIC is with duplicate MAC, and perhaps even unplug or unwire it so that it would be obvious that it's using someone else's MAC. 4. Don't block, and give the problematic NIC a new MAC from the pool. Solution 1 is obviously not the greatest (hence this email). In my opinion, 4 is sort of a cat in a bag, since I'm not sure changing the HWADDR for the guest OS is really a good idea. Solution 2 would be nice going forward, but it just reduces the chances of an admin to come across this situation and doesn't solve it entirely. Hence, I would favour solution 3 which seems to solve the problem and allow the admin to choose what to do. Please voice your opinion, or propose an alternate solution. Regards, Mike ------=_Part_14223209_123477223.1360131191449 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><= div style=3D'font-family: times new roman,new york,times,serif; font-size: = 12pt; color: #000000'>Hi, The current situation dictates that if the= configuration value AllowDuplicateMacAddresses is set to false (this i= s the default setting), then we block import or switching snapshots where<b= r>a MAC address in one or more of the snapshot/ovf's virtual NICs is alread= y used. Given that we don't currently give the admin any option to s= elect otherwise, I'm not sure that's a very robust behaviour.. First= of all the MAC address should be unique per network and not in the whole s= ystem (like it is currently). Furthermore, as long as in the same net= work there are no two virtual NICs running with the same address, it is= not such a bad situation. Therefore, I would like to propose a coup= le of solutions (from backend perspective):   1. Keep blocking. =   2. Keep blocking but fix the mac pools to be per network basis. &= nbsp; 3. Don't block, and allow duplicate MACs in these scenarios, but bloc= k on activating a NIC       with duplicate MAC= address. Warn the user that the NIC is with duplicate MAC, and  &= nbsp;    perhaps even unplug or unwire it so that it would b= e obvious that it's using someone else's       = MAC.   4. Don't block, and give the problematic NIC a new MAC from = the pool. Solution 1 is obviously not the greatest (hence this email= ). In my opinion, 4 is sort of a cat in a bag, since I'm not sure changi= ng the HWADDR for the guest OS is really a good idea. Solution 2 woul= d be nice going forward, but it just reduces the chances of an admin to com= e across this situation and doesn't solve it entirely. Hence, I would= favour solution 3 which seems to solve the problem and allow the admin to<= br>choose what to do. Please voice your opinion, or propose an alter= nate solution. <div>Regards, Mike </div> </div></body></html> ------=_Part_14223209_123477223.1360131191449--

4 5

[Engine-devel] NPE during addStorageServer command
by Deepak C Shetty 08 Feb '13

08 Feb '13

Hi All, I am trying to compile ovirt engine after applying sharad's glusterfs domain support patches @ http://gerrit.ovirt.org/#/q/project:ovirt-engine+branch:master+topic:gluste… After compiling, deploying the engine ( by following the steps in wiki.ovirt.org/Building_Ovirt_Engine ) I connect to the weadmin GUI, add a VDSM host ( this is my own vdsm host with VDSM glsuter domain support ) and the host is "Up" state. Then I select New SD->None in DC -> select my vdsm host->provide the args (remote path = volfileserver:volume, vfstype=glusterfs, mount => left blank) and click on OK I see NPE in the engine side during addStorageServer cmd ( IIUC ) and then engine tries to send disconnectStorageServer, which reaches my VDSM host and it throws a excp, since the domain is not mounted at all. I have captured the logs on the engien and vdsm side and attached here. I am looking for some help on why the NPE is being seen on the engien side during adding a new SD ? thanx, deepak

4 7

[Engine-devel] Proposing Kiril nesenko as power user for "ovirt engine tools"
by Eyal Edri 07 Feb '13

07 Feb '13

Hi, I would like to propose kiril nesenko as 'jenkins power user' for ovirt engine tools. These tools indlude iso uploader, log collector, image uploader and others. Kiril is very involved in building and running Jenkins jobs on the rhevm product, and maintains & package the ovirt tools currently. As part of being power user on jenkins.ovirt.org, he will create new jobs to build and release tools for the various OS supported. I vote +1 as i personally know kiril and he's experience. Thansk, Eyal.

4 4

[Engine-devel] engine-config behaviour on -g by alternateKey
by Martin Betak 07 Feb '13

07 Feb '13

Hi All, I've been working on the ability to set keyboard layout for VNC server as per each individual VM. Currently the only option is to use engine-config to set the value globally, e.g. engine-config -s VncKeyboardLayout=en-us. After adding this option to database and respective entities there were raised valid concerns about why is this option called VncKeyboardLayout and not just KeyboardLayout as it applies to SPICE equally (note that also VDSM calls this config value as 'keyboardLayout'). So to achieve consistency I also renamed it in engine-config.properties and set KeyboardLayout.alternateKey=VncKeyboardLayout. This indeed works for setting (engine-config -s VncKeyboardLayout=en-us sets KeyboardLayout and engine-config -g KeyboardLayout works but it is unable to read the value by the alternateKey) engine-config -g VncKeyboardLayout fails with "no such entry with default version" in the method EngineConfigLogic.printAllValuesForKey as it is passing the user given key name directly to database which returns zero results. Setter methods such as EngineConfigLogic.persistValue use the entity ConfigKey constructed from the user given key-name which correctly constructs appropriate ConfigKey even when given alternateKey name. So I wanted to ask whether this is the desired behaviour (set by alternateKey name but get only by the primary) or is this a bug? I have also simple patch that fixes this and enables also getting the config value by alternateKey. Thank you

2 3

[Engine-devel] Instance Types Feature
by Tomas Jelinek 07 Feb '13

07 Feb '13

Hi All, this is the proposed new feature called instance types: http://www.ovirt.org/Features/Instance_Types Long story short - it should basically split the VM template into: - "hardware profile" called instance types - "software profile" called image This should enable to do something like: Create a new "small" VM and attach a disk with "RHEL + Postgres" installed. Any comments are more than welcome! Tomas

6 16

[Engine-devel] Current oVirt 3.2 blockers
by Moran Goldboim 06 Feb '13

06 Feb '13

This is a multi-part message in MIME format. --------------030001010501000107010308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit attached is the list of current blockers as appears on version tracker bug [1] maintainers please see that the below issues are fixed (unless not really blockers). users, if there are any additional blockers you are facing - let's discuss it in the meeting today. network ======= Bug ID Product Whiteboard Component Assignee Status Resolution Summary 906289 oVirt network ovirt-engine-webadmin alkaplan(a)redhat.com POST --- [oVirt-webadmin] [network] Non-VM networks shown as VM networks on cluster attachment dialog 906291 oVirt network ovirt-engine-webadmin lpeer(a)redhat.com POST --- [oVirt-webadmin] [network] Non-VM networks not being detached from cluster 906383 oVirt network vdsm danken(a)redhat.com POST --- [vdsm] [setupNetworks] Error while attaching non-VM network to interface on Fedora 18 DWH/integration ============= oVirt integration ovirt-dwh ydary(a)redhat.com POST --- dwh setup fails to create db on fedora18 Gluster ====== oVirt gluster ovirt-engine-core shireesh(a)redhat.com MODIFIED --- Deleting one gluster volume from gluster cli triggers deletion of all volumes in engine oVirt gluster ovirt-engine-installer avishwan(a)redhat.com MODIFIED --- engine-setup should prompt for application mode oVirt-node ======== oVirt ovirt-node fdeutsch(a)redhat.com ASSIGNED --- configure kdump fail oVirt ovirt-node mburns(a)redhat.com POST --- problem to make /etc/hosts persistent oVirt ovirt-node fdeutsch(a)redhat.com NEW --- DNS info is missed after reboot rhev-h oVirt ovirt-node mburns(a)redhat.com NEW --- Migrate Node to Fedora 18 oVirt ovirt-node jboggs(a)redhat.com POST --- [F18] Firewalld problem oVirt ovirt-node jboggs(a)redhat.com POST --- [F18] Failed to copy EFI files, no EFI Support will be included. oVirt ovirt-node mburns(a)redhat.com POST --- [F18] snmpd.conf wasn't found oVirt ovirt-node jboggs(a)redhat.com POST --- [F18] useradd: group 'sfcb' does not exist oVirt ovirt-node jboggs(a)redhat.com POST --- [F18] SELinux problems oVirt ovirt-node fdeutsch(a)redhat.com POST --- [F18] All qemu architectures are pulled in and increase the size of the image / What arches are required? oVirt ovirt-node mburns(a)redhat.com NEW --- [F18] journal is full of collectd messages please be ready with it's status for today's weekly meeting, packages should be built by the end of this week fixing the above bugs I'm still missing some packages on the beta repo: -dwh/reports -docs -engine-sdk-java please let us know it's status with respect to 3.2 release. [1] https://bugzilla.redhat.com/showdependencytree.cgi?id=881006&hide_resolved=1 thanks, Moran. --------------030001010501000107010308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#FFFFFF" text="#000000"> attached is the list of current blockers as appears on version tracker bug [1] maintainers please see that the below issues are fixed (unless not really blockers). users, if there are any additional blockers you are facing - let's discuss it in the meeting today. network ======= <meta http-equiv="CONTENT-TYPE" content="text/html; charset=ISO-8859-1"> <title></title> <meta name="GENERATOR" content="LibreOffice 3.5 (Linux)"> <style>  </style>Bug ID    Product    Whiteboard    Component    Assignee    Status    Resolution    Summary 906289    oVirt    network    ovirt-engine-webadmin    <a class="moz-txt-link-abbreviated" href="mailto:alkaplan@redhat.com">alkaplan(a)redhat.com</a>    POST    ---    [oVirt-webadmin] [network] Non-VM networks shown as VM networks on cluster attachment dialog 906291    oVirt    network    ovirt-engine-webadmin    <a class="moz-txt-link-abbreviated" href="mailto:lpeer@redhat.com">lpeer(a)redhat.com</a>    POST    ---    [oVirt-webadmin] [network] Non-VM networks not being detached from cluster 906383    oVirt    network    vdsm    <a class="moz-txt-link-abbreviated" href="mailto:danken@redhat.com">danken(a)redhat.com</a>    POST    ---    [vdsm] [setupNetworks] Error while attaching non-VM network to interface on Fedora 18 DWH/integration ============= <meta http-equiv="CONTENT-TYPE" content="text/html; charset=ISO-8859-1"> oVirt    integration    ovirt-dwh    <a class="moz-txt-link-abbreviated" href="mailto:ydary@redhat.com">ydary(a)redhat.com</a>    POST    ---    dwh setup fails to create db on fedora18 Gluster ====== oVirt    gluster    ovirt-engine-core    <a class="moz-txt-link-abbreviated" href="mailto:shireesh@redhat.com">shireesh(a)redhat.com</a>    MODIFIED    ---    Deleting one gluster volume from gluster cli triggers deletion of all volumes in engine oVirt    gluster    ovirt-engine-installer    <a class="moz-txt-link-abbreviated" href="mailto:avishwan@redhat.com">avishwan(a)redhat.com</a>    MODIFIED    ---    engine-setup should prompt for application mode oVirt-node ======== oVirt        ovirt-node    <a class="moz-txt-link-abbreviated" href="mailto:fdeutsch@redhat.com">fdeutsch(a)redhat.com</a>    ASSIGNED    ---    configure kdump fail oVirt        ovirt-node    <a class="moz-txt-link-abbreviated" href="mailto:mburns@redhat.com">mburns(a)redhat.com</a>    POST    ---    problem to make /etc/hosts persistent oVirt        ovirt-node    <a class="moz-txt-link-abbreviated" href="mailto:fdeutsch@redhat.com">fdeutsch(a)redhat.com</a>    NEW    ---    DNS info is missed after reboot rhev-h oVirt        ovirt-node    <a class="moz-txt-link-abbreviated" href="mailto:mburns@redhat.com">mburns(a)redhat.com</a>    NEW    ---    Migrate Node to Fedora 18 oVirt        ovirt-node    <a class="moz-txt-link-abbreviated" href="mailto:jboggs@redhat.com">jboggs(a)redhat.com</a>    POST    ---    [F18] Firewalld problem oVirt        ovirt-node    <a class="moz-txt-link-abbreviated" href="mailto:jboggs@redhat.com">jboggs(a)redhat.com</a>    POST    ---    [F18] Failed to copy EFI files, no EFI Support will be included. oVirt        ovirt-node    <a class="moz-txt-link-abbreviated" href="mailto:mburns@redhat.com">mburns(a)redhat.com</a>    POST    ---    [F18] snmpd.conf wasn't found oVirt        ovirt-node    <a class="moz-txt-link-abbreviated" href="mailto:jboggs@redhat.com">jboggs(a)redhat.com</a>    POST    ---    [F18] useradd: group 'sfcb' does not exist oVirt        ovirt-node    <a class="moz-txt-link-abbreviated" href="mailto:jboggs@redhat.com">jboggs(a)redhat.com</a>    POST    ---    [F18] SELinux problems oVirt        ovirt-node    <a class="moz-txt-link-abbreviated" href="mailto:fdeutsch@redhat.com">fdeutsch(a)redhat.com</a>    POST    ---    [F18] All qemu architectures are pulled in and increase the size of the image / What arches are required? oVirt        ovirt-node    <a class="moz-txt-link-abbreviated" href="mailto:mburns@redhat.com">mburns(a)redhat.com</a>    NEW    ---    [F18] journal is full of collectd messages please be ready with it's status for today's weekly meeting, packages should be built by the end of this week fixing the above bugs I'm still missing some packages on the beta repo: -dwh/reports -docs -engine-sdk-java please let us know it's status with respect to 3.2 release. [1] <a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/showdependencytree.cgi?id=881006&hide_resol…">https://bugzilla.redhat.com/showdependencytree.cgi?id=881006&hide_resol…</a> thanks, Moran. </body> </html> --------------030001010501000107010308--

2 1

[Engine-devel] Latest open jdk and JBOSS
by Alexander Wels 06 Feb '13

06 Feb '13

Just an FYI there is an issue with the latest openjdk and JBOSS which causes JBOSS to NOT start. Details can be found here: https://community.jboss.org/message/796347#796347 I did upgrade yesterday and I am having the exact same issue. For now do not upgrade your open jdk to the latest version. Alexander.

1 0

[Engine-devel] UI Plugin API: Introducing optional arguments object
by Vojtech Szocs 05 Feb '13

05 Feb '13

Hi guys, as we're planning to improve some plugin API functions [1,2] I'd like to introduce the concept of optional arguments ('options') object, very similar to jQuery 'settings' object [3]. Each API function will declare only mandatory (required) arguments as part of its signature, with any optional arguments embedded within the 'options' object. The 'options' object itself will be optional (can be omitted) and will always be the last argument of each API function. For example: // Without 'options' object, all optional arguments fall back to their default values showDialog('My Dialog', 'my-dialog', 'http://www.example.com/', '800px', '600px') // With empty 'options' object, all optional arguments fall back to their default values showDialog('My Dialog', 'my-dialog', 'http://www.example.com/', '800px', '600px', {}) // With non-empty 'options' object, overriding default 'resizeEnabled' optional argument value showDialog('My Dialog', 'my-dialog', 'http://www.example.com/', '800px', '600px', { resizeEnabled: true }) Support for this concept should be part of [1]. Vojtech [1] http://gerrit.ovirt.org/#/c/11717/ [2] http://gerrit.ovirt.org/#/c/11273/ [3] http://api.jquery.com/jQuery.ajax/

1 0