Hi David, On Mon, 2007-06-11 at 12:20 -0700, David Lutterkort wrote: > On Sat, 2007-06-09 at 14:51 +0100, Mark McLoughlin wrote: > > - From what I can see, you still have the ability to create a disk at > > instantiation time, but not format it? > > The more I think about it, the less this whole notion of 'instantiate > disk automatically' seems to make sense to me; will appliances really > detect that they'd been given a blank disk and then partition and format > it ? > > 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? :-) > > - 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. 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. Cheers, Mark.
