[Engine-devel] Open Attestation integration with oVirt engine proposal, how to improve engine's performance?

[Doron Fediuck]

----- Original Message -----
> From: "Wei D Chen" <wei.d.chen at intel.com>
> To: "engine-devel at ovirt.org" <engine-devel at ovirt.org>
> Cc: "Lijuan Zhang" <lijuan.zhang at intel.com>
> Sent: Monday, January 28, 2013 10:42:19 AM
> Subject: [Engine-devel] Open Attestation integration with oVirt engine proposal, how to improve engine's performance?
> 
> Open Attestation is a project aim to enable basic open sourced SDK
> with Intel TXT technology to get node's trustworthiness in a cloud
> usage environment. Integration Open Attestation with Ovirt will
> definitely provide a more secure cloud ecosystem which will give end
> user a choice of whether guest virtual machine need launch on a
> trusted host server or not.
> 
> Initially, we want to attest the host's trustworthiness every time
> when every guest virtual machine launch on the host, thanks to Doron
> Fediuck's reminding, we just need attest the host at the first
> request and cache the result for subsequent requests is enough,
> further, we want to bring down server's response time in case of
> large concurrence request. To resolve/improve engine's performance,
> we decide to tackle this issue by caching all of node's
> trustworthiness while the first guest virtual machine's launching,
> this will take a little longer before its running. Node's
> trustworthiness would be stored in database or just in system
> memory, the value will be effective within one hour or so, of
> course, the period of validity could be configured, node's status
> need to be updated in the case of end user reboot the virtual
> machine and the duration exceed valid time.
> 
> Does this acceptable and any good suggestion?
> 
> Some details can be found in this link:
> http://wiki.ovirt.org/Trusted_compute_pools
> 
> 
> Best Regards,
> Dave Chen
> 

Hi Dave,
As already commented in a different thread, I think moving the trust
constraint from VM level to cluster level may do you good. Current
design suggests that VMs may fail to migrate because there's no trusted
host in the current cluster. However, if you decide that all hosts in the
cluster must be trusted, than this will remove the need to check it for
each VM. You will need a quartz job running to perform the attestation
verification for every host one in a given (configurable) time. If attestation
fail you may choose to move this host into a different status until its
attestation level is handled.