- Devel - libvirt List Archives

[libvirt] About 'virsh update-device' for floppy and cdrom
by liyang 20 Sep '13

20 Sep '13

Hi experts: When I did some test, I was puzzled by one thing: When I use "virsh update-device" to update floppy device, always got an error message, "error: internal error unable to execute QEMU command 'change': Could not open'***file':Permission denied".But when I execute command "setenforce 0" befroe "udpate-device", floppy device can be updated. Steps like this: ---------------------------------------------------------------Start # virsh start virt-tests-vm1 Domain virt-tests-vm1 started # cat /add_storage/liyang/github-autotest_new/client/tests/virt/tmp/tmp/update_iso.xml <disk type='file' device='floppy'> <driver name='qemu' type='raw'/> <source file='/add_storage/liyang/github-autotest_new/client/tests/virt/tmp/tmp/change_media_old.iso'/> <target dev='fda'/> <readonly/> </disk> # ll /add_storage/liyang/github-autotest_new/client/tests/virt/tmp/tmp/change_media_old.iso -rw-r--r--. 1 qemu qemu 1404928 Sep 20 10:48 /add_storage/liyang/github-autotest_new/client/tests/virt/tmp/tmp/change_media_old.iso # virsh update-device virt-tests-vm1 /add_storage/liyang/github-autotest_new/client/tests/virt/tmp/tmp/update_iso.xml --force error: Failed to update device from /add_storage/liyang/github-autotest_new/client/tests/virt/tmp/tmp/update_iso.xml error: internal error unable to execute QEMU command 'change': Could not open '/add_storage/liyang/github-autotest_new/client/tests/virt/tmp/tmp/change_media_old.iso': Permission denied # cat /selinux/enforce 1 # setenforce 0 # virsh update-device virt-tests-vm1 /add_storage/liyang/github-autotest_new/client/tests/virt/tmp/tmp/update_iso.xml --force Device updated successfully ---------------------------------------------------------------End But with same command, about cdrom device it worked though "/selinux/enforce" is 1. Steps like this: ---------------------------------------------------------------Start # virsh start virt-tests-vm1 Domain virt-tests-vm1 started # cat /add_storage/liyang/github-autotest_new/client/tests/virt/tmp/tmp/update_iso.xml <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/add_storage/liyang/github-autotest_new/client/tests/virt/tmp/tmp/change_media_old.iso'/> <target dev='hdc'/> <readonly/> </disk> # ll /add_storage/liyang/github-autotest_new/client/tests/virt/tmp/tmp/change_media_old.iso -rw-r--r--. 1 qemu qemu 1404928 Sep 20 10:58 /add_storage/liyang/github-autotest_new/client/tests/virt/tmp/tmp/change_media_old.iso # cat /selinux/enforce 1 # virsh update-device virt-tests-vm1 /add_storage/liyang/github-autotest_new/client/tests/virt/tmp/tmp/update_iso.xml --force Device updated successfully ---------------------------------------------------------------End So I want to know why it's different between 'floppy' and 'cdrom', and what's the difference? Also why floppy needs 'permissive' mode but cdrom doesn't? Wish your help! -- Regards, -------------------------------------------------- Li Yang TEL：+86+25-86630566-8529 EMail：liyang.fnst(a)cn.fujitsu.com --------------------------------------------------

1 0

[libvirt] Schedule for next release
by Daniel Veillard 20 Sep '13

20 Sep '13

If we want to stick to the end of the month schedule we need to enter freeze for 1.1.3 next week, I suggest to do this early on Wed 25 so that we can plan on pushing 1.1.3 on the Tue 1st Oct So unless there is a serious issue, let's plan to freeze next Wed, Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/

1 0

[libvirt] [v0.9.12-maint 0/9] CVE fixes
by Eric Blake 20 Sep '13

20 Sep '13

