November 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] 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] 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] Design review summary for 3.2 - adding support for External Events
by Eli Mesika 16 Dec '12

16 Dec '12

Discussion : http://wiki.ovirt.org/wiki/Talk:ExternalEvents Updated Design : http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents#Future_di…

5 16

[Engine-devel] UI Plugins: PoC patch revision 7 is here
by Vojtech Szocs 12 Dec '12

12 Dec '12

------=_Part_6244399_613158090.1352995860557 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi guys, the latest revisi on of UI Plugins proof-of-c on cept patch is now available for you to experiment with. I've split revision 7 changes apart from revision 6 to make it easier to review new features that were added into revision 7. You can download and apply UI Plugins patches from oVirt Gerrit code review system: 1. revision 6 - http://gerrit.ovirt.org/#/c/8120/ 2. revision 7 - http://gerrit.ovirt.org/#/c/9250/ Please read on to learn what's new in this revisi on . If you have any comments, questi on s or ideas, please let me know! Engine REST API integration UiInit is not the only event handler function anymore! :) UI plugin infrastructure now integrates with Engine REST API by acquiring new REST API session [1] upon successful user authentication. REST API session ID is provided to plugins via RestApiSessionAcquired event handler function. For example: api.register({ RestApiSessionAcquired: function(sessionId) { // Do something with newly acquired session ID } }); Note that UiInit function is still the first function to be invoked on the given plugin. Plugins can therefore expect RestApiSessionAcquired function to be called shortly after UiInit function. For now, UI plugin infrastructure guarantees that acquired Engine REST API session will be valid while the user stays authenticated in WebAdmin. This is done by keeping REST API session alive via periodic heartbeats (HTTP requests) in the background. This also means that it's safe to store and use REST API session ID until RestApiSessionAcquired function is called again with new value. In future, we might consider dropping this kind of guarantee to avoid the keep-alive heartbeat, and use some kind of "is session valid" query to determine if the REST API session is still valid. After the user signs out of WebAdmin, Engine REST API session will be closed, as per [1]. After signing in again, the process of acquiring new REST API session and calling RestApiSessionAcquired function repeats with new session ID value. Engine REST API integration also works seamlessly with auto login - if the user is already logged in on the backend, running WebAdmin in new window (tab) will take him directly to the main (authenticated) section of the application. In this case, UI plugin infrastructure remembers the currently valid REST API session ID using HTML5 local storage (or cookie if the browser doesn't support it). New API function: showDialog It's now possible to open custom dialogs using showDialog function. For example: api.register({ UiInit: function() { api.addMainTabActionButton('Host', 'Show Test Dialog', { onClick: function() { api.showDialog('Test Dialog', 'http://www.ovirt.org/', 600, 400); } }); } }); The signature of showDialog function is following: showDialog (title, contentUrl, width, height) For now, dialogs are shown using window.open API (non-modal browser popups ). This will be changed in future, providing close integration with GWTP / WebAdmin dialog infrastructure. New API function: setMainTabContentUrl It's now possible to update content URL of the given custom main tab using setMainTabContentUrl function. For example: api.register({ UiInit: function() { // Use 'about:blank' URL to display empty content api.addMainTab('Custom Tab', 'custom-tab', 'about:blank'); }, RestApiSessionAcquired: function(sessionId) { var url = 'http://www.ovirt.org/?s=' + encodeURIComponent(sessionId); api.setMainTabContentUrl('custom-tab', url); } }); In the above example, we first add an empty custom main tab. We do this in UiInit event handler function because we know that it's the best place for one-time UI initialization :) As soon as we receive REST API session ID, we update the URL of the custom main tab. This is just an example how REST API session ID can be sent over to your server as part of main tab content URL. The signature of setMainTabContentUrl function is following: setMainTabContentUrl(historyToken, contentUrl) Note that historyToken essentially identifies the custom main tab. That's it for now, let me know what you think! Regards, Vojtech [1] http://wiki.ovirt.org/wiki/Features/RESTSessionManagement ------=_Part_6244399_613158090.1352995860557 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 guys, the latest revision<= /span> of UI Plugins= proof-of-c<spa= n id=3D"DWT4665" class=3D"ZmSearchResult">oncept patch is now= available for you to experiment with. I've split revision 7 changes apart = from revision 6 to make it easier to review new features that were added in= to revision 7. You can download and apply UI Plugins patches from oV= irt Gerrit code review system: <ol><li>revision 6 - http://gerrit.ovirt.= org/#/c/8120/</li><li>revision 7 - http://gerrit.ovirt.org/#/c/9250/ </l= i></ol>Please read on to learn what's new = in this revision. If you have any comments, = questions or ideas, please let me know! <= br><hr style=3D"width: 100%; height: 2px;"> Engine REST API inte= gration UiInit is not= the only event handler function anymore! :) UI plugin infrastructur= e now integrates with Engine REST API by acquiring new REST API session [1]= upon successful user authentication. REST API session ID is provide= d to plugins via RestApiSessionAcquired= event handler function. For example: api.register({</span= >   RestApiSessionAcquired: function(sessionId) { &nbsp= ;   // Do something with newly acquired session ID &nbs= p; } }); Note that UiInit function is still the first function to be invoked on the= given plugin. Plugins can therefore expect RestApiSessionAcquired function to be called shortly after <spa= n style=3D"font-style: italic;">UiInit function. For now, UI = plugin infrastructure guarantees that acquired Engine REST API session will= be valid while the user stays authenticated in WebAdmin. This is done by k= eeping REST API session alive via periodic heartbeats (HTTP requests) in th= e background. This also means that it's safe to store and use REST API sess= ion ID until RestApiSessionAcquired</sp= an> function is called again with new value. In future, we might consider d= ropping this kind of guarantee to avoid the keep-alive heartbeat, and use s= ome kind of "is session valid" query to determine if the REST API session i= s still valid. After the user signs out of WebAdmin, Engine REST API= session will be closed, as per [1]. After signing in again, the process of= acquiring new REST API session and calling RestApiSessionAcquired function repeats with new session ID val= ue. Engine REST API integration also works seamlessly with auto logi= n - if the user is already logged in on the backend, running WebAdmin in ne= w window (tab) will take him directly to the main (authenticated) section o= f the application. In this case, UI plugin infrastructure remembers the cur= rently valid REST API session ID using HTML5 local storage (or cookie if th= e browser doesn't support it). <hr style=3D"width: 100%; height: 2px= ;"> New API function: showDialog</spa= n> It's now possible to open custom dia= logs using showDialog function. = For example: api.register({   UiInit: function() {=     api.addMainTabActionButton('Host', 'Show Test= Dialog', {       onClick: function() {<= /span>         api.showDialog('Test D= ialog', 'http://www.ovirt.org/', 600, 400);     &nbs= p; }     });   } });</spa= n> The signature of showDialog</spa= n> function is following: <div style=3D"margin-left: 40px;">showDialog(title, contentUrl, width, height)</s= pan> </div> For now, dialogs are shown using window.open API (non-modal browser popups). This will be= changed in future, providing close integration with GWTP / WebAdmin dialog= infrastructure. <hr style=3D"width: 100%; height: 2px;"> New API function: setMainTabContentUrl<b= r style=3D"font-weight: bold;"> It's now possible to update content URL = of the given custom main tab using setM= ainTabContentUrl function. For example: api.register({</sp= an>   UiInit: function() {     // Use 'abo= ut:blank' URL to display empty content     api.add= MainTab('Custom Tab', 'custom-tab', 'about:blank');   },</sp= an>   RestApiSessionAcquired: function(sessionId) { &nbsp= ;   var url =3D 'http://www.ovirt.org/?s=3D' + encodeURIComponent= (sessionId);     api.setMainTabContentUrl('custom-= tab', url);   } }); In the above exampl= e, we first add an empty custom main tab. We do this in UiInit event handler function because we know that = it's the best place for one-time UI initialization :) As soon as we receive= REST API session ID, we update the URL of the custom main tab. This is jus= t an example how REST API session ID can be sent over to your server as par= t of main tab content URL. The signature of setMainTabContentUrl function is following: <div = style=3D"margin-left: 40px;">setMainTab= ContentUrl(historyToken, contentUrl) </div> Note that historyToken essentially identifies the = custom main tab. <hr style=3D"width: 100%; height: 2px;"> That's = it for now, let me know what you think! Regards, Vojtech <= span style=3D"font-weight: bold;"> [1] http://wiki.ovirt.org/wiki= /Features/RESTSessionManagement </div></body></html> ------=_Part_6244399_613158090.1352995860557--

3 13

[Engine-devel] RFD: API: Identifying vdsm objects in the next-gen API
by Adam Litke 03 Dec '12

03 Dec '12

Today in vdsm, every object (StoragePool, StorageDomain, VM, Volume, etc) is identified by a single UUID. On the surface, it seems like this is enough info to properly identify a resource but in practice it's not. For example, when you look at the API's dealing with Volumes, almost all of them require an sdUUID, spUUID, and imgUUID in order to provide proper context for the operation. Needing to provide these extra UUIDs is a burden on the API user because knowing which values to pass requires internal knowledge of the API. For example, the spUUID parameter is almost always just the connected storage pool. Since we know there can currently be only one connected pool, the value is known. I would like to move away from needing to understand all of these relationships from the end user perspective by encapsulating the extra context into new object identifier types as follows: StoragePoolIdentifier: { 'storagepoolID': 'UUID' } StorageDomainIdentifier: { 'storagepoolID*': 'UUID', 'storagedomainID': 'UUID' } ImageIdentifier: { 'storagepoolID*': 'UUID', 'storagedomainID': 'UUID', 'imageID': 'UUID' } VolumeIdentifier: { 'storagepoolID*': 'UUID', 'storagedomainID': 'UUID', 'imageID': 'UUID', 'volumeID': 'UUID' } TaskIdentifier: { 'taskID': 'UUID' } VMIdentifier: { 'vmID': 'UUID' } In the new API, anytime a reference to an object is required, one of the above structures must be passed in place of today's single UUID. In many cases, this will allow us to reduce the number of parameters to the function since the needed contextual parameters (spUUID, etc) will be part of the object's identifier. Similarly, any time the API returns an object reference it would return a *Identifier instead of a bare UUID. These identifier types are basically opaque blobs to the API users and are only ever generated by vdsm itself. Because of this, we can change the internal structure of the identifier to require new information or (before freezing the API) remove fields that no longer make sense. I would greatly appreciate your comments on this proposal. If it seems reasonable, I will revamp the current schema to make the necessary changes and provide the Bridge patch functions to convert between the current implementation and the new schema. --- sample schema patch --- commit 48f6b0f0a111dd0b372d211a4e566ce87f375cee Author: Adam Litke <agl(a)us.ibm.com> Date: Tue Nov 27 14:14:06 2012 -0600 schema: Introduce class identifier types When calling API methods that belong to a particular class, a class instance must be indicated by passing a set of identifiers in the request. The location of these parameters within the request is: 'params' -> '__obj__'. Since this set of identifiers must be used together to correctly instantiate an object, it makes sense to define these as proper types within the API. Then, functions that return an object (or list of objects) can refer to the correct type. Signed-off-by: Adam Litke <agl(a)us.ibm.com> diff --git a/vdsm_api/vdsmapi-schema.json b/vdsm_api/vdsmapi-schema.json index 0418e6e..7e2e851 100644 --- a/vdsm_api/vdsmapi-schema.json +++ b/vdsm_api/vdsmapi-schema.json @@ -937,7 +937,7 @@ # Since: 4.10.0 ## {'command': {'class': 'Host', 'name': 'getConnectedStoragePools'}, - 'returns': ['StoragePool']} + 'returns': ['StoragePoolIdentifier']} ## # @BlockDeviceType: @@ -1572,7 +1572,7 @@ {'command': {'class': 'Host', 'name': 'getStorageDomains'}, 'data': {'*storagepoolID': 'UUID', '*domainClass': 'StorageDomainImageClass', '*storageType': 'StorageDomainType', '*remotePath': 'str'}, - 'returns': ['StorageDomain']} + 'returns': ['StorageDomainIdentifier']} ## # @Host.getStorageRepoStats: @@ -2406,7 +2406,7 @@ ## {'command': {'class': 'Host', 'name': 'getVMList'}, 'data': {'*vmList': ['UUID']}, - 'returns': ['VM']} + 'returns': ['VMIdentifier']} ## # @Host.ping: @@ -2744,10 +2744,11 @@ 'returns': 'ConnectionRefMap'} ## Category: @ISCSIConnection ################################################## + ## -# @ISCSIConnection: +# @ISCSIConnectionIdentifier: # -# ISCSIConnection API object. +# Identifier for an ISCSIConnection object. # # @host: A fully-qualified domain name (FQDN) or IP address # @@ -2757,11 +2758,21 @@ # # @password: #optional The password associated with the given username # -# Since: 4.10.0 +# Since: 4.10.1 +## +{'type': 'ISCSIConnectionIdentifier', + 'data': {'host': 'str', 'port': 'int', '*user': 'str', '*password': 'str'}} + +## +# @ISCSIConnection: +# +# ISCSIConnection API object. +# +# @ident: The object identifier +# +# Since: 4.10.1 ## -{'class': 'ISCSIConnection', - 'data': {'host': 'str', 'port': 'int', '*user': 'str', - '*password': 'str'}} +{'class': 'ISCSIConnection', 'ident': 'ISCSIConnectionIdentifier'} ## # @ISCSIConnection.discoverSendTargets: @@ -2777,10 +2788,11 @@ 'returns': ['str']} ## Category: @Image ############################################################ + ## -# @Image: +# @ImageIdentifier: # -# Image API object. +# Identifier for an Image object. # # @imageID: The UUID of the Image # @@ -2788,13 +2800,24 @@ # # @storagedomainID: The UUID of the Storage Domain associated with the Image # -# Since: 4.10.0 +# Since: 4.10.1 ## -{'class': 'Image', +{'type': 'ImageIdentifier', 'data': {'imageID': 'UUID', 'storagepoolID': 'UUID', 'storagedomainID': 'UUID'}} ## +# @Image: +# +# Image API object. +# +# @ident: The object identifier +# +# Since: 4.10.1 +## +{'class': 'Image', 'ident': 'ImageIdentifier'} + +## # @Image.delete: # # Delete the Image and all of its Volumes. @@ -2843,7 +2866,7 @@ # Since: 4.10.0 ## {'command': {'class': 'Image', 'name': 'getVolumes'}, - 'returns': ['Volume']} + 'returns': ['VolumeIdentifier']} ## # @Image.mergeSnapshots: @@ -2905,17 +2928,26 @@ ## Category: @LVMVolumeGroup ################################################### ## +# @LVMVolumeGroupIdentifier: +# +# An identifier for a LVMVolumeGroup object. +# +# @lvmvolumegroupID: The volume group UUID +# +# Since: 4.10.1 +## +{'type': 'LVMVolumeGroupIdentifier', 'data': {'lvmvolumegroupID': 'UUID'}} + +## # @LVMVolumeGroup: # # LVMVolumeGroup API object. # -# @lvmvolumegroupID: #optional Associate this object with an existing LVM -# Volume Group +# @ident: The object identifier # -# Since: 4.10.0 +# Since: 4.10.1 ## -{'class': 'LVMVolumeGroup', - 'data': {'lvmvolumegroupID': 'UUID'}} +{'class': 'LVMVolumeGroup', 'ident': 'LVMVolumeGroupIdentifier'} ## # @LVMVolumeGroup.create: @@ -2964,21 +2996,32 @@ ## Category: @StorageDomain #################################################### ## -# @StorageDomain: +# @StorageDomainIdentifier: # -# StorageDomain API object. +# An identifier for a StorageDomain object. # # @storagedomainID: Associate this object with a new or existing Storage Domain # # @storagepoolID: #optional The Storage Pool UUID if this Storage Domain is # attached # -# Since: 4.10.0 +# Since: 4.10.1 ## -{'class': 'StorageDomain', +{'type': 'StorageDomainIdentifier', 'data': {'storagedomainID': 'UUID', 'storagepoolID': 'UUID'}} ## +# @StorageDomain: +# +# StorageDomain API object. +# +# @ident: The object identifier +# +# Since: 4.10.1 +## +{'class': 'StorageDomain', 'ident': 'StorageDomainIdentifier'} + +## # @StorageDomain.activate: # # Activate an attached but inactive Storage Domain. @@ -3184,7 +3227,7 @@ # Since: 4.10.0 ## {'command': {'class': 'StorageDomain', 'name': 'getImages'}, - 'returns': ['Image']} + 'returns': ['ImageIdentifier']} ## # @StorageDomainRole: @@ -3295,7 +3338,7 @@ ## {'command': {'class': 'StorageDomain', 'name': 'getVolumes'}, 'data': {'imageID': 'UUID'}, - 'returns': ['Volume']} + 'returns': ['VolumeIdentifier']} ## # @StorageDomain.setDescription: @@ -3355,15 +3398,26 @@ ## Category: @StoragePool ###################################################### ## +# @StoragePoolIdentifier: +# +# An identifier for a StoragePool object. +# +# @storagepoolID: Associate this object with a new or existing Storage Pool +# +# Since: 4.10.1 +## +{'type': 'StoragePoolIdentifier', 'data': {'storagepoolID': 'UUID'}} + +## # @StoragePool: # # StoragePool API object. # -# @storagepoolID: Associate this object with a new or existing Storage Pool +# @ident: The object identifier # -# Since: 4.10.0 +# Since: 4.10.1 ## -{'class': 'StoragePool', 'data': {'storagepoolID': 'UUID'}} +{'class': 'StoragePool', 'ident': 'StoragePoolIdentifier'} ## # @StoragePool.connect: @@ -3629,7 +3683,7 @@ ## {'command': {'class': 'StoragePool', 'name': 'getDomainsContainingImage'}, 'data': {'imageID': 'UUID', '*onlyDataDomains': 'bool'}, - 'returns': ['StorageDomain']} + 'returns': ['StorageDomainIdentifier']} ## # @StoragePool.getIsoList: @@ -4058,15 +4112,27 @@ ## Category: @Task ############################################################# ## +# @TaskIdentifier: +# +# An identifier for a Task object. +# +# @taskID: The task UUID +# +# Since: 4.10.1 +## +{'type': 'TaskIdentifier', 'data': {'taskID': 'UUID'}} + + +## # @Task: # # Task API object. # -# @taskID: Associate this object with an existing Task +# @ident: The object identifier # -# Since: 4.10.0 +# Since: 4.10.1 ## -{'class': 'Task', 'data': {'taskID': 'UUID'}} +{'class': 'Task', 'ident': 'TaskIdentifier'} ## # @Task.clear: @@ -4123,15 +4189,26 @@ ## Category: @VM ############################################################### ## +# @VMIdentifier: +# +# An identifier for a VM object. +# +# @vmID: The task UUID +# +# Since: 4.10.1 +## +{'type': 'VMIdentifier', 'data': {'vmID': 'UUID'}} + +## # @VM: # # VM API object. # -# @vmID: Associate this object with an existing VM +# @ident: The object identifier # -# Since: 4.10.0 +# Since: 4.10.1 ## -{'class': 'VM', 'data': {'vmID': 'UUID'}} +{'class': 'VM', 'ident': 'VMIdentifier'} ## # @DriveSpecVolume: @@ -5161,9 +5238,9 @@ ## Category: @Volume ########################################################### ## -# @Volume: +# @VolumeIdentifier: # -# Volume API object. +# An identifier for a Volume object. # # @volumeID: The UUID of the Volume # @@ -5173,13 +5250,24 @@ # # @imageID: The Image associated with @UUID # -# Since: 4.10.0 +# Since: 4.10.1 ## -{'class': 'Volume', +{'type': 'VolumeIdentifier', 'data': {'volumeID': 'UUID', 'storagepoolID': 'UUID', 'storagedomainID': 'UUID', 'imageID': 'UUID'}} ## +# @Volume: +# +# Volume API object. +# +# @ident: The object identifier +# +# Since: 4.10.1 +## +{'class': 'Volume', 'ident': 'VolumeIdentifier'} + +## # @VolumeRole: # # An enumeration of Volume Roles. -- Adam Litke <agl(a)us.ibm.com> IBM Linux Technology Center

2 8

[Engine-devel] unsuscribe
by Damon Chesser 29 Nov '12

29 Nov '12

-- Damon L. Chesser damon(a)damtek.com http://www.linkedin.com/in/dchesser

1 0

[Engine-devel] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2)
by Alon Bar-Lev 29 Nov '12

29 Nov '12

Hello All, Preparing to ovirt-engine 3.2 the entire "vdsm-bootstrap" bootstrap was re-written from scratch into more pluggable and flexible implementation, available at git master and nightly snapshots. As far as packaging is concerned there are now two more dependencies to ovirt-engine: * otopi -- oVirt Task Oriented Pluggable Installer/Implementation * ovirt-host-deploy -- oVirt host deploy tool These packages replace the legacy vdsm-bootstrap package that was distributed with vdsm. Git repositories are available at at[1][2]. Documentation is available at Git repositories - README*. Builds are available at usual place[3]. Bugzilla components will be available shortly. Change log is attached. There is no change in the way the engine is performing the host deployment process in term of user experience, other than event log messages during deployment were improved. The log of the deployment is fetched from host and stored at engine machine at /var/log/ovirt-engine/host-deploy, on host it is at /tmp/ovirt-host-deploy*.log and deleted when fetched to engine. Among other features, the ovir-host-deploy package can be installed manually on host and executed to prepare host for installation, in future we may be able to add host to engine without performing the deployment process, for now it will be usable for integration tests. The internals are completely different, instead of having 3 different bootstrap sequences: 1. host install 2. ovirt-node install 3. ovirt-node approve We now have single sequence which is common to host and node installation or re-installation, end result is much simpler implementation. Please report any issues even minor issues, so we can stabilize it for 3.2 release. Best Regards, Alon Bar-Lev. [1] http://gerrit.ovirt.org/gitweb?p=otopi.git;a=tree [2] http://gerrit.ovirt.org/gitweb?p=ovirt-host-deploy.git;a=tree [3] http://www.ovirt.org/releases/nightly/rpm/Fedora/17/noarch/ --- Change Log * offline packager feature. * tuned is installed with virtual-host profile. * initial implementation based on otpoi. * implementation is based on legacy vdsm-bootstrap pacakge functionality. * legacy-removed: legacy VDSM (<3.0) config upgrade. * legacy-removed: change machine width core file # echo /var/lib/vdsm/core > /proc/sys/kernel/core_pattern * legacy-removed: kernel version test, package dependency is sufficient. * legacy-removed: do not add kernel parameter processor.max_cstate=1 warn if not have constant_tsc https://bugzilla.redhat.com/show_bug.cgi?id=770153 * legacy-change: io elevator scheduler set in kernel command-line use either udev rule in vdsm package or tuned. * legacy-change: vdsm libvirt reconfigure vdsm is reconfigured with file based trigger instead unsupported systemd init.d parameter. * legacy-change: distribution checks are simpler based on Python platform, minimum: - rhel-6.2 - fedora-17 * legacy-change: minimum vdsm version is taken from engine not hard coded. * legacy-change: pki is now using m2crypto to generate certificate request and parse certificates. * legacy-change: use iproute2 instead of python ethtool to avoid another dependency for host name validation. * legacy-change: use iproute2 instead of reading /proc/net/route for route information and interface information. * legacy-change: do not use vdsm.netinfo for vlan and bonding as it requires /usr/share/vdsm modules, and it is trivial anyway. * legacy-change: use vdsm-store-net-config script to commit network config instead of internal duplicate implementation. * legacy-change: /etc/vdsm/vdsm.conf is overridden unless VDSM/configOverride environment is set to True * legacy-change: /etc/vdsm/vdsm.conf is not read of fake_qemu. set VDSM/checkVirtHardware environment to False to avoid hardware detection. * legacy-change: following gluster packages not installed: - glusterfs-rdma - glusterfs-geo-replication

4 10

[Engine-devel] maven settings.xml in building ovirt engine wiki
by Alissa Bonas 29 Nov '12

29 Nov '12

Hi, In this wiki http://wiki.ovirt.org/wiki/Building_oVirt_engine The suggested maven settings.xml contains hardcoded paths to jboss_home and java_home. IMHO it's better to use environment variables to take the above settings from there, instead of managing those settings twice in 2 different places. The current settings look like this (note that java path is incorrect anyway, including /bin/java) <jbossHome>/usr/share/jboss-as</jbossHome> <JAVA_HOME>/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.0.x86_64/bin/java</JAVA_HOME> How about changing settings.xml to something like: <jbossHome>${env.JBOSS_HOME}</jbossHome> <JAVA_HOME>${env.JAVA_HOME}</JAVA_HOME> Does anyone see a problem with the suggested approach? Thanks Alissa

10 24

[Engine-devel] Error running virt-v2v on Fedora 17
by Ravi Nori 29 Nov '12

29 Nov '12

I am getting an error when converting a QEMU/KVM VM to run on ovirt. I am running everything on fedora 17 and virt-v2v version is 0.8.8 from rpm virt-v2v-0.8.8-1.fc17.x86_64 How would I resolve this error? Thanks Ravi virt-v2v -o rhev -os vdsm.rnori.com:/export --network ovirtmgmt v2Fed v2vFed.img: 100% [==========================================================================================================]D 0h03m38s Use of uninitialized value $grub_conf in string eq at /usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter/RedHat.pm line 220. Use of uninitialized value $grub_conf in string eq at /usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter/RedHat.pm line 220. Use of uninitialized value in subroutine entry at /usr/share/perl5/vendor_perl/Sys/VirtConvert/GuestfsHandle.pm line 200. Use of uninitialized value $grub_conf in concatenation (.) or string at /usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter/RedHat.pm line 580. Use of uninitialized value $grub_conf in concatenation (.) or string at /usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter/RedHat.pm line 651. Use of uninitialized value $grub_conf in concatenation (.) or string at /usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter/RedHat.pm line 501. Use of uninitialized value $grub_conf in concatenation (.) or string at /usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter/RedHat.pm line 513. virtio configured, but no virtio kernel found at /usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter/RedHat.pm line 790.

2 1

[Engine-devel] ovirt network
by Livnat Peer 28 Nov '12

28 Nov '12

------=_Part_869418_192849599.1354086886752 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit A single instance of the following meeting has been modified: Subject: ovirt network Organiser: "Livnat Peer" <lpeer(a)redhat.com> Time: Wednesday, 5 December, 2012, 4:00:00 PM - 5:00:00 PM GMT +02:00 Jerusalem [MODIFIED] Invitees: engine-devel(a)ovirt.org; vdsm-devel(a)lists.fedorahosted.org; GARGYA(a)de.ibm.com; dyasny(a)redhat.com; simon(a)redhat.com; mkolesni(a)redhat.com; atal(a)redhat.com; ilvovsky(a)redhat.com; dfediuck(a)redhat.com; pradipta.banerjee(a)gmail.com; gkotton(a)redhat.com ... *~*~*~*~*~*~*~*~*~* Hi All, As discussed previously on the list, I am adding a monthly discussion on Networking in oVirt. In this meeting we'll discuss general status of networking and features that we're missing. Thanks, Livnat Bridge ID: 972506565679 Dial-in information: Reservationless-Plus Toll Free Dial-In Number (US & Canada): (800) 451-8679 Reservationless-Plus International Dial-In Number: (212) 729-5016 Conference code: 8425973915 Global Access Numbers Local: Australia, Sydney Dial-In #: 0289852326 Austria, Vienna Dial-In #: 012534978196 Belgium, Brussels Dial-In #: 027920405 China Dial-In #: 4006205013 Denmark, Copenhagen Dial-In #: 32729215 Finland, Helsinki Dial-In #: 0923194436 France, Paris Dial-In #: 0170377140 Germany, Berlin Dial-In #: 030300190579 Ireland, Dublin Dial-In #: 014367793 Italy, Milan Dial-In #: 0236269529 Netherlands, Amsterdam Dial-In #: 0207975872 Norway, Oslo Dial-In #: 21033188 Singapore Dial-In #: 64840858 Spain, Barcelona Dial-In #: 935452328 Sweden, Stockholm Dial-In #: 0850513770 Switzerland, Geneva Dial-In #: 0225927881 United Kingdom Dial-In #: 02078970515 United Kingdom Dial-In #: 08445790676 United Kingdom, LocalCall Dial-In #: 08445790678 United States Dial-In #: 2127295016 Global Access Numbers Tollfree: Argentina Dial-In #: 8004441016 Australia Dial-In #: 1800337169 Austria Dial-In #: 0800005898 Bahamas Dial-In #: 18002054776 Bahrain Dial-In #: 80004377 Belgium Dial-In #: 080048325 Brazil Dial-In #: 08008921002 Bulgaria Dial-In #: 008001100236 Chile Dial-In #: 800370228 Colombia Dial-In #: 018009134033 Costa Rica Dial-In #: 08000131048 Cyprus Dial-In #: 80095297 Czech Republic Dial-In #: 800700318 Denmark Dial-In #: 80887114 Dominican Republic Dial-In #: 18887512313 Estonia Dial-In #: 8000100232 Finland Dial-In #: 0800117116 France Dial-In #: 0805632867 Germany Dial-In #: 8006647541 Greece Dial-In #: 00800127562 Hong Kong Dial-In #: 800930349 Hungary Dial-In #: 0680016796 Iceland Dial-In #: 8008967 India Dial-In #: 0008006501533 Indonesia Dial-In #: 0018030179162 Ireland Dial-In #: 1800932401 Israel Dial-In #: 1809462557 Italy Dial-In #: 800985897 Jamaica Dial-In #: 18002050328 Japan Dial-In #: 0120934453 Korea (South) Dial-In #: 007986517393 Latvia Dial-In #: 80003339 Lithuania Dial-In #: 880030479 Luxembourg Dial-In #: 80026595 Malaysia Dial-In #: 1800814451 Mexico Dial-In #: 0018664590915 New Zealand Dial-In #: 0800888167 Norway Dial-In #: 80012994 Panama Dial-In #: 008002269184 Philippines Dial-In #: 180011100991 Poland Dial-In #: 008001210187 Portugal Dial-In #: 800814625 Russian Federation Dial-In #: 81080028341012 Saint Kitts and Nevis Dial-In #: 18002059252 Singapore Dial-In #: 8006162235 Slovak Republic Dial-In #: 0800001441 South Africa Dial-In #: 0800981148 Spain Dial-In #: 800300524 Sweden Dial-In #: 200896860 Switzerland Dial-In #: 800650077 Taiwan Dial-In #: 00801127141 Thailand Dial-In #: 001800656966 Trinidad and Tobago Dial-In #: 18002024615 United Arab Emirates Dial-In #: 8000650591 United Kingdom Dial-In #: 08006948057 United States Dial-In #: 8004518679 Uruguay Dial-In #: 00040190315 Venezuela Dial-In #: 08001627182 ------=_Part_869418_192849599.1354086886752 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><h3>A single instance of the following meeting has been modifie= d:</h3> <table border=3D'0'> <tr><th align=3Dleft>Subject:</th><td>ovirt network </td></tr> <tr><th align=3Dleft>Organiser:</th><td>"Livnat Peer" <lpeer(a)redhat.com&= gt; </td></tr> </table> <table border=3D'0'> <tr><th align=3Dleft>Time:</th><td>Wednesday, 5 December, 2012, 4:00:00 PM = - 5:00:00 PM GMT +02:00 Jerusalem [MODIFIED] </td></tr></table> <table border=3D'0'> <tr><th align=3Dleft>Invitees:</th><td>engine-devel(a)ovirt.org; vdsm-devel@l= ists.fedorahosted.org; GARGYA(a)de.ibm.com; dyasny(a)redhat.com; simon(a)redhat.c= om; mkolesni(a)redhat.com; atal(a)redhat.com; ilvovsky(a)redhat.com; dfediuck@red= hat.com; pradipta.banerjee(a)gmail.com; gkotton(a)redhat.com ... </td></tr> </table> <div>*~*~*~*~*~*~*~*~*~*</div> Hi All, As discussed previously on th= e list, I am adding a monthly discussion on Networking in oVirt. In thi= s meeting we'll discuss general status of networking and features that we'r= e missing. Thanks, Livnat Bridge ID: 972506565679 D= ial-in information: Reservationless-Plus Toll Free Dial-In Number (US &= amp; Canada): (800) 451-8679 Reservationless-Plus International Dial-In= Number: (212) 729-5016 Conference code: 8425973915 Global Acce= ss Numbers Local: Australia, Sydney Dial-In #: 0289852326 Austria, = Vienna Dial-In #: 012534978196 Belgium, Brussels Dial-In #: 027920405 <= br>China Dial-In #: 4006205013 Denmark, Copenhagen Dial-In #: 32729215 = Finland, Helsinki Dial-In #: 0923194436 France, Paris Dial-In #: 01= 70377140 Germany, Berlin Dial-In #: 030300190579 Ireland, Dublin Di= al-In #: 014367793 Italy, Milan Dial-In #: 0236269529 Netherlands, = Amsterdam Dial-In #: 0207975872 Norway, Oslo Dial-In #: 21033188 Si= ngapore Dial-In #: 64840858 Spain, Barcelona Dial-In #: 935452328 S= weden, Stockholm Dial-In #: 0850513770 Switzerland, Geneva Dial-In #: 0= 225927881 United Kingdom Dial-In #: 02078970515 United Kingdom Dial= -In #: 08445790676 United Kingdom, LocalCall Dial-In #: 08445790678 <br= >United States Dial-In #: 2127295016 Global Access Numbers Toll= free: Argentina Dial-In #: 8004441016 Australia Dial-In #: 18003371= 69 Austria Dial-In #: 0800005898 Bahamas Dial-In #: 18002054776 <br= >Bahrain Dial-In #: 80004377 Belgium Dial-In #: 080048325 Brazil Di= al-In #: 08008921002 Bulgaria Dial-In #: 008001100236 Chile Dial-In= #: 800370228 Colombia Dial-In #: 018009134033 Costa Rica Dial-In #= : 08000131048 Cyprus Dial-In #: 80095297 Czech Republic Dial-In #: = 800700318 Denmark Dial-In #: 80887114 Dominican Republic Dial-In #:= 18887512313 Estonia Dial-In #: 8000100232 Finland Dial-In #: 08001= 17116 France Dial-In #: 0805632867 Germany Dial-In #: 8006647541 <b= r>Greece Dial-In #: 00800127562 Hong Kong Dial-In #: 800930349 Hung= ary Dial-In #: 0680016796 Iceland Dial-In #: 8008967 India Dial-In = #: 0008006501533 Indonesia Dial-In #: 0018030179162 Ireland Dial-In= #: 1800932401 Israel Dial-In #: 1809462557 Italy Dial-In #: 800985= 897 Jamaica Dial-In #: 18002050328 Japan Dial-In #: 0120934453 = Korea (South) Dial-In #: 007986517393 Latvia Dial-In #: 80003339 Li= thuania Dial-In #: 880030479 Luxembourg Dial-In #: 80026595 Malaysi= a Dial-In #: 1800814451 Mexico Dial-In #: 0018664590915 New Zealand= Dial-In #: 0800888167 Norway Dial-In #: 80012994 Panama Dial-In #:= 008002269184 Philippines Dial-In #: 180011100991 Poland Dial-In #:= 008001210187 Portugal Dial-In #: 800814625 Russian Federation Dial= -In #: 81080028341012 Saint Kitts and Nevis Dial-In #: 18002059252 = Singapore Dial-In #: 8006162235 Slovak Republic Dial-In #: 0800001441 <= br>South Africa Dial-In #: 0800981148 Spain Dial-In #: 800300524 Sw= eden Dial-In #: 200896860 Switzerland Dial-In #: 800650077 Taiwan D= ial-In #: 00801127141 Thailand Dial-In #: 001800656966 Trinidad and= Tobago Dial-In #: 18002024615 United Arab Emirates Dial-In #: 80006505= 91 United Kingdom Dial-In #: 08006948057 United States Dial-In #: 8= 004518679 Uruguay Dial-In #: 00040190315 Venezuela Dial-In #: 08001= 627182 </body></html> ------=_Part_869418_192849599.1354086886752 Content-Type: text/calendar; charset=utf-8; method=REQUEST; name=meeting.ics Content-Transfer-Encoding: 7bit BEGIN:VCALENDAR PRODID:Zimbra-Calendar-Provider VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:Asia/Jerusalem BEGIN:STANDARD DTSTART:19710101T020000 TZOFFSETTO:+0200 TZOFFSETFROM:+0300 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=9;BYDAY=4SU TZNAME:IST END:STANDARD BEGIN:DAYLIGHT DTSTART:19710101T020000 TZOFFSETTO:+0300 TZOFFSETFROM:+0200 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1FR TZNAME:IDT END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT UID:cfd70d5d-b663-41f3-b72a-15b532782b23 SUMMARY:ovirt network ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailto:engine- devel(a)ovirt.org ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailto:vdsm-de vel(a)lists.fedorahosted.org ATTENDEE;CN=Tony Gargya/Germany/IBM;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTI ON;RSVP=TRUE:mailto:GARGYA@de.ibm.com ATTENDEE;CN=Dan Yasny;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:m ailto:dyasny@redhat.com ATTENDEE;CN=Simon Grinberg;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=T RUE:mailto:simon@redhat.com ATTENDEE;CN=Mike Kolesnik;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TR UE:mailto:mkolesni@redhat.com ATTENDEE;CN=Avi Tal;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mai lto:atal@redhat.com ATTENDEE;CN=Igor Lvovsky;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRU E:mailto:ilvovsky@redhat.com ATTENDEE;CN=Doron Fediuck;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TR UE:mailto:dfediuck@redhat.com ATTENDEE;CN=Pradipta Kumar Banerjee;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTI ON;RSVP=TRUE:mailto:pradipta.banerjee@gmail.com ATTENDEE;CN=Gary Kotton;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE :mailto:gkotton@redhat.com ATTENDEE;CN=Keith Robertson;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE:mailto:kroberts@redhat.com ATTENDEE;CN=Antoni Segura Puimedon;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTIO N;RSVP=TRUE:mailto:asegurap@redhat.com ATTENDEE;CN=Thang Pham/Poughkeepsie/IBM;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS- ACTION;RSVP=TRUE:mailto:thang.pham@us.ibm.com ATTENDEE;CN=Yaniv Kaul;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE: mailto:ykaul@redhat.com ORGANIZER;CN=Livnat Peer:mailto:lpeer@redhat.com DTSTART;TZID="Asia/Jerusalem":20121205T160000 DTEND;TZID="Asia/Jerusalem":20121205T170000 STATUS:CONFIRMED CLASS:PUBLIC X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY TRANSP:OPAQUE RECURRENCE-ID;TZID="Asia/Jerusalem":20121128T160000 LAST-MODIFIED:20121128T071446Z DTSTAMP:20121128T071446Z SEQUENCE:2 DESCRIPTION:A single instance of the following meeting has been modified:\n\ nSubject: ovirt network \nOrganiser: "Livnat Peer" <lpeer(a)redhat.com> \n\nT ime: Wednesday\, 5 December\, 2012\, 4:00:00 PM - 5:00:00 PM GMT +02:00 Jeru salem [MODIFIED]\n \nInvitees: engine-devel(a)ovirt.org\; vdsm-devel(a)lists.fed orahosted.org\; GARGYA(a)de.ibm.com\; dyasny(a)redhat.com\; simon(a)redhat.com\; m kolesni(a)redhat.com\; atal(a)redhat.com\; ilvovsky(a)redhat.com\; dfediuck@redhat .com\; pradipta.banerjee(a)gmail.com\; gkotton(a)redhat.com ... \n\n\n*~*~*~*~*~ *~*~*~*~*\n\nHi All\, \nAs discussed previously on the list\, I am adding a monthly discussion on Networking in oVirt. \nIn this meeting we'll discuss g eneral status of networking and features that we're missing. \n\nThanks\, Li vnat \n\n\nBridge ID: 972506565679 \nDial-in information: \nReservationless- Plus Toll Free Dial-In Number (US & Canada): (800) 451-8679 \nReservationles s-Plus International Dial-In Number: (212) 729-5016 \nConference code: 84259 73915 \n\nGlobal Access Numbers Local: \nAustralia\, Sydney Dial-In #: 02898 52326 \nAustria\, Vienna Dial-In #: 012534978196 \nBelgium\, Brussels Dial-I n #: 027920405 \nChina Dial-In #: 4006205013 \nDenmark\, Copenhagen Dial-In #: 32729215 \nFinland\, Helsinki Dial-In #: 0923194436 \nFrance\, Paris Dial -In #: 0170377140 \nGermany\, Berlin Dial-In #: 030300190579 \nIreland\, Dub lin Dial-In #: 014367793 \nItaly\, Milan Dial-In #: 0236269529 \nNetherlands \, Amsterdam Dial-In #: 0207975872 \nNorway\, Oslo Dial-In #: 21033188 \nSin gapore Dial-In #: 64840858 \nSpain\, Barcelona Dial-In #: 935452328 \nSweden \, Stockholm Dial-In #: 0850513770 \nSwitzerland\, Geneva Dial-In #: 0225927 881 \nUnited Kingdom Dial-In #: 02078970515 \nUnited Kingdom Dial-In #: 0844 5790676 \nUnited Kingdom\, LocalCall Dial-In #: 08445790678 \nUnited States Dial-In #: 2127295016 \n\n\nGlobal Access Numbers Tollfree: \nArgentina Dial -In #: 8004441016 \nAustralia Dial-In #: 1800337169 \nAustria Dial-In #: 080 0005898 \nBahamas Dial-In #: 18002054776 \nBahrain Dial-In #: 80004377 \nBel gium Dial-In #: 080048325 \nBrazil Dial-In #: 08008921002 \nBulgaria Dial-In #: 008001100236 \nChile Dial-In #: 800370228 \nColombia Dial-In #: 01800913 4033 \nCosta Rica Dial-In #: 08000131048 \nCyprus Dial-In #: 80095297 \nCzec h Republic Dial-In #: 800700318 \nDenmark Dial-In #: 80887114 \nDominican Re public Dial-In #: 18887512313 \nEstonia Dial-In #: 8000100232 \nFinland Dial -In #: 0800117116 \nFrance Dial-In #: 0805632867 \nGermany Dial-In #: 800664 7541 \nGreece Dial-In #: 00800127562 \nHong Kong Dial-In #: 800930349 \nHung ary Dial-In #: 0680016796 \nIceland Dial-In #: 8008967 \nIndia Dial-In #: 00 08006501533 \nIndonesia Dial-In #: 0018030179162 \nIreland Dial-In #: 180093 2401 \nIsrael Dial-In #: 1809462557 \nItaly Dial-In #: 800985897 \nJamaica D ial-In #: 18002050328 \nJapan Dial-In #: 0120934453 \nKorea (South) Dial-In #: 007986517393 \nLatvia Dial-In #: 80003339 \nLithuania Dial-In #: 88003047 9 \nLuxembourg Dial-In #: 80026595 \nMalaysia Dial-In #: 1800814451 \nMexico Dial-In #: 0018664590915 \nNew Zealand Dial-In #: 0800888167 \nNorway Dial- In #: 80012994 \nPanama Dial-In #: 008002269184 \nPhilippines Dial-In #: 180 011100991 \nPoland Dial-In #: 008001210187 \nPortugal Dial-In #: 800814625 \ nRussian Federation Dial-In #: 81080028341012 \nSaint Kitts and Nevis Dial-I n #: 18002059252 \nSingapore Dial-In #: 8006162235 \nSlovak Republic Dial-In #: 0800001441 \nSouth Africa Dial-In #: 0800981148 \nSpain Dial-In #: 80030 0524 \nSweden Dial-In #: 200896860 \nSwitzerland Dial-In #: 800650077 \nTaiw an Dial-In #: 00801127141 \nThailand Dial-In #: 001800656966 \nTrinidad and Tobago Dial-In #: 18002024615 \nUnited Arab Emirates Dial-In #: 8000650591 \ nUnited Kingdom Dial-In #: 08006948057 \nUnited States Dial-In #: 8004518679 \nUruguay Dial-In #: 00040190315 \nVenezuela Dial-In #: 08001627182 X-ALT-DESC;FMTTYPE=text/html:<html><body><h3>A single instance of the follow ing meeting has been modified:</h3>\n\n\n<table border='0'>\n<tr><th alig n=left>Subject:</th><td>ovirt network </td></tr>\n<tr><th align=left>Organi ser:</th><td>"Livnat Peer" &lt\;lpeer(a)redhat.com&gt\; </td></tr>\n</table>\n \n<table border='0'>\n<tr><th align=left>Time:</th><td>Wednesday\, 5 Dece mber\, 2012\, 4:00:00 PM - 5:00:00 PM GMT +02:00 Jerusalem [MODIFIED]\n </td ></tr></table>\n\n<table border='0'>\n<tr><th align=left>Invitees:</th><t d>engine-devel(a)ovirt.org\; vdsm-devel(a)lists.fedorahosted.org\; GARGYA(a)de.ibm .com\; dyasny(a)redhat.com\; simon(a)redhat.com\; mkolesni(a)redhat.com\; atal@red hat.com\; ilvovsky(a)redhat.com\; dfediuck(a)redhat.com\; pradipta.banerjee@gmai l.com\; gkotton(a)redhat.com ... </td></tr>\n</table>\n<div>*~*~*~*~*~*~*~*~*~ *</div> Hi All\, As discussed previously on the list\, I am adding a monthly discussion on Networking in oVirt. In this meeting we'll discuss general status of networking and features that we're missing. Thank s\, Livnat Bridge ID: 972506565679 Dial-in information: Reservationless-Plus Toll Free Dial-In Number (US &amp\; Canada): (800) 451- 8679 Reservationless-Plus International Dial-In Number: (212) 729-5016 Conference code: 8425973915 Global Access Numbers Local: Aust ralia\, Sydney Dial-In #: 0289852326 Austria\, Vienna Dial-In #: 0125349 78196 Belgium\, Brussels Dial-In #: 027920405 China Dial-In #: 40062 05013 Denmark\, Copenhagen Dial-In #: 32729215 Finland\, Helsinki Di al-In #: 0923194436 France\, Paris Dial-In #: 0170377140 Germany\, B erlin Dial-In #: 030300190579 Ireland\, Dublin Dial-In #: 014367793 Italy\, Milan Dial-In #: 0236269529 Netherlands\, Amsterdam Dial-In #: 0 207975872 Norway\, Oslo Dial-In #: 21033188 Singapore Dial-In #: 648 40858 Spain\, Barcelona Dial-In #: 935452328 Sweden\, Stockholm Dial -In #: 0850513770 Switzerland\, Geneva Dial-In #: 0225927881 United Kingdom Dial-In #: 02078970515 United Kingdom Dial-In #: 08445790676 United Kingdom\, LocalCall Dial-In #: 08445790678 United States Dial-In #: 2127295016 Global Access Numbers Tollfree: Argentina Dia l-In #: 8004441016 Australia Dial-In #: 1800337169 Austria Dial-In # : 0800005898 Bahamas Dial-In #: 18002054776 Bahrain Dial-In #: 80004 377 Belgium Dial-In #: 080048325 Brazil Dial-In #: 08008921002 B ulgaria Dial-In #: 008001100236 Chile Dial-In #: 800370228 Colombia Dial-In #: 018009134033 Costa Rica Dial-In #: 08000131048 Cyprus Dia l-In #: 80095297 Czech Republic Dial-In #: 800700318 Denmark Dial-In #: 80887114 Dominican Republic Dial-In #: 18887512313 Estonia Dial- In #: 8000100232 Finland Dial-In #: 0800117116 France Dial-In #: 080 5632867 Germany Dial-In #: 8006647541 Greece Dial-In #: 00800127562 Hong Kong Dial-In #: 800930349 Hungary Dial-In #: 0680016796 Ice land Dial-In #: 8008967 India Dial-In #: 0008006501533 Indonesia Dia l-In #: 0018030179162 Ireland Dial-In #: 1800932401 Israel Dial-In # : 1809462557 Italy Dial-In #: 800985897 Jamaica Dial-In #: 180020503 28 Japan Dial-In #: 0120934453 Korea (South) Dial-In #: 007986517393 Latvia Dial-In #: 80003339 Lithuania Dial-In #: 880030479 Luxem bourg Dial-In #: 80026595 Malaysia Dial-In #: 1800814451 Mexico Dial -In #: 0018664590915 New Zealand Dial-In #: 0800888167 Norway Dial-I n #: 80012994 Panama Dial-In #: 008002269184 Philippines Dial-In #: 180011100991 Poland Dial-In #: 008001210187 Portugal Dial-In #: 8008 14625 Russian Federation Dial-In #: 81080028341012 Saint Kitts and N evis Dial-In #: 18002059252 Singapore Dial-In #: 8006162235 Slovak R epublic Dial-In #: 0800001441 South Africa Dial-In #: 0800981148 Spa in Dial-In #: 800300524 Sweden Dial-In #: 200896860 Switzerland Dial -In #: 800650077 Taiwan Dial-In #: 00801127141 Thailand Dial-In #: 0 01800656966 Trinidad and Tobago Dial-In #: 18002024615 United Arab E mirates Dial-In #: 8000650591 United Kingdom Dial-In #: 08006948057 United States Dial-In #: 8004518679 Uruguay Dial-In #: 00040190315 V enezuela Dial-In #: 08001627182 </body></html> BEGIN:VALARM ACTION:DISPLAY TRIGGER;RELATED=START:-PT5M DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR ------=_Part_869418_192849599.1354086886752--

1 0

[Engine-devel] ovirt network monthly sync meeting - Agenda
by Livnat Peer 28 Nov '12

28 Nov '12

Hi All, We have a scheduled sync meeting on oVirt network today. We did not set an agenda for this meeting yet so I'll postpone it for next week. Please respond to this note with agenda items. If there are no agenda items by December 5th, I'll cancel the call. Thanks, Livnat

1 0

[Engine-devel] Report vNic Implementation Details - Review
by Amihay Winter 28 Nov '12

28 Nov '12

-------- Original Message -------- Subject: [Engine-devel] Report vNic Implementation Details Date: Wed, 21 Nov 2012 19:36:58 +0200 From: Moti Asayag <masayag(a)redhat.com> To: engine-devel(a)ovirt.org <engine-devel(a)ovirt.org> Hi all, This is a proposal for reporting the vNic implementation details as reported by the guest agent per each vNic. Please review the wiki and add your comments. http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation Thanks, ***************** Does the design handle other properties other than increasing the address scope from 64 to 128 bits? I mean properties like (1) stateless address auto-configuration, (2) Multicast, (3) support bigger Jumboframes, (4) disable the broadcast feature that is being used in IPv4, (5) IPSec - and so on... Amihay Winter. ***************** Moti _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

1 0

Re: [Engine-devel] Engine-devel Digest, Vol 14, Issue 70
by 适兕 27 Nov '12

27 Nov '12

agreed, I think before configure setting.xml , developer/builder must config ~/.bash_profile. add blow lines: JAVA_HOME=/usrs/path JBOSS_HOME=/jboss7/path export JAVA_HOME export JBOSS_HOME ..... 2012/11/27 <engine-devel-request(a)ovirt.org> > Send Engine-devel mailing list submissions to > engine-devel(a)ovirt.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.ovirt.org/mailman/listinfo/engine-devel > or, via email, send a message with subject or body 'help' to > engine-devel-request(a)ovirt.org > > You can reach the person managing the list at > engine-devel-owner(a)ovirt.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Engine-devel digest..." > > > Today's Topics: > > 1. maven settings.xml in building ovirt engine wiki (Alissa Bonas) > 2. Re: maven settings.xml in building ovirt engine wiki > (Alon Bar-Lev) > 3. Re: maven settings.xml in building ovirt engine wiki > (Laszlo Hornyak) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 26 Nov 2012 04:15:14 -0500 (EST) > From: Alissa Bonas <abonas(a)redhat.com> > To: engine-devel(a)ovirt.org > Subject: [Engine-devel] maven settings.xml in building ovirt engine > wiki > Message-ID: > <1007139143.6796345.1353921314570.JavaMail.root(a)redhat.com> > Content-Type: text/plain; charset=utf-8 > > Hi, > > In this wiki http://wiki.ovirt.org/wiki/Building_oVirt_engine > > The suggested maven settings.xml contains hardcoded paths to jboss_home > and java_home. > IMHO it's better to use environment variables to take the above settings > from there, instead of managing those settings twice in 2 different places. > > The current settings look like this (note that java path is incorrect > anyway, including /bin/java) > > <jbossHome>/usr/share/jboss-as</jbossHome> > > <JAVA_HOME>/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.0.x86_64/bin/java</JAVA_HOME> > > How about changing settings.xml to something like: > > <jbossHome>${env.JBOSS_HOME}</jbossHome> > <JAVA_HOME>${env.JAVA_HOME}</JAVA_HOME> > > > Does anyone see a problem with the suggested approach? > > Thanks > > Alissa > > > > ------------------------------ > > Message: 2 > Date: Mon, 26 Nov 2012 04:18:57 -0500 (EST) > From: Alon Bar-Lev <alonbl(a)redhat.com> > To: Alissa Bonas <abonas(a)redhat.com> > Cc: engine-devel(a)ovirt.org > Subject: Re: [Engine-devel] maven settings.xml in building ovirt > engine wiki > Message-ID: > <1686367332.1388894.1353921537535.JavaMail.root(a)redhat.com> > Content-Type: text/plain; charset=utf-8 > > > > ----- Original Message ----- > > From: "Alissa Bonas" <abonas(a)redhat.com> > > To: engine-devel(a)ovirt.org > > Sent: Monday, November 26, 2012 11:15:14 AM > > Subject: [Engine-devel] maven settings.xml in building ovirt engine wiki > > > > Hi, > > > > In this wiki http://wiki.ovirt.org/wiki/Building_oVirt_engine > > > > The suggested maven settings.xml contains hardcoded paths to > > jboss_home and java_home. > > IMHO it's better to use environment variables to take the above > > settings from there, instead of managing those settings twice in 2 > > different places. > > > > The current settings look like this (note that java path is incorrect > > anyway, including /bin/java) > > > > <jbossHome>/usr/share/jboss-as</jbossHome> > > > <JAVA_HOME>/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.0.x86_64/bin/java</JAVA_HOME> > > > > How about changing settings.xml to something like: > > > > <jbossHome>${env.JBOSS_HOME}</jbossHome> > > <JAVA_HOME>${env.JAVA_HOME}</JAVA_HOME> > > > > > > Does anyone see a problem with the suggested approach? > > Well, I did not use this either... just pass -DjbossHome=... to maven. > > > > > Thanks > > > > Alissa > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > ------------------------------ > > Message: 3 > Date: Mon, 26 Nov 2012 11:52:52 -0500 (EST) > From: Laszlo Hornyak <lhornyak(a)redhat.com> > To: Alissa Bonas <abonas(a)redhat.com> > Cc: engine-devel(a)ovirt.org > Subject: Re: [Engine-devel] maven settings.xml in building ovirt > engine wiki > Message-ID: <110546079.728955.1353948772248.JavaMail.root(a)redhat.com> > Content-Type: text/plain; charset=utf-8 > > Hi, > > That too could work, but once it already needs to be in the settings.xml, > why would you want another configuration file (like .bashrc)? > > ----- Original Message ----- > > From: "Alissa Bonas" <abonas(a)redhat.com> > > To: engine-devel(a)ovirt.org > > Sent: Monday, November 26, 2012 10:15:14 AM > > Subject: [Engine-devel] maven settings.xml in building ovirt engine wiki > > > > Hi, > > > > In this wiki http://wiki.ovirt.org/wiki/Building_oVirt_engine > > > > The suggested maven settings.xml contains hardcoded paths to > > jboss_home and java_home. > > IMHO it's better to use environment variables to take the above > > settings from there, instead of managing those settings twice in 2 > > different places. > > > > The current settings look like this (note that java path is incorrect > > anyway, including /bin/java) > > > > <jbossHome>/usr/share/jboss-as</jbossHome> > > > <JAVA_HOME>/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.0.x86_64/bin/java</JAVA_HOME> > > > > How about changing settings.xml to something like: > > > > <jbossHome>${env.JBOSS_HOME}</jbossHome> > > <JAVA_HOME>${env.JAVA_HOME}</JAVA_HOME> > > > > > > Does anyone see a problem with the suggested approach? > > > > Thanks > > > > Alissa > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > ------------------------------ > > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > End of Engine-devel Digest, Vol 14, Issue 70 > ******************************************** > -- 独立之思想，自由之精神。 --陈寅恪

1 0

[Engine-devel] Report vNic Implementation Details
by Moti Asayag 25 Nov '12

25 Nov '12

Hi all, This is a proposal for reporting the vNic implementation details as reported by the guest agent per each vNic. Please review the wiki and add your comments. http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation Thanks, Moti

9 25

[Engine-devel] Proposal of Alon bar-lev as oVirt jenkins power user
by Eyal Edri 25 Nov '12

25 Nov '12

Hi, To continue our new tradition of delegating power users for various oVirt sub project management in jenkins, I want to propose Alon bar-lev as power user for oVirt jenkins. Alon is well known within the oVirt community, and been contributing it in the past months. Alon has contributed code to many oVirt projects including massive re-factoring of the bootstrap process and numerous patches on other oVirt projects, Latest projects are otopi and ovirt-host-deploy. He is very technical with previous knowledge of Jenkins. as a power user he will be to: 1. create/update new jobs in jenkins.ovirt.org 2. run/trigger builds 3. run manual gerrit trigger jobs. i vote +1. please vote confidence with +1 or -1 for not. thanks, Eyal Edri.

6 6

[Engine-devel] Mocking EJB resources
by Allon Mureinik 25 Nov '12

25 Nov '12

Hi guys, Many of our classes use EJBUtils to access JBoss' resources/beans, such as TransactionManager, Schedular, LockingManager, etc. This is all fine and well, but it's a bit of a pain when testing those classes. Earlier today I merged a patch (thanks Laszlo, Michael K., Yair and Alissa for their comments!) that allows a streamlined, easier way of doing this, instead of having to muck around with mock objects (or mock around with muck objects, for that matter). The details can be found in the following wiki page: http://wiki.ovirt.org/wiki/MockEJBStrategyRule Enjoy, Allon

1 0

[Engine-devel] Testing failed
by Stephen Liu 23 Nov '12

23 Nov '12

Hi all Fedora 17 64bit # cd /home/satimis/jboss-as/bin # ./standalone.sh -b 0.0.0.0 ...... ...... ./standalone.sh: line 178: 2121 Aborted (core dumped) "java" -D"[Standalone]" -server -XX:+UseCompressedOops -XX:+TieredCompilation -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Djboss.server.default.config=standalone.xml "-Dorg.jboss.boot.log.file=/home/satimis/jboss-as/standalone/log/boot.log" "-Dlogging.configuration=file:/home/satimis/jboss-as/standalone/configuration/logging.properties" -jar "/home/satimis/jboss-as/jboss-modules.jar" -mp "/home/satimis/jboss-as/modules" -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -Djboss.home.dir="/home/satimis/jboss-as" -b 0.0.0.0 Pls help Re running:- http://<server name>:<port>/api server name? Is it the hostname of Fedora17? # hostname fedora17 TIA B.R Stephen L

3 6

[Engine-devel] UI plugins crash course (for plugin developers)
by Vojtech Szocs 23 Nov '12

23 Nov '12

Hi guys, Oved asked me how to get started with writing UI plugins, and I thought I'd post a quick "crash course" for writing simple UI plugin here. Level 1 - Plugin basics ======================= 1. Sync with upstream git repository and apply recent UI plugin patches (rev.6 and rev.7) $ cd <OVIRT_HOME> $ git fetch && git rebase origin $ git fetch git://gerrit.ovirt.org/ovirt-engine refs/changes/20/8120/4 && git checkout FETCH_HEAD $ git fetch git://gerrit.ovirt.org/ovirt-engine refs/changes/50/9250/2 && git checkout FETCH_HEAD 2. Verify your default (machine-specific) Engine configuration - do this if /usr/share/ovirt-engine/conf doesn't exist yet: $ mkdir -p /usr/share/ovirt-engine/conf $ cp <OVIRT_HOME>/backend/manager/conf/engine.conf.defaults /usr/share/ovirt-engine/conf/engine.conf.defaults 3. Create plugin descriptor $ mkdir /usr/share/ovirt-engine/ui-plugins $ vim /usr/share/ovirt-engine/ui-plugins/hello-ui-world.json [hello-world.json] { "name": "HelloWorldPlugin", "url": "/webadmin/webadmin/plugin/HelloWorldPlugin/start.html", "resourcePath": "hello-world-files" } [/hello-ui-world.json] 4. Create plugin host page $ mkdir /usr/share/ovirt-engine/ui-plugins/hello-world-files $ vim /usr/share/ovirt-engine/ui-plugins/hello-world-files/start.html [start.html] <!DOCTYPE html><html><head> <script type='text/javascript'> var api = parent.pluginApi('HelloWorldPlugin'); api.register({ UiInit: function() { window.alert('Hello World!'); } }); api.ready(); </script> </head><body></body></html> [/start.html] 5. See plugin in action by logging into WebAdmin, you should see following message in Engine log: ... Reading UI plugin descriptor [/usr/share/ovirt-engine/ui-plugins/hello-ui-world.json] Level 2 - Using plugin API ========================== 6. Add custom main tab that shows content of the given URL [start.html] ... api.register({ UiInit: function() { api.addMainTab('Test Tab', 'test-tab', 'http://www.example.com/'); } }); ... [/start.html] 7. Update main tab content URL [start.html] ... # Anywhere within event handler function code (e.g. UiInit) api.setMainTabContentUrl('test-tab', 'http://www.another-example.com/'); ... [/start.html] 8. Add custom context-sensitive button to existing main tab [start.html] ... api.register({ UiInit: function() { api.addMainTabActionButton('Host', 'Do something with selected host', { onClick: function() { # arguments[0] is the first selected item var hostId = arguments[0].entityId; window.alert('Host ID ' + hostId); }, isEnabled: function() { # This button is enabled only on single item selection return arguments.length == 1; } }); } }); ... [/start.html] 9. Show custom dialog that shows content of the given URL [start.html] ... # Anywhere within event handler function code (e.g. UiInit) api.showDialog('Test Dialog', 'http://www.example.com/', 600, 400); ... [/start.html] Level 3 - REST API integration ============================== 10. Get notified upon acquiring new Engine REST API session [start.html] ... api.register({ RestApiSessionAcquired: function(sessionId) { window.alert('REST API session ID ' + sessionId); } }); ... [/start.html] Regards, Vojtech

2 4

[Engine-devel] Design review summary for 3.2 - Host Power Management Multiple Agent Support
by Eli Mesika 22 Nov '12

22 Nov '12

http://wiki.ovirt.org/wiki/Talk:HostPMMultipleAgents Regards Eli Mesika

1 0

[Engine-devel] Atlassian Crowd Support for Ovirt
by Justin Hammond 22 Nov '12

22 Nov '12

This is a multi-part message in MIME format. Your mail reader does not understand MIME message format. --=_fJzGa-X67Q+KhqdUoCI9FEhv0D7g0Ni-1T1OEDm6pV+tgkUS Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi All,=0D=0A=0D=0AI've just uploaded to Gerrit a patch that adds atlassi= an crowd authentication support to oVirt.(http://gerrit.ovirt.org/9324)=0D= =0A=0D=0A=C2=A0=0D=0AAll the nitty gritty details are in the commit messa= ge, but basically this adds a new authentication domain, and when selecte= d sends the authentication request off to a crowd server.=0D=0A=0D=0A=C2=A0= =0D=0AWe have been using this patch on 3.1 for a while, and I thought its= overdue to see if you guys are interested in taking this upstream=3F=0D=0A= =0D=0A=C2=A0=0D=0AThere are two areas that I know could use improvements:= =0D=0A=0D=0A1) caching the results from the crowd server, so we don't que= ry for every API request etc.=0D=0A=0D=0A2) adding proper memberOf suppor= t so groups work correctly.=0D=0A=0D=0A=C2=A0=0D=0APlease let me know if = you guys are interested in this, and please be gentle on your reviews - I= =E1=B8=BF not a Java Programmer by any means, and probably brought too ma= ny C++ traits over here... :)=0D=0A=0D=0A=C2=A0=0D=0AThanks=0D=0A=0D=0A=C2= =A0=0D=0AJustin=0D=0A=0D=0A --=_fJzGa-X67Q+KhqdUoCI9FEhv0D7g0Ni-1T1OEDm6pV+tgkUS Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://ww= w.w3.org/TR/html4/loose.dtd"><html>=0A<head>=0A <meta name=3D"Generator"= content=3D"Zarafa WebAccess v7.0.3-30515">=0A <meta http-equiv=3D"Conte= nt-Type" content=3D"text/html; charset=3Dutf-8">=0A <title>Atlassian Cro= wd Support for Ovirt</title>=0A <style type=3D"text/css">=0A body=0D= =0A {=0D=0A font-family: Arial, Verdana, Sans-Serif ! importa= nt;=0D=0A font-size: 12px;=0D=0A padding: 5px 5px 5px 5px;=0D= =0A margin: 0px;=0D=0A border-style: none;=0D=0A bac= kground-color: #ffffff;=0D=0A }=0D=0A=0D=0A p, ul, li=0D=0A = {=0D=0A margin-top: 0px;=0D=0A margin-bottom: 0px;=0D=0A = }=0D=0A </style>=0A</head>=0A<body>=0AHi All,I've jus= t uploaded to Gerrit a patch that adds atlassian crowd authentication sup= port to oVirt.(http://gerrit.ovirt.org/9324) All the n= itty gritty details are in the commit message, but basically this adds a = new authentication domain, and when selected sends the authentication req= uest off to a crowd server. We have been using this pa= tch on 3.1 for a while, and I thought its overdue to see if you guys are = interested in taking this upstream=3F There are two ar= eas that I know could use improvements:1) caching the results from= the crowd server, so we don't query for every API request etc.<p= >2) adding proper memberOf support so groups work correctly. = Please let me know if you guys are interested in this, and please = be gentle on your reviews - I=E1=B8=BF not a Java Programmer by any means= , and probably brought too many C++ traits over here... :) </= p>Thanks Justin=0A</body>=0A</html> --=_fJzGa-X67Q+KhqdUoCI9FEhv0D7g0Ni-1T1OEDm6pV+tgkUS--

