- Devel - libvirt List Archives

[libvirt] [PATCH v2] Disk- and Controller Hotplug
by wolfgang.mauerer＠siemens.com 30 Nov '09

30 Nov '09

Hi, this is the second revision of a patch series to improve disk hotadd support for libvirt. It focuses on the qemu backend, but is naturally designed to be compatible with other backends as well. The objective is two-fold: 1.) Split off controller from disk handling. This is done by introducing a new domain element <controller> that is used to describe disk controllers. Support for hotplugging such controllers is added. Support to reference controllers by name is also included. 2.) <disk>s can now be associated with a specific controller; this is done by means of a <controller> subelemnt for disks. This patch addresses the questions that were raised during the review of the initial submission, massages the code by fixing some whitespace issues, gets static controller configurations to work, and adds documentation. Notice that in contrast to the first submission I did not include the patch that adds support for disk- and controller hot_remove_. Since the qemu codebase is still in bit of a flux wrt. the necessary patches required for this functionality, it will reappear some time later as a separate submission. Best, Wolfgang daemon/libvirtd.c | 2 +- docs/formatdomain.html.in | 38 +++++ docs/schemas/domain.rng | 158 ++++++++++++++++----- src/conf/domain_conf.c | 314 +++++++++++++++++++++++++++++++++++++++++- src/conf/domain_conf.h | 62 ++++++++- src/libvirt_private.syms | 7 +- src/qemu/qemu_driver.c | 184 +++++++++++++++++++++++-- src/qemu/qemu_monitor_text.c | 197 ++++++++++++++++++++++++++ src/qemu/qemu_monitor_text.h | 7 + 9 files changed, 910 insertions(+), 59 deletions(-) -- Siemens AG, CT T DE Corporate Competence Centre Embedded Linux

3 20

[libvirt] questions on build qemu driver with non-root
by Shi Jin 30 Nov '09

30 Nov '09

Hi there, I have been successful in building the latest libvirt code from the git repository. The options I used to build is ./autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var --without-xen --with-qemu --with-qemu-user=oneadmin --with-qemu-group=oneadmin --without-uml --without-vbox --without-openvz --without-lxc Please note that I have specified qemu user and group to be non-root. So far the libvirtd service and virsh both seem to work fine but I have a few issues 1. Before running "virsh create", the image belongs to user oneadmin. During the run, it still does. But the as soon as I shutdown/destroy the instance, the image ownership changes to -rw-rw—— 1 root root I don't understand why. Is this a bug? 2. From the documentation at http://libvirt.org/drvqemu.html, the directories /var/run/libvirt/qemu/, /var/lib/libvirt/qemu/ and /var/cache/libvirt/qemu/ must all have their ownership set to oneadmin:oneadmin. However, mine are still set to root:root and it does not seem to affect the running of libvirt/qemu/kvm. For example, oneadmin@test2:~$ ls /var/run/libvirt/qemu -la total 8 drwxr-xr-x 2 root root 80 2009-11-27 13:22 . drwxr-xr-x 3 root root 100 2009-11-27 13:07 .. -rw------- 1 root root 4 2009-11-27 13:22 client.pid -rw------- 1 root root 1250 2009-11-27 13:22 client.xml 3. The libvirtd service still shows the warning message: warning : qemudStartup:904 : Unable to create cgroup for driver: No such device or address I read from earlier posts that the --without-lxc option should get rid of this message. Thank you for your help. -- Shi Jin, PhD

3 2

[libvirt] About node device enumeration problem
by ajia 30 Nov '09

30 Nov '09

Hi all, I saw two sets of node device enumeration implementation in libvirt-0.7.4 source code: 1.libudev implementation 2.HAL-based implementation I want to know which kind is used in libvirt.if both are used, which kinds solution is better? in my opinion,their abstract layer is different,HAL-based implementation may be flexible, by contrast, libudev implementation may be with better performance.whether plan to merge them or reserve a kind of implementation? thank you very much.I would be most grateful for any response . Best Regards, Alex Jia

3 2

[libvirt] attach-disk to freebsd based guest
by Sebastian Greatful 30 Nov '09

30 Nov '09

I can easily attach a disk using the following command in virsh to a linux guest: attach-disk mydomain /dev/vg0/somethnig vdb Hwoever when I try the same to a freebsd based guest it doesnt show up under /dev. I hvae tried to substitude vdb with vda1 and all sorts of other things to no avail. How can I attache a disk to my freebsd guest? best regards, Seb

3 2

[libvirt] [PATCH] add another SENTINEL attribute
by Paolo Bonzini 30 Nov '09

