- Devel - libvirt List Archives

[libvirt] Re: virDomainCreate() response time
by Christopher Pyper 03 Dec '09

03 Dec '09

I am using xen with libvirt and I have very slow response times with calls to virDomainCreate(). It takes approximately 5-6 seconds to return. Other calls like virDomainReboot() or virtDomainShutdown() return immediately. Do you know what might be causing this, and how I might speed this up. Cheers.

2 1

[libvirt] Eventtest unit test failure
by Soren Hansen 01 Dec '09

01 Dec '09

Hi, guys. I've changed the libvirt package in Ubuntu to run the test suite with every build. However, on our build daemons, the eventtest unit test seems to almost[1] consistently fail. You can see an example build log here: http://launchpadlibrarian.net/36196282/buildlog_ubuntu-lucid-amd64.libvirt_… Does this look familiar to anyone? Any idea what might be causing this? FWIW, I cannot reproduce it locally, so it's likely environmental, but at this point, I don't really know where to begin to look. [1]: It actually succeeds on sparc and armel :-/ -- Soren Hansen | Lead virtualisation engineer | Ubuntu Server Team Canonical Ltd. | http://www.ubuntu.com/

2 3

[libvirt] how do I stop libvirt futzing with my network configuration?
by Nix 01 Dec '09

01 Dec '09

So I have an existing QEMU/KVM setup with networks connected to a bridge which is routed/forwarded to the host's other interfaces. I'm trying to switch to administering at least *some* of its VMs through libvirt (probably not all as I use QEMU snapshots extensively for some of them and libvirt doesn't support that yet, if ever). So libvirt has to be able to start guests connected to a particular host bridge, and give them appropriate IP addresses. I thought it was easy to teach libvirt about this: spindle:/etc/libvirt/qemu/networks# cat /etc/libvirt/qemu/networks/default.xml <network> <name>default</name> <uuid>ee573497-1d74-473b-a2cb-9916229209b8</uuid> <forward mode='route'/> <bridge name='vm-net' stp='on' delay='0' /> <ip address='192.168.20.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.20.1' end='192.168.20.254' /> </dhcp> </ip> </network> However, there appears to be no way to say 'this is what the network is already like'. That network is considered 'inactive' and can't be used by any guests, and if I try to make it active, I get this: virsh # net-start default error: Failed to start network default error: cannot create bridge 'vm-net': File exists Of course it bloody can't create that bridge: it's already there, has an IP address on the host, and has the host routing packets to it. There appears to be no option to allow libvirt to assign IPs on the host... ... should I fix that, 'net-start' tries to update iptables rules! How should I put this: I do not *not not* want libvirt pissing with the firewall in any way at all. If I want firewall rules, I'll create them. But there's no way to tell it 'hands off! This network is already active, don't try to *make* it active!' ... at least, there's none in the documentation, and there's none in the code that I can see. Or is there?

3 11

Re: [libvirt] how do I stop libvirt futzing with my network configuration?
by Ian Woodstock 01 Dec '09

01 Dec '09

----- "Nix" <nix(a)esperi.org.uk> wrote: > From: "Nix" <nix(a)esperi.org.uk> > To: "Daniel P. Berrange" <berrange(a)redhat.com> > Cc: libvir-list(a)redhat.com > Sent: Saturday, November 28, 2009 4:10:28 PM GMT -05:00 US/Canada Eastern > Subject: Re: [libvirt] how do I stop libvirt futzing with my network configuration? > > On 26 Nov 2009, Daniel P. Berrange spake thusly: > > > On Thu, Nov 26, 2009 at 06:25:07PM +0000, Nix wrote: > >> However, there appears to be no way to say 'this is what the network is > >> already like'. That network is considered 'inactive' and can't be used by > >> any guests, and if I try to make it active, I get this: > >> > >> virsh # net-start default > >> error: Failed to start network default > >> error: cannot create bridge 'vm-net': File exists > >> > >> Of course it bloody can't create that bridge: it's already there, has an > >> IP address on the host, and has the host routing packets to it. There > >> appears to be no option to allow libvirt to assign IPs on the host... > >> > >> ... should I fix that, 'net-start' tries to update iptables rules! > >> How should I put this: I do not *not not* want libvirt pissing with the > >> firewall in any way at all. If I want firewall rules, I'll create them. > >> But there's no way to tell it 'hands off! This network is already active, > >> don't try to *make* it active!' > > > > If you don't want libvirt to create the bridge + setup IPtables rules > > then don't use the net-XXX commands / XML. That functionality is > > not there for pointing libvirt to existing bridge devices. > > > > If you already have a bridge configured, then just point the guest > > directly at that bridge by name. > > OK, I still can't make this work: it worked briefly but then stopped. > As far as I can tell tools like virt-manager are unwilling to *let* you > connect to a network considered 'inactive', and networks are only > considered active if they have a configuration file under > /var/run/libvirt/network. These files are only created if libvirt has > created the bridge itself as well. If no networks are considerd active, > virt-manager won't let you create a guest at all: it insists on trying > to start the sodding network, and when that fails doesn't let you get > any further. > I've been running with this configuration for many months on dozens of hosts. - Created a bridge (the old fashion way) in /etc/sysconfig/network-scripts Bridge called br0 with one device eth1. - Created a VM in virt manager (or edit existing) Picked "Shared Physical Device" Device "eth1 (Bridge br0)" in the GUI. Or just add it to the VMs XML <interface type='bridge'> <mac address='52:54:00:4f:0a:76'/> <source bridge='br0'/> </interface> Works like a charm and there's certainly no configuration in libvirt for this interface, ie. nothing in /var/run/libvirt/network, and *nothing* set up in Virt Manager under "Host Details->Virtual networks You do need to make sure that you disable netfilter on the bridge or setup the appropriate iptables rules ( see http://wiki.libvirt.org/page/Networking#Bridged_networking_.28aka_.22shared…) > So as far as I can tell, if you don't want libvirt creating all your > bridges for you, you may as well give up hope of using virt-manager, or > start hacking all this stuff out of the source. > > I hoped I could use libvirt in conjunction with raw qemu. So much for > that, it seems :( it *really* wants to take over the world... > > > (aside: ideally I should not have to spend half an hour crawling around > the source to figure this out. The only other program I've ever seen > that was this hard to set up was Oracle! Whole *Linux distros* take less > work than this. I have half a dozen patches I'll send your way, but I > wasn't going to send any of them until I'd actually managed to get a VM > working. I got one up last night, somehow -- I no longer have any idea > how, obviously one network had somehow got marked active -- whereupon > KVM fell over. *sigh*) > > -- > Libvir-list mailing list > Libvir-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list >

3 6

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

01 Dec '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