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 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 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... 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? 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? -- Pino Toscano _______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
