- Devel - libvirt List Archives

[libvirt] [PATCH] initialize pointer to NULL
by Wen Congyang 04 Jul '11

04 Jul '11

>From 577ac7e8594cbcccb59653786e80c3916a3238cb Mon Sep 17 00:00:00 2001 From: Wen Congyang <wency(a)cn.fujitsu.com> Date: Sat, 2 Jul 2011 06:41:18 +0800 Subject: [PATCH] initialize pointer to NULL def and cmd is not initialized to NULL, but we try to freed it if we meet some error. It's very dangerous. --- src/qemu/qemu_command.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 90a6653..6c78161 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -5818,7 +5818,7 @@ virDomainDefPtr qemuParseCommandLine(virCapsPtr caps, const char **progenv, const char **progargv) { - virDomainDefPtr def; + virDomainDefPtr def = NULL; int i; int nographics = 0; int fullscreen = 0; @@ -5827,7 +5827,7 @@ virDomainDefPtr qemuParseCommandLine(virCapsPtr caps, const char **nics = NULL; int video = VIR_DOMAIN_VIDEO_TYPE_CIRRUS; int nvirtiodisk = 0; - qemuDomainCmdlineDefPtr cmd; + qemuDomainCmdlineDefPtr cmd = NULL; if (!progargv[0]) { qemuReportError(VIR_ERR_INTERNAL_ERROR, -- 1.6.5.2

3 2

[libvirt] [PATCH 0/8] more coverity cleanups
by Eric Blake 04 Jul '11

04 Jul '11

Many are minor (silencing warnings or only affect OOM), but at least patch 5/8 is a real bug that needs to be fixed pre-release. Eric Blake (8): rpc: avoid memory leak on error qemu: silence coverity warnings rpc: silence coverity warning cgroup: silence coverity warning rpc: fix logic bug qemu: avoid null deref on low memory vmware: avoid null deref on failed lookup storage: avoid crash on parse error src/qemu/qemu_audit.c | 6 ++++-- src/qemu/qemu_command.c | 6 +++++- src/qemu/qemu_domain.c | 4 ++-- src/qemu/qemu_migration.c | 3 ++- src/rpc/virnetclient.c | 3 ++- src/rpc/virnetserverclient.c | 1 + src/rpc/virnetserverservice.c | 7 ++++++- src/storage/storage_backend_iscsi.c | 14 ++++++++++---- src/util/cgroup.c | 2 +- src/vmware/vmware_driver.c | 2 +- 10 files changed, 34 insertions(+), 14 deletions(-) -- 1.7.4.4

3 15

[libvirt] [PATCH] monitor-proxy: Tool for testing qemu monitor interaction
by Jiri Denemark 04 Jul '11

04 Jul '11

