Re: [libvirt] [PATCH]: vgscan before doing logical pool discovery
On Tue, Nov 04, 2008 at 06:32:37PM +0100, Chris Lalancette wrote: Assume that you have an iSCSI target available, and on that iSCSI target 1 LUN is exported. On that 1 LUN, you have an LVM volume group (say, myvg), with 2 logical volumes (say, lv1 and lv2). Now you execute the following sequence of commands: 1) virsh define iscsi_pool.xml 2) virsh start iscsi_pool 3) virsh find-storage-pool-sources-as logical With that sequence, you would expect step 3) to return XML similar to: sourcessourcenamemyvg/namedevice path='/dev/sdb'//source/sources However, what you instead get is: sources/. That's because if you just try to do storage pool discovery on a logical pool without ever touching the logical pool in any fashion, pvs (what we use to do discovery) doesn't return anything. If you touch the logical volume group at all (say, with vgscan), they then suddenly appear. To make sure we see all of the potential volume groups when doing pool discovery, make sure to run vgscan before we run pvs. With this patch in place, logical discovery just does the right thing. ACK, this makes total sense. 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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH]: vgscan before doing logical pool discovery
Daniel P. Berrange wrote: On Tue, Nov 04, 2008 at 06:32:37PM +0100, Chris Lalancette wrote: Assume that you have an iSCSI target available, and on that iSCSI target 1 LUN is exported. On that 1 LUN, you have an LVM volume group (say, myvg), with 2 logical volumes (say, lv1 and lv2). Now you execute the following sequence of commands: 1) virsh define iscsi_pool.xml 2) virsh start iscsi_pool 3) virsh find-storage-pool-sources-as logical With that sequence, you would expect step 3) to return XML similar to: sourcessourcenamemyvg/namedevice path='/dev/sdb'//source/sources However, what you instead get is: sources/. That's because if you just try to do storage pool discovery on a logical pool without ever touching the logical pool in any fashion, pvs (what we use to do discovery) doesn't return anything. If you touch the logical volume group at all (say, with vgscan), they then suddenly appear. To make sure we see all of the potential volume groups when doing pool discovery, make sure to run vgscan before we run pvs. With this patch in place, logical discovery just does the right thing. ACK, this makes total sense. Thanks, committed. -- Chris Lalancette -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] plug two leaks and fix a diagnostic
On Wed, Nov 05, 2008 at 02:53:19PM +0100, Jim Meyering wrote: Without this patch, running make check would trigger this minor leak: 10 bytes in 1 blocks are definitely lost in loss record 1 of 20 at 0x4A0739E: malloc (vg_replace_malloc.c:207) by 0x3F872808A1: strdup (strdup.c:43) by 0x4CA2503: qemudLoadDriverConfig (qemu_conf.c:70) by 0x4CA7EA7: qemudStartup (qemu_driver.c:216) by 0x4C3AEBC: __virStateInitialize (libvirt.c:592) by 0x4096B6: qemudInitialize (qemud.c:738) by 0x40CCCF: main (qemud.c:2216) Looking into it, I found there were actually two separate leaks and an erroneous diagnostic. This fixes them: The patch looks fine to me, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ [EMAIL PROTECTED] | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] plug two leaks and fix a diagnostic
Daniel Veillard [EMAIL PROTECTED] wrote: On Wed, Nov 05, 2008 at 02:53:19PM +0100, Jim Meyering wrote: Without this patch, running make check would trigger this minor leak: 10 bytes in 1 blocks are definitely lost in loss record 1 of 20 at 0x4A0739E: malloc (vg_replace_malloc.c:207) by 0x3F872808A1: strdup (strdup.c:43) by 0x4CA2503: qemudLoadDriverConfig (qemu_conf.c:70) by 0x4CA7EA7: qemudStartup (qemu_driver.c:216) by 0x4C3AEBC: __virStateInitialize (libvirt.c:592) by 0x4096B6: qemudInitialize (qemud.c:738) by 0x40CCCF: main (qemud.c:2216) Looking into it, I found there were actually two separate leaks and an erroneous diagnostic. This fixes them: The patch looks fine to me, Thanks. I've committed it. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] plug two leaks and fix a diagnostic
Without this patch, running make check would trigger this minor leak:
10 bytes in 1 blocks are definitely lost in loss record 1 of 20
at 0x4A0739E: malloc (vg_replace_malloc.c:207)
by 0x3F872808A1: strdup (strdup.c:43)
by 0x4CA2503: qemudLoadDriverConfig (qemu_conf.c:70)
by 0x4CA7EA7: qemudStartup (qemu_driver.c:216)
by 0x4C3AEBC: __virStateInitialize (libvirt.c:592)
by 0x4096B6: qemudInitialize (qemud.c:738)
by 0x40CCCF: main (qemud.c:2216)
Looking into it, I found there were actually two separate leaks
and an erroneous diagnostic. This fixes them:
From b1f17b05e59cf12aa3f73fde1be713dbadf02f76 Mon Sep 17 00:00:00 2001
From: Jim Meyering [EMAIL PROTECTED]
Date: Wed, 5 Nov 2008 14:50:24 +0100
Subject: [PATCH] plug two leaks and fix a diagnostic
* src/qemu_conf.c (qemudLoadDriverConfig): Don't leak -vncListen.
Fix an erroneous copy-and-pasted diagnostic.
* src/qemu_driver.c (qemudShutdown): Don't leak another -vncListen.
---
src/qemu_conf.c |3 ++-
src/qemu_driver.c |1 +
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/qemu_conf.c b/src/qemu_conf.c
index 54ac23d..0e3b959 100644
--- a/src/qemu_conf.c
+++ b/src/qemu_conf.c
@@ -118,9 +118,10 @@ int qemudLoadDriverConfig(struct qemud_driver *driver,
p = virConfGetValue (conf, vnc_listen);
CHECK_TYPE (vnc_listen, VIR_CONF_STRING);
if (p p-str) {
+VIR_FREE(driver-vncListen);
if (!(driver-vncListen = strdup(p-str))) {
qemudReportError(NULL, NULL, NULL, VIR_ERR_NO_MEMORY,
- %s, _(failed to allocate vncTLSx509certdir));
+ %s, _(failed to allocate vnc_listen));
virConfFree(conf);
return -1;
}
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index 4adeb73..5d108ed 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -314,6 +314,7 @@ qemudShutdown(void) {
VIR_FREE(qemu_driver-configDir);
VIR_FREE(qemu_driver-autostartDir);
VIR_FREE(qemu_driver-vncTLSx509certdir);
+VIR_FREE(qemu_driver-vncListen);
/* Free domain callback list */
virDomainEventCallbackListFree(qemu_driver-domainEventCallbacks);
--
1.6.0.3.756.gb776d
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] making (newly public) EventImpl interface moreconsistent
On Tue, Nov 04, 2008 at 07:04:54AM -0500, Ben Guthro wrote: I'll respond now while I'm looking at this, as Dave may not be able to get to this until later today I was talking with Dave about this yesterday, and if I'm not mistaken, this idea comes from some of the implementations for either DevKit, DBus, or libHAL (I can't remember which one he was looking at at that particular moment) Essentially, if I understand the model correctly, they have 2 fd sets - one for reading, one for writing. DevKit HAL are just APIs built ontop of DBus, so the key here is integration with DBus watch APIs. AFAIK, those only require that the event loop impl have one callback per unique FD. I could see an additional use where you have multiple callbacks - one for data, and one for error handling. These 2 calls to AddHandle would take the sale fd, but would have different event mask sets, for the different callbacks. QT allows this model for its QSocketNotifier class, indeed it actually requires it, but GLib leaves this unspecified, and I've not been able to determine from the code whether its possible to register the same FD twice with GLib. 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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] add the check whether the domain has already used a disk which attach
On Wed, Nov 05, 2008 at 10:05:14AM +0900, S.Sakamoto wrote: Hi, attach-disk does not give an error, when the domain which is attached has already used the source which attach. This has danger of the data corruption. I make the patch to add the check of this. This patch outputs an error, when the domain which is attached has already used the source which attach. What hypervisor were you testing with ? AFAIR, XenD should already raise an appropriate error in this scenario. The libvirt QEMU driver, however, does need this checking. That should really be done in the qemu_driver.c attach method. 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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] dynamic debug patch
First version of a small patch allowing to gather debug informations
from a running libvirt daemon. Basically one can send signal USR2
to the daemon, the daemon will from that point dump its current internal
state and all verbose debug output to a file /tmp/libvirt_debug_.
When sending back signal USR2 the file is closed and can be looked at
for analysis, this allow to save extensive debug informations from a
running daemon.
The patch is rather minimal right now, it just applies to
qemud/qemud.c, modifies it to have global variables for error and
information output FILE, an init routing setting them up and hooking
a handler for USR2, the handler, a very minimal state dump. But it
works as is.
Now I would like to extend that debugging to the library itself, so
any app linking to libvirt can be debugged in the same way. I would
also like to add debugging routines for most internal data structures.
I'm still wondering about the best form for those, should they use
a FILE * argument, an fd argument or a virBufferPtr for genericity
(probably the later would make most sense).
#ifdef ENABLE_DEBUG
void virConnectDebug(virBufferPtr buf, virConnectPtr conn);
#endif
and similar for main internal data structures and drivers
The patch is just a work in progress but trying to get early feedback.
Maybe this could be used to get remote introspection capabilities too
but ATM I'm more looking at providing an easy way to get debug
informations on a libvirt program.
Also I'm unclear, do we really want to have all the debug strings
internationalized with _() , that's more work for localization team
and it's unclear this would benefit 'end users'.
Patch and an example of log attached,
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
[EMAIL PROTECTED] | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
Index: qemud/qemud.c
===
RCS file: /data/cvs/libxen/qemud/qemud.c,v
retrieving revision 1.109
diff -u -p -r1.109 qemud.c
--- qemud/qemud.c 4 Nov 2008 23:22:06 - 1.109
+++ qemud/qemud.c 5 Nov 2008 14:51:50 -
@@ -128,6 +128,116 @@ static void sig_handler(int sig, siginfo
errno = origerrno;
}
+static FILE *error_out = NULL;
+static FILE *info_out = NULL;
+static int debug_activated = 0;
+
+#ifdef ENABLE_DEBUG
+
+/*
+ * Signal entry point on USR2 we can't do anything at that point except
+ * log the signal and have qemudToggleDebug called when back into the
+ * main loop.
+ */
+static void sig_debug(int sig, siginfo_t * siginfo, void* context) {
+sig_handler(sig, siginfo, context);
+}
+
+/*
+ * Debug the state of a client
+ */
+static void qemudDumpDebugClient(struct qemud_client *client) {
+if (client-magic != QEMUD_CLIENT_MAGIC) {
+qemudLog(QEMUD_DEBUG,
+ _(\nQEmud client: invalid magic %X, skipping\n),
+ (unsigned int) client-magic);
+return;
+}
+qemudLog(QEMUD_DEBUG, _(QEmud client: fd %d readonly %d mode %d),
+ client-fd, client-readonly, client-mode);
+
+/* TODO: more complete dump of state, especially the connection */
+}
+
+/*
+ * Debug the state of a server
+ */
+static void qemudDumpDebugServer(struct qemud_server *server) {
+struct qemud_client *client;
+
+if (server == NULL) {
+qemudLog(QEMUD_DEBUG, %s,
+_(QEmud server: NULL pointer\n));
+return;
+}
+qemudLog(QEMUD_DEBUG,
+_(QEmud server: listening on %d sockets, %d clients\n),
+ server-nsockets, server-nclients);
+
+client = server-clients;
+
+while (client != NULL) {
+qemudDumpDebugClient(client);
+client = client-next;
+}
+}
+
+/*
+ * Toggle the debug status on/off, on on create a new temporary
+ * debug file and start saving the output there
+ * It is called when the signal USR2 is received.
+ */
+static void qemudToggleDebug(struct qemud_server *server) {
+if (debug_activated == 0) {
+char path[50] = /tmp/libvirt_debug_XX;
+int fd = mkstemp(path);
+if (fd = 0) {
+error_out = fdopen(fd, a);
+if (error_out != NULL) {
+info_out = error_out;
+debug_activated = 1;
+qemudDumpDebugServer(server);
+} else {
+qemudLog(QEMUD_ERR,
+ %s, _(Failed to create temporary debug file));
+error_out = stderr;
+}
+} else {
+qemudLog(QEMUD_ERR,
+ %s, _(Failed to get temporary debug file));
+}
+} else {
+debug_activated = 0;
+fclose(error_out);
+error_out = stderr;
+info_out = stdout;
+}
+}
+#endif
+
+/*
+ * Set up the debugging environment
+ */
+static void qemudInitDebug(void) {
+#ifdef ENABLE_DEBUG
+struct sigaction oldact;
+struct
Re: [libvirt] [RFC] making (newly public) EventImpl interface moreconsistent
On Wed, 2008-11-05 at 11:51 +, Daniel P. Berrange wrote:
DevKit HAL are just APIs built ontop of DBus, so the key here
is integration with DBus watch APIs. AFAIK, those only require
that the event loop impl have one callback per unique FD.
Here's what I'm seeing when registering for dbus watch callbacks. In
halNodeDriverStartup (in node_device_hal.c in the submitted host dev
enum patch), I register for dbus watch callbacks:
/* Register dbus watch callbacks */
if (!dbus_connection_set_watch_functions(dbus_conn,
add_dbus_watch,
remove_dbus_watch,
toggle_dbus_watch,
NULL, NULL)) {
fprintf(stderr, %s: dbus_connection_set_watch_functions failed\n,
__FUNCTION__);
goto failure;
}
And then I instrumented add/remove/toggle_dbus_watch. add_dbus_watch is
called twice as soon as we register the watch functions:
add_dbus_watch 0xae4200 fd 6 flags 0x2 enabled 0
add_dbus_watch 0xaeb950 fd 6 flags 0x1 enabled 1
*** DUPLICATE HANDLE 6 at [0] ***
So here we have two different DBusWatches sharing the same unix fd. In
this case, the first one (POLLOUT flags) is disabled, and never toggled,
so things happen to work just fine. The current qemud AddHandleImpl
will in fact overwrite the first entry with the second, so it has
totally lost the first watch.
But this is just lucky. Because the behavior of adding a duplicate
handle is undefined, the implementation could just as well have ignored
the second entry, in which case DBus events would never be received.
I'll look into the glib handle-watching code (which I'm not familiar
with currently) and see how it behaves, but I can't imagine it doesn't
support this when DBus watches clearly require it.
Dave
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] dynamic debug patch
On Wed, Nov 05, 2008 at 04:26:15PM +0100, Daniel Veillard wrote:
First version of a small patch allowing to gather debug informations
from a running libvirt daemon. Basically one can send signal USR2
to the daemon, the daemon will from that point dump its current internal
state and all verbose debug output to a file /tmp/libvirt_debug_.
When sending back signal USR2 the file is closed and can be looked at
for analysis, this allow to save extensive debug informations from a
running daemon.
Hardcoding a file in /tmp is not very good practice - it'll certainly
not play nicely with SELinux. We should make the logfile name be
configurable via /etc/libvirt/libvirtd.conf.
The patch is rather minimal right now, it just applies to
qemud/qemud.c, modifies it to have global variables for error and
information output FILE, an init routing setting them up and hooking
a handler for USR2, the handler, a very minimal state dump. But it
works as is.
Now I would like to extend that debugging to the library itself, so
any app linking to libvirt can be debugged in the same way. I would
also like to add debugging routines for most internal data structures.
I'm still wondering about the best form for those, should they use
a FILE * argument, an fd argument or a virBufferPtr for genericity
(probably the later would make most sense).
#ifdef ENABLE_DEBUG
void virConnectDebug(virBufferPtr buf, virConnectPtr conn);
#endif
and similar for main internal data structures and drivers
The patch is just a work in progress but trying to get early feedback.
Maybe this could be used to get remote introspection capabilities too
but ATM I'm more looking at providing an easy way to get debug
informations on a libvirt program.
I think use virBufferPtr is rather too cumbersome for the calling
program. The internal API for logging currently just takes
void qemudLog(int priority, const char *fmt, ...)
Either we can pass variable args out to the app, or format the error
message and then pass it out. The calling app can write this straight
to a file, send to syslog, or anything else it wants, without having
the intermediate step of potentially uneccessary buffering. I think
it'll also be desirable to include a 'category' string to allow
applications to filter the messages it uses.
In the Java world, with log4j, the typical pattern is that each class
registers a logging category matching its classname, eg you might have
org.libvirt.Connect, org.libvirt.Domain, etc.
The application using the class can configure the log4j infrastructure
to turn on/off log messages per-category. We need a similar capability
in libvirt - the existing logging in the daemon is already non-scalable
because the 'EVENT' messages are soo frequent they typically drown out
the more interesting stuff from the daemon.
In parallel with debugging / logging of functional aspects of the
daemon / library, it is also desirable to get the ability to record
a log of operations invoked on objects. eg, I want to record all
operation invoked against a particular driver, so as a support
person I can ask a bug-reporter to send me the log of the operations
they did leading upto the problem.
As an application using libvirt API, I'd expect to have ability to
register a callback to receive debug info, and APIs to control the
logging level
enum {
VIR_LOG_DEBUG,
VIR_LOG_INFO,
VIR_LOG_WARN,
VIR_LOG_ERROR,
};
typedef void (*virLogHandler)(const char *category,
int priority,
const char *msg);
virLogAddHandler(virLogHandler callback);
virLogSetDefaultPriority(int priority);
virLogSetPriority(const char *category,
int priority);
And a semi-public internal API (ie for use by libvirt.so and libvirtd)
virLogMessage(const char *category, int priority, const char *fmt, );
I'd be inclined to say that categories are named to match the filename,
so if you wanted to log messasges from the event.c file, at a level of
'INFO' or higher, you'd do
void mylogger(const char *cat, int prior, const char *msg) {
fprintf(stderr, %s, msg);
}
virLogAddHandler(mylogger);
virLogSetPriority(file.events, VIR_INFO)
The default priority would be 'WARN', unless explicitly set for a
category.
In the context of libvirtd daemon, if you passed '--verbose' we'd
set virLogDefaultPriority(VIR_LOG_INFO) and if you passed --debug
we'd set it to VIR_LOG_DEBUG. So the same public API would be useful
both for libvirtd, and other apps linking to libvirt.so in just the
same way - we'd merely need to expose virLogMessage() to the daemon
so its own log messages can flow through the same channels as those
inside the library.
Currently we toggle between using stderr, and syslog according to
whether the --deamon flag is passed. This isn't particularly
great. We should be configurable independantly of thise.
I'd
Re: [libvirt] [RFC] making (newly public) EventImpl interface moreconsistent
On Wed, Nov 05, 2008 at 11:26:07AM -0500, David Lively wrote:
On Wed, 2008-11-05 at 11:51 +, Daniel P. Berrange wrote:
DevKit HAL are just APIs built ontop of DBus, so the key here
is integration with DBus watch APIs. AFAIK, those only require
that the event loop impl have one callback per unique FD.
Here's what I'm seeing when registering for dbus watch callbacks. In
halNodeDriverStartup (in node_device_hal.c in the submitted host dev
enum patch), I register for dbus watch callbacks:
/* Register dbus watch callbacks */
if (!dbus_connection_set_watch_functions(dbus_conn,
add_dbus_watch,
remove_dbus_watch,
toggle_dbus_watch,
NULL, NULL)) {
fprintf(stderr, %s: dbus_connection_set_watch_functions failed\n,
__FUNCTION__);
goto failure;
}
And then I instrumented add/remove/toggle_dbus_watch. add_dbus_watch is
called twice as soon as we register the watch functions:
add_dbus_watch 0xae4200 fd 6 flags 0x2 enabled 0
add_dbus_watch 0xaeb950 fd 6 flags 0x1 enabled 1
*** DUPLICATE HANDLE 6 at [0] ***
So here we have two different DBusWatches sharing the same unix fd. In
this case, the first one (POLLOUT flags) is disabled, and never toggled,
so things happen to work just fine. The current qemud AddHandleImpl
will in fact overwrite the first entry with the second, so it has
totally lost the first watch.
But this is just lucky. Because the behavior of adding a duplicate
handle is undefined, the implementation could just as well have ignored
the second entry, in which case DBus events would never be received.
I'll look into the glib handle-watching code (which I'm not familiar
with currently) and see how it behaves, but I can't imagine it doesn't
support this when DBus watches clearly require it.
I think the problem here is that the existing Avahi mdns code in the
libvirtd daemon is also already using DBus, and has already setup the
DBus system bus instances to integrate with the libvirtd event loop.
By default, there is a single DBus system bus connection in the app
which is shared amongst all users. The DBus API spec for its watch
functions mandates that the application only setup watches once per
connection, so having both the Avahi and HAL/DevKit code in libvirt
call dbus_connection_set_watch_functions() against the shared connection
is in fact a bug. For added fun, PolicyKit code in the daemon also makes
use of DBus, but doesn't (yet) need callbacks so hasn't done mainloop
integration.
So the flaw here is that the individual drivers should not all be
attempting to setup integration with the shared dbus system bus
connection. Either each driver should use a private dbus system bus
conenction, or the main daemon startup code should take responsibility
for integrating the shared connection instance into its main loop.
I'd be inclined to go for the latter. For simplicitly, I think you
ought to simply be able to remove the dbus_connection_set_watch_functions
call from the driver, and rely on fact that Avahi code has already done
this.
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@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Problem with fullyvirtualized guest direct kernel boot
Hi All, I am trying to use fullyvirtualized guest direct kernel boot, but all I see is the following error: libvir: Xen Daemon error : POST operation failed: (xend.err 'Error creating domain: (2, \'Invalid kernel\', elf_xen_note_check: ERROR: Not a Xen-ELF image: No ELF notes or \'__xen_guest\' section found.\\n)') Kernel, initrd and root file system are extracted from working Fedora 9 disk image without any additional tinkering. Guest Fedora is clean and was installed from scratch. When I use this whole disk image with fullyvirtualized guest BIOS boot with, everything works fine. I also tried paravirtualized guest bootloader with another linux kernel and it also works fine. Xen version is 3.2.1-rc1-pre. Host OS is Ubuntu Hardy. Here is the libvirt config for direct kernel boot: domain type='xen' id='18' nametest1/name uuid4dea22b31d52d8f32516782e98ab3fa0/uuid os typelinux/type loader/usr/lib/xen/boot/hvmloader/loader kernel/tmp/vmlinuz-2.6.25-14.fc9.i686/kernel initrd/tmp/initrd-2.6.25-14.fc9.i686.img/initrd root/dev/sda1/root cmdlinero/cmdline /os memory524288/memory vcpu1/vcpu devices emulator/usr/lib/xen/bin/qemu-dm/emulator disk type='file' driver name=tap type=aio/ source file='/tmp/f9_disassembled/root.img'/ target dev='sda1'/ /disk disk type='file' driver name=tap type=aio/ source file='/tmp/swap'/ target dev='sda3'/ /disk interface type='bridge' source bridge='eth0'/ mac address='00:16:3e:5d:c7:9e'/ script path='/etc/xen/scripts/vif-bridge'/ /interface graphics type='vnc' port='5904'/ /devices /domain What do you think can be the cause of this issue? -- Thanks, Max libvir-list@redhat.com -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Problem with fullyvirtualized guest direct kernel boot
On Wed, Nov 05, 2008 at 09:28:16PM +0300, Max Martynov wrote: Hi All, I am trying to use fullyvirtualized guest direct kernel boot, but all I see is the following error: libvir: Xen Daemon error : POST operation failed: (xend.err 'Error creating domain: (2, \'Invalid kernel\', elf_xen_note_check: ERROR: Not a Xen-ELF image: No ELF notes or \'__xen_guest\' section found.\\n)') Kernel, initrd and root file system are extracted from working Fedora 9 disk image without any additional tinkering. Guest Fedora is clean and was installed from scratch. When I use this whole disk image with fullyvirtualized guest BIOS boot with, everything works fine. I also tried paravirtualized guest bootloader with another linux kernel and it also works fine. Xen version is 3.2.1-rc1-pre. Host OS is Ubuntu Hardy. That Xen is too probably old - you need 3.3.x or newer. The Xen 3.2 in Fedora has a backport of this functionality, and I doubt the Ubuntu xen has copied that. Here is the libvirt config for direct kernel boot: domain type='xen' id='18' nametest1/name uuid4dea22b31d52d8f32516782e98ab3fa0/uuid os typelinux/type This tag is telling Xen todo a paravirt guest, but you say you want a fullvirt one, so replace this with typehvm/type loader/usr/lib/xen/boot/hvmloader/loader kernel/tmp/vmlinuz-2.6.25-14.fc9.i686/kernel initrd/tmp/initrd-2.6.25-14.fc9.i686.img/initrd root/dev/sda1/root cmdlinero/cmdline /os memory524288/memory vcpu1/vcpu devices emulator/usr/lib/xen/bin/qemu-dm/emulator disk type='file' driver name=tap type=aio/ source file='/tmp/f9_disassembled/root.img'/ target dev='sda1'/ /disk disk type='file' driver name=tap type=aio/ source file='/tmp/swap'/ target dev='sda3'/ /disk interface type='bridge' source bridge='eth0'/ mac address='00:16:3e:5d:c7:9e'/ script path='/etc/xen/scripts/vif-bridge'/ /interface graphics type='vnc' port='5904'/ /devices /domain 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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Problem with fullyvirtualized guest direct kernel boot
On Wed, Nov 5, 2008 at 9:34 PM, Daniel P. Berrange [EMAIL PROTECTED] wrote: On Wed, Nov 05, 2008 at 09:28:16PM +0300, Max Martynov wrote: Hi All, I am trying to use fullyvirtualized guest direct kernel boot, but all I see is the following error: libvir: Xen Daemon error : POST operation failed: (xend.err 'Error creating domain: (2, \'Invalid kernel\', elf_xen_note_check: ERROR: Not a Xen-ELF image: No ELF notes or \'__xen_guest\' section found.\\n)') Kernel, initrd and root file system are extracted from working Fedora 9 disk image without any additional tinkering. Guest Fedora is clean and was installed from scratch. When I use this whole disk image with fullyvirtualized guest BIOS boot with, everything works fine. I also tried paravirtualized guest bootloader with another linux kernel and it also works fine. Xen version is 3.2.1-rc1-pre. Host OS is Ubuntu Hardy. That Xen is too probably old - you need 3.3.x or newer. The Xen 3.2 in Fedora has a backport of this functionality, and I doubt the Ubuntu xen has copied that. Thanks, I will try to do that. However, the sample for fullyvirtualized guest direct kernel boot uses Fedora. Here is the libvirt config for direct kernel boot: domain type='xen' id='18' nametest1/name uuid4dea22b31d52d8f32516782e98ab3fa0/uuid os typelinux/type This tag is telling Xen todo a paravirt guest, but you say you want a fullvirt one, so replace this with typehvm/type Yes, this was just a typo, because I tried several variants. It was hvm when I tested it. loader/usr/lib/xen/boot/hvmloader/loader kernel/tmp/vmlinuz-2.6.25-14.fc9.i686/kernel initrd/tmp/initrd-2.6.25-14.fc9.i686.img/initrd root/dev/sda1/root cmdlinero/cmdline /os memory524288/memory vcpu1/vcpu devices emulator/usr/lib/xen/bin/qemu-dm/emulator disk type='file' driver name=tap type=aio/ source file='/tmp/f9_disassembled/root.img'/ target dev='sda1'/ /disk disk type='file' driver name=tap type=aio/ source file='/tmp/swap'/ target dev='sda3'/ /disk interface type='bridge' source bridge='eth0'/ mac address='00:16:3e:5d:c7:9e'/ script path='/etc/xen/scripts/vif-bridge'/ /interface graphics type='vnc' port='5904'/ /devices /domain 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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] dynamic debug patch
On Wed, Nov 05, 2008 at 08:49:23PM +0100, Daniel Veillard wrote:
On Wed, Nov 05, 2008 at 04:42:21PM +, Daniel P. Berrange wrote:
On Wed, Nov 05, 2008 at 04:26:15PM +0100, Daniel Veillard wrote:
First version of a small patch allowing to gather debug informations
from a running libvirt daemon. Basically one can send signal USR2
to the daemon, the daemon will from that point dump its current internal
state and all verbose debug output to a file /tmp/libvirt_debug_.
When sending back signal USR2 the file is closed and can be looked at
for analysis, this allow to save extensive debug informations from a
running daemon.
Hardcoding a file in /tmp is not very good practice - it'll certainly
not play nicely with SELinux. We should make the logfile name be
I don't see why SELinux should object a binary open and write a file
into /tmp/ . Also that's a path that a binary linking to libvirt
but running under as non-root can still use.
/tmp/libvirt_debug_ is of course opened with mkstemp !
configurable via /etc/libvirt/libvirtd.conf.
Which is libvirtd specific. Seems I failed to carry my suggestion
that the thing should work work any app linked to libvirt shared lib
even if my initial patch didn't do this.
That's the key comment missing - all your code was targetting the
daemon, so I didn't realize you wanted any client app to use this.
In parallel with debugging / logging of functional aspects of the
daemon / library, it is also desirable to get the ability to record
a log of operations invoked on objects. eg, I want to record all
operation invoked against a particular driver, so as a support
person I can ask a bug-reporter to send me the log of the operations
they did leading upto the problem.
yes that's the goal.
As an application using libvirt API, I'd expect to have ability to
register a callback to receive debug info, and APIs to control the
logging level
enum {
VIR_LOG_DEBUG,
VIR_LOG_INFO,
VIR_LOG_WARN,
VIR_LOG_ERROR,
};
typedef void (*virLogHandler)(const char *category,
int priority,
const char *msg);
virLogAddHandler(virLogHandler callback);
virLogSetDefaultPriority(int priority);
virLogSetPriority(const char *category,
int priority);
Okay, that's an API, expecting the app will use it. What i want is
allow debug without the application being modified which is rather
different.
I don't think libraries have any business hooking into application
signal handlers, because each app has its own preferred debugging
infrastructure. In Java, you'd want to hook all this info into log4j,
so it is interleaving in the reast of the application logs to get
contextual info. Likewise in virt-manager, a separate logfile in
/tmp is not particularly useful. We have extensive logging builtin
to virt-manager and I'd want the libvirt info interleaved into this,
hence my proposal for the API to let apps deal with it as they see
fit.
And a semi-public internal API (ie for use by libvirt.so and libvirtd)
virLogMessage(const char *category, int priority, const char *fmt,
);
That's fine but i would rather structure object dump based on
something more neutral, which is why i think the dump to a buffer
is more generally useful. that could be reused in various ways.
Currently we toggle between using stderr, and syslog according to
whether the --deamon flag is passed. This isn't particularly
great. We should be configurable independantly of thise.
I'd expect /etc/libvirt/libvirtd.conf to allow you to set
# Choice of 'null', 'syslog', 'stderr', 'file'
log.backend = syslog
# If 'file' was chosen, then also allow
log.file = /var/log/libvirtd.log
# or if 'syslog' was chosen, then allow admin to set the
# syslog facility name for openlog() call.
log.syslog = libvirtd
# One of VIR_LOG_XXX constants
log.priority = WARN
# And per category overrides
log.category.events = DEBUG
log.category.mdns = INFO
We already have SIGUSR1 hooked up to make it re-read the domain XML
files, so we could extend this to also re-read the master config
file. So if someone wanted to temporarily debug the system they
Hum, that's libvirtd specific.
Intentionally so - libvirt library shouldn't impose the debugging
process on applications, it should be allowing apps to feed libvirt
debugging info into its existing debug infrastructure. Nearly all
applications have some form of debugging mode of their own we can
integrate with.
could just edit 'log.backend' from 'null' to 'file', and send the
'SIGUSR1'. Or if they already have it logging to a file by default
and just wanted to increase verbosity, they'd edit 'log.priority'
and send SIGUSR1.
It's still quite a
Re: [libvirt] [PATCH] dynamic debug patch
On Wed, Nov 05, 2008 at 08:15:31PM +, Daniel P. Berrange wrote: On Wed, Nov 05, 2008 at 08:49:23PM +0100, Daniel Veillard wrote: Okay, that's an API, expecting the app will use it. What i want is allow debug without the application being modified which is rather different. I don't think libraries have any business hooking into application signal handlers, because each app has its own preferred debugging infrastructure. And sometimes you just can't expect the app to pass it. SIGUSR2 is hooked in gamin library, which for quite a while was linked to all desktop apps. This never raised any problem, but allowed to get debug informations in situations where it's hard to activate a logger. The more complex the interaction of the library with the system the more it's useful to have this kind of debugging available in my opinion. In Java, you'd want to hook all this info into log4j, You're still thinking in terms of application driven logging, and this mechanism is different. They suit different purpose. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ [EMAIL PROTECTED] | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] making (newly public) EventImpl interface moreconsistent
Ugh. I see what you mean. It seems more complicated than that, though. For one thing, the AvahiWatch/AvahiPoll stuff is sufficiently abstract that it doesn't mention DBusConnection (or any other DBus type, AFAIK), so there's no indication that *any* DBusConnection is being used (though I trust that there is). Turning on AVAHI_DEBUG, I see both my (node_device_hal.c) callbacks and the avahi callbacks being called (but at different times, and with different fds and event sets). Makes me wonder whether the avahi library is using dbus_bus_get_private() to get its own DBusConnection that it doesn't have to worry about sharing with others. I tried changing the node_device_hal code to use a private dbus connection, and see exactly the same behavior (i.e., dbus immediately registers the same fd twice, with different event sets and enable state). Regardless, I like the idea of simply using this private connection (as you suggested but rejected), just for the sake of simplicity. (Also, what if Avahi's been configured out?) But ... back to the original problem. Immediately after calling dbus_set_watch_functions (and *before* initializing the Avahi stuff), I see two callbacks to watch_add with the same fd. Looking at the glib watch functions, I see watches on GIOChannels are added with g_io_add_watch(), which indeed doesn't specify what happens if the same GIOChannel is added twice. But GIOChannels aren't fds. Presumably, one could create two different GIOChannels with the same fd (via g_io_channel_unix_new) and then register watches on each of them. So I remain convinced that we need to support the registration of the same fd multiple times ... Dave [Caveat: Okay, so I've never actually *used* glib ... I'm going from the docs here ...] On Wed, 2008-11-05 at 16:49 +, Daniel P. Berrange wrote: On Wed, Nov 05, 2008 at 11:26:07AM -0500, David Lively wrote: On Wed, 2008-11-05 at 11:51 +, Daniel P. Berrange wrote: I think the problem here is that the existing Avahi mdns code in the libvirtd daemon is also already using DBus, and has already setup the DBus system bus instances to integrate with the libvirtd event loop. By default, there is a single DBus system bus connection in the app which is shared amongst all users. The DBus API spec for its watch functions mandates that the application only setup watches once per connection, so having both the Avahi and HAL/DevKit code in libvirt call dbus_connection_set_watch_functions() against the shared connection is in fact a bug. For added fun, PolicyKit code in the daemon also makes use of DBus, but doesn't (yet) need callbacks so hasn't done mainloop integration. So the flaw here is that the individual drivers should not all be attempting to setup integration with the shared dbus system bus connection. Either each driver should use a private dbus system bus conenction, or the main daemon startup code should take responsibility for integrating the shared connection instance into its main loop. I'd be inclined to go for the latter. For simplicitly, I think you ought to simply be able to remove the dbus_connection_set_watch_functions call from the driver, and rely on fact that Avahi code has already done this. Daniel -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Libvirt CVS fails to build on PPC
Actually, the subject isn't strictly true. Libvirt CVS currently fails to build when using this configuration on any platform: ./configure --build=i686-redhat-linux-gnu --host=i686-redhat-linux-gnu --target=i386-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --without-xen --without-qemu --with-init-script=redhat --with-qemud-pid-file=/var/run/libvirt_qemud.pid --with-remote-file=/var/run/libvirtd.pid (the important part is the --without-xen --without-qemu in there). This just happens to be the configuration that koji uses when it is building the ppc libvirt package. There are a lot of build errors, but they start with: network_driver.c:64: error: expected specifier-qualifier-list before 'iptablesContext' network_driver.c: In function 'networkStartup': network_driver.c:124: error: 'struct network_driver' has no member named 'logDir' This seems to stem from the new module refactoring. I'm not entirely sure what's the correct way to fix it, however; I *think* we always want to build the network_driver at this point, but if that's the case, then we need to make sure we have the header files for iptablesContext and friends included. Dan, any ideas? -- Chris Lalancette -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Libvirt CVS fails to build on PPC
Chris Lalancette [EMAIL PROTECTED] wrote:
Actually, the subject isn't strictly true. Libvirt CVS currently fails to
build
when using this configuration on any platform:
./configure --build=i686-redhat-linux-gnu --host=i686-redhat-linux-gnu
--target=i386-redhat-linux-gnu --program-prefix= --prefix=/usr
--exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib
--libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com
--mandir=/usr/share/man --infodir=/usr/share/info --without-xen --without-qemu
--with-init-script=redhat --with-qemud-pid-file=/var/run/libvirt_qemud.pid
--with-remote-file=/var/run/libvirtd.pid
(the important part is the --without-xen --without-qemu in there). This just
happens to be the configuration that koji uses when it is building the ppc
libvirt package. There are a lot of build errors, but they start with:
network_driver.c:64: error: expected specifier-qualifier-list before
'iptablesContext'
network_driver.c: In function 'networkStartup':
network_driver.c:124: error: 'struct network_driver' has no member named
'logDir'
This seems to stem from the new module refactoring. I'm not entirely sure
what's the correct way to fix it, however; I *think* we always want to build
the
network_driver at this point, but if that's the case, then we need to make
sure
we have the header files for iptablesContext and friends included. Dan, any
ideas?
Hi Chris,
FYI, this patch fixes it.
The result builds both on rawhide and for mingw.
From ea7a97d34f1ae04ef6bd1f9584d946a5bc4575b4 Mon Sep 17 00:00:00 2001
From: Jim Meyering [EMAIL PROTECTED]
Date: Thu, 6 Nov 2008 08:42:33 +0100
Subject: [PATCH] always compile iptables.c
Avoid a build error when configuring --without-xen --without-qemu.
* src/iptables.c [WITH_QEMU]: Don't #ifdef-out.
* src/iptables.h [WITH_QEMU]: Don't #ifdef-out.
---
src/iptables.c |4
src/iptables.h |6 +-
2 files changed, 1 insertions(+), 9 deletions(-)
diff --git a/src/iptables.c b/src/iptables.c
index 53e0f41..ad7fddf 100644
--- a/src/iptables.c
+++ b/src/iptables.c
@@ -21,8 +21,6 @@
#include config.h
-#if WITH_QEMU
-
#include stdio.h
#include stdlib.h
#include stdarg.h
@@ -1120,5 +1118,3 @@ iptablesRemoveForwardMasquerade(iptablesContext *ctx,
{
return iptablesForwardMasquerade(ctx, network, physdev, REMOVE);
}
-
-#endif /* WITH_QEMU */
diff --git a/src/iptables.h b/src/iptables.h
index 95f07de..fbe9b5d 100644
--- a/src/iptables.h
+++ b/src/iptables.h
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2007 Red Hat, Inc.
+ * Copyright (C) 2007, 2008 Red Hat, Inc.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
@@ -22,8 +22,6 @@
#ifndef __QEMUD_IPTABLES_H__
#define __QEMUD_IPTABLES_H__
-#if WITH_QEMU
-
typedef struct _iptablesContext iptablesContext;
iptablesContext *iptablesContextNew (void);
@@ -95,6 +93,4 @@ int iptablesRemoveForwardMasquerade
(iptablesContext *ctx,
const char *network,
const char *physdev);
-#endif /* WITH_QEMU */
-
#endif /* __QEMUD_IPTABLES_H__ */
--
1.6.0.3.756.gb776d
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Libvirt CVS fails to build on PPC
Jim Meyering wrote: Chris Lalancette [EMAIL PROTECTED] wrote: Actually, the subject isn't strictly true. Libvirt CVS currently fails to build when using this configuration on any platform: ./configure --build=i686-redhat-linux-gnu --host=i686-redhat-linux-gnu --target=i386-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --without-xen --without-qemu --with-init-script=redhat --with-qemud-pid-file=/var/run/libvirt_qemud.pid --with-remote-file=/var/run/libvirtd.pid (the important part is the --without-xen --without-qemu in there). This just happens to be the configuration that koji uses when it is building the ppc libvirt package. There are a lot of build errors, but they start with: network_driver.c:64: error: expected specifier-qualifier-list before 'iptablesContext' network_driver.c: In function 'networkStartup': network_driver.c:124: error: 'struct network_driver' has no member named 'logDir' This seems to stem from the new module refactoring. I'm not entirely sure what's the correct way to fix it, however; I *think* we always want to build the network_driver at this point, but if that's the case, then we need to make sure we have the header files for iptablesContext and friends included. Dan, any ideas? Hi Chris, FYI, this patch fixes it. The result builds both on rawhide and for mingw. Yep, fixes it here too. Thanks. Assuming danpb is OK with this, we should push it. -- Chris Lalancette -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
