On Fri, Jan 30, 2009 at 10:50:38AM -0800, john.levon@xxxxxxx wrote:
> # HG changeset patch
> # User john.levon@xxxxxxx
> # Date 1233340700 28800
> # Node ID c1cc701bfb5b7417c2c8cd3571022dcd161c518f
> # Parent cb53cd19242ca7c4a8d20a54495108d7f6639e57
> Add <distro> to domain XML
>
> Support recording the distro type and variant of a domain.
I don't really consider distro type & variant as represented by
virt-install to be very satisfactory. It was intended to represent
the capabilities of the OS being installed, but it is too
inflexible to cope with changing capabilities over time.
eg, distro='linux' varient='rhel5' can't cope with fact that
RHEL-5 gained ability todo VirtIO disks in RHEL-5.3,
or indeed the fact that you have really have 3 level
stream, since you also get point releease 5.2, 5.2.1, etc
Tracking it in the XML also doesn't take account of the fact that
it is only indicating the capabilities of the install media, and
has no knowledge of the fact that the guest OS does upgrades on
the fly.
It also doesn't sufficiently track commonality between families
of distros - eg the 2 level hierarchy type='linux' and varient=
'fedora7', 'fedora8', 'fedora9', 'rhel5', 'ubuntu8', 'debian3',
etc. It can't show that basically all Fedora & RHEL are the same
family, and that Ubuntu & Debian are the same family. It is on
my todo list to try our news ideas to fix this in virt-install,
possibly by switching to a 4-level hiearchy (some levels being
optional). One thing I'm considering is a split like
- family MicroSoft Windows / Red Hat / Debian
- distro Windows / RHEL / Fedora / Debian / Ubuntu
- release Win2k / RHEL-5 / Fedora 8 / Debian Sarge / Ubuntu Hardy
- update Win2k Update 1 / RHEL-5.1 / na / na / na
But I'm not entirely happy with that either. It also needs a
better way to deal with psuedonyms. eg we currently have distro
variants rhel5 and centos5, which is utterly dumb, since centos5
is 100% identical to rhel5 in functional terms.
So I really don't want to formally encode a flawed concept like
distro type & variant in the XML.
If this is just arbitrary metadata for debugging purposes, with
no need for formal machine readable interpretation, then perhaps
we should instead consider adding a free text 'description'
or 'comment' field to the libvirt XML & upstream XenD's SEXPR.
> diff --git a/src/xend_internal.c b/src/xend_internal.c
> --- a/src/xend_internal.c
> +++ b/src/xend_internal.c
> @@ -2274,6 +2274,14 @@ xenDaemonParseSxpr(virConnectPtr conn,
> }
> } else
> def->onCrash = VIR_DOMAIN_LIFECYCLE_DESTROY;
> +
> + tmp = sexpr_node(root, "domain/distro_type");
> + if (tmp != NULL && (def->distro_type = strdup(tmp)) == NULL)
> + goto no_memory;
> +
> + tmp = sexpr_node(root, "domain/distro_variant");
> + if (tmp != NULL && (def->distro_variant = strdup(tmp)) == NULL)
> + goto no_memory;
>
>
> if (hvm) {
> @@ -5337,6 +5345,11 @@ xenDaemonFormatSxpr(virConnectPtr conn,
> }
> virBufferVSprintf(&buf, "(on_crash '%s')", tmp);
>
> + if (def->distro_type != NULL)
> + virBufferVSprintf(&buf, "(distro_type '%s')", def->distro_type);
> + if (def->distro_variant != NULL)
> + virBufferVSprintf(&buf, "(distro_variant '%s')", def->distro_variant);
> +
> /*
> * xend puts localtime in image/{hvm,linux}/, but is clearly
> * bootloader independent. As a simple workaround, we define it
None of this exists in upstream XenD. As a general rule unless it is in
upstream XenD, then we shouldn't include it in libvirt. That said, I
don't think this should be in XenD anyways, because the 2-level type +
variant is flawed representation.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list