On Fri, Jul 04, 2008 at 05:22:19PM +0100, Daniel P. Berrange wrote:
> The 'arch' is refering to the architecture of the guest OS kernel, eg one
> of i686, x86_64, ppc, sparc, etc, etc. The 'virsh capabilities' XML for
> a hypervisor driver declares what architectures the driver supports and
> thus allows virt-image to determine whether it is capable of executing
> the OS being requested. Some drivers like QEMU supported a whole suite
> of architectures by virtue of doing emulation, others only support matching
> host arch (eg Xen).
What do you mean? Xen most definitely runs i686 guest OSes on x86_64.
But, thanks, I see now.
> Basically the idea behind the virt-image XML in general is to declare the
> requirements for its execution. This is matched up with capabilities of
Right, I'd gathered as much.
> > Another question: it seems that virt-image always insists on an install
> > step. What was the intent behind using virt-convert (nee virt-unpack)
> > with virt-image output, in this case?
>
> I'm not sure what you mean by 'install step' here. The idea is that the
> disk image associated with the XML doc contains a pre-installed operating
> system (or 'appliance' in marketing buzzword bingo), so there isn't
> really any install step. We're merely validating requirements against
> capabilities, and configuring deployment specific details.
virt-image.py:217
dom = guest.start_install(None, progresscb, options.replace)
Is this just using the install code as a shell, or something?
> The idea behind the virt-image/virt-unpack association is that the
> virt-image XML defines a portable format for 'appliance' metadata
> information (cf OVF) but not the distribution format (ZIP, tar.gz,
> etc). So the virt-pack tool would doing bundling into ZIP files.
Right. It's not yet clear what's the best way to deal with the
unpack/pack step: maybe virt-convert could automatically handle it.
Presumably we /do/ want to move virt-pack to be virt-convert too at some
point.
regards
john
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
