8:48 a.m.
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
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
6:29 a.m.
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
7:19 a.m.
On Mon, Feb 17, 2014 at 01:29:39PM +0100, Pino Toscano wrote:
On Friday 14 February 2014 16:08:10 Richard W.M. Jones wrote:
> 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)?
No, I mean that on an aarch64 host, the default should be to build
aarch64 guests. Otherwise people wouldn't be able to immediately run
the guests they build.
Thinking about this a bit more, there is a nasty corner case with 32
bit hosts -- eg. an i686 host or ppc32 host. Should we build a 32 or
64 bit guest by default (without --arch)? But such hosts are so rare
that I don't think we should worry about them.
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.)
Correct. As I said if you want to implement this, go ahead!
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
10:19 a.m.
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
6:32 a.m.
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
7:20 a.m.
On Mon, Feb 17, 2014 at 01:32:48PM +0100, Pino Toscano wrote:
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.
Agreed. It would be easier to ship two sets of indexes, and phase
out the 1.24-compatible ones over time.
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
3998
days inactive
4001
days old
6 comments
2 participants
participants (2)
-
Pino Toscano -
Richard W.M. Jones