It has two modes, normal and interactive. In normal mode, messages are passed from libvirt to qemu and back as they come and copyied to stdout so that one can monitor the communication. In interactive mode, whenever a message comes from either libvirt or qemu, it is printed to stdout and the user is asked what action to take. One can also inject any message to either libvirt or qemu. Interactive mode can be entered by sending any command to monitor-proxy (sending an empty command, i.e., hitting enter enters interactive mode without doing anything else). The proxy can also be started directly in interactive mode by specifying "-i" command line option. Command "cont" can be used to return back to normal mode. For list of supported commands and their description, use "help" or "h" command. To start monitor-proxy one needs to follow the following steps: - start a domain - run monitor-proxy [-i] <monitor socket path> for example: monitor-proxy /var/lib/libvirt/qemu/vm1.monitor - restart libvirtd (this makes libvirtd disconnect from qemu and reconnect to the proxy) monitor-proxy supports libvirtd restarts, i.e., if libvirtd disconnects, the proxy just waits until it reconnects again. Stopping the proxy while libvirtd is running kills the domain since libvirtd sees monitor EOF. To stop using monitor-proxy without killing the domain, one needs to stop libvirtd, stop monitor-proxy, and start libvirtd. The proxy works by renaming qemu monitor socket so that it can listen at the original place for connections from libvirtd. Once libvirtd connects to monitor-proxy, the proxy connects to qemu through the renamed socket. The socket is renamed back to its original name when proxy is killed or asked to exit. The proxy also supports fd passing through SCM_RIGHTS so to be usable for testing migrations. --- Makefile.am | 3 +- configure.ac | 3 +- examples/monitor-proxy/Makefile.am | 3 + examples/monitor-proxy/README | 36 ++ examples/monitor-proxy/monitor-proxy.c | 751 ++++++++++++++++++++++++++++++++ 5 files changed, 794 insertions(+), 2 deletions(-) create mode 100644 examples/monitor-proxy/Makefile.am create mode 100644 examples/monitor-proxy/README create mode 100644 examples/monitor-proxy/monitor-proxy.c diff --git a/Makefile.am b/Makefile.am index 49e42bf..1ac65e3 100644 --- a/Makefile.am +++ b/Makefile.am @@ -6,7 +6,8 @@ GENHTML = genhtml SUBDIRS = gnulib/lib include src daemon tools docs gnulib/tests \ python tests po examples/domain-events/events-c examples/hellolibvirt \ examples/dominfo examples/domsuspend examples/python examples/apparmor \ - examples/xml/nwfilter examples/openauth examples/systemtap + examples/xml/nwfilter examples/openauth examples/systemtap \ + examples/monitor-proxy ACLOCAL_AMFLAGS = -I m4 -I gnulib/m4 diff --git a/configure.ac b/configure.ac index cd22afb..9d2fe04 100644 --- a/configure.ac +++ b/configure.ac @@ -2414,7 +2414,8 @@ AC_OUTPUT(Makefile src/Makefile include/Makefile docs/Makefile \ examples/python/Makefile \ examples/hellolibvirt/Makefile \ examples/systemtap/Makefile \ - examples/xml/nwfilter/Makefile) + examples/xml/nwfilter/Makefile \ + examples/monitor-proxy/Makefile) AC_MSG_NOTICE([]) AC_MSG_NOTICE([Configuration summary]) diff --git a/examples/monitor-proxy/Makefile.am b/examples/monitor-proxy/Makefile.am new file mode 100644 index 0000000..4fbbed5 --- /dev/null +++ b/examples/monitor-proxy/Makefile.am @@ -0,0 +1,3 @@ +noinst_PROGRAMS = monitor-proxy +monitor_proxy_CFLAGS = $(WARN_CFLAGS) +monitor_proxy_SOURCES = monitor-proxy.c diff --git a/examples/monitor-proxy/README b/examples/monitor-proxy/README new file mode 100644 index 0000000..bf00460 --- /dev/null +++ b/examples/monitor-proxy/README @@ -0,0 +1,36 @@ +monitor-proxy is meant as a developer tool for testing libvirt-qemu +communication. + +It has two modes, normal and interactive. In normal mode, messages are passed +from libvirt to qemu and back as they come and copyied to stdout so that one +can monitor the communication. In interactive mode, whenever a message comes +from either libvirt or qemu, it is printed to stdout and the user is asked +what action to take. One can also inject any message to either libvirt or +qemu. Interactive mode can be entered by sending any command to monitor-proxy +(sending an empty command, i.e., hitting enter enters interactive mode without +doing anything else). The proxy can also be started directly in interactive +mode by specifying "-i" command line option. Command "cont" can be used to +return back to normal mode. For list of supported commands and their +description, use "help" or "h" command. + +To start monitor-proxy one needs to follow the following steps: +- start a domain +- run monitor-proxy [-i] <monitor socket path> + for example: monitor-proxy /var/lib/libvirt/qemu/vm1.monitor +- restart libvirtd (this makes libvirtd disconnect from qemu and reconnect to + the proxy) + +monitor-proxy supports libvirtd restarts, i.e., if libvirtd disconnects, the +proxy just waits until it reconnects again. Stopping the proxy while libvirtd +is running kills the domain since libvirtd sees monitor EOF. To stop using +monitor-proxy without killing the domain, one needs to stop libvirtd, stop +monitor-proxy, and start libvirtd. + +The proxy works by renaming qemu monitor socket so that it can listen at the +original place for connections from libvirtd. Once libvirtd connects to +monitor-proxy, the proxy connects to qemu through the renamed socket. The +socket is renamed back to its original name when proxy is killed or asked to +exit. + +The proxy also supports fd passing through SCM_RIGHTS so to be usable for +testing migrations. diff --git a/examples/monitor-proxy/monitor-proxy.c b/examples/monitor-proxy/monitor-proxy.c new file mode 100644 index 0000000..403033d --- /dev/null +++ b/examples/monitor-proxy/monitor-proxy.c @@ -0,0 +1,751 @@ +#include <stdlib.h> +#include <stdio.h> +#include <stdbool.h> +#include <stdarg.h> +#include <string.h> +#include <signal.h> +#include <unistd.h> +#include <fcntl.h> +#include <errno.h> +#include <sys/select.h> +#include <sys/socket.h> +#include <sys/un.h> + +# ifndef ATTRIBUTE_FMT_PRINTF +# if __GNUC_PREREQ (4, 4) +# define ATTRIBUTE_FMT_PRINTF(fmtpos,argpos) __attribute__((__format__ (gnu_printf, fmtpos,argpos))) +# else +# define ATTRIBUTE_FMT_PRINTF(fmtpos,argpos) __attribute__((__format__ (printf, fmtpos,argpos))) +# endif +# endif + +# ifndef ATTRIBUTE_NORETURN +# define ATTRIBUTE_NORETURN __attribute__((__noreturn__)) +# endif + +#ifndef UNIX_PATH_MAX +# define UNIX_PATH_MAX 108 +#endif +#define SOCK_SUFFIX ".proxy" +#define SIZE (1 << 14) + +#define LABEL_LIBVIRT "libvirt> " +#define LABEL_QEMU "qemu> " +#define LABEL_PROMPT "command> " + +enum party { + PARTY_QEMU, + PARTY_LIBVIRT +}; + +enum command { + CMD_NONE, + CMD_NOOP, + CMD_UNKNOWN, + CMD_CONTINUE, + CMD_QUIT, + CMD_HELP, + CMD_PASS, + CMD_DISCARD, + CMD_SEND_QEMU, + CMD_SEND_LIBVIRT +}; + +struct proxy_command { + enum command command; + const char *name; + bool shortcut; + bool argument; + const char *description; +}; + +const char *monitor; +char *monitor_qemu; + +char *buffer; +char *control; +char *commands; + +struct message { + enum party source; + int fd_qemu; + int fd_libvirt; + struct msghdr hdr; +}; + + +#define ncommands (sizeof(proxy_commands) / sizeof(*proxy_commands)) +static const struct proxy_command proxy_commands[] = { + { + CMD_CONTINUE, + "cont", true, false, + "leave interactive mode" + }, { + CMD_QUIT, + "quit", false, false, + "quit monitor-proxy" + }, { + CMD_HELP, + "help", true, false, + "print this help" + }, { + CMD_PASS, + "pass", true, false, + "pass current data to its destination" + }, { + CMD_DISCARD, + "discard", true, false, + "discard current data" + }, { + CMD_SEND_QEMU, + "qemu", true, true, + "send DATA to qemu" + }, { + CMD_SEND_LIBVIRT, + "libvirt", true, true, + "send DATA to libvirt" + } +}; + + +static void ATTRIBUTE_NORETURN +usage(int ret) +{ + fprintf(stderr, "monitor-proxy [-i] <qemu monitor socket>\n"); + exit(ret); +} + + +static void ATTRIBUTE_FMT_PRINTF(1, 2) +print(const char *msg, ...) +{ + va_list args; + + printf("* "); + va_start(args, msg); + vprintf(msg, args); + va_end(args); + printf("\n"); + fflush(NULL); +} + + +#define HELP_LINE 80 +#define HELP_NAME 20 +static void +help(void) +{ + unsigned int i; + char line[HELP_LINE]; + char name[HELP_NAME]; + + print("Available proxy commands:"); + for (i = 0; i < ncommands; i++) { + const struct proxy_command *cmd = proxy_commands + i; + + if (cmd->shortcut) + snprintf(name, HELP_NAME, "%c(%s)", cmd->name[0], cmd->name + 1); + else + strncpy(name, cmd->name, HELP_NAME); + name[HELP_NAME - 1] = '\0'; + if (cmd->argument) { + strncpy(name + strlen(name), " DATA", HELP_NAME - strlen(name)); + name[HELP_NAME - 1] = '\0'; + } + + snprintf(line, HELP_LINE, " %-*s %s", + HELP_NAME, name, cmd->description); + line[HELP_LINE - 1] = '\0'; + print("%s", line); + } + print("Signals:"); + print(" SIGINT (^C) quit monitor-proxy"); +} + + +static int +move_socket(void) +{ + if (monitor_qemu) { + fprintf(stderr, "Socket already moved to %s\n", monitor_qemu); + return -1; + } + + monitor_qemu = malloc(strlen(monitor) + strlen(SOCK_SUFFIX) + 1); + if (!monitor_qemu) + return -1; + + sprintf(monitor_qemu, "%s%s", monitor, SOCK_SUFFIX); + + if (rename(monitor, monitor_qemu) < 0) { + perror("Cannot move monitor socket"); + free(monitor_qemu); + monitor_qemu = NULL; + return -1; + } + + print("Monitor socket renamed as %s", monitor_qemu); + + return 0; +} + + +static int +restore_socket(void) +{ + if (!monitor_qemu) + return 0; + + if (rename(monitor_qemu, monitor) < 0) { + perror("Cannot restore monitor socket"); + return -1; + } + + print("Monitor socket renamed back to %s", monitor); + + free(monitor_qemu); + monitor_qemu = NULL; + + return 0; +} + + +static void ATTRIBUTE_NORETURN +signal_handler(int signum) +{ + restore_socket(); + + if (signum == SIGINT) + exit(0); + else + exit(1); +} + + +static int +open_qemu(void) +{ + struct sockaddr_un addr; + int fd = -1; + + if ((fd = socket(PF_UNIX, SOCK_STREAM, 0)) == -1) { + perror("Cannot create monitor socket"); + goto error; + } + + addr.sun_family = AF_UNIX; + strncpy(addr.sun_path, monitor_qemu, UNIX_PATH_MAX); + addr.sun_path[UNIX_PATH_MAX - 1] = '\0'; + + if (connect(fd, (struct sockaddr *) &addr, sizeof(addr)) < 0) { + perror("Cannot connect to qemu monitor"); + goto error; + } + + print("Connected to qemu monitor"); + + return fd; + +error: + close(fd); + return -1; +} + + +static int +listen_libvirt(void) +{ + struct sockaddr_un addr; + int fd = -1; + + if ((fd = socket(PF_UNIX, SOCK_STREAM, 0)) == -1) { + perror("Cannot create listening socket"); + goto error; + } + + addr.sun_family = AF_UNIX; + strncpy(addr.sun_path, monitor, UNIX_PATH_MAX); + addr.sun_path[UNIX_PATH_MAX - 1] = '\0'; + + if (bind(fd, (struct sockaddr *) &addr, sizeof(addr)) < 0) { + perror("Cannot bind listening socket"); + goto error; + } + + if (listen(fd, 1) < 0) { + perror("Cannot listen"); + goto error; + } + + return fd; + +error: + close(fd); + return -1; +} + + +static int +accept_libvirt(int sock) +{ + int fd = -1; + + print("Waiting for libvirt connection"); + + if ((fd = accept(sock, NULL, NULL)) == -1) { + perror("Cannot accept connection from libvirt"); + goto error; + } + + print("Libvirt connection accepted"); + + return fd; + +error: + close(fd); + return -1; +} + + +static int +init_message(struct message *msg, int qemu, int libvirt) +{ + struct iovec *iov; + + if (!(iov = malloc(sizeof(*iov)))) + return -1; + + memset(msg, 0, sizeof(*msg)); + msg->fd_qemu = qemu; + msg->fd_libvirt = libvirt; + msg->hdr.msg_iov = iov; + msg->hdr.msg_iovlen = 1; + + return 0; +} + + +static ssize_t +receive_message(enum party source, struct message *msg) +{ + ssize_t count; + int fd = source == PARTY_QEMU ? msg->fd_qemu : msg->fd_libvirt; + + msg->source = source; + msg->hdr.msg_iov[0].iov_base = buffer; + msg->hdr.msg_iov[0].iov_len = SIZE; + msg->hdr.msg_control = control; + msg->hdr.msg_controllen = SIZE; + + if ((count = recvmsg(fd, &msg->hdr, 0)) >= 0) { + msg->hdr.msg_iov[0].iov_len = count; + if (msg->hdr.msg_controllen == 0) + msg->hdr.msg_control = NULL; + } + + return count; +} + + +static void +send_message(enum party target, struct message *msg) +{ + int fd = target == PARTY_QEMU ? msg->fd_qemu : msg->fd_libvirt; + + if (sendmsg(fd, &msg->hdr, 0) < 0) { + if (target == PARTY_QEMU) { + perror("Cannot send message to qemu"); + } else { + perror("Cannot send message to libvirt"); + } + } + + msg->hdr.msg_iov[0].iov_base = NULL; + msg->hdr.msg_iov[0].iov_len = 0; + msg->hdr.msg_control = NULL; + msg->hdr.msg_controllen = 0; +} + + +static int +write_all(int fd, const char *buf, size_t count) +{ + size_t written = 0; + ssize_t w; + + while (count > 0) { + w = write(fd, buf, count); + + if (w == 0) { + break; + } else if (w < 0) { + if (errno == EINTR) + continue; + perror("Cannot write data"); + return -1; + } + + buf += w; + count -= w; + written += w; + } + + return written; +} + + +static int +output(const char *label, const struct message *msg) +{ + ssize_t start = 0; + char *buf = msg->hdr.msg_iov[0].iov_base; + ssize_t count = msg->hdr.msg_iov[0].iov_len; + + while (start < count) { + ssize_t len = 0; + const char* p; + + if (write_all(STDOUT_FILENO, label, strlen(label)) < 0) + return -1; + + p = buf + start; + while (start + len < count && *p != '\n') { + len++; + p++; + } + if (start + len < count) + len++; + + if (write_all(STDOUT_FILENO, buf + start, len) < 0) + return -1; + + start += len; + } + + return 0; +} + + +static ssize_t +read_line(char *buf, size_t size, bool data) +{ + ssize_t count = 0; + struct timeval tv = { 0, 0 }; + struct timeval *timeout; + fd_set fds; + int ret; + + FD_ZERO(&fds); + FD_SET(STDIN_FILENO, &fds); + + if (data) + timeout = NULL; + else + timeout = &tv; + + ret = select(STDIN_FILENO + 1, &fds, NULL, NULL, timeout); + if (ret < 0) + return -1; + if (ret == 0) + return 0; + + while (count < size - 1 && read(STDIN_FILENO, buf, 1) == 1) { + count++; + if (*buf == '\n') { + *buf = '\r'; + *++buf = '\n'; + count++; + break; + } + buf++; + } + return count; +} + + +static enum command +get_command(char **cmd_buf, ssize_t *cmd_len, bool data) +{ + ssize_t len; + unsigned int i; + + if (data) + write_all(STDOUT_FILENO, LABEL_PROMPT, strlen(LABEL_PROMPT)); + + len = read_line(commands, SIZE, data); + if (len < 0) + return CMD_QUIT; + if (len == 0) + return CMD_NONE; + if (len <= 2) + return CMD_NOOP; + + commands[len] = '\0'; + + for (i = 0; i < ncommands; i++) { + const struct proxy_command *cmd = proxy_commands + i; + int skip; + + if (strncmp(commands, cmd->name, strlen(cmd->name)) == 0) + skip = strlen(cmd->name); + else if (cmd->shortcut && *commands == *cmd->name) + skip = 1; + else + continue; + + if (cmd->argument) { + if (commands[skip] == ' ') { + skip++; + *cmd_buf = commands + skip; + *cmd_len = len - skip; + return cmd->command; + } + } else { + if (strncmp(commands + skip, "\r\n", 2) == 0) + return cmd->command; + } + } + + commands[len - 2] = '\0'; + *cmd_buf = commands; + *cmd_len = len - 2; + return CMD_UNKNOWN; +} + + +static int +process_commands(struct message *msg, bool *interactive) +{ + enum party source = msg->source; + ssize_t data_len = msg->hdr.msg_iov[0].iov_len; + ssize_t control_len = msg->hdr.msg_controllen; + bool data = data_len > 0 || control_len > 0; + enum command cmd; + char *cmd_buf = NULL; + ssize_t cmd_len = 0; + + msg->hdr.msg_iov[0].iov_base = NULL; + msg->hdr.msg_iov[0].iov_len = 0; + msg->hdr.msg_control = NULL; + msg->hdr.msg_controllen = 0; + + if (data) { + print("Processing data from %s", + source == PARTY_QEMU ? "qemu" : "libvirt"); + print(" Enter proxy commands (type \"help\" to list them)"); + print(" Finish processing with \"pass\" or \"discard\" command"); + } + + while (*interactive && + (cmd = get_command(&cmd_buf, &cmd_len, data)) != CMD_NONE) { + switch (cmd) { + case CMD_NONE: + case CMD_NOOP: + break; + + case CMD_QUIT: + return -1; + + case CMD_HELP: + help(); + break; + + case CMD_UNKNOWN: + print("Unknown command: \"%s\"", cmd_buf); + break; + + case CMD_CONTINUE: + *interactive = false; + print("Leaving interactive mode"); + case CMD_PASS: + if (data_len > 0) { + msg->hdr.msg_iov[0].iov_len = data_len; + msg->hdr.msg_iov[0].iov_base = buffer; + } + if (control_len > 0) { + msg->hdr.msg_controllen = control_len; + msg->hdr.msg_control = control; + } + if (data) { + print("Passing data from %s to %s", + source == PARTY_QEMU ? "qemu" : "libvirt", + source == PARTY_QEMU ? "libvirt" : "qemu"); + send_message(source == PARTY_QEMU ? PARTY_LIBVIRT : PARTY_QEMU, + msg); + data = false; + } else { + if (cmd == CMD_PASS) + print("No data to pass"); + } + break; + + case CMD_DISCARD: + if (data) { + print("Discarding data from %s", + source == PARTY_QEMU ? "qemu" : "libvirt"); + } else { + print("No data to discard"); + } + data_len = control_len = 0; + data = false; + break; + + case CMD_SEND_QEMU: + case CMD_SEND_LIBVIRT: + msg->hdr.msg_iov[0].iov_len = cmd_len; + msg->hdr.msg_iov[0].iov_base = cmd_buf; + send_message(cmd == CMD_SEND_QEMU ? PARTY_QEMU : PARTY_LIBVIRT, + msg); + break; + } + } + + return 0; +} + + +static int +process_data(struct message *msg, bool *interactive) +{ + output(msg->source == PARTY_QEMU ? LABEL_QEMU : LABEL_LIBVIRT, msg); + + if (!*interactive) { + send_message(msg->source == PARTY_QEMU ? PARTY_LIBVIRT : PARTY_QEMU, + msg); + } else { + return process_commands(msg, interactive); + } + + return 0; +} + + +static int +proxy(bool *interactive, int libvirt, int qemu) +{ + fd_set fds; + int maxfd; + struct message msg; + int ret = -1; + ssize_t count; + + print("New monitor session"); + if (*interactive) + print("Entering interactive mode"); + + if (init_message(&msg, qemu, libvirt) < 0) { + perror("Cannot initialize msghdr"); + goto cleanup; + } + + maxfd = libvirt > qemu ? libvirt : qemu; + while (1) { + FD_ZERO(&fds); + FD_SET(STDIN_FILENO, &fds); + FD_SET(libvirt, &fds); + FD_SET(qemu, &fds); + + if (select(maxfd + 1, &fds, NULL, NULL, NULL) == -1) { + perror("select() failed"); + goto cleanup; + } + + if (FD_ISSET(qemu, &fds)) { + if ((count = receive_message(PARTY_QEMU, &msg)) <= 0) { + if (count < 0) + perror("Cannot receive message from qemu"); + else + print("Qemu closed connection"); + goto cleanup; + } + if (process_data(&msg, interactive) < 0) + goto cleanup; + } + + if (FD_ISSET(libvirt, &fds)) { + if ((count = receive_message(PARTY_LIBVIRT, &msg) <= 0)) { + if (count < 0) { + perror("Cannot receive message from libvirt"); + } else { + print("Libvirt closed connection"); + ret = 0; + } + goto cleanup; + } + if (process_data(&msg, interactive) < 0) + goto cleanup; + } + + if (!*interactive && FD_ISSET(STDIN_FILENO, &fds)) { + print("Entering interactive mode"); + *interactive = true; + } + + if (*interactive && process_commands(&msg, interactive) < 0) + goto cleanup; + } + +cleanup: + print("Session closed"); + + close(libvirt); + close(qemu); + return ret; +} + + +int +main(int argc, char **argv) +{ + int sock = -1; + int libvirt = -1; + bool interactive = false; + + if (argc < 2) + usage(2); + + if (strcmp(argv[1], "-i") == 0) { + interactive = true; + if (argc < 3) + usage(2); + monitor = argv[2]; + } else { + monitor = argv[1]; + } + + signal(SIGHUP, signal_handler); + signal(SIGINT, signal_handler); + signal(SIGQUIT, signal_handler); + signal(SIGABRT, signal_handler); + signal(SIGKILL, signal_handler); + signal(SIGPIPE, SIG_IGN); + signal(SIGTERM, signal_handler); + + if (move_socket() < 0) + goto error; + + buffer = malloc(SIZE); + control = malloc(SIZE); + commands = malloc(SIZE); + if (!buffer || !control || !commands) + goto error; + + if ((sock = listen_libvirt()) == -1) + goto error; + + while ((libvirt = accept_libvirt(sock)) != -1) { + int qemu; + + if ((qemu = open_qemu()) != -1) { + if (proxy(&interactive, libvirt, qemu) < 0) + break; + } else { + close(libvirt); + } + } + +error: + restore_socket(); + close(sock); + return 1; +} -- 1.7.6