I've completed and pushed my backport work for both CVEs that were patched today, into all branches v0.10.2-maint and newer (basically, we have 0.10.2, then all releases since 1.0.2). One last branch in active use (hello Debian) remains to be patched; but here, the backport work had enough conflict resolutions that I decided to post my work for review first. Daniel P. Berrange (9): Introduce APIs for splitting/joining strings Rename virKillProcess to virProcessKill Rename virPid{Abort, Wait} to virProcess{Abort, Wait} Rename virCommandTranslateStatus to virProcessTranslateStatus Move virProcessKill into virprocess.{h, c} Move virProcess{Kill, Abort, TranslateStatus} into virprocess.{c, h} Include process start time when doing polkit checks Add support for using 3-arg pkcheck syntax for process (CVE-2013-4311) Fix crash in remoteDispatchDomainMemoryStats (CVE-2013-4296) .gitignore | 1 + configure.ac | 8 + daemon/libvirtd.c | 3 +- daemon/remote.c | 33 +++- libvirt.spec.in | 3 +- po/POTFILES.in | 1 + src/Makefile.am | 2 + src/libvirt_private.syms | 16 +- src/lxc/lxc_container.c | 3 +- src/lxc/lxc_controller.c | 3 +- src/qemu/qemu_agent.c | 3 +- src/qemu/qemu_monitor.c | 3 +- src/qemu/qemu_process.c | 3 +- src/rpc/virnetserverclient.c | 8 +- src/rpc/virnetserverclient.h | 3 +- src/rpc/virnetsocket.c | 22 ++- src/rpc/virnetsocket.h | 3 +- src/uml/uml_driver.c | 3 +- src/util/command.c | 167 ++------------------ src/util/command.h | 8 - src/util/util.c | 64 +------- src/util/util.h | 1 - src/util/virprocess.c | 359 +++++++++++++++++++++++++++++++++++++++++++ src/util/virprocess.h | 45 ++++++ src/util/virstring.c | 179 +++++++++++++++++++++ src/util/virstring.h | 40 +++++ tests/Makefile.am | 9 +- tests/testutils.c | 5 +- tests/virstringtest.c | 161 +++++++++++++++++++ 29 files changed, 908 insertions(+), 251 deletions(-) create mode 100644 src/util/virprocess.c create mode 100644 src/util/virprocess.h create mode 100644 src/util/virstring.c create mode 100644 src/util/virstring.h create mode 100644 tests/virstringtest.c -- 1.8.3.1

2 12

[libvirt] [PATCH 0/3] Fix for polkit race condition
by Daniel P. Berrange 19 Sep '13

19 Sep '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> The following 3 patches have been reviewed on the libvirt-security list as the libvirt side of the fix for polkit CVE-2013-4288. Given that it was already reviewed, I have pushed this. Daniel P. Berrange (3): Also store user & group ID values in virIdentity Ensure system identity includes process start time Add support for using 3-arg pkcheck syntax for process (CVE-2013-4311) configure.ac | 8 ++++++++ daemon/remote.c | 22 ++++++++++++++++++--- libvirt.spec.in | 3 +-- src/access/viraccessdriverpolkit.c | 40 +++++++++++++++++++++++++++++++++----- src/rpc/virnetserverclient.c | 18 +++++++++++++++++ src/util/viridentity.c | 39 +++++++++++++++++++++++++++++++++---- src/util/viridentity.h | 2 ++ 7 files changed, 118 insertions(+), 14 deletions(-) -- 1.8.3.1

3 9

[libvirt] memory pinning problem
by David Weber 19 Sep '13

19 Sep '13

