August 2012 - Devel - libvirt List Archives

[libvirt] [PATCH] build: silence stupid gcc warning on STREQ_NULLABLE
by Eric Blake 21 Aug '12

21 Aug '12

Our existing STRNEQ_NULLABLE() triggered a warning in gcc 4.7 when used with a literal NULL argument: qemumonitorjsontest.c: In function 'testQemuMonitorJSONGetMachines': qemumonitorjsontest.c:289:5: error: null argument where non-null required (argument 1) [-Werror=nonnull] even though the strcmp is provably dead when a null argument is present. Squelch the warning by refactoring things so that gcc never sees strcmp() called with NULL arguments (we still compare NULL as not equal to "", this rewrite merely aids gcc). Next, gcc has a valid warning about a literal NULLSTR(NULL): qemumonitorjsontest.c:289:5: error: invalid application of 'sizeof' to a void type [-Werror=pointer-arith] Of course, you'd never write NULLSTR(NULL) directly, but it is handy to use through macros. And since we only really need the code to be warning-free when developing with modern gcc, and merely compiled correctly elsewhere, we can rely on gcc extensions to avoid dereferencing NULL even inside a sizeof operation. * src/internal.h (STREQ_NULLABLE, STRNEQ_NULLABLE): Avoid gcc 4.7 stupidity. (NULLSTR): Allow passing compile-time constants via macros. --- src/internal.h | 24 ++++++++++++++++++------ 1 file changed, 18 insertions(+), 6 deletions(-) diff --git a/src/internal.h b/src/internal.h index 300de3a..c27ffc5 100644 --- a/src/internal.h +++ b/src/internal.h @@ -79,10 +79,9 @@ # define STRSKIP(a,b) (STRPREFIX(a,b) ? (a) + strlen(b) : NULL) # define STREQ_NULLABLE(a, b) \ - ((!(a) && !(b)) || ((a) && (b) && STREQ((a), (b)))) + ((a) ? (b) && STREQ((a) ? (a) : "", (b) ? (b) : "") : !(b)) # define STRNEQ_NULLABLE(a, b) \ - ((!(a) ^ !(b)) || ((a) && (b) && STRNEQ((a), (b)))) - + ((a) ? !(b) || STRNEQ((a) ? (a) : "", (b) ? (b) : "") : !!(b)) # define NUL_TERMINATE(buf) do { (buf)[sizeof(buf)-1] = '\0'; } while (0) # define ARRAY_CARDINALITY(Array) (sizeof(Array) / sizeof(*(Array))) @@ -206,9 +205,22 @@ /* * Use this when passing possibly-NULL strings to printf-a-likes. */ -# define NULLSTR(s) \ - ((void)verify_true(sizeof(*(s)) == sizeof(char)), \ - (s) ? (s) : "(null)") +# if __GNUC_PREREQ(4, 6) +char *link_error_due_to_bad_NULLSTR_type(void); +# define NULLSTR(s) \ + ({ \ + const char *_tmp; \ + if (__builtin_constant_p(s) || \ + __builtin_types_compatible_p(typeof(s), char *) || \ + __builtin_types_compatible_p(typeof(s), const char *)) \ + _tmp = (s) ? (s) : "(null)"; \ + else \ + _tmp = link_error_due_to_bad_NULLSTR_type(); \ + _tmp; \ + }) +# else +# define NULLSTR(s) ((s) ? (s) : "(null)") +# endif /** * TODO: -- 1.7.11.4

2 2

[libvirt] [PATCH 0/4] Support for limiting guest coredumps
by Martin Kletzander 21 Aug '12

21 Aug '12