2 1

[Engine-devel] [Design for 3.2 RFE] Host Power Management Multiple Agent Support
by Eli Mesika 20 Nov '12

20 Nov '12

Requirements: http://wiki.ovirt.org/wiki/Features/HostPMMultipleAgents DR : http://wiki.ovirt.org/wiki/Features/Design/DetailedHostPMMultipleAgents

3 7

[Engine-devel] Registering an existing disk or VM through the REST API
by Morrissey, Christopher 20 Nov '12

20 Nov '12

--_000_D290AD8432118048947689BA3AE8A9B3EBCEB7SACEXCMBX04PRDhqn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, As many of you know, we're working on adding a plugin to oVirt for NetApp s= torage controllers. The plugin will allow users to add a new storage domain= and rapidly clone VMs using the native ONTAP APIs. Our plan is to do this = outside of oVirt in a separate engine and then register the new storage dom= ain or cloned VMs through the REST API. I've been going through the oVirt code and I'm not able to find a way to re= gister an existing VM or disk through the REST API. Am I missing something = or is this functionality that needs to be added? As part of the cloning pro= cess we can generate new UUIDs for the cloned disks and images, but I don't= see a way to get them recognized by oVirt. This functionality is very important to moving forward on our plugin and I = can certainly help add this capability if needed. -Chris Chris Morrissey Software Engineer NetApp Inc. 919.476.4428 --_000_D290AD8432118048947689BA3AE8A9B3EBCEB7SACEXCMBX04PRDhqn_ 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> As many of you know, we’re working on adding a= plugin to oVirt for NetApp storage controllers. The plugin will allow user= s to add a new storage domain and rapidly clone VMs using the native ONTAP = APIs. Our plan is to do this outside of oVirt in a separate engine and then register the new storage domain or clo= ned VMs through the REST API.<o:p></o:p> <o:p> </o:p> I’ve been going through the oVirt code and I&#= 8217;m not able to find a way to register an existing VM or disk through th= e REST API. Am I missing something or is this functionality that needs to b= e added? As part of the cloning process we can generate new UUIDs for the cloned disks and images, but I don’t see = a way to get them recognized by oVirt.<o:p></o:p> <o:p> </o:p> This functionality is very important to moving forwa= rd on our plugin and I can certainly help add this capability if needed.<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_D290AD8432118048947689BA3AE8A9B3EBCEB7SACEXCMBX04PRDhqn_--

