[libvirt] [PATCH] Add <distro> to domain XML
# HG changeset patch # User john.levon@sun.com # Date 1233340700 28800 # Node ID c1cc701bfb5b7417c2c8cd3571022dcd161c518f # Parent cb53cd19242ca7c4a8d20a54495108d7f6639e57 Add <distro> to domain XML Support recording the distro type and variant of a domain. Signed-off-by: John Levon <john.levon@sun.com> diff --git a/docs/schemas/domain.rng b/docs/schemas/domain.rng --- a/docs/schemas/domain.rng +++ b/docs/schemas/domain.rng @@ -19,6 +19,7 @@ <ref name='resources'/> <ref name='features'/> <ref name='termination'/> + <ref name='distro'/> <optional> <ref name='devices'/> </optional> @@ -326,6 +327,20 @@ </attribute> <empty/> </element> + </define> + + + <define name='distro'> + <optional> + <element name='distro'> + <element name='type'> + <text/> + </element> + <element name='variant'> + <text/> + </element> + </element> + </optional> </define> diff --git a/src/domain_conf.c b/src/domain_conf.c --- a/src/domain_conf.c +++ b/src/domain_conf.c @@ -436,6 +436,8 @@ void virDomainDefFree(virDomainDefPtr de VIR_FREE(def->name); VIR_FREE(def->cpumask); VIR_FREE(def->emulator); + VIR_FREE(def->distro_type); + VIR_FREE(def->distro_variant); VIR_FREE(def); } @@ -2010,6 +2012,9 @@ static virDomainDefPtr virDomainDefParse &def->onCrash, VIR_DOMAIN_LIFECYCLE_DESTROY) < 0) goto error; + def->distro_type = virXPathString(conn, "string(./distro/type[1])", ctxt); + def->distro_variant = virXPathString(conn, + "string(./distro/variant[1])", ctxt); tmp = virXPathString(conn, "string(./clock/@offset)", ctxt); if (tmp && STREQ(tmp, "localtime")) @@ -3352,6 +3357,17 @@ char *virDomainDefFormat(virConnectPtr c "on_crash") < 0) goto cleanup; + if (def->distro_type != NULL) { + virBufferAddLit(&buf, " <distro>\n"); + virBufferEscapeString(&buf, " <type>%s</type>\n", + def->distro_type); + if (def->distro_variant != NULL) { + virBufferEscapeString(&buf, " <variant>%s</variant>\n", + def->distro_variant); + } + virBufferAddLit(&buf, " </distro>\n"); + } + virBufferAddLit(&buf, " <devices>\n"); if (def->emulator) diff --git a/src/domain_conf.h b/src/domain_conf.h --- a/src/domain_conf.h +++ b/src/domain_conf.h @@ -428,6 +428,9 @@ struct _virDomainDef { int onReboot; int onPoweroff; int onCrash; + + char *distro_type; + char *distro_variant; virDomainOSDef os; char *emulator; 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 diff --git a/tests/sexpr2xmldata/sexpr2xml-fv-distro.sexpr b/tests/sexpr2xmldata/sexpr2xml-fv-distro.sexpr new file mode 100644 --- /dev/null +++ b/tests/sexpr2xmldata/sexpr2xml-fv-distro.sexpr @@ -0,0 +1,86 @@ +(domain + (domid 1) + (on_crash destroy) + (uuid 7dbd82d8-bd75-72ea-0f23-f988c4ef95bd) + (bootloader_args ) + (vcpus 1) + (name domu-220) + (on_poweroff destroy) + (on_reboot destroy) + (bootloader ) + (maxmem 1024) + (memory 1024) + (shadow_memory 9) + (cpu_weight 256) + (cpu_cap 0) + (features ) + (on_xend_start ignore) + (on_xend_stop shutdown) + (start_time 1233338703.67) + (cpu_time 31.675171334) + (online_vcpus 1) + (distro_type windows) + (distro_variant winxp) + (image + (hvm + (kernel /usr/lib/xen/boot/hvmloader) + (boot d) + (device_model /usr/lib/xen/bin/qemu-dm) + (keymap en-us) + (localtime 1) + (pae 1) + (serial pty) + (usb 1) + (usbdevice tablet) + (notes (SUSPEND_CANCEL 1)) + ) + ) + (status 2) + (state r-----) + (store_mfn 262142) + (device + (vif + (mac 00:16:36:1a:73:6d) + (script vif-vnic) + (uuid e81f0e1a-69d9-fd9a-6bee-540693c66eeb) + (backend 0) + ) + ) + (device + (vbd + (uname phy:/dev/zvol/dsk/export/dom/domu-220-root) + (uuid 4e71c222-f7cf-7fac-bae3-dc57f1e3f2bc) + (mode w) + (dev hda:disk) + (backend 0) + (bootable 1) + ) + ) + (device + (vbd + (uname file:/net/heaped/export/netimage/windows/xp-sp2-vol.iso) + (uuid 2f321f31-80c9-c71e-cb80-0e6a932b071b) + (mode r) + (dev hdc:cdrom) + (backend 0) + (bootable 0) + ) + ) + (device (vkbd (backend 0))) + (device + (vfb + (vncunused 1) + (keymap en-us) + (type vnc) + (uuid a296597b-b5ac-a5b6-05c5-1d98200c528f) + (location localhost:5900) + ) + ) + (device + (console + (protocol vt100) + (location 3) + (uuid 8665fe81-678a-4ddc-5f8d-24e3d5fa46d9) + ) + ) +) diff --git a/tests/sexpr2xmldata/sexpr2xml-fv-distro.xml b/tests/sexpr2xmldata/sexpr2xml-fv-distro.xml new file mode 100644 --- /dev/null +++ b/tests/sexpr2xmldata/sexpr2xml-fv-distro.xml @@ -0,0 +1,51 @@ +<domain type='xen' id='1'> + <name>domu-220</name> + <uuid>7dbd82d8-bd75-72ea-0f23-f988c4ef95bd</uuid> + <memory>1048576</memory> + <currentMemory>1048576</currentMemory> + <vcpu>1</vcpu> + <os> + <type>hvm</type> + <loader>/usr/lib/xen/boot/hvmloader</loader> + <boot dev='cdrom'/> + </os> + <features> + <pae/> + </features> + <clock offset='localtime'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>destroy</on_reboot> + <on_crash>destroy</on_crash> + <distro> + <type>windows</type> + <variant>winxp</variant> + </distro> + <devices> + <emulator>/usr/lib/xen/bin/qemu-dm</emulator> + <disk type='block' device='disk'> + <driver name='phy'/> + <source dev='/dev/zvol/dsk/export/dom/domu-220-root'/> + <target dev='hda' bus='ide'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='file'/> + <source file='/net/heaped/export/netimage/windows/xp-sp2-vol.iso'/> + <target dev='hdc' bus='ide'/> + <readonly/> + </disk> + <interface type='ethernet'> + <mac address='00:16:36:1a:73:6d'/> + <script path='vif-vnic'/> + <target dev='vif1.0'/> + </interface> + <serial type='pty'> + <target port='0'/> + </serial> + <console type='pty'> + <target port='0'/> + </console> + <input type='tablet' bus='usb'/> + <input type='mouse' bus='ps2'/> + <graphics type='vnc' port='-1' autoport='yes' keymap='en-us'/> + </devices> +</domain> diff --git a/tests/sexpr2xmltest.c b/tests/sexpr2xmltest.c --- a/tests/sexpr2xmltest.c +++ b/tests/sexpr2xmltest.c @@ -150,6 +150,7 @@ mymain(int argc, char **argv) DO_TEST("fv-usbmouse", "fv-usbmouse", 1); DO_TEST("fv-usbtablet", "fv-usbtablet", 1); DO_TEST("fv-kernel", "fv-kernel", 1); + DO_TEST("fv-distro", "fv-distro", 3); DO_TEST("fv-serial-null", "fv-serial-null", 1); DO_TEST("fv-serial-file", "fv-serial-file", 1); diff --git a/tests/xml2sexprdata/xml2sexpr-fv-distro.sexpr b/tests/xml2sexprdata/xml2sexpr-fv-distro.sexpr new file mode 100644 --- /dev/null +++ b/tests/xml2sexprdata/xml2sexpr-fv-distro.sexpr @@ -0,0 +1,1 @@ +(vm (name 'domu-220')(memory 1024)(maxmem 1024)(vcpus 1)(uuid '7dbd82d8-bd75-72ea-0f23-f988c4ef95bd')(on_poweroff 'destroy')(on_reboot 'destroy')(on_crash 'destroy')(distro_type 'windows')(distro_variant 'winxp')(localtime 1)(image (hvm (kernel '/usr/lib/xen/boot/hvmloader')(vcpus 1)(boot d)(pae 1)(usb 1)(usbdevice tablet)(parallel none)(serial pty)(device_model '/usr/lib/xen/bin/qemu-dm')(vnc 1)(vncunused 1)(keymap 'en-us')))(device (vbd (dev 'hda:disk')(uname 'phy:/dev/zvol/dsk/export/dom/domu-220-root')(mode 'w')))(device (vbd (dev 'hdc:cdrom')(uname 'file:/net/heaped/export/netimage/windows/xp-sp2-vol.iso')(mode 'r')))(device (vif (mac '00:16:36:1a:73:6d')(script 'vif-vnic')(type ioemu)))) \ No newline at end of file diff --git a/tests/xml2sexprdata/xml2sexpr-fv-distro.xml b/tests/xml2sexprdata/xml2sexpr-fv-distro.xml new file mode 100644 --- /dev/null +++ b/tests/xml2sexprdata/xml2sexpr-fv-distro.xml @@ -0,0 +1,51 @@ +<domain type='xen' id='1'> + <name>domu-220</name> + <uuid>7dbd82d8-bd75-72ea-0f23-f988c4ef95bd</uuid> + <memory>1048576</memory> + <currentMemory>1048576</currentMemory> + <vcpu>1</vcpu> + <os> + <type>hvm</type> + <loader>/usr/lib/xen/boot/hvmloader</loader> + <boot dev='cdrom'/> + </os> + <features> + <pae/> + </features> + <clock offset='localtime'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>destroy</on_reboot> + <on_crash>destroy</on_crash> + <distro> + <type>windows</type> + <variant>winxp</variant> + </distro> + <devices> + <emulator>/usr/lib/xen/bin/qemu-dm</emulator> + <disk type='block' device='disk'> + <driver name='phy'/> + <source dev='/dev/zvol/dsk/export/dom/domu-220-root'/> + <target dev='hda' bus='ide'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='file'/> + <source file='/net/heaped/export/netimage/windows/xp-sp2-vol.iso'/> + <target dev='hdc' bus='ide'/> + <readonly/> + </disk> + <interface type='ethernet'> + <mac address='00:16:36:1a:73:6d'/> + <script path='vif-vnic'/> + <target dev='vif1.0'/> + </interface> + <serial type='pty'> + <target port='0'/> + </serial> + <console type='pty'> + <target port='0'/> + </console> + <input type='tablet' bus='usb'/> + <input type='mouse' bus='ps2'/> + <graphics type='vnc' port='-1' autoport='yes' keymap='en-us'/> + </devices> +</domain> diff --git a/tests/xml2sexprtest.c b/tests/xml2sexprtest.c --- a/tests/xml2sexprtest.c +++ b/tests/xml2sexprtest.c @@ -136,6 +136,7 @@ mymain(int argc, char **argv) DO_TEST("fv-usbmouse", "fv-usbmouse", "fvtest", 1); DO_TEST("fv-usbmouse", "fv-usbmouse", "fvtest", 1); DO_TEST("fv-kernel", "fv-kernel", "fvtest", 1); + DO_TEST("fv-distro", "fv-distro", "fvtest", 3); DO_TEST("fv-serial-null", "fv-serial-null", "fvtest", 1); DO_TEST("fv-serial-file", "fv-serial-file", "fvtest", 1);
On Fri, Jan 30, 2009 at 10:50:38AM -0800, john.levon@sun.com wrote:
Add <distro> to domain XML
Support recording the distro type and variant of a domain.
Comments? We obviously don't want to fork the XML, but consider being able to record this for debugging purposes very important. regards john
John Levon <levon@movementarian.org> wrote:
On Fri, Jan 30, 2009 at 10:50:38AM -0800, john.levon@sun.com wrote:
Add <distro> to domain XML
Support recording the distro type and variant of a domain.
Comments? We obviously don't want to fork the XML, but consider being able to record this for debugging purposes very important.
Looks fine to me. Feature additions usually require *some* justification, and you've just provided it: "for debugging". Please mention that in the ChangeLog, too. In general, you'll get more from me as a reviewer if you say more in the change description or comments. The less I have to guess about the intent of a change, the better I can cross-check.
diff --git a/tests/xml2sexprdata/xml2sexpr-fv-distro.sexpr b/tests/xml2sexprdata/xml2sexpr-fv-distro.sexpr new file mode 100644 ... \ No newline at end of file
I know many other .sexpr files lack the final (sole) newline, but new ones should all have it.
On Fri, Jan 30, 2009 at 10:50:38AM -0800, john.levon@sun.com wrote:
# HG changeset patch # User john.levon@sun.com # 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 :|
On Thu, Feb 05, 2009 at 11:53:37AM +0000, Daniel P. Berrange wrote:
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.
It seems I'm being hoisted by virt-install's petard.
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.
The intention is for this to become a dynamic reflection of what's actually in the guest, where possible.
So I really don't want to formally encode a flawed concept like distro type & variant in the XML.
Please propose exactly what you want and I'll go do it. Being XML it is of course perfectly able to extend itself for more information. So you could add your <family> or <compat> tag or whatever without any problems.
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
Oh come on. Hacks for RHEL5 are OK, but anyone else has changes in their system and it's not? Whatever happened to libvirt not being lowest common denominator? john
On Thu, Feb 05, 2009 at 04:57:06PM +0000, John Levon wrote:
On Thu, Feb 05, 2009 at 11:53:37AM +0000, Daniel P. Berrange wrote:
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
Oh come on. Hacks for RHEL5 are OK, but anyone else has changes in their system and it's not? Whatever happened to libvirt not being lowest common denominator?
The changes put in RHEL5 are *backports* of existing features in upstream Xen, so we know the changes there are not going to conflict with what upstream Xen does in the future. The libvirt changes we just enabling existing Xen code in libvirt, to work with earlier versions of Xen. If there were RHEL-5 Xen features which were not already upstream in a newer Xen version, we wouldn't include them in libvirt (they wouldn't be in RHEL-5 Xen anyway, because we don't add stuff there unless it is already in upstream Xen). Regards, 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 :|
On Thu, Feb 05, 2009 at 05:00:41PM +0000, Daniel P. Berrange wrote:
Oh come on. Hacks for RHEL5 are OK, but anyone else has changes in their system and it's not? Whatever happened to libvirt not being lowest common denominator?
The changes put in RHEL5 are *backports* of existing features in upstream Xen, so we know the changes there are not going to conflict with what upstream Xen does in the future. The libvirt changes we just enabling
Sigh, fine, we'll keep it private. john
On Thu, Feb 05, 2009 at 05:00:41PM +0000, Daniel P. Berrange wrote:
there were RHEL-5 Xen features which were not already upstream in a newer Xen version, we wouldn't include them in libvirt (they wouldn't be in RHEL-5 Xen anyway, because we don't add stuff there unless it is already in upstream Xen).
BTW by this argument we wouldn't be able to use libvirt at all since we can't even *compile* the "real" Xen. john
participants (5)
-
Daniel P. Berrange -
Jim Meyering -
John Levon -
John Levon -
john.levon＠sun.com