This series applies on the disable_s3/s4 series [1] and works with qemu patch [2] (not applied yet), so it shouldn't be pushed before the qemu part is. Basically qemu supports marking guest memory as (not)dumpable using madvise(2) system call and in case the guest memory is not desired the option can reduce the coredump by a reasonable size. Martin [1] https://www.redhat.com/archives/libvir-list/2012-August/msg00572.html [2] http://lists.nongnu.org/archive/html/qemu-devel/2012-08/msg00554.html Martin Kletzander (4): Add support for limiting guest coredump qemu: add support for dump-guest-core option tests: Add tests for dump-core option docs: Document dump-core memory feature docs/formatdomain.html.in | 13 ++- docs/schemas/domaincommon.rng | 8 ++ src/conf/domain_conf.c | 19 ++++- src/conf/domain_conf.h | 10 ++ src/libvirt_private.syms | 2 + src/qemu/qemu_capabilities.c | 4 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 89 ++++++++++++++++++-- tests/qemuargv2xmltest.c | 2 + .../qemuxml2argv-machine-core-off.args | 5 + .../qemuxml2argv-machine-core-off.xml | 26 ++++++ .../qemuxml2argv-machine-core-on.args | 5 + .../qemuxml2argv-machine-core-on.xml | 26 ++++++ tests/qemuxml2argvtest.c | 3 + tests/qemuxml2xmltest.c | 2 + 15 files changed, 202 insertions(+), 13 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-machine-core-off.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-machine-core-off.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-machine-core-on.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-machine-core-on.xml -- 1.7.8.6

2 8

[libvirt] [PATCHv2 0/4] Add LibSSH2 transport
by Peter Krempa 21 Aug '12

21 Aug '12

This is a second respin of the LibSSH2 transport patch series. The most notable changes: ------------------------- - Rebased on top of current upstream (virObject, new error codes) - ported to use virObject stuff - re-named all functions and other literals to contain the "2" - implemented suggestions from Eric's review - added symbol file and various other cleanups The easiest way to test the actual implementation is to apply the patchset and try connecting to a remote host using virsh and then trying some API's. The most complex part of the code are the various authentication options that can be selected in the connection URI. Peter Krempa (4): libssh2_transport: add main libssh2 transport implementation libssh2_transport: add ssh context support to virNetSocket libssh2_transport: Add libssh2 session support to net client code libssh2_transport: Use libssh2 driver code in remote driver configure.ac | 40 +- include/libvirt/virterror.h | 2 + po/POTFILES.in | 1 + src/Makefile.am | 16 +- src/libvirt_libssh2.syms | 18 + src/libvirt_private.syms | 2 + src/remote/remote_driver.c | 47 ++- src/rpc/virnetclient.c | 117 ++++ src/rpc/virnetclient.h | 14 +- src/rpc/virnetlibssh2session.c | 1464 ++++++++++++++++++++++++++++++++++++++++ src/rpc/virnetlibssh2session.h | 83 +++ src/rpc/virnetsocket.c | 178 +++++- src/rpc/virnetsocket.h | 13 + src/util/virterror.c | 8 +- 14 files changed, 1993 insertions(+), 10 deletions(-) create mode 100644 src/libvirt_libssh2.syms create mode 100644 src/rpc/virnetlibssh2session.c create mode 100644 src/rpc/virnetlibssh2session.h -- 1.7.8.6

4 15

[libvirt] [PATCH] Fix parsing of uid/gid on Mingw32
by Daniel P. Berrange 21 Aug '12

21 Aug '12

