10:08 a.m.
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