Hi, we try to use vcpu pinning on a 2 socket server with Intel Xeon E5620 cpus, HT enabled and 2*6*16GiB Ram but experience problems if we try to start a guest on the second socket: error: Failed to start domain test error: internal error: process exited while connecting to monitor: kvm_init_vcpu failed: Cannot allocate memory Libvirt version 1.1.1 Linux 3.11-rc7 Because I coudn't find any other service which allowed a 7M file upload, I put the log file and everything else which could perhabs be relevant into a github repository: https://github.com/David-Weber/vcpu-pinning When we try to start a guest on the first node it runs fine: <vcpu placement='static' cpuset='0-3,8-11'>4</vcpu> <numatune> <memory mode='strict' nodeset='0'/> </numatune> Starting it on the second node fails <vcpu placement='static' cpuset='4-7,12-15'>4</vcpu> <numatune> <memory mode='strict' nodeset='1'/> </numatune> Even more strange, starting it with the CPUs of the second node and the memory of the first node works: <vcpu placement='static' cpuset='4-7,12-15'>4</vcpu> <numatune> <memory mode='strict' nodeset='0'/> </numatune> The log file contains these three cases. Using the placement='auto' parameter leads to the same problem. If numad return the second node, the guest won't start. Is this a configuration, a libvirt or a cgroup problem? :) Cheers, David

2 7

[libvirt] Auto-assignment of USB devices and auto-creation of USB hubs
by Jamie Bainbridge 19 Sep '13

19 Sep '13

Hello, I've been helping a customer out this week with assigning specific devices to specific USB controllers inside his KVM VMs. He's got USB1 devices which need a UHCI controller (because of rubbishy Windows device drivers) and USB2 devices which need a EHCI controller ("speed mismatch" on a UHCI hub). I've suggested config similar to this: <controller type='usb' index='0' model='ehci'> </controller> <controller type='usb' index='1' model='piix3-uhci'> </controller> <input type='tablet' bus='usb'/> <hub type='usb'> <address type='usb' bus='1' port='2'/> </hub> <hostdev mode='subsystem' type='usb' managed='yes'> <source> <vendor id='0xAAAA'/> <product id='0xAAAA'/> </source> <address type='usb' bus='1' port='2.1'/> </hostdev> <hostdev mode='subsystem' type='usb' managed='yes'> <source> <vendor id='0xBBBB'/> <product id='0xBBBB'/> </source> <address type='usb' bus='1' port='2.2'/> </hostdev> and I explained the concept to him with diagrams like these: UHCI --+-- Tablet (port 1) +-- HUB (port 2) --. +-- Device (port 2.1) +-- Device (port 2.2) UHCI --+-- Tablet (port 1) +-- HUB (port 2) --. +-- HUB (port 2.1) --. | +-- Device (port 2.1.1) | +-- Device (port 2.1.2) | +-- HUB (port 2.2) --. +-- Device (port 2.2.1) (then imagine extending this example out to also include EHCI controller and devices) He's very happy so far and I've just been working it all out through trial and error and reading the libvirt domain specification. My observation is that you can either: a) let libvirt plug everything into the UHCI controller, regardless of what other controllers are there and what order they appear in or b) find out how many ports a controller/hub has through trial and error, manually create USB hubs, and map every single device and port out manually with no middle ground in between. I think it would be way better if users could just assign a USB hostdev to a controller, then let libvirt do all the heavy lifting in regards to hubs and ports. For example, : <controller type='usb' index='0' model='ehci'> </controller> <controller type='usb' index='1' model='piix3-uhci'> </controller> <hostdev mode='subsystem' type='usb' managed='yes'> <source> <vendor id='0x0529'/> <product id='0x0001'/> </source> <address type='usb' bus='1'/> </hostdev> <hostdev mode='subsystem' type='usb' managed='yes'> <source> <vendor id='0x3923'/> <product id='0x709b'/> </source> <address type='usb' bus='1'/> </hostdev> I can see it's already been discussed that we couldn't just implement "port=auto" because we need migration stability: http://www.redhat.com/archives/libvir-list/2011-August/msg00816.html but much like how you add: <controller type='usb' index='0' model='ehci'> </controller> then save the XML, and go "virsh edit" and the controller automagically has a PCI address assigned, we could enter this into the XML: <hostdev mode='subsystem' type='usb' managed='yes'> <source> whatever </source> <address type='usb' bus='1'/> </hostdev> then save the XML, and "virsh edit" again, and all the port/hub stuff would already be there pre-made as required. Any thoughts? Is this worth logging an RFE for? Cheers, Jamie

