On Tue, 2007-06-12 at 08:39 +0100, Mark McLoughlin wrote: > > It'd probably make more sense if the metadata could express what > > partitions with what FS's should be on disks - then auto-creation of > > scratch or user disks could actually be useful for appliance builders. > > You're confusing me now - my ImageInstaller had support for formatting > auto-created disks and I thought you didn't like that idea. My point was > going to be that auto-creating disks is useless without formatting > support. > > Does that mean we agree now? :-) Definitely; the only thing that bothered me about the ImageInstaller was that it didn't export full disks to the VM, only partitions. I think it would be very useful to expand this code to take FS images and build disks from them (or create disks with formatted partitions) > > > - 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? > > > > Agreed; going just by the order in the metadata seems cleaner. If we do > > that, then there's no need for libvirt ordering the types. > > Huh? You don't have the hypervisor type in the metadata. And rightly > so. I'll read my own code at some point ;) > So, I'm suggesting that we go by libvirt's ordering rather than a > hard-coded ordering. > > > > - Shouldn't we be copying even system disk images, unless they're > > > read-only, on instantiation - i.e. you should be able to run > > > virt-image multiple times. > > > > I kinda left the issue of multiple instantiations of images out on > > purpose, to keep the first cut simple, since they require a good deal of > > book-keeping, too, to make image-based updates possible. > > I think it's pretty natural to assume people will run virt-image more > than once. Absolutely, I just didn't want to deal with it in the first round. David
