- Devel - libvirt List Archives

[libvirt] [PATCH] phyp: Fixing possible buffer overflow
by Eduardo Otubo 06 Aug '10

06 Aug '10

The line src/phyp/phyp_driver.c:427 was crashing by buffer overflow if the return of the command wasn't <=10. The highest number for a LPAR ID is 256 per machine, no need to allocate 10 bytes for it. So, adjusting the correct size (+1 byte for the '\n') and checking for errors. --- src/phyp/phyp_driver.c | 9 +++++++-- 1 files changed, 7 insertions(+), 2 deletions(-) diff --git a/src/phyp/phyp_driver.c b/src/phyp/phyp_driver.c index ee1e21b..f8fd29b 100644 --- a/src/phyp/phyp_driver.c +++ b/src/phyp/phyp_driver.c @@ -383,7 +383,7 @@ phypListDomainsGeneric(virConnectPtr conn, int *ids, int nids, int got = 0; char *char_ptr; unsigned int i = 0, j = 0; - char id_c[10]; + char id_c[4]; char *cmd = NULL; char *ret = NULL; const char *state; @@ -394,7 +394,7 @@ phypListDomainsGeneric(virConnectPtr conn, int *ids, int nids, else state = " "; - memset(id_c, 0, 10); + memset(id_c, 0, 4); virBufferAddLit(&buf, "lssyscfg -r lpar"); if (system_type == HMC) @@ -410,6 +410,11 @@ phypListDomainsGeneric(virConnectPtr conn, int *ids, int nids, ret = phypExec(session, cmd, &exit_status, conn); + if (strlen(ret) > 4) { + VIR_ERROR0(ret); + goto err; + } + /* I need to parse the textual return in order to get the ret */ if (exit_status < 0 || ret == NULL) goto err; -- 1.7.0.4

3 10

[libvirt] [PATCH] docs: significant expansion of custom hook script information
by Justin Clift 06 Aug '10

06 Aug '10

