Mailing List Archive: Xen: API

Comments on VM and host classes

Index | Next | Previous | View Threaded

jfehlig at novell

Jun 26, 2006, 3:53 PM

Post #1 of 4 (233 views)
Permalink

Comments on VM and host classes

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 [at] lists
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

stefanb at us

Jun 27, 2006, 1:04 PM

Post #2 of 4 (228 views)
Permalink

Re: Comments on VM and host classes [In reply to]

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 [at] lists 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 [at] lists
> http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

ewan at xensource

Jun 28, 2006, 10:03 AM

Post #3 of 4 (221 views)
Permalink

Re: Comments on VM and host classes [In reply to]

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 [at] lists
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

ewan at xensource

Jun 28, 2006, 10:09 AM

Post #4 of 4 (227 views)
Permalink

Re: Comments on VM and host classes [In reply to]

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 [at] lists
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads