[Engine-devel] Trusted Compute Pools
by Wei, Gang
------=_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--
12 years, 1 month
[Engine-devel] Error building ovirt engine rpm.
by snmishra＠linux.vnet.ibm.com
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(a)/3.3.0/g' \
-e 's/@PACKAGE_RELEASE(a)/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
12 years, 1 month
[Engine-devel] Import/snapshots duplicate MAC support
by Mike Kolesnik
------=_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,<br><br>The current situation dictates that if the=
configuration value AllowDuplicateMacAddresses <br>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.<br><br>Given that we don't currently give the admin any option to s=
elect otherwise, I'm not sure <br>that's a very robust behaviour..<br>First=
of all the MAC address should be unique per network and not in the whole s=
ystem (like<br>it is currently).<br>Furthermore, as long as in the same net=
work there are no two virtual NICs running with the <br>same address, it is=
not such a bad situation.<br><br>Therefore, I would like to propose a coup=
le of solutions (from backend perspective):<br> 1. Keep blocking.<br>=
2. Keep blocking but fix the mac pools to be per network basis.<br>&=
nbsp; 3. Don't block, and allow duplicate MACs in these scenarios, but bloc=
k on activating a NIC <br> with duplicate MAC=
address. Warn the user that the NIC is with duplicate MAC, and <br> &=
nbsp; perhaps even unplug or unwire it so that it would b=
e obvious that it's using someone else's<br> =
MAC.<br> 4. Don't block, and give the problematic NIC a new MAC from =
the pool.<br><br>Solution 1 is obviously not the greatest (hence this email=
).<br>In my opinion, 4 is sort of a cat in a bag, since I'm not sure changi=
ng the HWADDR for the<br>guest OS is really a good idea.<br>Solution 2 woul=
d be nice going forward, but it just reduces the chances of an admin to com=
e<br>across this situation and doesn't solve it entirely.<br>Hence, I would=
favour solution 3 which seems to solve the problem and allow the admin to<=
br>choose what to do.<br><br>Please voice your opinion, or propose an alter=
nate solution.<br><br><div><span name=3D"x"></span>Regards,<br>Mike<span na=
me=3D"x"></span><br></div><br></div></body></html>
------=_Part_14223209_123477223.1360131191449--
12 years, 1 month
[Engine-devel] NPE during addStorageServer command
by Deepak C Shetty
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:glus...
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
12 years, 1 month
[Engine-devel] Proposing Kiril nesenko as power user for "ovirt engine tools"
by Eyal Edri
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.
12 years, 1 month
[Engine-devel] engine-config behaviour on -g by alternateKey
by Martin Betak
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
12 years, 1 month
[Engine-devel] Instance Types Feature
by Tomas Jelinek
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
12 years, 1 month
[Engine-devel] Current oVirt 3.2 blockers
by Moran Goldboim
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]<br>
maintainers please see that the below issues are fixed (unless not
really blockers).<br>
users, if there are any additional blockers you are facing - let's
discuss it in the meeting today.<br>
<br>
network<br>
=======<br>
<meta http-equiv="CONTENT-TYPE" content="text/html;
charset=ISO-8859-1">
<title></title>
<meta name="GENERATOR" content="LibreOffice 3.5 (Linux)">
<style>
<!--
BODY,DIV,TABLE,THEAD,TBODY,TFOOT,TR,TH,TD,P { font-family:"Liberation Sans"; font-size:x-small }
-->
</style>Bug ID Product Whiteboard Component Assignee
Status Resolution Summary<br>
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<br>
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<br>
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<br>
<br>
DWH/integration<br>
=============<br>
<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<br>
<br>
Gluster<br>
======<br>
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<br>
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<br>
<br>
oVirt-node<br>
========<br>
oVirt ovirt-node <a class="moz-txt-link-abbreviated" href="mailto:fdeutsch@redhat.com">fdeutsch(a)redhat.com</a> ASSIGNED ---
configure kdump fail<br>
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<br>
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<br>
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<br>
oVirt ovirt-node <a class="moz-txt-link-abbreviated" href="mailto:jboggs@redhat.com">jboggs(a)redhat.com</a> POST --- [F18]
Firewalld problem<br>
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.<br>
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<br>
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<br>
oVirt ovirt-node <a class="moz-txt-link-abbreviated" href="mailto:jboggs@redhat.com">jboggs(a)redhat.com</a> POST --- [F18]
SELinux problems<br>
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?<br>
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<br>
<br>
<br>
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<br>
<br>
I'm still missing some packages on the beta repo:<br>
-dwh/reports<br>
-docs<br>
-engine-sdk-java<br>
<br>
please let us know it's status with respect to 3.2 release.<br>
<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/showdependencytree.cgi?id=881006&hide_res...">https://bugzilla.redhat.com/showdependencytree.cgi?id=881006&hide_res...</a><br>
<br>
thanks,<br>
Moran.<br>
</body>
</html>
--------------030001010501000107010308--
12 years, 1 month
[Engine-devel] UI Plugin API: Introducing optional arguments object
by Vojtech Szocs
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/
12 years, 1 month