3 2

[libvirt] Network device abstraction aka virtual switch - V3
by Laine Stump 03 Jul '11

03 Jul '11

This is a followup to https://www.redhat.com/archives/libvir-list/2011-April/msg00591.html (and an even earlier draft) which I alluded to here: https://www.redhat.com/archives/libvir-list/2011-June/msg00383.html Network device abstraction aka virtual switch - V3 ================================================== The <interface> element of a guest's domain config in libvirt has a <source> element that describes what resources on a host will be used to connect the guest's network interface to the rest of the world. This is very flexible, allowing several different types of connection (virtual network, host bridge, direct macvtap connection to physical interface, qemu usermode, user-defined via an external script), but currently has the problem that unnecessary details of the host resources are embedded into the guest's config; if the guest is migrated to a different host, and that host has a different hardware or network config (or possibly the same hardware, but that hardware is currently in use by a different guest), the migration will fail. I am proposing a change to libvirt's network XML that will allow us to (optionally - old configs will remain valid) remove the host details from the guest's domain XML (which can move around from host to host) and place them in the network XML (which remains with a single host); the domain XML will then use existing config elements to associate each guest interface with a "network". The motivating use case for this change is the "direct" connection type (which uses macvtap for vepa and vnlink connections directly between a guest and a physical interface, rather than through a bridge), but it is applicable for all types of connection. (Another hopeful side effect of this change will be to make libvirt's network connection model easier to realize on non-Linux hypervisors (eg, VMWare ESX) and for other network technologies, such as openvswitch, VDE, and various VPN implementations). Background ========== (parts lifted from Dan Berrange's last mail on this subject) Currently <network> supports 3 connectivity modes - Non-routed network, separate subnet (no <forward> element present) - Routed network, separate subnet with NAT (<forward mode='nat'/>) - Routed network, separate subnet (<forward mode='route'/>) Each of these is implemented in the existing network driver by creating a bridge device using brctl, and connecting the guest network interfaces via tap devices (a detail which, now that I've stated it, you should promptly forget!). All traffic between that bridge and the outside network is done via the host's IP routing stack (ie, there is no physical device directly connected to the bridge) In the future, these two additional routed modes might be useful: - Routed network, IP subnetting - Routed network, separate subnet with VPN The core goal of this proposal, though, is to replace type=bridge and type=direct from the domain interface XML with new types of <network> definitions so that the domain can just give "type='network'" and have all the necessary details filled in at runtime. This basically means we're adding several bridging modes (the submodes of "direct" have been flattened out here): - Bridged network, eth + bridge + tap - Bridged network, eth + macvtap + vepa - Bridged network, eth + macvtap + private - Bridged network, eth + macvtap + passthrough - Bridged network, eth + macvtap + bridge Another "future expansion" could be to add: - Bridged network, with VPN Likewise, support for other technologies, such as openvswitch and VDE would each be another entry on this list. (Dan also listed each of the above "+sriov" separately, but that ends up being handled in an orthogonal manner (by just specifying a pool of interfaces for a single network), so I'm only giving the abbreviated list) I. Changes to domain <interface> element ======================================== In many cases, the <interface> element of the domain XML will be identical to what is used now when connecting the interface to a libvirt-style virtual network: <interface type='network'> <source network='red-network'/> <mac address='xx:xx:xx:xx:xx:xx'/> </interface> Depending on the definition of the network "red-network" on the host the guest was started on / migrated to, this could be either a direct (macvtap) connection using one of the various direct modes (vepa/private/bridge/passthrough), a bridge (again, pointed to by the definition of 'red-network'), or a virtual network (using the current network definition syntax). This way the same guest could be migrated not only between macvtap-enabled hosts, but from there to a host using a bridge, or maybe a host in a remote location that used a virtual network with a secure tunnel to connect back to the rest of the red-network. (Part of the migration process would of course check that the destination host had a network of the proper name with adequate available resources, and fail if it didn't; management software at a level above libvirt would probably filter a list of candidate migration destinations based on available networks and any various details of those networks (eg. it could search for only networks using vepa for the connection), and only attempt migration to one that had the matching network available). <virtualport> element of <interface> ------------------------------------ Since many of the attributes/sub-elements of <virtualport> (used by some modes of "direct" interface connections) are identical for all interfaces connecting to any given switch, most of the information in <virtualport> will be optional in the domain's interface definition - it can be filled in from a similar <virtualport> element that will be added to the <network> definition. Some parameters in <virtualport> ("instanceid", for example) must be unique for every interface, though, so those will still be specified in the <interface> XML. The two <virtualport> elements will be OR'ed at runtime to arrive at the actual set of parameters that are used. (Open Question: What should be the policy when a parameter is specified in both places? Should one take precedence? Or should it be considered an error?) portgroup attribute of <source> ------------------------------- The <source> element of an interface definition will be able to optionally specify a "portgroup" attribute. If portgroup is *NOT* given, the default (first) portgroup of the network will be used (if any are defined). If portgroup *IS* specified, the source network must have a portgroup by that name (or the domain startup/migration will fail), and the attributes of that portgroup will be used for the connection. Here is an example <interface> definition that has both a reduced <virtualport> element, as well as a portgroup attribute: <interface type='network'> <source network='red-network' portgroup='engineering'/> <virtualport type="802.1Qbg"> <parameters instanceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f"/> </virtualport> <mac address='de:ad:be:ef:ca:fe'/> </interface> (The specifics of what can be in a portgroup are given below) II. Changes to <network> definition =================================== As Dan has pointed out, any additions to <network> must be designed so that existing management applications (written to understand <network> prior to these new additions) will at least recognize that the XML they've been given is for something new that they don't fully understand. At the same time, the new types of network definition should attempt to re-use as much of the existing elements/attributes as possible, both to make it easier to extend these applications, as well as to make the status displays of un-updated applications make as much sense as possible. Dan's suggestion (which I obviously endorse :-) is that the new types of network should be specified by extending the choices for <forward mode='....'>. He also suggested adding a new "layer='network|link'" attribute to <forward>. I'm not convinced that item is necessary (it seems redundant), but am including it here for sake of discussion. The current modes are: <forward layer='network' mode='route|nat'/> (in addition to not listing any mode, which equates to "isolated") Here are suggested new modes: <forward layer='link' mode='bridge-brctl|vepa|private|passthrough|bridge-macvtap'/> A description of each: bridge-brctl - equivalent to "<interface type='bridge'>" in the interface definition. The bridge device to use would be given in the existing <forward dev='xxx'>. (Dan also suggests putting this in <network>'s <bridge name='xxx'/> - opinions?) (Question: better name for this?) vepa - same as "<interface type='direct'>..." with <source mode='vepa'/> private - <interface type='direct'> ... <source mode='private'/> passthrough - <interface type='direct'> ... <source mode='passthrough'/> bridge-macvtap - <interface type='direct'> ... <source mode='bridge'/> (Question: better name for this?) Interface Pools --------------- In many cases, a single host network may have multiple physical network devices associated with it (especially in the case of an SRIOV-capable ethernet card, which will have several "virtual functions" associated with a single physical ethernet connection). The host will at least want to balance the load of multiple guests between these multiple devices, and may even require (in the case of passthrough mode, for example) that only a single guest interface be attached to each host device. The current specification for <forward> only allows for a single "dev" attribute, though. In order to support multiple device names, we will extend <forward> to allow 0 or more <interface> sub-elements: <forward mode='vepa' dev='eth10'/> <interface dev='eth10'/> <interface dev='eth11'/> <interface dev='eth12'/> <interface dev='eth13'/> </forward> Note that, as a convenience, the first of these elements will always be a duplicate of the "dev" attribute in <forward> itself. (Is this necessary/desirable?) In the case of mode='passthrough', only one guest interface can be connected to a device at a time. libvirt will keep track of which devices are in use, and attempt to assign a free device; failure to assign a device will result in a failure of the domain to start/migrate. For the other direct modes, libvirt will simply keep track of the number of guest interfaces currently using each device, and attempt to keep them balanced. (Open question: where will we keep track of this allocation/assignment?) Portgroups ----------- A <portgroup> (sub-element of <network>) is just a way of easily putting connections to the network into different classes, with each class having a different level/type of service. Each <network> can have multiple <portgroup> elements, and each <portgroup> has a name, as well as various attributes associated with it. The first thing we will use portgroups for is as an alternate place to specify <virtualport> parameters: <portgroup name='engineering'> <virtualport type="802.1Qbg"> <parameters managerid="11" typeid="1193047" typeidversion="2"/> </virtualport> </portgroup> Anything that is valid in an interface's <virtualport> is also valid here. The next thing to specify in a portgroup will be bandwidth limiting / QoS configuration. Since I don't know exactly what's needed for that, I won't specify it here. If anything is specified both directly under <network> and in a <portgroup>, the value in portgroup will take precedence. (Again - what will the precedence of items specified in the <interface> be?) EXAMPLES -------- Examples of 'red-network' for different types of connections (all of these would work with minor variations of the interface XML given above, e.g. the 'vepa' version would require <virtualport> in the interface that specified an instanceid, and if the <interface> specified a portgroup, it would need to also be in the <network> definition (even if it was empty aside from name).  <network> <name>red-network</name> <bridge name='virbr0'/> <forward layer='network' mode='route'/> ... </network>  <network> <name>red-network</name> <forward mode='bridge-brctl' dev='br0'/> </network>  <network> <name>red-network</name> <forward layer='link' mode='vepa' dev='eth10'/> <virtualport type='802.1Qbg'> <parameters managerid='11' typeid='1193047' typeidversion='2'/> </virtualport>   <portgroup name='accounting'> <virtualport> <parameters typeid='22'/> </virtualport> </portgroup> <portgroup name='engineering'> <virtualport> <parameters typeid='33'/> </virtualport> </portgroup> </network>  <network> <name>red-network</name> <forward layer='link' mode='passthrough' dev='eth10'/> <interface dev='eth10'/> <interface dev='eth11'/> <interface dev='eth12'/> <interface dev='eth13'/> <interface dev='eth14'/> <interface dev='eth15'/> <interface dev='eth16'/> <interface dev='eth17'/> </forward> </network> ============= Open Questions: * Is there a good reason to include the "layer='network|link'" attribute in forward? (maybe just because it's useful info for a management application that doesn't know the details of the modes?) Or is it redundant? * What should be the policy when a virtualport parameter is specified in both the <interface> and the <network>/<portgroup>? Should one take precedence? Or should it be considered an error? * Is it okay for the domain's own definition to specify what portgroup it will be in? Or are there cases where we want to allow someone to modify their domain XML, but force them into a particular portgroup beyond their control? * Is it really necessary/desirable for the first ethernet device in a pool to be duplicated in the <forward dev='xxx'...> attribute? Or can that attribute be omitted when there is a pool of devices? * Where will we keep track of the count of guest interfaces connected to each host interface device, and where will we keep track of which device is being used by a particular guest interface? In the network/domain XML? * Does anyone have better names for "brctl-bridge" and "macvtap-bridge"?

