This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-API] Comments on VM and host classes

To: xen-api <xen-api@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-API] Comments on VM and host classes
From: Stefan Berger <stefanb@xxxxxxxxxx>
Date: Tue, 27 Jun 2006 16:04:52 -0400
Cc: Ramon Caceres <caceres@xxxxxxxxxx>, Reiner Sailer <sailer@xxxxxxxxxx>
Delivery-date: Tue, 27 Jun 2006 13:06:40 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <44A0657D.5000600@xxxxxxxxxx>
List-help: <mailto:xen-api-request@lists.xensource.com?subject=help>
List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
List-post: <mailto:xen-api@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx

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@xxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
xen-api mailing list
<Prev in Thread] Current Thread [Next in Thread>