[Libguestfs] Handling different architectures in virt-builder

[Pino Toscano]

On Friday 14 February 2014 16:08:10 Richard W.M. Jones wrote:
> On Fri, Feb 14, 2014 at 03:48:34PM +0100, Pino Toscano wrote:
> > Hi,
> > 
> > currently virt-builder's index contains only x86_64/amd64 images, so
> > asking virt-builder to produce an image always produce a x86_64
> > image, regardless of the host. This also mean that trying to
> > produce, say, a new fedora-20 image from an i686 not only would
> > produce an unexpected result, but also would prevent to e.g.
> > install packages on it.
> > 
> > So virt-builder and its index need to be able to distinguish the
> > architecture; choosing the architecture could be a --arch parameter
> > for virt-builder, but what about the keys in the index since it
> > needs to preserve compatibility with former versions?
> > Maybe a solution could be:
> > a) adding arch=.. keys in entries
> 
> An observation: All current images are x86-64, so you can assume if
> arch= is missing then it means arch=x86_64.

Sounds fair.

> > b) rename (or just copy, to avoid breaking older virt-builders) keys
> > to> 
> >    $distro-$version-$arch
> > 
> > c) to not break compatibility with user input virt-builder joins
> > 
> >    $user_selection + $arch = $user_selection-$arch, and looks in the
> >    index
> > 
> > d) default $arch to `uname -m/p`, if --arch is not specified
> 
> I think (d) for the following reasons.

The list above was not actually a choice of possibilities, but a list of 
steps to do (IMHO) ;)

> We ought to keep:
> 
>   virt-builder fedora-20
> 
> doing the Right Thing, which for the vast majority of users, on x86-64
> host, means they want an x86-64 guest.

True, that's what I want to achieve.
> 
> If aarch64 becomes popular, then:
> 
>   virt-builder fedora-20
> 
> should build an aarch64 image.  Reason: building an x86-64 image isn't
> very useful, because the user wouldn't immediately be able to run it
> (or: it would run very very slowly).

I'm not sure to understand: are you implying that at some point the 
default output might be aarch64 (or whatever is the cool arch at that 
time)?

> If people want to do strange stuff, they can use the --arch option.

Right.

> > Or maybe an even idea could be to give the index file a suffix with
> > the architecture name... although that could break users specifying
> > an absolute URL for an own index of distros...
> 
> Yup, sounds complicated.
> 
> For 1.26 I would like to change (again) how virt-builder finds its
> index.
> 
> The idea is to have /etc/virt-builder.d/... file(s) which each list
> an upstream source, so for example:
> 
>   /etc/virt-builder.d/fedora.conf
> 
> would contain:
> 
>   name=Fedora
>   source=http://cloud.fedoraproject.org/metadata/index.asc
>   fingerprint=blah blah
> 
> which would list all Fedora cloud images (assuming we publish ARM
> cloud images in future, they would be in the same place).
> 
> As these are configuration files, people could add their own.

This sounds like a better idea indeed -- I guess also our current 
hardcoded remote location would become just a config file shipped by 
default? (This way distros can even not use it, if they feel to.)

> > Also, two side notes related to the "different architecture
> > handling"
> > issue:
> > 1) the naming of architectures can change between distros (e.g.
> > amd64 vs> 
> >    x86_64 vs x64, powerpc vs ppc) -- a simple hardcoded mapping in
> >    virt-builder should do the job, I guess?
> 
> Even better, list what architectures we support in the man page, and
> refuse to process index files that contain other names.

Hm, not sure about this; while hardcoding does not seem nice (although 
would be a small mapping), rejecting unknown architectures that might 
work OOTB might be worse.

> > 2) what should be done with commands/operations (e.g. --install)
> > that
> > 
> >    try to run stuff from the guest, when the host and guest
> >    architectures are different? Always deny, deny but allow with a
> >    configure switch, or don't bother and let the user get their
> >    failure?
> 
> I would say: if host arch != requested guest arch, then deny.  It's
> the principle of least surprise for users, and people can always use a
> firstboot script.
> 
> We can fix it later, as it is theoretically possible to run qemu in
> TCG to emulate other architectures, just real slow.

Reasonable enough, I'd say.

-- 
Pino Toscano