Libguestfs - Feb 2014 - Handling different architectures in virt-builder

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

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

On Fri, Feb 14, 2014 at 03:48:34PM +0100, Pino Toscano
wrote:
> 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
os-version is a unique key in the index today, but does it need to be?
You could have multiple os-version entries differing only by at least
the following fields:

. revision
. arch
. format

So your unique key internally in virt-builder would be (os-version,
revision, arch, format) ...

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

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

On Friday 14 February 2014 16:19:39 Richard W.M. Jones
wrote:
> On Fri, Feb 14, 2014 at 03:48:34PM +0100, Pino Toscano wrote:
> > 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
> 
> os-version is a unique key in the index today, but does it need to be?
> You could have multiple os-version entries differing only by at least
> the following fields:
> 
> . revision
> . arch
> . format
> 
> So your unique key internally in virt-builder would be (os-version,
> revision, arch, format) ...
Sure, changing the key is not actually an issue by itself; the issue 
comes up whether we want the "new" indexes to be usable by older
virt-builders, which want os-version as unique key.

OTOH, if we switch to the virt-builder.d/*.conf configuration files, 
those would need to be written anew, so could automatically gain new 
features incompatible with older virt-builders.

-- 
Pino Toscano