--- Also available for easy review online here for a while: http://justinclift.fedorapeople.org/libvirt_docs/hooks.html docs/hooks.html.in | 226 +++++++++++++++++++++++++++++++++++++-------------- 1 files changed, 164 insertions(+), 62 deletions(-) diff --git a/docs/hooks.html.in b/docs/hooks.html.in index 2afdecf..5eeec27 100644 --- a/docs/hooks.html.in +++ b/docs/hooks.html.in @@ -2,69 +2,171 @@ <html> <body> <h1>Hooks for specific system management</h1> - Libvirt includes synchronous hooks, starting from version 0.8.0, as a - way to tie in specific tailored system actions at a specific time. - If these scripts are present on the host where the hypervisor - is running, then they are called when the libvirt daemon is doingi - some significant action. - The scripts are expected to execute quickly, return a zero exit - status if all conditions are set for the daemon to continue the - action (non zero will be considered a failure which may - be ignored but in general will stop the ongoing operation). - The script also should not call back into libvirt as the daemon - is waiting for the script exit and deadlock is likely to occur. - The scripts are stored in the directory <code>/etc/libvirt/hooks/</code> - when using a standard installation path - (<code>$SYSCONF_DIR/libvirt/hooks/</code> in general). - Each script is given the following command line arguments: - <ul> - <li> the first argument is the name of the object involved in the - operation, or '-' if there is none. - <li> the second argument is the name of the operation. - <li> the third argument is a suboperation indication like 'start' or - 'end', or '-' if there is none. - <li> the last argument is an extra argument string or '-' if there - is none. - </ul> - There are currently scripts for 3 domains of operation: + + <ul id="toc"></ul> + + <h2><a name="intro">Custom event scripts</a></h2> + Beginning with libvirt 0.8.0, specific events on a host system will + trigger custom scripts. + These custom hook scripts are executed when any of the following + actions occur: <ul> - <li><code>/etc/libvirt/hooks/daemon</code> script if - present is called at 3 points in time: - at daemon startup, typically started with the following - arguments: - <pre>/etc/libvirt/hooks/daemon - start - start</pre> - at daemon shutdown when it is about to exit, with the following - arguments: - <pre>/etc/libvirt/hooks/daemon - shutdown - shutdown</pre> - When the daemon is asked to reload its driver state when - receiving the SIGHUP signal, arguments are: - <pre>/etc/libvirt/hooks/daemon - reload begin SIGHUP</pre> - </li> - <li><code>/etc/libvirt/hooks/qemu</code> script and - <code>/etc/libvirt/hooks/lxc</code> associate hooks for domain - operation on the respective QEmu/KVM and LXC drivers. - The domain related hooks also receive the full XML description - for the concerned domain on their stdin, which allows them to get - all the information from the domain, including UUID or storage - if that is needed for the script operation. - Currently only domain startup and domain end operations - involve the hook, the first one just before the domain gets - created. - For example if starting a QEmu domain named <code>test</code> - the following script will get called: - <pre>/etc/libvirt/hooks/qemu test start begin -</pre> - note that a non-zero return value from the script will abort the - domain startup operation, and if an error string is passed on - stderr by the hook script, it will be provided back to the user - at the libvirt API level. - For domain shutdown, the script will be called just after the - domain has finished execution, and the script will get: - <pre>/etc/libvirt/hooks/qemu test stopped end -</pre> - It is expected that other operations will be associated to hooks - but at the time of 0.8.0 only those 2 are associated to the - domains life cycle - </li> + <li>The libvirt daemon starts, stops, or reloads its + configuration </li> + <li>A QEMU guest is started or stopped </li> + <li>An LXC guest is started or stopped </li> </ul> - + + <h2><a name="location">Script Location</a></h2> + The libvirt hook scripts are located in the directory + <code>$SYSCONF_DIR/etc/libvirt/hooks/</code>. + With Fedora and RHEL, this is <code>/etc/libvirt/hooks/</code>. + On other Linux distributions this may be different. + + + <h2><a name="names">Script names</a></h2> + At present, there are three hook scripts: + <ul> + <li><code>/etc/libvirt/hooks/daemon</code> + Executed when the libvirt daemon is started, stopped, or reloads + its configuration </li> + <li><code>/etc/libvirt/hooks/qemu</code> + Executed when a QEMU guest is started, stopped, or migrated </li> + <li><code>/etc/libvirt/hooks/lxc</code> + Executed when an LXC guest is started or stopped</li> + </ul> + + + <h2><a name="structure">Script structure</a></h2> + The hook scripts are executed using standard Linux process creation + functions. Therefore, they must begin with the declaration of the + command interpreter to use. + For example: + <pre>#!/bin/bash</pre> + or: + <pre>#!/usr/bin/python</pre> + Other command interpreters are equally valid, as is any executable + binary, so you are welcome to use your favourite languages. + + + <h2><a name="arguments">Script arguments</a></h2> + The hook scripts are called with specific command line arguments, + depending upon the script, and the operation being performed. + The guest hook scripts, qemu and lxc, are also given the full + XML description for the domain on their stdin. This includes items + such the UUID of the domain and its storage information, and is + intended to provide all the libvirt information the script needs. + + The command line arguments take this approach: + <ol> + <li>The first argument is the name of the object involved in the + operation, or '-' if there is none. + For example, the name of a guest being started. </li> + <li>The second argument is the name of the operation being + performed. + For example, "start" if a guest is being started. </li> + <li>The third argument is a sub-operation indication, or '-' if there + is none. </li> + <li>The last argument is an extra argument string, or '-' if there is + none.</li> + </ol> + + <h4><a name="arguments_specifics">Specifics</a></h4> + This translates to the following specifics for each hook script: + + <h5><a name="daemon">/etc/libvirt/hooks/daemon</a></h5> + <ul> + <li>When the libvirt daemon is started, this script is called as: + <pre>/etc/libvirt/hooks/daemon - start - start</pre></li> + <li>When the libvirt daemon is shut down, this script is called as: + <pre>/etc/libvirt/hooks/daemon - shutdown - shutdown</pre></li> + <li>When the libvirt daemon receives the SIGHUP signal, it reloads its + configuration and triggers the hook script as: + <pre>/etc/libvirt/hooks/daemon - reload begin SIGHUP</pre></li> + </ul> + + <h5><a name="qemu">/etc/libvirt/hooks/qemu</a></h5> + <ul> + <li>When a QEMU guest is started, the qemu hook script is called as: + <pre>/etc/libvirt/hooks/qemu guest_name start begin -</pre></li> + <li>When a QEMU guest is stopped, the qemu hook script is called + as: + <pre>/etc/libvirt/hooks/qemu guest_name stopped end -</pre></li> + </ul> + + <h5><a name="lxc">/etc/libvirt/hooks/lxc</a></h5> + <ul> + <li>When an LXC guest is started, the lxc hook script is called as: + <pre>/etc/libvirt/hooks/lxc guest_name start begin -</pre></li> + <li>When a LXC guest is stopped, the lxc hook script is called + as: + <pre>/etc/libvirt/hooks/lxc guest_name stopped end -</pre></li> + </ul> + + + <h2><a name="execution">Script execution</a></h2> + <ul> + <li>The "start" operation for the guest hook scripts, qemu and lxc, + executes prior to the guest being created. This allows the + guest start operation to be aborted if the script returns indicating + failure. </li> + <li>The "shutdown" operation for the guest hook scripts, qemu and lxc, + executes after the guest has stopped. If the hook script + indicates failure in its return, the shut down of the guest cannot + be aborted because it has already been performed. </li> + <li>Hook scripts execute in a synchronous fashion. Libvirt waits + for them to return before continuing the given operation. + This is most noticeable with the guest start operation, as a lengthy + operation in the hook script can mean an extended wait for the guest + to be available to end users. </li> + <li>For a hook script to be utilised, it have it's execute bit set + (ie. chmod +x qemu), and must be present when the libvirt + daemon is started. </li> + <li>If a hook script is added to a host after the libvirt daemon is + already running, it won't be used until the libvirt daemon + next starts.</li> + </ul> + + + <h2><a name="qemu_migration">QEMU guest migration</a></h2> + Migration of a QEMU guest involves running the hook scripts on both the + source and destination hosts: + <ol> + <li>At the beginning of the migration, the qemu hook script on + the destination host is executed with the "start" + operation. </li> + <li>If this hook script returns indicating success (error code 0), the + migration continues. Any other return code indicates failure, and + the migration is aborted. </li> + <li>The QEMU guest is then migrated to the destination host. + </li> + <li>Unless an error occurs during the migration process, the qemu + hook script on the source host is then executed with the "stopped" + operation, to indicate it is no longer running on this + host. + Regardless of the return code from this hook script, the migration + is not aborted as it has already been performed.</li> + </ol> + + + <h2><a name="recursive">Calling libvirt functions from within a hook script</a></h2> + DO NOT DO THIS! + A hook script must not call back into libvirt, as the libvirt daemon + is already waiting for the script to exit. + A deadlock is likely to occur. + + + <h2><a name="return_codes">Return codes and logging</a></h2> + If a hook script returns with an exit code of 0, the libvirt daemon + regards this as successful and performs no logging of it. + However, if a hook script returns with a non zero exit code, the libvirt + daemon regards this as a failure, logs it with return code 256, and + additionally logs anything on stderr the hook script returns. + For example, a hook script might use this code to indicate failure, + and send a text string to stderr: + <pre>echo "Could not find required XYZZY" >&2 +exit 1</pre> + The resulting entry in the libvirt log will appear as: + <pre>20:02:40.297: error : virHookCall:416 : Hook script execution failed: Hook script /etc/libvirt/hooks/qemu qemu failed with error code 256:Could not find required XYZZY</pre> </body> </html> -- 1.7.2