From: "Daniel P. Berrange" <berrange(a)redhat.com> The DAC security driver uses the virStrToLong_ui function to parse the uid/gid out of the seclabel string. This works on Linux where 'uid_t' is an unsigned int, but on Mingw32 it is just an 'int'. This causes compiler warnings about signed/ unsigned int pointer mis-match. To avoid this, use explicit 'unsigned int ouruid' local vars to pass into virStrToLong_ui, and then simply assign to the 'uid_t' type after parsing Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- src/security/security_dac.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/src/security/security_dac.c b/src/security/security_dac.c index e37b09e..925498f 100644 --- a/src/security/security_dac.c +++ b/src/security/security_dac.c @@ -68,25 +68,25 @@ void virSecurityDACSetDynamicOwnership(virSecurityManagerPtr mgr, static int parseIds(const char *label, uid_t *uidPtr, gid_t *gidPtr) { - uid_t uid; - gid_t gid; + unsigned int theuid; + unsigned int thegid; char *endptr = NULL; if (label == NULL) return -1; - if (virStrToLong_ui(label, &endptr, 10, &uid) || + if (virStrToLong_ui(label, &endptr, 10, &theuid) || endptr == NULL || *endptr != ':') { return -1; } - if (virStrToLong_ui(endptr + 1, NULL, 10, &gid)) + if (virStrToLong_ui(endptr + 1, NULL, 10, &thegid)) return -1; if (uidPtr) - *uidPtr = uid; + *uidPtr = theuid; if (gidPtr) - *gidPtr = gid; + *gidPtr = thegid; return 0; } -- 1.7.11.2

2 1

[libvirt] [libguestfs] Options for hotplugging
by Richard W.M. Jones 21 Aug '12

21 Aug '12

libguestfs recently added support for virtio-scsi and libvirt, and when these are both available this lets us relatively easily add hotplugging of drives. This email is about how we would present that through the libguestfs API. (a) The current API Currently you have to add drive(s) via guestfs_add_drive* and then call guestfs_launch, ie. your program must look something like this: guestfs_h *g = guestfs_create (); guestfs_add_drive (g, "/tmp/disk1.img"); guestfs_add_drive (g, "/tmp/disk2.img"); guestfs_launch (g); After guestfs_launch [the qemu backend is running] you are not allowed to add more drives. The API specifies that you refer to drives in other commands in one of two ways. Either you're allowed to use names like "/dev/sda", "/dev/sdb" etc to refer to the first, second etc drive you added, in the same order that you added them. Or you can call guestfs_list_devices which returns a list of device names, opaque strings that you pass to other functions. In the first case (using "/dev/sdX" names), some magic already happens translating these to the real names underneath, but currently that magic is just "/dev/sdX" -> "/dev/vdX" for the virtio case. Note that we cannot change this API or break existing programs. (b) The hidden appliance drive The libguestfs appliance has to have its own root drive. Currently this is added after the user-added drives. For example, if the user adds two drives, then the appliance will appear as /dev/sdc (or /dev/vdc or whatever). Some magic in the bootloader causes the last drive to be used as the root filesystem. This hidden drive doesn't appear in the API -- for example it is suppressed when we generate the result of guestfs_list_devices. (c) /dev/null drives It's always been possible to add "/dev/null" as a drive via guestfs_add_drive*. This is mainly useful for testing, or if you want to access just those parts of the API which don't require a disk image (for various reasons we force you to add one drive, so if you don't have any drive to add, you can use "/dev/null"). Current libguestfs treats "/dev/null" as a magic string and (because of bugs in qemu) substitutes a non-zero sized temporary file. (d) Maximum number of drives With virtio-scsi, this maximum is pretty large -- currently 255 (256 targets less the hidden appliance), but if we used LUNs or even multiple controllers then it'd be almost unlimited. We actually test up to 255, and virt-df will use as many slots as it can. (e) For libguestfs you can assume the latest of everything, qemu, guest kernel, host kernel, libvirt, tools. Any suggestions based on very new features are fine, even proposed features provided there's a working implementation which is likely to go upstream. - - - - Here are some ideas about how we might add hotplugging without breaking existing clients. (1) The "raw libvirt" option In this one we'd simply provide thin wrappers around virDomainAttachDevice and virDomainDetactDevice, and leave it up to the user to know what they're doing. The problem with this is the hidden appliance disk. We certainly don't want the user to accidentally detach that(!) It's also undesirable for there to be a "hole" in the naming scheme so that you'd have: /dev/sda <- your normal drives /dev/sdb <- [/dev/sdc # sorry, you can't use this, we won't tell you why] /dev/sdd <- your first hotplugged device As far as I know, the kernel assigns /dev/sdX names on a first-free basis, so there's no way to permanently put the appliance at /dev/sdzzz (if there is, please let me know!) (2) The "slots" option In this option you'd have to use null devices to reserve the maximum number of drive slots that you're going to use in the libguestfs handle before launch. Then after launching you'd be allowed to hotplug only those slots. So for example: guestfs_add_drive (g, "/dev/null"); # reserves /dev/sda guestfs_add_drive (g, "/dev/null"); # reserves /dev/sdb guestfs_add_drive (g, "/dev/null"); # reserves /dev/sdc guestfs_launch (g); guestfs_hotplug (g, 1, "/tmp/foo"); # replaces index 1 == /dev/sdb guestfs_hotplug (g, 3, "/tmp/foo"); # error! Although ugly, in some ways this is quite attractive. It maps easily into guestfish scripts. You have contiguous device naming. You often know how many drives you'll need in advance, and if you don't then you can reserve up to max_disks-1. (3) The "serial numbers" option This was Dan's suggestion. Hotplugged drives are known only by their serial number. ie. We hotplug them via libvirt using the <serial/> field, and then they are accessed using /dev/disk/by-id/serial. This is tempting, but unfortunately it doesn't quite work in stock udev, because the actual name used is: /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_SERIAL We could add a custom udev rule to get the path we wanted. (4) The "rewriting device names" option Since we already have the infrastructure to rewrite device names, we could do some complicated and hairy device name rewriting to make names appear continguous, even though there's an hidden appliance drive. This is my least favourite option, mainly because of the complexity, and complexity is bound to lead to bugs. (5) Your idea here ... As usual, comments and suggestions welcome. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top

3 4

[libvirt] [PATCH v3 0/4] qemu: configurable port boundaries for remote displays
by Martin Kletzander 21 Aug '12

21 Aug '12

This series introduces a possibility to change default minimal and maximal port numbers that are used to specify a remote display port for both VNC and SPICE. Because the code was a bit messy, PATCH 1/4 cleans up few things needed to make a clean run of PATCH 2/4, that does the main change in the code. I also noticed two things that could be changed and it made sense for me to do that, but these are nowhere near any importance, so feel free to reject them if your heart feels that way. PATCH 3/4 [optional] rewords three messages and applying it would mean that they are not translated. Even though I think it makes more sense this way, I'm not a good English speaker, so that's more like an RFC. PATCH 4/4 [optional] makes more flexible port searching available, but now it is used just on one place and it's not necessary to have it. -- v3: - rebase on current HEAD v2: - apply the change to both VNC and SPICE sessions Martin Kletzander (4): qemu: Unify port-wise SPICE and VNC behavior qemu: configurable remote display port boundaries qemu: modify 3 error messages qemu: allow searching for all open ports src/conf/domain_conf.c | 2 +- src/qemu/libvirtd_qemu.aug | 4 ++ src/qemu/qemu.conf | 14 ++++++ src/qemu/qemu_command.h | 11 ++++- src/qemu/qemu_conf.c | 48 +++++++++++++++++++++- src/qemu/qemu_conf.h | 4 +- src/qemu/qemu_driver.c | 19 ++++----- src/qemu/qemu_process.c | 80 +++++++++++++++++++++-------------- src/qemu/test_libvirtd_qemu.aug.in | 2 + 9 files changed, 136 insertions(+), 48 deletions(-) -- 1.7.8.6

2 12

[libvirt] [PATCH v2 00/17] Supports for emulator-pin and emulator-bandwidth
by Hu Tao 21 Aug '12

21 Aug '12

This series adds support of emulator-pin to pin emulator threads on specified physical CPUs, and emulator-bandwidth to control physical CPU bandwidth for emulator threads. changes: v2: - rename hypervisor to emulator all through the series - no Flags-suffix for new APIs - reduce code duplication - rollback to old vcpupin def if error Hu Tao (9): Introduce the function virCgroupMoveTask add function bitmapFromBytemap() to convert bytemap to bitmap refactor virDomainVcpuPinAdd() updates of some vcpupin related functions Enable cpuset cgroup and synchronous vcpupin info to cgroup. Change virDomainVcpuPinDefParseXML to support parsing emulatorpin qemu: support emulator pinning Add a new function vshPrintPinInfo. new command emulatorpin Tang Chen (6): Support simulatorpin xml parse. qemu: synchronize emulatorpin info to cgroup Add qemuProcessSetEmulatorAffinites and set emulator threads affinities Introduce virDomainPinEmulator and virDomainGetEmulatorPinInfo functions. Introduce virDomainEmulatorPinAdd and virDomainEmulatorPinDel functions remote: introduce emulator pinning RPCs Wen Congyang (2): Introduce the function virCgroupForEmulator create a new cgroup and move all emulator threads to the new cgroup daemon/remote.c | 91 +++++++ docs/formatdomain.html.in | 9 + docs/schemas/domaincommon.rng | 7 + include/libvirt/libvirt.h.in | 10 + src/conf/domain_conf.c | 279 ++++++++++++++----- src/conf/domain_conf.h | 15 +- src/driver.h | 12 + src/libvirt.c | 147 ++++++++++ src/libvirt_private.syms | 9 + src/libvirt_public.syms | 2 + src/libxl/libxl_driver.c | 13 +- src/qemu/qemu_cgroup.c | 131 ++++++++- src/qemu/qemu_cgroup.h | 7 + src/qemu/qemu_driver.c | 325 ++++++++++++++++++++++- src/qemu/qemu_process.c | 60 ++++- src/remote/remote_driver.c | 99 +++++++ src/remote/remote_protocol.x | 21 +- src/remote_protocol-structs | 22 ++ src/util/cgroup.c | 186 ++++++++++++- src/util/cgroup.h | 15 ++ src/xen/xend_internal.c | 13 +- tests/qemuxml2argvdata/qemuxml2argv-cputune.xml | 1 + tools/virsh-domain.c | 253 ++++++++++++++++-- tools/virsh.pod | 16 ++ 24 files changed, 1634 insertions(+), 109 deletions(-) -- 1.7.10.2

1 19

[libvirt] [PATCH 0/5] network: define new API virNetworkDefineXMLFlags
by Laine Stump 21 Aug '12

21 Aug '12

I would like to enhance libvirt's network API to allow enacting any changes in definition immediately, as an alternative to the current behavior of saving the changes right away, but not using them until the next time the network is destroyed and re-started. This could easily be handled by a flag passed to virNetworkDefineXML(). Unfortunately, virNetworkDefineXML() was added to libvirt before we came up with the idea of adding a flags arg to every new API (just for things like this). To remedy this, I've effectively duplicated that API with a new API, virNetworkDefineXMLFlags(), which currently behaves identically, but has an extra "flags" argument. At the end of this patch series, it's still not possible to call virNetworkDefineXMLFlags() with anything other than 0 in flags, butt this gets the API in place, and in use by virsh (although with no extra functionality). A later patchset will add a VIR_NETWORK_DEFINE_AFFECT_LIVE flag and the network driver support behind it. (It almost seems like overkill to split this into so many teeny tiny patches, but this is the currently popular/accepted format for API addition patches.)

3 14

[libvirt] [PATCH 0/4] start cleaning up virsh split
by Eric Blake 21 Aug '12

21 Aug '12

Not complete, but this is what I got done in a couple hours after complaining about Osier's series: https://www.redhat.com/archives/libvir-list/2012-August/msg01247.html There's more work to be done, but this should give an idea at the sort of cleanups made possible when we cleanly split into different .o files. Eric Blake (4): virsh: move vshWatchJob earlier virsh: split out virsh.h virsh: split out virsh-domain.c virsh: kill some double underscores tools/Makefile.am | 15 +- tools/virsh-domain-monitor.c | 2 +- tools/virsh-domain.c | 220 ++++++++++++--------- tools/virsh-domain.h | 33 ++++ tools/virsh.c | 460 ++++++------------------------------------- tools/virsh.h | 384 ++++++++++++++++++++++++++++++++++++ 6 files changed, 622 insertions(+), 492 deletions(-) create mode 100644 tools/virsh-domain.h create mode 100644 tools/virsh.h -- 1.7.11.2

3 40

[libvirt] virsh vol-upload purpose question
by Li, Chun Wen 21 Aug '12

21 Aug '12

I use virsh vol-upload to upload some data in a volume and use vol-download to download these data from the same volume, both these two commands work well. However, when I first use these two commands, I thought I can use vol-upload to upload some file, then attach this volume to a vm, and access the upload file in this vm. I did this experiment, bud it not success. Once I upload a file into a volume, attach it to a vm, then the vm can not recognize the file type of this vm, if I mkfs to the volume, the file I upload disappear. So, my question is the purpose of the vol-upload is just to save some data in the volume outside vm? I think it is more reasonable if we can access upload data from vm. Best Regards Kimi Li

1 0