4 7

Re: [Engine-devel] network wiring DD questions/comments
by Alona Kaplan 20 Nov '12

20 Nov '12

> Hi, > > I"ve added my answers as inline comments. > > Thanks, > Alona. > > > Hi Alona, > > I reviewed the DD of wired/unwired and I have a few > > questions/comments - > > > > 1. update vnic while the VM is running should be limited to cluster > > 3.2 > > (except for plug/unplug) > I"ve updated the detailed wiki- > 1. On Add- there will be a canDoAction error if the user will try to > change the network to "none" on 3.1 or less. > I don't think the "none" should be removed from the combo. The user > won't understand why sometimes he has "none" and sometimes not. > 2. On Update- there are two problematic cases with 3.1 or less- > 2.1 The user changes the network to "none" - should behave as add. > 2.2 The vnic is plugged (before and after the update) and the only > change is the network. > In this case an "UpdateDevice" verb should be sent to vdsm, so > if it is 3.1 or less the backend should throw a canDoAction. (I > updated the wiki we this scenario) > But, if mac address, type or plug were updated- we are sending > plug/unplug to the vdsm. So the update can be done although for > 3.1. > We talked about disabling all the fields (except "plug/unplug") > in the dialog if the nic is plugged and rollback the ui if the > user change from plugged to unplugged and then to plugged > again. > I don't think it is right. Because if the user wants just to > update the mac for example, we should allow it even if the nic > is plugged. > I think the canDoAction is enough. > 2.3 I think for 3.0 or less, the update button should be disabled if > the vm is not down. (Updated the wiki). > > > > 2. RunVM - why do we need to pass the 'linkState' property to > > VDSM? > > I > > think that if the link is down we should pass none as the network > > and > > if > > the link is up we should pass the network name, like we did so far. > > the > > link-state is internal implementation detail in the engine. > > > I will talk to Simon. If he is ok with it, I will remove the link > state from the feature. > > > 3. looking on the VDSM API - > > * why do we need 'type' ? > Danken wanted UpdateDevice to be a common api for updating all the > devices. By the type the vdsm decides which device is updated. > > * why do we need 'device'? > You are right, it should be removed. (I updated the wiki) > > * why do we need 'alias'? > We don't send the mac. This is the "unique id" of the nic. > The libvirt sets a unique alias for each device(disk, interface...), > so it can be used as the identifier of the device. > > * As I wrote I think we don't need 'linkState' > > > > 4. I am missing the error handling description when the user > > performs > > - > > Update Vnic while changing the type for example. What is the > > behavior > > if > > we succeed to unplug but not plug after that, etc. > > > When changing the type we are internally using the plug/unplug > actions. > If the unplug succeeds and the plug fails- the backend/ui will get an > error from the plug action. > At the end of such situation the vnic will be unplugged. > I"m not sure what we should do with the type- store the new type or > rollback to the old value in the db? > > > 5. Updated APIs section -This section is based on the fact that we > > pass > > linkstate to vdsm which is not needed IMO, so if we change that > > this > > section should be updated accordingly. > > > > 6. The EVENT section is empty, what events should be issued to > > audit > > log? > > I think we should have an even for update vnic and if plug/unplug > > is > > required a second event should be issued. > We already have events for update_vnic failure- > NETWORK_UPDATE_VM_INTERFACE_FAILED and success- > NETWORK_UPDATE_VM_INTERFACE. > And as we use the old plug/unplug actions we don't have to add new > events to the audit log. > I don't think we have to add extra code to the events. > > > > > 7. why does link state is varchar in DB? you expect to support > > other > > option in addition to up/Down (which can be represented by 1 bit), > > maybe > > n/a status? > You are right, should be boolean. (Updated the wiki). > (If Simon will agree to remove the link state from the feature, will > be removed...) > > > > 8. About the open issues- > > > > * About deprecation of ActivateDeactivateVmNic command - I think > > that > > we should remove this command from the backend to avoid duplicate > > flows > > and bugs etc. for Backwards compatibility we should update the > > clients > > to use the new UpdateVmNetworkInterface. the down side for that is > > we > > have to make the can do action validation more complicated > > (according > > to > > cluster level etc.) > > > > * If we remove ActivateDeactivateVmNic there is no need to rename > > it > > ;) > We use it internally. > Also we have to keep it exposed for backward compatibility with Rest > API. > I"m not sure it should be renamed... > > > > > > Thanks, Livnat > > >

2 1