3 5

[libvirt] Callback and stream questions
by arnaud.champion＠devatom.fr 06 Aug '10

06 Aug '10

Hi, I would know if there is some callbacks for network adding/change/remove and for storage pool add/change/remove, I haven't seen these kind of callback in the API documentation. Also, I don't understand the use of the virStream... functions (what is it used for ?) Thanks Arnaud Champion

2 1

[libvirt] [PATCH 1/3] Attempt to load tun module on tap add error
by Doug Goldstein 06 Aug '10

06 Aug '10

When attempting to add a tap device, the error message is fairly cryptic as to what really happened. If possible, try to load the tun module and then try again to add the tap device again to improve the user experience. Signed-off-by: Doug Goldstein <cardoe(a)gentoo.org> --- src/util/bridge.c | 21 +++++++++++++++++++-- 1 files changed, 19 insertions(+), 2 deletions(-) diff --git a/src/util/bridge.c b/src/util/bridge.c index 7d0caae..ca4bcc9 100644 --- a/src/util/bridge.c +++ b/src/util/bridge.c @@ -486,12 +486,29 @@ brAddTap(brControl *ctl, { int fd; struct ifreq ifr; + const char * const argv[] = { "modprobe", "tun", NULL }; + int err, exitstatus = 0; if (!ctl || !ctl->fd || !bridge || !ifname) return EINVAL; - if ((fd = open("/dev/net/tun", O_RDWR)) < 0) - return errno; + if ((fd = open("/dev/net/tun", O_RDWR)) < 0) { + err = errno; + + /* If the tun device was non-existent, lets try to load the module */ + if (err == ENOENT) { + if (virRun(argv, &exitstatus) < 0) { + return ENOENT; + } + + /* Now lets try to open the tun device again */ + if ((fd = open("/dev/net/tun", O_RDWR)) < 0) { + return errno; + } + } else { + return err; + } + } memset(&ifr, 0, sizeof(ifr)); -- 1.7.2

3 2

[libvirt] [PATCH 3/3] Fix return value usage
by Doug Goldstein 06 Aug '10

06 Aug '10

Fix the error checking to use the return value from brAddTap() instead of checking the current errno value which might have been changed by clean up calls inside of brAddTap(). Signed-off-by: Doug Goldstein <cardoe(a)gentoo.org> --- src/qemu/qemu_conf.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c index e92021a..7c0e354 100644 --- a/src/qemu/qemu_conf.c +++ b/src/qemu/qemu_conf.c @@ -1689,7 +1689,7 @@ qemudNetworkIfaceConnect(virConnectPtr conn, tapmac, vnet_hdr, &tapfd))) { - if (errno == ENOTSUP) { + if (err == ENOTSUP) { /* In this particular case, give a better diagnostic. */ qemuReportError(VIR_ERR_INTERNAL_ERROR, _("Failed to add tap interface to bridge. " -- 1.7.2

3 2

[libvirt] [PATCH 2/3] Add a detailed message when tap device add fails
by Doug Goldstein 05 Aug '10

05 Aug '10

Added a more detailed error message when adding a tap devices fails and the kernel is missing tun support. Signed-off-by: Doug Goldstein <cardoe(a)gentoo.org> --- src/qemu/qemu_conf.c | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c index 2ca3350..e92021a 100644 --- a/src/qemu/qemu_conf.c +++ b/src/qemu/qemu_conf.c @@ -1694,6 +1694,13 @@ qemudNetworkIfaceConnect(virConnectPtr conn, qemuReportError(VIR_ERR_INTERNAL_ERROR, _("Failed to add tap interface to bridge. " "%s is not a bridge device"), brname); + } else if (err == ENOENT) { + /* When the tun drive is missing, give a better message. */ + qemuReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Failed to add tap interface to bridge. " + "Your kernel is missing the 'tun' module or " + "CONFIG_TUN or you need to add the " + "/dev/net/tun device node.")); } else if (template_ifname) { virReportSystemError(err, _("Failed to add tap interface to bridge '%s'"), -- 1.7.2

2 1

[libvirt] [PATCH] build: rerun bootstrap if po/Makevars got nuked
by Eric Blake 05 Aug '10

05 Aug '10

There has been a frequent complaint of: make[2]: Entering directory `/home/remote/eblake/libvirt/po' make[2]: *** No rule to make target `/config.status', needed by `Makefile'. Stop. It happens after nuking and regenerating the po directory, which is a common action after running anything like 'make dist' or 'make rpm' that dirties all the .po files. Teach autogen.sh that it must regenerate po/Makevars to avoid the missing variable declaration, and teach cfg.mk to recognize that a nuked po directory is cause to rerun autogen.sh. * cfg.mk (_update_required): Check for po/Makevars. * autogen.sh (bootstrap): Run bootstrap if it got lost. Diagnosed by Justin Clift. --- Tested by 'git clean -x -f po && make'. A bit drastic (I prefer 'git checkout po' as the fastest way to undo local changes to the po directory caused by 'make dist', since that won't erase po/Makevars), but using that sledgehammer to clean po/ proves that this patch works. This should even work in a VPATH build :) autogen.sh | 8 ++++++-- cfg.mk | 1 + 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/autogen.sh b/autogen.sh index 2f5b42d..c0a1c4a 100755 --- a/autogen.sh +++ b/autogen.sh @@ -74,10 +74,14 @@ bootstrap_hash() # Ensure that whenever we pull in a gnulib update or otherwise change to a # different version (i.e., when switching branches), we also rerun ./bootstrap. +# Also, running 'make rpm' tends to litter the po/ directory, and some people +# like to run 'git clean -x -f po' to fix it; but only ./bootstrap regenerates +# the required file po/Makevars. curr_status=.git-module-status t=$(bootstrap_hash; git diff .gnulib) -if test "$t" = "$(cat $curr_status 2>/dev/null)"; then - : # good, it's up to date, all we need is autoreconf +if test "$t" = "$(cat $curr_status 2>/dev/null)" \ + && test -f "$THEDIR/po/Makevars"; then + # good, it's up to date, all we need is autoreconf autoreconf -if else echo running bootstrap... diff --git a/cfg.mk b/cfg.mk index e12265e..7226828 100644 --- a/cfg.mk +++ b/cfg.mk @@ -459,6 +459,7 @@ ifeq (0,$(MAKELEVEL)) # b653eda3ac4864de205419d9f41eec267cb89eeb _submodule_hash = sed 's/^[ +-]//;s/ .*//' _update_required := $(shell \ + test -f po/Makevars || { echo 1; exit; }; \ cd '$(srcdir)'; \ actual=$$(git submodule status | $(_submodule_hash); \ git hash-object bootstrap.conf; \ -- 1.7.2

2 2

[libvirt] NUMA cell?
by adrian wyssen 05 Aug '10

05 Aug '10

Hi, I have a question regarding the documentation of libvirt. There is a structure called 'virNodeInfo' and in the doc, you speak about NUMA cell. I was wondering what that is. And what do you understand by 'the number of threads per core'? Thank you for a quick response, since I need to write an explanation in a report until this evening. Have a good day!

2 1

[libvirt] Libvirt synchronous hooks
by Radek Hladik 05 Aug '10

05 Aug '10

I am trying Libvirt synchronous hooks and I would like to ask a question. I would like to use the machine start (qemu+kvm) hook to set up the storage for the machine. I already mentioned my setup in this mailing list but for now it is only important that VM storage is a md raid constructed from iSCSI disks. The VM's config is using simple file device: <disk type='file' device='disk'> <driver name='qemu' type=''/> <source file='/dev/disk/by-id/md-uuid-e464a51e:f61e98b4:bfe78010:bc810f04'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </disk> Stopping the array from stop hook works perfectly however it seems that on the startup the storage is checked before the hook is executed. At least I do get errors that the storage file (/dev/disk/by-id/md-uuid-....) does not exist and my hook is not called. I would say that I am hooking on wrong places that I should hook on storage startup/shutdown but as far as I know there are no hooks for storage drivers. Are there any plans in this area? Or is there any other way how to do it that I do not see? Radek

3 2

[libvirt] [PATCH v4 0/8]: Add arbitrary qemu command-line and monitor commands
by Chris Lalancette 05 Aug '10

05 Aug '10

As we discussed previously, here is the patch series to add the ability to specify arbitrary qemu command-line parameters and environment variables, and also give arbitrary monitor commands to a guest. Because these extra arguments have a good shot at confusing libvirt, the use of them is not supported, but left available for advanced users and developers. They are also in a separate library and have a separate on-the-wire protocol. There is one bug left that I have not yet been able to fix. Because of the complicated way that virsh parses command-line arguments, it is not possible to pass through spaces and quotes when using the qemu-monitor-command. Unfortunately, the qemu monitor commands (and in particular when using QMP) depend heavily on quoting and spacing, so using virsh to send through command-lines is difficult. I'll have to think about how to better resolve this issue, but it should not hold up the rest of the series. I will point out one particular patch that could use some careful review, namely PATCH 6/8. In there, I change the remote_message_hdr to use an int proc instead of a enum remote_procedure proc. Now, as far as I can tell the two sizes should be the same, so the wire protocol should be the same. Indeed, testing seems to show that older virsh can talk just fine to a libvirtd with these patches applied. However, the regenerated remote_protocol.c file for parsing remote_message_header has some strange bits in it that I don't quite understand. I'm hoping someone else can look at it and confirm that it is OK. Thanks to Dan Berrange and Eric Blake for their reviews already, and to DV for the Relax NG schema changes. Changes since v3 are listed in the individual patches.

7 26