6 11

[libvirt] FreeBSD Port, update to 0.9.2 compile error
by Jason Helfman 01 Jul '11

01 Jul '11

Hi, I am trying to update the port for libvirt to 0.9.2, but am receiving a new compiling error, that I have not seen yet. console.c:280: warning: declaration of 'devname' shadows a global declaration [-Wshadow] /usr/include/stdlib.h:264: warning: shadowed declaration is here [-Wshadow] CC virsh-virsh.o CCLD virsh GEN virt-xml-validate GEN virt-pki-validate gmake[3]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.2/tools' gmake[2]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.2/tools' Making all in docs gmake[2]: Entering directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.2/docs' GEN libvirt-api.xml ./apibuild.py: not found gmake[2]: *** [libvirt-api.xml] Error 127 gmake[2]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.2/docs' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.2' gmake: *** [all] Error 2 *** Error code 1 Stop in /home/jhelfman/ports/devel/libvirt. Any thoughts? Thanks, Jason -- Jason Helfman System Administrator experts-exchange.com http://www.experts-exchange.com/M_4830110.html E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5

5 19

[libvirt] [PATCH] build: avoid 'make syntax-check' failure
by Eric Blake 01 Jul '11

01 Jul '11

* tests/utiltest.c (DO_TEST): Fix indentation for cppi. --- Pushing under the build-breaker rule. tests/utiltest.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tests/utiltest.c b/tests/utiltest.c index 1b26b72..774a2f7 100644 --- a/tests/utiltest.c +++ b/tests/utiltest.c @@ -160,7 +160,7 @@ mymain(void) virSetErrorFunc(NULL, testQuietError); - #define DO_TEST(_name) \ +#define DO_TEST(_name) \ do { \ if (virtTestRun("Util "#_name, 1, test##_name, \ NULL) < 0) { \ -- 1.7.4.4