30 Nov '09

xend_op also can benefit from the attribute. * src/xen/xend_internal.c (xend_op): Add ATTRIBUTE_SENTINEL. --- src/xen/xend_internal.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/xen/xend_internal.c b/src/xen/xend_internal.c index 4d9dcd1..66d2e7f 100644 --- a/src/xen/xend_internal.c +++ b/src/xen/xend_internal.c @@ -552,7 +552,7 @@ xend_op_ext(virConnectPtr xend, const char *path, char *error, * * Returns 0 in case of success, -1 in case of failure. */ -static int +static int ATTRIBUTE_SENTINEL xend_op(virConnectPtr xend, const char *name, const char *key, ...) { char buffer[1024]; -- 1.6.5.2

2 1

[libvirt] [PATCH] avoid chowning domain devices if higer-level mgmt does it for us
by Dan Kenigsberg 30 Nov '09

30 Nov '09

this is particularily important if said device is a file sitting on a root_squashing nfs export. --- src/qemu/qemu.conf | 4 ++++ src/qemu/qemu_conf.c | 3 +++ src/qemu/qemu_conf.h | 1 + src/qemu/qemu_driver.c | 2 +- 4 files changed, 9 insertions(+), 1 deletions(-) diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf index bca858a..892a50b 100644 --- a/src/qemu/qemu.conf +++ b/src/qemu/qemu.conf @@ -96,6 +96,10 @@ # The group ID for QEMU processes run by the system instance #group = "root" +# should libvirt assume that devices are accessible to the above user:group. +# by default, libvirt tries to chown devices before starting up a domain and +# restore ownership to root when domain comes down. +#assume_devices_accessible = 0 # What cgroup controllers to make use of with QEMU guests # diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c index b1b9e5f..520a395 100644 --- a/src/qemu/qemu_conf.c +++ b/src/qemu/qemu_conf.c @@ -232,6 +232,9 @@ int qemudLoadDriverConfig(struct qemud_driver *driver, return -1; } + p = virConfGetValue (conf, "assume_devices_accessible"); + CHECK_TYPE ("assume_devices_accessible", VIR_CONF_LONG); + if (p) driver->avoid_dev_chown = p->l; if (virGetGroupID(NULL, group, &driver->group) < 0) { VIR_FREE(group); diff --git a/src/qemu/qemu_conf.h b/src/qemu/qemu_conf.h index 675c636..3a9da73 100644 --- a/src/qemu/qemu_conf.h +++ b/src/qemu/qemu_conf.h @@ -87,6 +87,7 @@ struct qemud_driver { uid_t user; gid_t group; + int avoid_dev_chown; unsigned int qemuVersion; int nextvmid; diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 2f273eb..4c5de80 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -1968,7 +1968,7 @@ static int qemuDomainSetDeviceOwnership(virConnectPtr conn, uid_t uid; gid_t gid; - if (!driver->privileged) + if (!driver->privileged || driver->avoid_dev_chown) return 0; /* short circuit case of root:root */ -- 1.6.5.2

4 7

[libvirt] strange problem only if /usr/sbin/libvirtd is named
by Shi Jin 29 Nov '09

29 Nov '09

Hi there, I am having a very strange problem. I have built a git libvirt for our servers running ubuntu 9.10. The same built works on all servers but one, which gives error information: 21:08:58.827: error : qemudStartup:926 : unable to set ownership of '/var/lib/libvirt/qemu' to user 400:400: Operation not permitted 21:08:58.827: error : qemudStartup:932 : unable to set ownership of '/var/cache/libvirt/qemu' to 400:400: This is because I used the --with-qemu-user and --with-qemu-group options in building libvirt. After hours of debugging, I figured out the problem: as long as the service binary is not named /usr/sbin/libvirtd, I don't have the above errors. For example, I can rename the binary as /usr/sbin/libvirtd.1 or copy it to anywhere else and it works. I am wondering if there is anything so special about this /usr/sbin/libvirtd file name. Also, it is so strange that it works for all other almost identical servers but this particular one. I appreciate your help. -- Shi Jin, PhD

1 0

[libvirt] saving domains causes stucks all other commands
by Nikola Ciprich 28 Nov '09

28 Nov '09

Hi, I noticed that using libvirt to save running KVM domain (ie using virsh save ...) causes all other attempts to connect to libvirt and do something to hang till the save finishes. Seems like the issue has been already reported once: http://www.mail-archive.com/libvir-list@redhat.com/msg11431.html but without any resoulution. I've tried libvirt-0.7.4 + also applied bb8d57c68a5d9601058692813c7bdaf83c3d3aff (Fix threading problems in python bindings) which seemed to me might be related but still the problem persists. here's the debug log of trying to list domains while saving some domain: [root@vbox3 ~]# virsh list 16:30:31.718: debug : virInitialize:278 : register drivers 16:30:31.718: debug : virRegisterDriver:779 : registering Test as driver 0 16:30:31.718: debug : virRegisterNetworkDriver:617 : registering Test as network driver 0 16:30:31.718: debug : virRegisterInterfaceDriver:648 : registering Test as interface driver 0 16:30:31.718: debug : virRegisterStorageDriver:679 : registering Test as storage driver 0 16:30:31.718: debug : virRegisterDeviceMonitor:710 : registering Test as device driver 0 16:30:31.718: debug : virRegisterSecretDriver:741 : registering Test as secret driver 0 16:30:31.718: debug : vboxRegister:101 : VBoxCGlueInit failed, using dummy driver 16:30:31.718: debug : virRegisterDriver:779 : registering VBOX as driver 1 16:30:31.718: debug : virRegisterNetworkDriver:617 : registering VBOX as network driver 1 16:30:31.718: debug : virRegisterStorageDriver:679 : registering VBOX as storage driver 1 16:30:31.718: debug : virRegisterDriver:779 : registering remote as driver 2 16:30:31.718: debug : virRegisterNetworkDriver:617 : registering remote as network driver 2 16:30:31.718: debug : virRegisterInterfaceDriver:648 : registering remote as interface driver 1 16:30:31.718: debug : virRegisterStorageDriver:679 : registering remote as storage driver 2 16:30:31.718: debug : virRegisterDeviceMonitor:710 : registering remote as device driver 1 16:30:31.718: debug : virRegisterSecretDriver:741 : registering remote as secret driver 1 16:30:31.718: debug : virConnectOpenAuth:1279 : name=(null), auth=0x7f89bc41b8a0, flags=0 16:30:31.718: debug : do_open:1050 : no name, allowing driver auto-select 16:30:31.718: debug : do_open:1058 : trying driver 0 (Test) ... 16:30:31.718: debug : do_open:1064 : driver 0 Test returned DECLINED 16:30:31.718: debug : do_open:1058 : trying driver 1 (VBOX) ... 16:30:31.718: debug : do_open:1064 : driver 1 VBOX returned DECLINED 16:30:31.718: debug : do_open:1058 : trying driver 2 (remote) ... 16:30:31.718: debug : remoteOpen:1064 : Auto-probe remote URI 16:30:31.718: debug : doRemoteOpen:564 : proceeding with name = 16:30:31.719: debug : remoteIO:8359 : Do proc=66 serial=0 length=28 wait=(nil) 16:30:31.719: debug : remoteIO:8421 : We have the buck 66 0x7f89bc5b5010 0x7f89bc5b5010 16:30:31.720: debug : remoteIODecodeMessageLength:7843 : Got length, now need 64 total (60 more) 16:30:31.720: debug : remoteIOEventLoop:8285 : Giving up the buck 66 0x7f89bc5b5010 (nil) 16:30:31.720: debug : remoteIO:8452 : All done with our call 66 (nil) 0x7f89bc5b5010 16:30:31.720: debug : remoteIO:8359 : Do proc=1 serial=1 length=40 wait=(nil) 16:30:31.720: debug : remoteIO:8421 : We have the buck 1 0x256ce90 0x256ce90 16:30:31.721: debug : remoteIODecodeMessageLength:7843 : Got length, now need 56 total (52 more) 16:30:31.722: debug : remoteIOEventLoop:8285 : Giving up the buck 1 0x256ce90 (nil) 16:30:31.722: debug : remoteIO:8452 : All done with our call 1 (nil) 0x256ce90 16:30:31.722: debug : remoteIO:8359 : Do proc=110 serial=2 length=28 wait=(nil) 16:30:31.722: debug : remoteIO:8421 : We have the buck 110 0x256ce90 0x256ce90 16:30:31.723: debug : remoteIODecodeMessageLength:7843 : Got length, now need 76 total (72 more) 16:30:31.723: debug : remoteIOEventLoop:8285 : Giving up the buck 110 0x256ce90 (nil) 16:30:31.723: debug : remoteIO:8452 : All done with our call 110 (nil) 0x256ce90 16:30:31.723: debug : doRemoteOpen:872 : Auto-probed URI is qemu:///system 16:30:31.723: debug : doRemoteOpen:891 : Adding Handler for remote events 16:30:31.723: debug : doRemoteOpen:898 : virEventAddHandle failed: No addHandleImpl defined. continuing without events. 16:30:31.723: debug : do_open:1064 : driver 2 remote returned SUCCESS 16:30:31.723: debug : do_open:1084 : network driver 0 Test returned DECLINED 16:30:31.723: debug : do_open:1084 : network driver 1 VBOX returned DECLINED 16:30:31.723: debug : do_open:1084 : network driver 2 remote returned SUCCESS 16:30:31.723: debug : do_open:1103 : interface driver 0 Test returned DECLINED 16:30:31.723: debug : do_open:1103 : interface driver 1 remote returned SUCCESS 16:30:31.723: debug : do_open:1123 : storage driver 0 Test returned DECLINED 16:30:31.723: debug : do_open:1123 : storage driver 1 VBOX returned DECLINED 16:30:31.723: debug : do_open:1123 : storage driver 2 remote returned SUCCESS 16:30:31.723: debug : do_open:1143 : node driver 0 Test returned DECLINED 16:30:31.723: debug : do_open:1143 : node driver 1 remote returned SUCCESS 16:30:31.723: debug : do_open:1170 : secret driver 0 Test returned DECLINED 16:30:31.723: debug : do_open:1170 : secret driver 1 remote returned SUCCESS 16:30:31.723: debug : virConnectNumOfDomains:1656 : conn=0x2569c30 16:30:31.723: debug : remoteIO:8359 : Do proc=51 serial=3 length=28 wait=(nil) 16:30:31.723: debug : remoteIO:8421 : We have the buck 51 0x256ced0 0x256ced0 .. (here's the long wait till save finishes).. 16:31:11.077: debug : remoteIODecodeMessageLength:7843 : Got length, now need 60 total (56 more) 16:31:11.077: debug : remoteIOEventLoop:8285 : Giving up the buck 51 0x256ced0 (nil) 16:31:11.077: debug : remoteIO:8452 : All done with our call 51 (nil) 0x256ced0 Id Name State ---------------------------------- 16:31:11.077: debug : virConnectClose:1297 : conn=0x2569c30 16:31:11.077: debug : virUnrefConnect:259 : unref connection 0x2569c30 1 16:31:11.077: debug : remoteIO:8359 : Do proc=2 serial=4 length=28 wait=(nil) 16:31:11.077: debug : remoteIO:8421 : We have the buck 2 0x256d0e0 0x256d0e0 16:31:11.079: debug : remoteIODecodeMessageLength:7843 : Got length, now need 56 total (52 more) 16:31:11.079: debug : remoteIOEventLoop:8285 : Giving up the buck 2 0x256d0e0 (nil) 16:31:11.079: debug : remoteIO:8452 : All done with our call 2 (nil) 0x256d0e0 16:31:11.079: debug : virReleaseConnect:216 : release connection 0x2569c30 Could somebody please have a look on this issue? I'll gladly provide any help if I'll be able. thanks a lot in advance! with best regards nik -- ------------------------------------- Nikola CIPRICH LinuxBox.cz, s.r.o. 28. rijna 168, 709 01 Ostrava tel.: +420 596 603 142 fax: +420 596 621 273 mobil: +420 777 093 799 www.linuxbox.cz mobil servis: +420 737 238 656 email servis: servis(a)linuxbox.cz -------------------------------------

1 0

[libvirt] Howto store schedinfo in the domain definition
by Ralf Nyren 27 Nov '09

27 Nov '09

Hi, Is there support for storing the values accessible with eg virsh schedinfo <domain> --set param=value in the domain definition xml file? Tried to find the syntax definition for this but didn't find anything. Many thanks, Ralf

2 1

[libvirt] Problem in handling fast prints from QEMU to stderr
by Saul Tamari 26 Nov '09

26 Nov '09

Hi, I think I spotted a bug in the way libvirtd handles stderr output from QEMU VMs. When starting a VM and QEMU outputs too much output data to stderr (during a given time period), libvirtd will fail and report the following error to /var/log/messages: libvirtd: 13:44:40.695: error : internal error Out of space while reading console log output I looked at the libvirt code a bit and it seems like the stderr-handling code (I think its in qemudReadLogOutput()) is time-dependent and if a 4K buffer overflows it will stop running this VM. As a workaround I added some usleep(250000) near the fprintf() calls (inside QEMU) and I now manage to get the VM running. Is this the way libvirtd is supposed to behave? Thanks, Saul p.s. This was tested on FC11 and libvirtd is version 0.6.2

3 4