Daniel P. Berrange wrote:
This patch adds support for another installation variant. The livecd-creator produces ISO images which boot using syslinux. The image-creator creates a single file containing a filesystem in which the OS is installated. This patch adds a new disk-creator, which creates a single file containing a partitioned disk with potentially many filesystems in which the OS is installed. Furthermore it installs grub in the boot sector, so this image is immediately bootable in a virtual machine.
FWIW, I advocate, (and my VirOS projects already uses), a system where such a virtual appliance is a mandatory phase of livecd creation. I don't expect any buy-in to convert livecd-creator to this, but this seems an appropriate time to advocate the design choice-
Basically, I see it as useful to look at the process as distro_config --(phase1process)--> virtual_appliance_disk_image --(phase2process)--> livecd_imageWhere an alternate phase2process plugin could be for example - network push deploy to physical host. Or, instantiate to virtual host.
Basically it seems like since what livecd-creator uses internally, is already _so close_ to an appliance image like this new disk-creator creates already, why not just go ahead and do it (also, theoretically for QA turnaround time, testing new stuff as virtappliance_diskimage is much quicker than waiting for full livecd mksquashfs processing)
Another reason why I like that pipeline breakdown, is because the sorts of things that go on in phase2process can even be largely distribution agnostic. Combined with alternate phase1process plugins that support other distributions, and you get quite a flexible provisioning tool.
$0.02... -dmc