[Libguestfs] Handling different architectures in virt-builder

[Richard W.M. Jones]

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.

> 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.

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.

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).

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

> 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.

(Actually if you feel like implementing this, go ahead :-)

> 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.

> 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.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top