[libvirt] PATCH: Fix booting QEMU off CDROM
by Daniel P. Berrange
KVM supports an alternate syntax for indicating a boot device when the
-drive parameter is available. Instead of -boot c, it allow 'boot=on'
to be set for the -drive parameter. Unfortauntely it turns that this
doesn't work with certain CDROM images, in particular Fedora 9
https://bugzilla.redhat.com/show_bug.cgi?id=452355
Discussion with upstream indicates we're lucky it ever worked at all for
CDROM media. So this patch removes use of the boot=on flag for CDROM devices.
NB, even when we added boot=on, we always still added -boot d param too,
so merely removing the boot=on flag is sufficient to make it work again.
src/qemu_conf.c | 3 -
tests/qemuxml2argvdata/qemuxml2argv-disk-drive-boot-cdrom.args | 1
tests/qemuxml2argvdata/qemuxml2argv-disk-drive-boot-cdrom.xml | 26 ++++++++++
tests/qemuxml2argvdata/qemuxml2argv-disk-drive-boot-disk.args | 1
tests/qemuxml2argvdata/qemuxml2argv-disk-drive-boot-disk.xml | 26 ++++++++++
tests/qemuxml2argvtest.c | 4 +
6 files changed, 60 insertions(+), 1 deletion(-)
Daniel
diff -rupN libvirt-0.4.4.orig/src/qemu_conf.c libvirt-0.4.4.new/src/qemu_conf.c
--- libvirt-0.4.4.orig/src/qemu_conf.c 2008-06-19 14:15:02.000000000 +0100
+++ libvirt-0.4.4.new/src/qemu_conf.c 2008-07-08 12:24:07.000000000 +0100
@@ -2616,7 +2616,8 @@ int qemudBuildCommandLine(virConnectPtr
disk->src, qemudBusIdToName(disk->bus, 1),
media ? media : "",
idx,
- bootable ? ",boot=on" : "");
+ bootable && disk->device == QEMUD_DISK_DISK
+ ? ",boot=on" : "");
ADD_ARG_LIT("-drive");
ADD_ARG_LIT(opt);
diff -rupN libvirt-0.4.4.orig/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-boot-cdrom.args libvirt-0.4.4.new/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-boot-cdrom.args
--- libvirt-0.4.4.orig/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-boot-cdrom.args 1970-01-01 01:00:00.000000000 +0100
+++ libvirt-0.4.4.new/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-boot-cdrom.args 2008-07-08 12:25:59.000000000 +0100
@@ -0,0 +1 @@
+/usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -monitor pty -no-acpi -boot d -drive file=/dev/HostVG/QEMUGuest1,if=ide,index=0 -drive file=/dev/HostVG/QEMUGuest2,if=ide,media=cdrom,index=2 -net none -serial none -parallel none -usb
\ No newline at end of file
diff -rupN libvirt-0.4.4.orig/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-boot-cdrom.xml libvirt-0.4.4.new/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-boot-cdrom.xml
--- libvirt-0.4.4.orig/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-boot-cdrom.xml 1970-01-01 01:00:00.000000000 +0100
+++ libvirt-0.4.4.new/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-boot-cdrom.xml 2008-07-08 12:20:42.000000000 +0100
@@ -0,0 +1,26 @@
+<domain type='qemu'>
+ <name>QEMUGuest1</name>
+ <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
+ <memory>219200</memory>
+ <currentMemory>219200</currentMemory>
+ <vcpu>1</vcpu>
+ <os>
+ <type arch='i686' machine='pc'>hvm</type>
+ <boot dev='cdrom'/>
+ </os>
+ <clock offset='utc'/>
+ <on_poweroff>destroy</on_poweroff>
+ <on_reboot>restart</on_reboot>
+ <on_crash>destroy</on_crash>
+ <devices>
+ <emulator>/usr/bin/qemu</emulator>
+ <disk type='block' device='disk'>
+ <source dev='/dev/HostVG/QEMUGuest1'/>
+ <target dev='hda' bus='ide'/>
+ </disk>
+ <disk type='block' device='cdrom'>
+ <source dev='/dev/HostVG/QEMUGuest2'/>
+ <target dev='hdc' bus='ide'/>
+ </disk>
+ </devices>
+</domain>
diff -rupN libvirt-0.4.4.orig/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-boot-disk.args libvirt-0.4.4.new/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-boot-disk.args
--- libvirt-0.4.4.orig/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-boot-disk.args 1970-01-01 01:00:00.000000000 +0100
+++ libvirt-0.4.4.new/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-boot-disk.args 2008-07-08 12:13:15.000000000 +0100
@@ -0,0 +1 @@
+/usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -monitor pty -no-acpi -boot c -drive file=/dev/HostVG/QEMUGuest1,if=ide,index=0,boot=on -drive file=/dev/HostVG/QEMUGuest2,if=ide,media=cdrom,index=2 -net none -serial none -parallel none -usb
\ No newline at end of file
diff -rupN libvirt-0.4.4.orig/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-boot-disk.xml libvirt-0.4.4.new/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-boot-disk.xml
--- libvirt-0.4.4.orig/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-boot-disk.xml 1970-01-01 01:00:00.000000000 +0100
+++ libvirt-0.4.4.new/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-boot-disk.xml 2008-07-08 12:12:41.000000000 +0100
@@ -0,0 +1,26 @@
+<domain type='qemu'>
+ <name>QEMUGuest1</name>
+ <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
+ <memory>219200</memory>
+ <currentMemory>219200</currentMemory>
+ <vcpu>1</vcpu>
+ <os>
+ <type arch='i686' machine='pc'>hvm</type>
+ <boot dev='hd'/>
+ </os>
+ <clock offset='utc'/>
+ <on_poweroff>destroy</on_poweroff>
+ <on_reboot>restart</on_reboot>
+ <on_crash>destroy</on_crash>
+ <devices>
+ <emulator>/usr/bin/qemu</emulator>
+ <disk type='block' device='disk'>
+ <source dev='/dev/HostVG/QEMUGuest1'/>
+ <target dev='hda' bus='ide'/>
+ </disk>
+ <disk type='block' device='cdrom'>
+ <source dev='/dev/HostVG/QEMUGuest2'/>
+ <target dev='hdc' bus='ide'/>
+ </disk>
+ </devices>
+</domain>
diff -rupN libvirt-0.4.4.orig/tests/qemuxml2argvtest.c libvirt-0.4.4.new/tests/qemuxml2argvtest.c
--- libvirt-0.4.4.orig/tests/qemuxml2argvtest.c 2008-06-02 10:16:46.000000000 +0100
+++ libvirt-0.4.4.new/tests/qemuxml2argvtest.c 2008-07-08 12:21:53.000000000 +0100
@@ -158,6 +158,10 @@ mymain(int argc, char **argv)
QEMUD_CMD_FLAG_DRIVE_BOOT);
DO_TEST("disk-xenvbd", QEMUD_CMD_FLAG_DRIVE |
QEMUD_CMD_FLAG_DRIVE_BOOT);
+ DO_TEST("disk-drive-boot-disk", QEMUD_CMD_FLAG_DRIVE |
+ QEMUD_CMD_FLAG_DRIVE_BOOT);
+ DO_TEST("disk-drive-boot-cdrom", QEMUD_CMD_FLAG_DRIVE |
+ QEMUD_CMD_FLAG_DRIVE_BOOT);
DO_TEST("graphics-vnc", 0);
DO_TEST("graphics-sdl", 0);
DO_TEST("input-usbmouse", 0);
--
|: 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 :|
16 years, 4 months
[libvirt] MinGW Windows cross-compiler in Fedora, compiling libvirt
by Richard W.M. Jones
We've set up a SIG (Special Interest Group) for people interested in
adding a Windows cross-compiler to Fedora:
https://fedoraproject.org/wiki/SIGs/MinGW
The primary target at the moment is to allow libvirt to be cross-
compiled on a Fedora machine, targetting Windows. This will allow us
to do more regular testing on the Windows build and ensure it doesn't
break so often.
At the moment you can already build all dependencies of libvirt, and
libvirt itself, but only statically (see detailed reasons below). I
also got virsh.exe working, and there seems to be no reason why other
C programs linked to libvirt wouldn't work too.
For the dependencies, start with the README file here:
http://hg.et.redhat.com/misc/fedora-mingw--devel
Building libvirt
----------------
After building and installing the dependencies, you will be able to
build libvirt from CVS (*not* libvirt 0.4.4 since that had a MinGW bug
which was subsequently patched):
CC="i686-pc-mingw32-gcc -I/usr/i686-pc-mingw32/sys-root/mingw/include/libxml2" \
./configure \
--host=i686-pc-mingw32 \
--prefix=/usr/i686-pc-mingw32/sys-root/mingw \
--without-xen \
--without-qemu \
--without-libvirtd \
--without-sasl \
--disable-shared
make
Running programs under Wine
---------------------------
If Wine is installed, you can just run programs like virsh.exe
directly. Make sure any required DLLs are on your path.
It's possible we could get the test suite running using Wine, but I
haven't tried this.
Current problems for libvirt on Windows/MinGW
---------------------------------------------
No python. Either it was my imagination, or we've lost the
'--disable-python' configure option. In any case we should be able to
detect that Python isn't going to work or disable it completely, so
the build doesn't fail at this point.
Libxml2 detection is broken (again?). The configure script insists on
finding the system library, not the MinGW sys-root library. Hence the
strange $CC variable above.
Static linking only: The problem here is that PortableXDR uses a
Windows library called Winsock (ws2_32.dll). MinGW doesn't provide a
dynamic version of this library, only a static version -- I'm not sure
why this is, obviously though if you were running on Windows then
you'd have the MSFT binary DLL. Hence PortableXDR can only be linked
statically. This implies that libvirt can also only be linked
statically. I think this is easy to solve: PortableXDR only uses a
handful of simple functions from Winsock, which we can just get from
Gnulib or some other source instead.
-----------
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
16 years, 4 months
[libvirt] trying to 'destroy' a domain with Python bindings...
by Michael March
When I do this:
conn.lookupByName('myDomU').destroy()
... I get this:
Traceback (most recent call last):
File "test.py", line 30, in ?
print conn.lookupByName('myDomU').destroy()
File "/usr/lib64/python2.4/site-packages/libvirt.py", line 238, in destroy
if ret == -1: raise libvirtError ('virDomainDestroy() failed', dom=self)
libvirt.libvirtError: virDomainDestroy() failed
What am I missing here? Destroy should do the equivalent of 'Delete' on
virt-manager, correct?
thanks!
(BTW... I'm running stock RH5.2.)
16 years, 4 months
[libvirt] [PATCH] update libvirt.rng
by John Levon
The below patch makes a significant update to libvirt.rng to bring it
into line with reality. This is an incremental improvement rather than a
full fix. In particular, various parts are still under-specified (e.g.
qemu char devices).
This version lets almost all of the XML files in tests/ validate. I'd
appreciate help getting the last few to validate - any volunteers?
One possible idea might be virsh validate: split out both the schema
validation and the additional checks in libvirt into one consolidated
place. This would help people check their definitions.
The question also arises on how to help avoid the schema getting so
badly out of date again. Some suggestions:
- add a validation phase to the test suite, and mark failures
- require any changes to the implicit schema to add a test suite entry
- and require such changes to update the schema too
Comments?
thanks,
john
Index: docs/libvirt.rng
===================================================================
RCS file: /data/cvs/libvirt/docs/libvirt.rng,v
retrieving revision 1.7
diff -u -r1.7 libvirt.rng
--- docs/libvirt.rng 14 Mar 2008 11:08:03 -0000 1.7
+++ docs/libvirt.rng 4 Jul 2008 22:22:52 -0000
@@ -50,6 +50,7 @@
</optional>
</group>
</choice>
+ <ref name='clock'/>
<ref name='resources'/>
<ref name='features'/>
<ref name='termination'/>
@@ -82,8 +83,13 @@
</choice>
<value>hvm</value>
</element>
+ <optional>
+ <ref name='bootdev'/>
+ </optional>
</element>
+ <ref name='clock'/>
<ref name='resources'/>
+ <ref name='termination'/>
<ref name='devices'/>
</interleave>
</group>
@@ -157,8 +163,14 @@
<interleave>
<element name='os'>
<element name='type'>
- <value>hvm</value>
+ <choice>
+ <value>hvm</value>
+ <value>xen</value>
+ </choice>
</element>
+ <optional>
+ <ref name='bootdev' />
+ </optional>
</element>
<ref name='resources'/>
<ref name='devices-with-emulator'/>
@@ -208,12 +220,29 @@
</optional>
<optional>
<element name='vcpu'>
+ <optional>
+ <attribute name='cpuset' />
+ </optional>
<ref name='countCPU'/>
</element>
</optional>
</interleave>
</define>
+ <define name='clock'>
+ <optional>
+ <element name='clock'>
+ <attribute name='offset'>
+ <choice>
+ <value>localtime</value>
+ <value>utc</value>
+ </choice>
+ </attribute>
+ <empty/>
+ </element>
+ </optional>
+ </define>
+
<!--
A bootloader may be used to extract the OS information instead of
defining the OS parameter in the instance. It points just to the
@@ -238,14 +267,7 @@
</element>
</define>
- <!--
- A paravirtualized linux domain, this requires at least a kernel path
- and the root device, the initrd and command line arguments are optional
- -->
- <define name='linux'>
- <element name='type'>
- <value>linux</value>
- </element>
+ <define name='kernboot'>
<interleave>
<element name='kernel'>
<ref name='absFilePath'/>
@@ -269,8 +291,39 @@
</define>
<!--
- A fully virtualized domain, this requires the path to the loader and
- an optional boot device (hd, fd or cdrom).
+ A paravirtualized linux domain, this requires at least a kernel path
+ and the root device, the initrd and command line arguments are optional
+ -->
+ <define name='linux'>
+ <element name='type'>
+ <value>linux</value>
+ </element>
+ <ref name='kernboot'/>
+ </define>
+
+ <define name='bootdev'>
+ <element name='boot'>
+ <attribute name='dev'>
+ <choice>
+ <value>hd</value>
+ <value>fd</value>
+ <value>cdrom</value>
+ <value>network</value>
+ </choice>
+ </attribute>
+ <empty/>
+ </element>
+ </define>
+
+ <define name='hvmboot'>
+ <choice>
+ <ref name='bootdev'/>
+ <ref name='kernboot'/>
+ </choice>
+ </define>
+
+ <!--
+ A fully virtualized domain and how to boot it.
-->
<define name='hvm'>
<element name='type'>
@@ -281,20 +334,28 @@
<ref name='absFilePath'/>
</element>
<optional>
- <element name='boot'>
- <attribute name='dev'>
- <choice>
- <value>hd</value>
- <value>fd</value>
- <value>cdrom</value>
- </choice>
- </attribute>
- <empty/>
- </element>
+ <ref name='hvmboot' />
</optional>
</interleave>
</define>
+ <define name='diskspec'>
+ <optional>
+ <ref name='driver'/>
+ </optional>
+ <ref name='target'/>
+ <optional>
+ <element name='readonly'>
+ <empty/>
+ </element>
+ </optional>
+ <optional>
+ <element name='shareable'>
+ <empty/>
+ </element>
+ </optional>
+ </define>
+
<!--
A disk description can be either of type file or block
The name of the attribute on the source element depends on the type
@@ -315,43 +376,32 @@
<group>
<attribute name='type'>
<value>file</value>
- </attribute>
+ </attribute>
<interleave>
- <element name='source'>
- <attribute name='file'>
- <ref name='absFilePath'/>
- </attribute>
- <empty/>
- </element>
- <optional>
- <ref name='driver'/>
- </optional>
- <ref name='target'/>
- <optional>
- <ref name='readonly'/>
- </optional>
- </interleave>
+ <element name='source'>
+ <attribute name='file'>
+ <ref name='absFilePath'/>
+ </attribute>
+ <empty/>
+ </element>
+ <ref name='diskspec'/>
+ </interleave>
</group>
<group>
<attribute name='type'>
- <value>block</value>
- </attribute>
- <interleave>
- <element name='source'>
- <attribute name='dev'>
- <ref name='deviceName'/>
- </attribute>
- <empty/>
- </element>
- <optional>
- <ref name='driver'/>
- </optional>
- <ref name='target'/>
- <optional>
- <ref name='readonly'/>
- </optional>
- </interleave>
+ <value>block</value>
+ </attribute>
+ <interleave>
+ <element name='source'>
+ <attribute name='dev'>
+ <ref name='deviceName'/>
+ </attribute>
+ <empty/>
+ </element>
+ <ref name='diskspec'/>
+ </interleave>
</group>
+ <ref name='diskspec'/>
</choice>
</element>
</define>
@@ -361,12 +411,16 @@
<attribute name='dev'>
<ref name='deviceName'/>
</attribute>
- </element>
- </define>
-
- <define name='readonly'>
- <element name='readonly'>
- <empty/>
+ <optional>
+ <attribute name='bus'>
+ <choice>
+ <value>ide</value>
+ <value>virtio</value>
+ <value>fdc</value>
+ <value>xen</value>
+ </choice>
+ </attribute>
+ </optional>
</element>
</define>
@@ -392,7 +446,7 @@
An interface description can either be of type bridge in which case
it will use a bridging source, or of type ethernet which uses a device
source and a device target instead. They both share a set of interface
- options.
+ options. FIXME
-->
<define name='interface'>
<element name='interface'>
@@ -402,12 +456,14 @@
<value>bridge</value>
</attribute>
<interleave>
- <element name='source'>
- <attribute name='bridge'>
- <ref name='deviceName'/>
- </attribute>
- <empty/>
- </element>
+ <optional>
+ <element name='source'>
+ <attribute name='bridge'>
+ <ref name='deviceName'/>
+ </attribute>
+ <empty/>
+ </element>
+ </optional>
<ref name='interface-options'/>
</interleave>
</group>
@@ -416,8 +472,24 @@
<value>ethernet</value>
</attribute>
<interleave>
+ <optional>
+ <element name='source'>
+ <attribute name='dev'>
+ <ref name='deviceName'/>
+ </attribute>
+ <empty/>
+ </element>
+ </optional>
+ <ref name='interface-options'/>
+ </interleave>
+ </group>
+ <group>
+ <attribute name='type'>
+ <value>network</value>
+ </attribute>
+ <interleave>
<element name='source'>
- <attribute name='dev'>
+ <attribute name='network'>
<ref name='deviceName'/>
</attribute>
<empty/>
@@ -478,11 +550,17 @@
<empty/>
</element>
</optional>
+ <optional>
+ <element name='model'>
+ <attribute name='type' />
+ <empty/>
+ </element>
+ </optional>
</interleave>
</define>
<!--
- An emulator descritpion is just a path to the binary used for the task
+ An emulator description is just a path to the binary used for the task
-->
<define name='emulator'>
<element name='emulator'>
@@ -493,7 +571,8 @@
<!--
A graphic description, currently in Xen only 2 types are supported:
- sdl without arguments
- - vnc with a required port and optional listen IP address and password
+ - vnc with a required port and optional listen IP address, password
+ and keymap
-->
<define name='graphic'>
<element name='graphics'>
@@ -518,6 +597,11 @@
<text/>
</attribute>
</optional>
+ <optional>
+ <attribute name='keymap'>
+ <text/>
+ </attribute>
+ </optional>
</group>
</choice>
</element>
@@ -565,24 +649,134 @@
</define>
<!--
+ Specific setup for a qemu emulated character device. Note: this
+ definition doesn't fully specify the constraints on this node.
+ -->
+ <define name='qemucdev'>
+ <attribute name='type'>
+ <choice>
+ <value>dev</value>
+ <value>file</value>
+ <value>pipe</value>
+ <value>unix</value>
+ <value>tcp</value>
+ <value>udp</value>
+ <value>null</value>
+ <value>stdio</value>
+ <value>vc</value>
+ <value>pty</value>
+ </choice>
+ </attribute>
+
+ <interleave>
+ <optional>
+ <oneOrMore>
+ <element name='source'>
+ <optional>
+ <attribute name='mode' />
+ </optional>
+ <optional>
+ <attribute name='path' />
+ </optional>
+ <optional>
+ <attribute name='host' />
+ </optional>
+ <optional>
+ <attribute name='service' />
+ </optional>
+ <optional>
+ <attribute name='wiremode' />
+ </optional>
+ </element>
+ </oneOrMore>
+ </optional>
+ <optional>
+ <element name='protocol'>
+ <optional>
+ <attribute name='type' />
+ </optional>
+ </element>
+ </optional>
+ <optional>
+ <element name='target'>
+ <optional>
+ <attribute name='port' />
+ </optional>
+ </element>
+ </optional>
+ </interleave>
+ </define>
+
+ <!--
The description for a console
just a tty device
-->
<define name='console'>
<element name='console'>
- <attribute name='tty'>
- <ref name='devicePath'/>
- </attribute>
- <empty/>
+ <choice>
+ <group>
+ <optional>
+ <attribute name='tty'>
+ <ref name='devicePath'/>
+ </attribute>
+ </optional>
+ <empty/>
+ </group>
+ <ref name='qemucdev' />
+ </choice>
+ </element>
+ </define>
+
+ <define name='sound'>
+ <oneOrMore>
+ <element name='sound'>
+ <attribute name='model'>
+ <choice>
+ <value>sb16</value>
+ <value>es1370</value>
+ <value>pcspk</value>
+ </choice>
+ </attribute>
+ </element>
+ </oneOrMore>
+ </define>
+
+ <define name='parallel'>
+ <element name='parallel'>
+ <ref name='qemucdev' />
+ </element>
+ </define>
+
+ <define name='serial'>
+ <element name='serial'>
+ <ref name='qemucdev' />
</element>
</define>
+ <define name='input'>
+ <oneOrMore>
+ <element name='input'>
+ <attribute name='type'>
+ <choice>
+ <value>tablet</value>
+ <value>mouse</value>
+ </choice>
+ </attribute>
+ <optional>
+ <attribute name='bus'>
+ <choice>
+ <value>ps2</value>
+ <value>usb</value>
+ <value>xen</value>
+ </choice>
+ </attribute>
+ </optional>
+ </element>
+ </oneOrMore>
+ </define>
+
<!--
- The devices bloc allows:
- - an optional emulator path, restricted to hvm configs but hard to check
- - an optional graphic description , restricted to hvm configs too
- - zero or more disk devices
- - zero or more interface devices
+ Devices attached to a domain.
-->
<define name='devices'>
<element name='devices'>
@@ -602,6 +796,18 @@
<optional>
<ref name='console'/>
</optional>
+ <optional>
+ <ref name='sound'/>
+ </optional>
+ <optional>
+ <ref name='parallel'/>
+ </optional>
+ <optional>
+ <ref name='serial'/>
+ </optional>
+ <optional>
+ <ref name='input'/>
+ </optional>
</interleave>
</element>
</define>
@@ -625,6 +831,18 @@
<optional>
<ref name='console'/>
</optional>
+ <optional>
+ <ref name='sound'/>
+ </optional>
+ <optional>
+ <ref name='parallel'/>
+ </optional>
+ <optional>
+ <ref name='serial'/>
+ </optional>
+ <optional>
+ <ref name='input'/>
+ </optional>
</interleave>
</element>
</define>
16 years, 4 months
[libvirt] Re: Libvir-list Digest, Vol 32, Issue 7
by Tóth István
I took at a look at that code.
The JNI code is basically unchanged from the 0.1 version.
The interesting part is the code is for handling the XML structures used
by libvirt.
You can see how Daniel Schweger's added functionality is meant to be
used in the srtc/testclient/org/libvirt/TestXen.java file.
The way I imagined the java-libvirt architecture is that there is a
lower 'core' level, which is basically a function-for function
equivalent of the C libvirt functionality, with the bare minimum of
object-orientedness thrown in to pass for a proper java library (the
current libvirt in CVS)
Plus, there should/can be anotherl API, that exposes the XML files as
java objects with get/set functions, etc. (It's in the
org.libvirt.schema package in Daniel Schweger's code)
Optionally, there could be higher level API that uses the core and XML
api, and provides a really clean java-style object model, but IO haven't
given it much thought yet.
I think these two or three layers should be clearly demarcated, maybe
even shipped as separate packages, becuse anything that layers on more
functionaity that what the current cvs provides represents design
decisions that are not inherent to libvirt.
One may not want to use the XML technology/object model/whatever that
libvirt-java ships, but rather add their own XML handling stuff/ higher
level abstractions on top of the core libvirt bindings. (for example,
Daniel Schweger's code uses XMLBeans, my original idea was to use JAXB
for the same purpose).
BTW I am working on adding the core bindings for the storage stuff, but
don't expect anything soon, as my day job is currently eating all my time.
regards
István
libvir-list-request(a)redhat.com wrote:
> Send Libvir-list mailing list submissions to
> libvir-list(a)redhat.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.redhat.com/mailman/listinfo/libvir-list
> or, via email, send a message with subject or body 'help' to
> libvir-list-request(a)redhat.com
>
> You can reach the person managing the list at
> libvir-list-owner(a)redhat.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Libvir-list digest..."
>
>
> Today's Topics:
>
> 1. Re: AW: beta libvirt-java port uploaded (Daniel Veillard)
> 2. AW: [libvirt] AW: beta libvirt-java port uploaded
> (Daniel Schwager)
> 3. storage_conf.c: In function 'virStorageSize' (Jaime Traver)
> 4. Re: storage_conf.c: In function 'virStorageSize' (Atsushi SAKAI)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 3 Jul 2008 12:29:04 -0400
> From: Daniel Veillard <veillard(a)redhat.com>
> Subject: Re: [libvirt] AW: beta libvirt-java port uploaded
> To: Daniel Schwager <Daniel.Schwager(a)dtnet.de>
> Cc: libvir-list(a)redhat.com
> Message-ID: <20080703162903.GI1362(a)redhat.com>
> Content-Type: text/plain; charset=us-ascii
>
> On Thu, Jul 03, 2008 at 12:10:40PM +0200, Daniel Schwager wrote:
>
>> Cool - there's an "official" port...
>> http://comments.gmane.org/gmane.comp.emulators.libvirt/7118
>>
>> sorry for my last port, i didn't watch this list in the last time ..
>>
>
> BTW there is a new one 0.1.2 with better portability and JPackage
> compatibility.
> I must admit i'm a bit lost by all the code in your tarball,
> there are changes to libvirt-java, even in code already included in
> 0.1.0 , and a lot of subtrees which seems only loosely coupled to
> libvirt.
> What are the diffs which should be applied to the cirrent 0.1.2
> code base ? and what specifically should be added in libvirt-java
> CVS. The Beans support seems one of them (but i have no idea how
> it's supposed to be used).
> A bit of explanations would go a long way ;-)
>
> Daniel
>
>
16 years, 4 months
Re: [libvirt] storage_conf.c: In function 'virStorageSize'
by Jaime Traver
hi,
thank Atsushi SAKAI i has fixed the problem with your recomendations, but
now it is happened the following
*libvirt_proxy.c: En la función `main':
libvirt_proxy.c:844: aviso: implicit declaration of function `fprintf'
libvirt_proxy.c:844: error: `stderr' undeclared (first use in this function)
libvirt_proxy.c:844: error: (Each undeclared identifier is reported only
once
libvirt_proxy.c:844: error: for each function it appears in.)
libvirt_proxy.c:845: aviso: implicit declaration of function `exit'*
About this i don't see nothing in the mail list. I hope that you can help
me.
thank by advance
revartj
2008/7/4 Jaime Traver <revartj(a)gmail.com>:
> I has done the folllowing changes:
>
> i has modified the file *
> /usr/src/linux-headers-2.6.18-6-xen-686/include/linux/limits.h,* add
>
> #define ULLONG_MAX 18446744073709551615ULL
>
> and also i has saw that file *
> /home/revartj/libvirt/libvirt-0.4.4/src/internal.h* have the include of
> limits.h.
>
> And the result is that it continue playing the same errors.
>
> thank you by the help and excuse me my bad english
>
> if you don't understand somethings, then ask me.
>
>
> 2008/7/4 Jaime Traver <revartj(a)gmail.com>:
>
> I am using i686
>>
>> 2.6.18-6-xen-686 #1 SMP Sat May 24 14:16:03 UTC 2008 *i686* GNU/Linux
>>
>> I will try now modify de limits.h and comment you.
>>
>> thanks
>>
>> 2008/7/4 Atsushi SAKAI <sakaia(a)jp.fujitsu.com>:
>>
>> Hi,
>>>
>>> ULLONG_MAX should be defined on limits.h.
>>> and its limits.h is includes on src/internal.h.
>>> Please check these files.
>>>
>>> By the way, you are using i486?.
>>>
>>>
>>> Thanks
>>> Atsushi SAKAI
>>>
>>>
>>> "Jaime Traver" <revartj(a)gmail.com> wrote:
>>>
>>> > Hi, I am having problem with compilation of libvirt, i has saw one post
>>> > about this in the maillist, but it don't resolved the problem. The
>>> detail of
>>> > erros is:
>>> >
>>> > storage_conf.c: In function 'virStorageSize':
>>> > storage_conf.c:627: error: 'ULLONG_MAX' undeclared (first use in this
>>> > function)
>>> > storage_conf.c:627: error: (Each undeclared identifier is reported only
>>> once
>>> > storage_conf.c:627: error: for each function it appears in.)
>>> > make[2]: *** [libvirt_la-storage_conf.lo] Error 1
>>> > make[2]: se sale del directorio
>>> `/home/revartj/libvirt/libvirt-0.4.4/src'
>>> > make[1]: *** [all-recursive] Error 1
>>> > make[1]: se sale del directorio `/home/revartj/libvirt/libvirt-0.4.4'
>>> > make: *** [all] Error 2
>>> >
>>> >
>>> > Any information about SO:
>>> >
>>> > EREBO:/home/revartj/libvirt/libvirt-0.4.4# *uname -a*
>>> > Linux EREBO 2.6.18-6-xen-686 #1 SMP Sat May 24 14:16:03 UTC 2008 i686
>>> > GNU/Linux
>>> >
>>> > EREBO:/home/revartj/libvirt/libvirt-0.4.4# *gcc -v*
>>> > Using built-in specs.
>>> > Target: i486-linux-gnu
>>> > Configured with: ../src/configure -v
>>> > --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
>>> > --enable-shared --with-system-zlib --libexecdir=/usr/lib
>>> > --without-included-gettext --enable-threads=posix --enable-nls
>>> > --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
>>> > --enable-libstdcxx-debug --enable-mpfr --with-tune=i686
>>> > --enable-checking=release i486-linux-gnu
>>> > Thread model: posix
>>> > gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
>>> >
>>> > Someboy know how i can resolved this error.
>>> >
>>> > Thank everybody by advance.
>>> >
>>> > revartj
>>>
>>>
>>>
>>
>
16 years, 4 months
[libvirt] Xen config files again
by Thomas Moyer
I've seen in the src tree that there are functions to read and use Xen
configuration files. Are these functions available in the Python
bindings or do I need to use C to get access to them? What I am
mostly interested in doing is parsing the Xen config file and getting
back the XML version that I can store and use later on.
--
Thomas Moyer
Graduate Student
CSE Department
Penn State University
tmmoyer(a)cse.psu.edu
http://www.cse.psu.edu/~tmmoyer
16 years, 4 months
[libvirt] 'starting' a domain using Python libvirt..
by Michael March
I'm trying to figure out how to start a domain .. and I can't figure out
what method to use..
When I do this:
>>> dir(conn.lookupByName('my-vm-1'))
I get these options:
['ID', 'OSType', 'UUID', 'UUIDString', 'XMLDesc', '__del__', '__doc__',
'__init__', '__module__', '_conn', '_o', 'attachDevice', 'autostart',
'blockStats', 'connect', 'coreDump', 'create', 'destroy',
'detachDevice', 'info', 'interfaceStats', 'maxMemory', 'maxVcpus',
'migrate', 'name', 'pinVcpu', 'reboot', 'resume', 'save',
'setAutostart', 'setMaxMemory', 'setMemory', 'setVcpus', 'shutdown',
'suspend', 'undefine']
I don't see a method to start a domain up.. What am I missing here?
thanks!
16 years, 4 months
[libvirt] storage_conf.c: In function 'virStorageSize'
by Jaime Traver
Hi, I am having problem with compilation of libvirt, i has saw one post
about this in the maillist, but it don't resolved the problem. The detail of
erros is:
storage_conf.c: In function 'virStorageSize':
storage_conf.c:627: error: 'ULLONG_MAX' undeclared (first use in this
function)
storage_conf.c:627: error: (Each undeclared identifier is reported only once
storage_conf.c:627: error: for each function it appears in.)
make[2]: *** [libvirt_la-storage_conf.lo] Error 1
make[2]: se sale del directorio `/home/revartj/libvirt/libvirt-0.4.4/src'
make[1]: *** [all-recursive] Error 1
make[1]: se sale del directorio `/home/revartj/libvirt/libvirt-0.4.4'
make: *** [all] Error 2
Any information about SO:
EREBO:/home/revartj/libvirt/libvirt-0.4.4# *uname -a*
Linux EREBO 2.6.18-6-xen-686 #1 SMP Sat May 24 14:16:03 UTC 2008 i686
GNU/Linux
EREBO:/home/revartj/libvirt/libvirt-0.4.4# *gcc -v*
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --with-tune=i686
--enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
Someboy know how i can resolved this error.
Thank everybody by advance.
revartj
16 years, 4 months
