[et-mgmt-tools] VM images
dlutter at redhat.com
Mon Jun 11 19:20:12 UTC 2007
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.
Agreed; that would be much cleaner. I'll revise the patches
> - The disk -> target mapping thing is pretty strange - I'd suggest
> that the order the disks are listed in just specifies the target.
In the code, specifying a target is actually optional; it just seemed
more understandable to me to allow explicit mappings.
> Is it hd/cdrom, make sure the boot disk is the first disk etc.
> <loader disk="boot-hvm.img" />
Doesn't the CDROM always need to be hdc ? (at least that's what the
current virt-install code does) With that, you'd have some funky
> - You don't have a human readable name for a UI that allows people to
> choose from a number of images.
Oh, yeah; I'll add a label and description.
> - 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'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.
> - If you added ImageInstaller support to virt-install, couldn't
> virt-image almost just run virt-install rather than re-implementing
> a lot of it? i.e. at a glance, it looks like you've forked
> virt-install in order to have a version with a simpler command
> line. I don't have a problem with virt-image, and the simpler
> command line, it's the copied and pasted code I don't like.
Yeah, I had that same uneasy feeling; I'll go through and factor out as
much as I can.
> - 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.
> - You don't have a way of specifying the disk image should be
Agreed, I'll try and stick that in there.
> - 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. In any event, I
think the user should still be able to override if copies are made or
not; to make this really usable you'd probably also want ot support an
image format that can do snapshot-based copies like qcow. At least on my
LAN, copying a few hundred megs of disk images around is no fun :(
More information about the et-mgmt-tools