On Tue, Aug 26, 2014 at 03:13:11PM -0400, Stefan Berger wrote:
"Kevin O'Connor"
<kevin(a)koconnor.net> wrote on 08/26/2014 12:49:57 PM:
On Tue, Aug 26, 2014 at 12:07:54PM -0400, Stefan
Berger wrote:
> The other aspect is that this extension propagates all the way into
higher
> layers: libvirt would need an API and
command
> line tool extension just to set this flag and presumably use the QEMU
> monitor with a new command to indicate it.
> You want to be able to do this in a cloud environment, you need
another
API
and/or GUI support in your cloud stack for doing
just this... I doesn't seem to become a lot easier this way.
Not easier. But I don't think adding this menu to SeaBIOS is the
solution either. As before, for the bulk of users it's just cryptic,
and for those rare users that do need it, it is not in a place they
want it.
Let me approach this all the way from the cloud user perspective:
One can add a TPM to a VM via an attribute to the image one wants to
deploy. So having a TPM attached to a VM
would be an option. Libvirt can then create a slightly different XML that
instructs QEMU to show the SeaBIOS menu
IF a TPM is attached. If no TPM is attached, no menu is shown, so no
changes here. I find this a useable solution
that helps those that want a TPM to be attached to the VM and leaves
things as they are for those that don't.
If you're going to update libvirt (and cloud stack) for a "show the
TPM menu" flag. Might as well just update libvirt (and stack) to set
the TPM enable/disable/clear setting directly.
Besides that root gets too much
control over VMs with attached TPMs running on a system if libvirt
was to be extended with this kind of support. You could then set the
above mentioned flags and see what happens when the VM gives up
ownership the next time it boots...
I don't understand the above. Root on the guest would have no such
ability. Root on the host can't be stopped anyway..
-Kevin