November 2009 - Devel - libvirt List Archives

[libvirt] [PATCH 0/3] fix migration of paused vms
by Paolo Bonzini 09 Dec '09

09 Dec '09

From: Paolo Bonzini <pbonzini(a)gnu.org> This is yet another try on fixing migration of paused vms. Since the driver-only solution didn't work out, I'm now fixing it directly in libvirt.c. The first two patches are the same as for the previous series. The first is a bugfix for failed migration for the QEMU driver; the second adds a "virsh migrate --suspend" option to leave the VM not running on the destination machine. As in the previous version of the patch, --suspend/VIR_MIGRATE_PAUSED is the bulk of implementing the new feature. I just query the domain state and, if it is paused, I implicitly add the VIR_MIGRATE_PAUSED flag to the migration. This is the third patch. I thought about transmitting the state in the end (since it works well if VIR_MIGRATE_PAUSED is passed only to MigrateFinish and not to MigratePerform), but I don't think it's a good idea to commit it now as it's basically untestable. It's in the fourth patch, but if you want it now and think the approach is sound, tell me and I'll test it more heavily.

2 10

[libvirt] [PATCH 00/14] Introduce support for the JSON based QEMU monitor
by Daniel P. Berrange 08 Dec '09

08 Dec '09

This is an updated series fully implementing the new QEMU monitor protocol based on JSON instead of plain text. I previously posted a proof of concept here http://www.redhat.com/archives/libvir-list/2009-November/msg00098.html Since that time, the QEMU side is actually working, so I've been able todo a real impl for libvirt now & also test it. I threw out the JSON library code I used last time, since it turned out to be quite unreliable code. Instead I'm using YAJL which is a much nicer library & integrates with libvirt very nicely. Daniel

6 56

[libvirt] [PATCH 0/2] Xen: Add support for interface model='netfront'
by Jiri Denemark 05 Dec '09

05 Dec '09