1 0

[libvirt] virtual switch - how to store state information
by Laine Stump 01 Jul '11

01 Jul '11

(If you already know about my work on putting a logical switch abstraction into libvirt's <network>, skip to part 2) INTRODUCTION =========== The rudimentary logical network switch capability I'm currently implementing (see https://bugzilla.redhat.com/show_bug.cgi?id=643947) is intended to allow a guest's interface XML to be free of any specific physical network device name, particularly in bridge and direct modes. It does this by expanding the definition of a libvirt <network> to include cases that merely describe a host-configured bridge, or a host interface (or pool of interfaces) that can be used by a guest in one of the 'direct' modes (bridge, private, vepa, or passthrough). It will also allow certain details of the guest's network connection to be configured by "portgroups" in the <network> definition (initially this will be limited to a portgroup containing a <virtualportprofile> and bandwidth limiting information). For example, in the past, a guest that wanted to connect to interface eth10 using the direct (aka 'macvtap') "vepa" mode would need to have this <interface> in its guest XML: <interface type='direct'> <mac address='52:54:00:34:a5:aa'/> <source dev='eth10' mode='vepa'/> <model type='virtio'/> <virtualport type='802.1Qbg'> <parameters managerid='33' typeid='89' typeidversion='3'/> </virtualport> </interface> With my new code, you can instead define a <network> with connections on several physical ethernets: <network> <name>test</name> <forward mode='vepa'> <interface dev='eth10'/> <interface dev='eth11'/> <interface dev='eth12'/> <interface dev='eth13'/> <interface dev='eth14'/> <interface dev='eth15'/> <interface dev='eth16'/> <interface dev='eth17'/> </forward> <portgroup name='accounting'> <virtualport type='802.1Qbg'> <parameters managerid='44' typeid='54' typeidversion='1'/> </virtualport> </portgroup> <portgroup name='engineering' default='yes'> <virtualport type='802.1Qbg'> <parameters managerid='33' typeid='89' typeidversion='3'/> </virtualport> </portgroup> </network> and then tell the domain's <interface> to get the information from the network: <interface type='network'> <mac address='52:54:00:34:a5:aa'/> <source network='test' portgroup='engineering'/> <model type='virtio'/> </interface> When libvirt sets up the interface connection, it will grab the config for network 'test', see that the forward mode is 'vepa', decide which physical ethernet to use, add in any extra stuff from the <portgroup>, and use that as the information for connection. In this manner, 1) it will remove the hardcoded device name from the domain config, making it possible to migrate the domain to other hardware, and 2) share a pool of physical devices over a group of domains. PROPOSAL ======== After I've determined which physical device to use, I need to save that information for as long as the domain is running, so that if libvirtd is restarted, it won't be lost (in some configs, only a single guest can use any particular netdev at a given time, so we want to be able to manage allocation of the devices without leaking any). My current idea is to save this in the domain <interface> XML that's put in the state directory, but make sure that it's never put into the XML returned by virsh dumpxml. What I'm thinking of is to add an <actual> subelement under <interface>, like this: <interface type='network'> <mac address='52:54:00:34:a5:aa'/> <source network='test' porgroup='engineering'/> <model type='virtio'/> <actual type='direct'/> <source dev='eth10' mode='vepa'/> <virtualport type='802.1Qbg'> <parameters managerid='33' typeid='89' typeidversion='3'/> </virtualport> </actual> </interface> This will be a private/internal thing used only within libvirt, however it does need to be stable, since it has to be understandable by a libvirtd that has started up while guests are running (eg during a libvirt upgrade). So I want to make sure I'm doing something reasonable. So, it is? Should <actual> contain *everything* from the parent interface, plus the items that are changed? Or should it contain only: * type attribute * source element * <bridge name=.../> (if applicable) * <virtualport> (and other items that might come from <portgroup> in the future (i.e. the things that have changed)? I *think* the answer is that it should just contain the items that have changed, and there should be a wrapper API around the virDomainNetDef object for retrieving things like type (if (def->actual) return def->actual.type; else return def->type; and similar) to make sure that all functions use the correct data.

1 0

[libvirt] [PATCH] tests: Add a general util test
by Matthias Bolte 01 Jul '11

01 Jul '11

Move non-esx specific tests from esxutilstest there and add a test for virParseVersionString. --- tests/.gitignore | 1 + tests/Makefile.am | 8 ++- tests/esxutilstest.c | 70 -------------------- tests/utiltest.c | 178 ++++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 186 insertions(+), 71 deletions(-) create mode 100644 tests/utiltest.c diff --git a/tests/.gitignore b/tests/.gitignore index 7f26dd7..32457ab 100644 --- a/tests/.gitignore +++ b/tests/.gitignore @@ -30,6 +30,7 @@ sockettest statstest storagepoolxml2xmltest storagevolxml2xmltest +utiltest virbuftest virnetmessagetest virnetsockettest diff --git a/tests/Makefile.am b/tests/Makefile.am index 4bea18e..30b2d95 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -84,7 +84,8 @@ EXTRA_DIST = \ check_PROGRAMS = virshtest conftest sockettest \ nodeinfotest qparamtest virbuftest \ commandtest commandhelper seclabeltest \ - hashtest virnetmessagetest virnetsockettest ssh + hashtest virnetmessagetest virnetsockettest ssh \ + utiltest # This is a fake SSH we use from virnetsockettest ssh_SOURCES = ssh.c @@ -202,6 +203,7 @@ TESTS = virshtest \ hashtest \ virnetmessagetest \ virnetsockettest \ + utiltest \ $(test_scripts) if HAVE_YAJL @@ -460,6 +462,10 @@ jsontest_SOURCES = \ jsontest.c testutils.h testutils.c jsontest_LDADD = $(LDADDS) +utiltest_SOURCES = \ + utiltest.c testutils.h testutils.c +utiltest_LDADD = $(LDADDS) + if WITH_LIBVIRTD eventtest_SOURCES = \ eventtest.c testutils.h testutils.c diff --git a/tests/esxutilstest.c b/tests/esxutilstest.c index 51c1e34..2097648 100644 --- a/tests/esxutilstest.c +++ b/tests/esxutilstest.c @@ -24,74 +24,6 @@ testQuietError(void *userData ATTRIBUTE_UNUSED, -static const char* names[] = { - "sda", "sdb", "sdc", "sdd", "sde", "sdf", "sdg", "sdh", "sdi", "sdj", "sdk", "sdl", "sdm", "sdn", "sdo", "sdp", "sdq", "sdr", "sds", "sdt", "sdu", "sdv", "sdw", "sdx", "sdy", "sdz", - "sdaa", "sdab", "sdac", "sdad", "sdae", "sdaf", "sdag", "sdah", "sdai", "sdaj", "sdak", "sdal", "sdam", "sdan", "sdao", "sdap", "sdaq", "sdar", "sdas", "sdat", "sdau", "sdav", "sdaw", "sdax", "sday", "sdaz", - "sdba", "sdbb", "sdbc", "sdbd", "sdbe", "sdbf", "sdbg", "sdbh", "sdbi", "sdbj", "sdbk", "sdbl", "sdbm", "sdbn", "sdbo", "sdbp", "sdbq", "sdbr", "sdbs", "sdbt", "sdbu", "sdbv", "sdbw", "sdbx", "sdby", "sdbz", - "sdca", "sdcb", "sdcc", "sdcd", "sdce", "sdcf", "sdcg", "sdch", "sdci", "sdcj", "sdck", "sdcl", "sdcm", "sdcn", "sdco", "sdcp", "sdcq", "sdcr", "sdcs", "sdct", "sdcu", "sdcv", "sdcw", "sdcx", "sdcy", "sdcz", - "sdda", "sddb", "sddc", "sddd", "sdde", "sddf", "sddg", "sddh", "sddi", "sddj", "sddk", "sddl", "sddm", "sddn", "sddo", "sddp", "sddq", "sddr", "sdds", "sddt", "sddu", "sddv", "sddw", "sddx", "sddy", "sddz", - "sdea", "sdeb", "sdec", "sded", "sdee", "sdef", "sdeg", "sdeh", "sdei", "sdej", "sdek", "sdel", "sdem", "sden", "sdeo", "sdep", "sdeq", "sder", "sdes", "sdet", "sdeu", "sdev", "sdew", "sdex", "sdey", "sdez", - "sdfa", "sdfb", "sdfc", "sdfd", "sdfe", "sdff", "sdfg", "sdfh", "sdfi", "sdfj", "sdfk", "sdfl", "sdfm", "sdfn", "sdfo", "sdfp", "sdfq", "sdfr", "sdfs", "sdft", "sdfu", "sdfv", "sdfw", "sdfx", "sdfy", "sdfz", - "sdga", "sdgb", "sdgc", "sdgd", "sdge", "sdgf", "sdgg", "sdgh", "sdgi", "sdgj", "sdgk", "sdgl", "sdgm", "sdgn", "sdgo", "sdgp", "sdgq", "sdgr", "sdgs", "sdgt", "sdgu", "sdgv", "sdgw", "sdgx", "sdgy", "sdgz", - "sdha", "sdhb", "sdhc", "sdhd", "sdhe", "sdhf", "sdhg", "sdhh", "sdhi", "sdhj", "sdhk", "sdhl", "sdhm", "sdhn", "sdho", "sdhp", "sdhq", "sdhr", "sdhs", "sdht", "sdhu", "sdhv", "sdhw", "sdhx", "sdhy", "sdhz", - "sdia", "sdib", "sdic", "sdid", "sdie", "sdif", "sdig", "sdih", "sdii", "sdij", "sdik", "sdil", "sdim", "sdin", "sdio", "sdip", "sdiq", "sdir", "sdis", "sdit", "sdiu", "sdiv", "sdiw", "sdix", "sdiy", "sdiz" -}; - -static int -testIndexToDiskName(const void *data ATTRIBUTE_UNUSED) -{ - int i; - char *name = NULL; - - for (i = 0; i < ARRAY_CARDINALITY(names); ++i) { - VIR_FREE(name); - - name = virIndexToDiskName(i, "sd"); - - if (STRNEQ(names[i], name)) { - virtTestDifference(stderr, names[i], name); - VIR_FREE(name); - - return -1; - } - } - - VIR_FREE(name); - - return 0; -} - -static int -testDiskNameToIndex(const void *data ATTRIBUTE_UNUSED) -{ - int i, k; - char *name = NULL; - - for (i = 0; i < 100000; ++i) { - VIR_FREE(name); - - name = virIndexToDiskName(i, "sd"); - k = virDiskNameToIndex(name); - - if (k != i) { - if (virTestGetDebug() > 0) { - fprintf(stderr, "\nExpect [%d]\n", i); - fprintf(stderr, "Actual [%d]\n", k); - } - - VIR_FREE(name); - - return -1; - } - } - - VIR_FREE(name); - - return 0; -} - - - struct testPath { const char *datastorePath; int result; @@ -336,8 +268,6 @@ mymain(void) } \ } while (0) - DO_TEST(IndexToDiskName); - DO_TEST(DiskNameToIndex); DO_TEST(ParseDatastorePath); DO_TEST(ConvertDateTimeToCalendarTime); DO_TEST(EscapeDatastoreItem); diff --git a/tests/utiltest.c b/tests/utiltest.c new file mode 100644 index 0000000..1b26b72 --- /dev/null +++ b/tests/utiltest.c @@ -0,0 +1,178 @@ +#include <config.h> + +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <unistd.h> + +#include "internal.h" +#include "memory.h" +#include "testutils.h" +#include "util.h" + + +static void +testQuietError(void *userData ATTRIBUTE_UNUSED, + virErrorPtr error ATTRIBUTE_UNUSED) +{ + /* nothing */ +} + + + +static const char* diskNames[] = { + "sda", "sdb", "sdc", "sdd", "sde", "sdf", "sdg", "sdh", "sdi", "sdj", "sdk", "sdl", "sdm", "sdn", "sdo", "sdp", "sdq", "sdr", "sds", "sdt", "sdu", "sdv", "sdw", "sdx", "sdy", "sdz", + "sdaa", "sdab", "sdac", "sdad", "sdae", "sdaf", "sdag", "sdah", "sdai", "sdaj", "sdak", "sdal", "sdam", "sdan", "sdao", "sdap", "sdaq", "sdar", "sdas", "sdat", "sdau", "sdav", "sdaw", "sdax", "sday", "sdaz", + "sdba", "sdbb", "sdbc", "sdbd", "sdbe", "sdbf", "sdbg", "sdbh", "sdbi", "sdbj", "sdbk", "sdbl", "sdbm", "sdbn", "sdbo", "sdbp", "sdbq", "sdbr", "sdbs", "sdbt", "sdbu", "sdbv", "sdbw", "sdbx", "sdby", "sdbz", + "sdca", "sdcb", "sdcc", "sdcd", "sdce", "sdcf", "sdcg", "sdch", "sdci", "sdcj", "sdck", "sdcl", "sdcm", "sdcn", "sdco", "sdcp", "sdcq", "sdcr", "sdcs", "sdct", "sdcu", "sdcv", "sdcw", "sdcx", "sdcy", "sdcz", + "sdda", "sddb", "sddc", "sddd", "sdde", "sddf", "sddg", "sddh", "sddi", "sddj", "sddk", "sddl", "sddm", "sddn", "sddo", "sddp", "sddq", "sddr", "sdds", "sddt", "sddu", "sddv", "sddw", "sddx", "sddy", "sddz", + "sdea", "sdeb", "sdec", "sded", "sdee", "sdef", "sdeg", "sdeh", "sdei", "sdej", "sdek", "sdel", "sdem", "sden", "sdeo", "sdep", "sdeq", "sder", "sdes", "sdet", "sdeu", "sdev", "sdew", "sdex", "sdey", "sdez", + "sdfa", "sdfb", "sdfc", "sdfd", "sdfe", "sdff", "sdfg", "sdfh", "sdfi", "sdfj", "sdfk", "sdfl", "sdfm", "sdfn", "sdfo", "sdfp", "sdfq", "sdfr", "sdfs", "sdft", "sdfu", "sdfv", "sdfw", "sdfx", "sdfy", "sdfz", + "sdga", "sdgb", "sdgc", "sdgd", "sdge", "sdgf", "sdgg", "sdgh", "sdgi", "sdgj", "sdgk", "sdgl", "sdgm", "sdgn", "sdgo", "sdgp", "sdgq", "sdgr", "sdgs", "sdgt", "sdgu", "sdgv", "sdgw", "sdgx", "sdgy", "sdgz", + "sdha", "sdhb", "sdhc", "sdhd", "sdhe", "sdhf", "sdhg", "sdhh", "sdhi", "sdhj", "sdhk", "sdhl", "sdhm", "sdhn", "sdho", "sdhp", "sdhq", "sdhr", "sdhs", "sdht", "sdhu", "sdhv", "sdhw", "sdhx", "sdhy", "sdhz", + "sdia", "sdib", "sdic", "sdid", "sdie", "sdif", "sdig", "sdih", "sdii", "sdij", "sdik", "sdil", "sdim", "sdin", "sdio", "sdip", "sdiq", "sdir", "sdis", "sdit", "sdiu", "sdiv", "sdiw", "sdix", "sdiy", "sdiz" +}; + +static int +testIndexToDiskName(const void *data ATTRIBUTE_UNUSED) +{ + int i; + char *diskName = NULL; + + for (i = 0; i < ARRAY_CARDINALITY(diskNames); ++i) { + VIR_FREE(diskName); + + diskName = virIndexToDiskName(i, "sd"); + + if (STRNEQ(diskNames[i], diskName)) { + virtTestDifference(stderr, diskNames[i], diskName); + VIR_FREE(diskName); + + return -1; + } + } + + VIR_FREE(diskName); + + return 0; +} + + + +static int +testDiskNameToIndex(const void *data ATTRIBUTE_UNUSED) +{ + int i, k; + char *diskName = NULL; + + for (i = 0; i < 100000; ++i) { + VIR_FREE(diskName); + + diskName = virIndexToDiskName(i, "sd"); + k = virDiskNameToIndex(diskName); + + if (k != i) { + if (virTestGetDebug() > 0) { + fprintf(stderr, "\nExpect [%d]\n", i); + fprintf(stderr, "Actual [%d]\n", k); + } + + VIR_FREE(diskName); + + return -1; + } + } + + VIR_FREE(diskName); + + return 0; +} + + + +struct testVersionString +{ + const char *string; + bool allowMissing; + int result; + unsigned long version; +}; + +static struct testVersionString versions[] = { + { "2.6.38-8-generic", false, 0, 1000000 * 2 + 1000 * 6 + 38 }, + { "3.0-1-virtual", true, 0, 1000000 * 3 + 1000 * 0 + 0 }, + { "5", true, 0, 1000000 * 5 + 1000 * 0 + 0 }, + { "4.1.0", false, 0, 1000000 * 4 + 1000 * 1 + 0 }, + { "12.345.678", false, 0, 1000000 * 12 + 1000 * 345 + 678 }, + { "1.234.5678", false, -1, 0 }, + { "1.2345.678", false, -1, 0 }, + { "12345.6.78", false, -1, 0 }, + { "123456789", true, -1, 0 }, + { "3.0-2-virtual", false, -1, 0 }, + { "no-number-here", false, -1, 0 }, +}; + +static int +testParseVersionString(const void *data ATTRIBUTE_UNUSED) +{ + int i, result; + unsigned long version; + + for (i = 0; i < ARRAY_CARDINALITY(versions); ++i) { + result = virParseVersionString(versions[i].string, &version, + versions[i].allowMissing); + + if (result != versions[i].result) { + if (virTestGetDebug() > 0) { + fprintf(stderr, "\nVersion string [%s]\n", versions[i].string); + fprintf(stderr, "Expect result [%d]\n", versions[i].result); + fprintf(stderr, "Actual result [%d]\n", result); + } + + return -1; + } + + if (result < 0) { + continue; + } + + if (version != versions[i].version) { + if (virTestGetDebug() > 0) { + fprintf(stderr, "\nVersion string [%s]\n", versions[i].string); + fprintf(stderr, "Expect version [%lu]\n", versions[i].version); + fprintf(stderr, "Actual version [%lu]\n", version); + } + + return -1; + } + } + + return 0; +} + + + + +static int +mymain(void) +{ + int result = 0; + + virSetErrorFunc(NULL, testQuietError); + + #define DO_TEST(_name) \ + do { \ + if (virtTestRun("Util "#_name, 1, test##_name, \ + NULL) < 0) { \ + result = -1; \ + } \ + } while (0) + + DO_TEST(IndexToDiskName); + DO_TEST(DiskNameToIndex); + DO_TEST(ParseVersionString); + + return result == 0 ? EXIT_SUCCESS : EXIT_FAILURE; +} + +VIRT_TEST_MAIN(mymain) -- 1.7.4.1

2 2

[libvirt] [PATCH] fix virParseVersionString with linux 3.0
by Scott Moser 01 Jul '11

01 Jul '11

linux 3.0 has no micro version number, and that is causing problems for virParseVersionString. The patch below should allow for: major major.minor major.minor.micro If major or minor are not present they just default to zero. We found this in Ubuntu (https://bugs.launchpad.net/bugs/802977) diff --git a/src/util/util.c b/src/util/util.c index 463d2b8..01848a1 100644 --- a/src/util/util.c +++ b/src/util/util.c @@ -1598,17 +1598,17 @@ virParseNumber(const char **str) int virParseVersionString(const char *str, unsigned long *version) { - unsigned int major, minor, micro; + unsigned int major, minor=0, micro=0; char *tmp; - if (virStrToLong_ui(str, &tmp, 10, &major) < 0 || *tmp != '.') + if (virStrToLong_ui(str, &tmp, 10, &major) < 0) return -1; - if (virStrToLong_ui(tmp + 1, &tmp, 10, &minor) < 0 || *tmp != '.') - return -1; + if ((*tmp == '.') && virStrToLong_ui(tmp + 1, &tmp, 10, &minor) < 0) + return -1; - if (virStrToLong_ui(tmp + 1, &tmp, 10, &micro) < 0) - return -1; + if ((*tmp == '.') && virStrToLong_ui(tmp + 1, &tmp, 10, &micro) < 0) + return -1; *version = 1000000 * major + 1000 * minor + micro;

3 9

[libvirt] [PATCHv2] build: consistently use CFLAGS
by Eric Blake 01 Jul '11

01 Jul '11

According to the automake manual, CPPFLAGS (aka INCLUDES, as spelled in automake 1.9.6) should only include -I, -D, and -U directives; more generic directives like -Wall belong in CFLAGS since they affect more phases of the build process. Therefore, we should be sticking CFLAGS additions into a CFLAGS container, not a CPPFLAGS container. * src/Makefile.am (INCLUDES): Move CFLAGS items... (AM_CFLAGS): ...to their proper location. * python/Makefile.am (INCLUDES, AM_CFLAGS): Likewise. * tests/Makefile.am (INCLUDES, AM_CFLAGS): Likewise. --- v1 had no review: https://www.redhat.com/archives/libvir-list/2011-May/msg01934.html changes from v1: rebase to latest I tested it on top of these two patches, hopefully they'll be ack'd first: https://www.redhat.com/archives/libvir-list/2011-June/msg01537.html https://www.redhat.com/archives/libvir-list/2011-June/msg01486.html python/Makefile.am | 5 +++-- src/Makefile.am | 15 +++++++-------- tests/Makefile.am | 8 +++++--- 3 files changed, 15 insertions(+), 13 deletions(-) diff --git a/python/Makefile.am b/python/Makefile.am index 432ad70..0edb3e4 100644 --- a/python/Makefile.am +++ b/python/Makefile.am @@ -3,12 +3,13 @@ SUBDIRS= . tests INCLUDES = \ - $(WARN_CFLAGS) \ - $(PYTHON_INCLUDES) \ + $(PYTHON_INCLUDES) \ -I$(top_srcdir)/include \ -I$(top_builddir)/include \ -I$(top_builddir)/$(subdir) +AM_CFLAGS = $(WARN_CFLAGS) + DOCS_DIR = $(datadir)/doc/libvirt-python-$(LIBVIRT_VERSION) DOCS = ${srcdir}/TODO diff --git a/src/Makefile.am b/src/Makefile.am index 4ba3ea7..10ee20a 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -3,20 +3,19 @@ # No libraries with the exception of LIBXML should be listed # here. List them against the individual XXX_la_CFLAGS targets # that actually use them -INCLUDES = \ - -I$(top_srcdir)/gnulib/lib \ +INCLUDES = -I$(top_srcdir)/gnulib/lib \ -I../gnulib/lib \ -I../include \ -I@top_srcdir@/src/util \ -I@top_srcdir@/include \ - $(DRIVER_MODULE_CFLAGS) \ + -DIN_LIBVIRT + +AM_CFLAGS = $(DRIVER_MODULE_CFLAGS) \ $(LIBXML_CFLAGS) \ $(WARN_CFLAGS) \ - $(LOCK_CHECKING_CFLAGS) \ - -DIN_LIBVIRT \ - $(WIN32_EXTRA_CFLAGS) - -AM_CFLAGS = $(COVERAGE_CFLAGS) + $(LOCK_CHECKING_CFLAGS) \ + $(WIN32_EXTRA_CFLAGS) \ + $(COVERAGE_CFLAGS) AM_LDFLAGS = $(COVERAGE_LDFLAGS) EXTRA_DIST = $(conf_DATA) diff --git a/tests/Makefile.am b/tests/Makefile.am index 38a353f..984d8fd 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -8,15 +8,17 @@ INCLUDES = \ -I$(top_srcdir)/include \ -I$(top_srcdir)/src \ -I$(top_srcdir)/src/util \ - -I$(top_srcdir)/src/conf \ + -I$(top_srcdir)/src/conf + +AM_CFLAGS = \ $(LIBXML_CFLAGS) \ $(GNUTLS_CFLAGS) \ $(SASL_CFLAGS) \ $(SELINUX_CFLAGS) \ $(APPARMOR_CFLAGS) \ $(YAJL_CFLAGS) \ - $(COVERAGE_CFLAGS) \ - $(WARN_CFLAGS) + $(COVERAGE_CFLAGS) \ + $(WARN_CFLAGS) if WITH_DRIVER_MODULES INCLUDES += \ -- 1.7.4.4

2 5