Re: [Libguestfs] Handling different architectures in virt-builder

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.

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