On Sat, 2007-06-09 at 14:51 +0100, Mark McLoughlin wrote: > - Including vcpu, memory, graphics and nic in this metadata is mixing > up two things - the things the image need in order to boot and the > defaults recommended when instantiating a guest with the image. > Perhaps put them in a different toplevel element e.g. > > <image> > <boot_options> > <boot> > ... > </boot_options> > <storage> > <disk> > ... > </storage> > <defaults> > <memory> > <vcpus> > ... > </defaults> > </image> After looking at this again, I realized that you think of the metadata slightly differently than I do: note that I don't have a <boot_options> tag, I rather have a <machine> tag, that describes the attributes of a virtual machine. The reason for structuring it this way is that if we ever need multi-VM appliances, it's at least obvious how the metadata format should be extended. Having a <defaults> section at the level you suggest would make describing a multi-VM image kidna hairy. > - This looks odd: > > + order = [ "xen", "kvm", "kqemu", "qemu" ] > + for o in order: > + if types.count(o) > 0: > > i.e. it'd be better not to have to keep that list updated. How > about you just pick the first type? If libvirt doesn't order the > list of available types in a useful order, maybe it should? I've punted on this for now, and justed added a FIXME comment in the code :( David _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/et-mgmt-tools