3 2

Re: [libvirt] [virt-tools-list] [Spice-devel] More on virt-viewer for windows
by Eric Blake 19 Sep '13

19 Sep '13

[adding libvir-list, for some cross-compiling development hints] On 09/17/2013 11:57 AM, Fernando Lozano wrote: > Yes, the libvirt comes grom 0.10.2. I'm running the latest windows > binaries provided by spice-space.org: > > C:\Program Files\VirtViewer\bin>virsh -V > Virsh command line tool of libvirt 0.10.2 Can someone from the Spice community chime in? Why is spice-space.org shipping a Fedora 18 build of libvirt (0.10.2.x) rather than Fedora 19 (1.0.5.x)? Who does the builds, and how often are they updated? >> Process Monitor is only useful if you make system calls; but libvirt is >> choking even before attempting the system calls because mingw is just >> such a hostile programming environment to programs that assume POSIX. > > That's precisely mingw advantage over cigwin: mingw binaries are native > windows binaries, using native windows semantics, not unix emulation. > They provide a better experience for windows users. Welcome to the > wonderful world of cross-platform developent! ;-) Actually, on my personal to-do list is to get a build of virsh working and available from cygwin.com, rather than requiring people to self-build it for cygwin. And since cygwin supports cross-compilation to mingw, just as Fedora does, but with the added advantage of also being able to run mingw binaries without having to worry about bugs in the wine emulation layer, it's actually a bit nicer for getting the best of both worlds when doing cross-compiling (posix development, native testing). If I can ever find the free time... > > >> Gnulib has helped a lot, and often times, it is just a matter of someone >> running under gdb to see where an assumption went wrong to make a quick >> patch to fix an issue. Where it gets tricky is that it is hard to find >> developers willing to do volunteer work on issues for a platform where >> you typically have to pay money before you can even use it. Also, the >> fact that you are using a pre-built version of a relatively old libvirt, >> instead of building your own from the latest sources, makes it hard to >> know what OTHER issues may have been fixed in the meantime (when given a >> choice, developers prefer to debug issues in the latest source, rather >> than trying to figure out which patches to backport to older branches). > I understand that, but I'm trying to be useful as a (windows) tester. If > I could I'd try to help as a developer. cross-compiling is not for the > faint of heart, and learning the first steps require a significant > investment in time. :-( > > Is there a how-to I can follow to generate binaries from the latest > sources? I do have Linux expertize, I use fedora on my personal > computer, but as C developer I can only run "configure; make; sudo make > install". All I've done so far is test cross-compilation from Fedora to mingw (I haven't tested the resulting binaries, only that the build completes without error). I suppose I could try to host the just-built binaries on a site for you to download; let me see what I can figure out. Meanwhile, I used './autobuild.sh' as my guide; which means I more or less did: $ sudo yum install \ mingw64-binutils \ mingw64-cpp \ mingw64-crt \ mingw64-curl \ mingw64-dbus \ mingw64-filesystem \ mingw64-gcc \ mingw64-gcc-c++ \ mingw64-gettext \ mingw64-gmp \ mingw64-gnutls \ mingw64-headers \ mingw64-libgcrypt \ mingw64-libgpg-error \ mingw64-libidn \ mingw64-libssh2 \ mingw64-libtasn1 \ mingw64-libxml2 \ mingw64-nettle \ mingw64-openssl \ mingw64-p11-kit \ mingw64-pkg-config \ mingw64-portablexdr \ mingw64-termcap \ mingw64-wine-gecko \ mingw64-win-iconv \ mingw64-zlib $ git clone git://libvirt.org/libvirt.git $ cd libvirt $ ./autogen.sh --help # see note [1] $ mkdir build-mingw $ cd build-mingw $ ../configure \ PKG_CONFIG_LIBDIR="/usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig:/usr/x86_64-w64-mingw32/sys-root/mingw/share/pkgconfig" \ PKG_CONFIG_PATH="$AUTOBUILD_INSTALL_ROOT/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig" \ CC="x86_64-w64-mingw32-gcc" \ --build=$(uname -m)-w64-linux \ --host=x86_64-w64-mingw32 \ --prefix="$AUTOBUILD_INSTALL_ROOT/x86_64-w64-mingw32/sys-root/mingw" \ --without-libvirtd \ --without-python $ make [1] Yeah, we probably ought to have a more convenient way to bootstrap libvirt.git for VPATH builds without having to rely on the hack that options unrecognized by ./autogen.sh are passed on to ./configure, and that ./configure --help is the easiest way to do avoid polluting the top-level tree in a way that would interfere with VPATH builds. I use a VPATH build for my mingw cross-compilation in part so I can test both 32-bit and 64-bit binaries in parallel directories. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

6 8

[libvirt] [v0.9.12-maint 0/5] building 0.9.12 on newer systems
by Eric Blake 19 Sep '13

19 Sep '13

I'm pushing these backports under the build-breaker rule; they were all necessary for me to complete 'make check' on this old branch from within Fedora 19. It will set the stage for the CVE patches in another series. Daniel P. Berrange (1): Fix TLS tests with gnutls 3 Eric Blake (3): build: allow building with newer glibc-headers and -O0 build: more workarounds for if_bridge.h build: avoid confusing make with raw name 'undefine' Jiri Denemark (1): virsh: Fix POD syntax configure.ac | 20 +++++++++++++++++--- m4/virt-compile-warnings.m4 | 8 ++++++-- src/util/virnetdevbridge.c | 18 ++++++++++++++++++ tests/Makefile.am | 10 ++++++---- tests/virnettlscontexttest.c | 25 +++++++++++++++---------- tests/{undefine => virsh-undefine} | 0 tools/virsh.pod | 4 ++-- 7 files changed, 64 insertions(+), 21 deletions(-) rename tests/{undefine => virsh-undefine} (100%) -- 1.8.3.1

1 5

[libvirt] Remove more hardcoded paths from libvirtd --help
by Christophe Fergeau 19 Sep '13

19 Sep '13

In my previous 2 patches, I used constants defined in remote_driver.h to build privileged libvirtd --help output. However, there are a few more constants in this header that we can use to build the --help output, this series addresses that. Christophe

2 4

[libvirt] [PATCH] docs: fix virEventAddHandle return details
by Jonathan Lebon 19 Sep '13

19 Sep '13

In commit 6d41cb8, the interface for virEventAddHandleFunc was changed. This patch updates the documentation for virEventAddHandle to reflect the new significance of the return value. Also, both functions now mention -1 for failure. --- include/libvirt/libvirt.h.in | 4 ++-- src/util/virevent.c | 3 ++- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in index a47e33c..7944dfb 100644 --- a/include/libvirt/libvirt.h.in +++ b/include/libvirt/libvirt.h.in @@ -3643,8 +3643,8 @@ typedef void (*virEventHandleCallback)(int watch, int fd, int events, void *opaq * If 'ff' callbacks are invoked directly from the virEventRemoveHandleFunc * they will likely deadlock in libvirt. * - * Returns a handle watch number to be used for updating - * and unregistering for events + * Returns -1 if the file handle cannot be registered, otherwise a handle + * watch number to be used for updating and unregistering for events */ typedef int (*virEventAddHandleFunc)(int fd, int event, virEventHandleCallback cb, diff --git a/src/util/virevent.c b/src/util/virevent.c index 886cb6d..fde29a2 100644 --- a/src/util/virevent.c +++ b/src/util/virevent.c @@ -48,7 +48,8 @@ static virEventRemoveTimeoutFunc removeTimeoutImpl = NULL; * * Register a callback for monitoring file handle events. * - * Returns -1 if the file handle cannot be registered, 0 upon success + * Returns -1 if the file handle cannot be registered, otherwise a handle + * watch number to be used for updating and unregistering for events */ int virEventAddHandle(int fd, -- 1.8.3.1

2 1