Mailing List Archive

I also have some comments regarding the VM class.
Would it not be better to have a class TPM and a member TPMs ((TPM ref)
Set) containing an array of zero or one references to TPMs? I assume that
an empty array would make it clear that no TPM is associated with the VM
instead of encoding its existence into TPM/instance or TPM/backend
somehow. The current members instance and backend could then be moved into
the TPM class.

Also a Xen system can be running an access control policy where each VM's
run-time access to resources is restricted by the label it has been given
compared to those of the resources. Currently a VM's configuration file
may contain a line like
access_control[policy='<name of the system's policy>',label='<label given
to VM>'].
I think the identifiers 'policy' and 'label' should also be part of the VM
class either directly in the form 'access_control/policy' or indirectly in
an access_control class.

-- Stefan


xen-api-bounces@lists.xensource.com wrote on 06/26/2006 06:53:49 PM:

> The VM class has a boot_method field of type boot_type, which includes
> the value kernel_internal. I'm assuming kernel_internal can be used to
> support bootloaders such as domUloader. There doesn't appear to be a
> way to specify which disk to find the internal kernel though. E.g. I
> give the VM multiple disks (or a single disk with multiple partitions),
> how would I indicate that the "internal" kernel can be found on /dev/hdb

> or /dev/hda2, etc?
>
> Should host class contain fields related to memory, e..g amount of host
> memory, amount consumed by VMs, max amount available for new VMs?
>
> Regards,
> Jim
>
> _______________________________________________
> xen-api mailing list
> xen-api@lists.xensource.com
> http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

On Mon, Jun 26, 2006 at 04:53:49PM -0600, Jim Fehlig wrote:

> The VM class has a boot_method field of type boot_type, which includes
> the value kernel_internal. I'm assuming kernel_internal can be used to
> support bootloaders such as domUloader. There doesn't appear to be a
> way to specify which disk to find the internal kernel though. E.g. I
> give the VM multiple disks (or a single disk with multiple partitions),
> how would I indicate that the "internal" kernel can be found on /dev/hdb
> or /dev/hda2, etc?

That's missing, you're right. I'll roll that in along with the changes to
bios_boot_option.

> Should host class contain fields related to memory, e..g amount of host
> memory, amount consumed by VMs, max amount available for new VMs?

These would be good to have, certainly. I'll roll those in too.

Ewan.

_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

On Tue, Jun 27, 2006 at 04:04:52PM -0400, Stefan Berger wrote:

> I also have some comments regarding the VM class.
> Would it not be better to have a class TPM and a member TPMs ((TPM ref)
> Set) containing an array of zero or one references to TPMs? I assume that
> an empty array would make it clear that no TPM is associated with the VM
> instead of encoding its existence into TPM/instance or TPM/backend
> somehow. The current members instance and backend could then be moved into
> the TPM class.
>
> Also a Xen system can be running an access control policy where each VM's
> run-time access to resources is restricted by the label it has been given
> compared to those of the resources. Currently a VM's configuration file
> may contain a line like
> access_control[policy='<name of the system's policy>',label='<label given
> to VM>'].
> I think the identifiers 'policy' and 'label' should also be part of the VM
> class either directly in the form 'access_control/policy' or indirectly in
> an access_control class.

I'm afraid I don't really understand the TPM stuff at all. What we've done is
copied the existing configuration file entries and the like from Xen. If
that's not a good fit for some reason, then please, suggest a better data
model. You, Reiner, Ramon, Bryan and whoever else is interested in this field
ought to stand up and define a model that suits you -- you know certainly
better than I do.

Ewan.

_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api