Xen HVM guests with PV drivers end up with two network interfaces for each configured interface. One of them being emulated by qemu and the other one paravirtual. As this might not be desirable, the attached patch provides a way for users to specify that only paravirtual network interface should be presented to the guest. The configuration was inspired by qemu/kvm driver, for which users can specify model='virtio' to use paravirtual network interface. The patch adds support for model='netfront' which results in type=netfront instead of type=ioemu (or nothing for newer xen versions) in guests native configuration. Xen's qemu ignores interfaces with type != ioemu and only paravirtual network device will be seen in the guest. Four possible configuration scenarios follow: - no model specified in domain's XML - libvirt will behave like before this change; it will set type=ioemu for HVM guests on xen host which is not newer than XEND_CONFIG_MAX_VERS_NET_TYPE_IOEMU - covered by existing tests - PV guest, any model - no functional change, model is passed as is (and ignored by the hypervisor) - covered by existing tests (e.g., *-net-e1000.*) - HVM guest, model=netfront - type is set to "netfront", model is not specified - covered by new *-net-netfront.* tests - HVM guest, model != netfront - type is set to "ioemu", model is passed as is - covered by new *-net-ioemu.* tests The fourth scenario feels like a regression for xen newer than XEND_CONFIG_MAX_VERS_NET_TYPE_IOEMU as users who had a model specified in their guest's configuration won't see a paravirtual interface in their guests any more. On the other hand, the reason for specifying a model is most likely the fact that they want to use such model which implies emulated interface. Users of older xen won't be affected at all as their xen provides paravirtual interface regardless of the type used. In previous version of this patch, I used "xenpv" instead of "netfront" as it looked more like kvm/qemu's virtio. However, you can find several tips how to force PV network interface for HVM guest by using type="netfront" so I changed it to conform with those tips. It also matches guest's driver name used for that device. Jiri Denemark (2): Support for interface model='netfront' Tests for interface type/model configuration src/xen/xend_internal.c | 32 +++++++++++---- src/xen/xm_internal.c | 38 +++++++++++++++-- tests/sexpr2xmldata/sexpr2xml-fv-net-ioemu.sexpr | 1 + tests/sexpr2xmldata/sexpr2xml-fv-net-ioemu.xml | 42 +++++++++++++++++++ .../sexpr2xmldata/sexpr2xml-fv-net-netfront.sexpr | 1 + tests/sexpr2xmldata/sexpr2xml-fv-net-netfront.xml | 42 +++++++++++++++++++ tests/sexpr2xmltest.c | 3 + tests/xmconfigdata/test-fullvirt-net-ioemu.cfg | 25 +++++++++++ tests/xmconfigdata/test-fullvirt-net-ioemu.xml | 43 ++++++++++++++++++++ tests/xmconfigdata/test-fullvirt-net-netfront.cfg | 25 +++++++++++ tests/xmconfigdata/test-fullvirt-net-netfront.xml | 43 ++++++++++++++++++++ tests/xmconfigtest.c | 3 + tests/xml2sexprdata/xml2sexpr-fv-net-ioemu.sexpr | 1 + tests/xml2sexprdata/xml2sexpr-fv-net-ioemu.xml | 31 ++++++++++++++ .../xml2sexprdata/xml2sexpr-fv-net-netfront.sexpr | 1 + tests/xml2sexprdata/xml2sexpr-fv-net-netfront.xml | 31 ++++++++++++++ tests/xml2sexprtest.c | 3 + 17 files changed, 352 insertions(+), 13 deletions(-) create mode 100644 tests/sexpr2xmldata/sexpr2xml-fv-net-ioemu.sexpr create mode 100644 tests/sexpr2xmldata/sexpr2xml-fv-net-ioemu.xml create mode 100644 tests/sexpr2xmldata/sexpr2xml-fv-net-netfront.sexpr create mode 100644 tests/sexpr2xmldata/sexpr2xml-fv-net-netfront.xml create mode 100644 tests/xmconfigdata/test-fullvirt-net-ioemu.cfg create mode 100644 tests/xmconfigdata/test-fullvirt-net-ioemu.xml create mode 100644 tests/xmconfigdata/test-fullvirt-net-netfront.cfg create mode 100644 tests/xmconfigdata/test-fullvirt-net-netfront.xml create mode 100644 tests/xml2sexprdata/xml2sexpr-fv-net-ioemu.sexpr create mode 100644 tests/xml2sexprdata/xml2sexpr-fv-net-ioemu.xml create mode 100644 tests/xml2sexprdata/xml2sexpr-fv-net-netfront.sexpr create mode 100644 tests/xml2sexprdata/xml2sexpr-fv-net-netfront.xml

3 4

[libvirt] [PATCH] Support for virtualbox version 3.1
by pritesh 04 Dec '09

04 Dec '09

Hi All, I have just added support for VirtualBox Version 3.1 (works for the beta as well) in the libvirt vbox driver. The patch for the same is attached below. Regards, Pritesh

3 8

[libvirt] Move esxVMX_IndexToDiskName to util.c
by Matthias Bolte 04 Dec '09

04 Dec '09

I needed the inverse function to virDiskNameToIndex() for the ESX driver and added it to esx_vmx.c. The pending VirtualBox 3.1 patch needs disk index to disk name mapping too. So I want to move esxVMX_IndexToDiskName() to util.c. esxVMX_IndexToDiskName() handles indices up to 701. This limit comes from a gap in the disk name to disk index mapping of virDiskNameToIndex(): sdzy -> 700 sdzz -> 701 sdaaa -> 728 sdaab -> 729 This line in virDiskNameToIndex() causes this gap: idx = (idx + i) * 26; It can be fixed by altering this line to: idx = (idx + (i < 1 ? 0 : 1)) * 26; But this change breaks compatibility for indices > 701. So, I made two patches for either option and ask you for comments. Matthias

3 3

[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