February 2010 - Devel - libvirt List Archives

[libvirt] [PATCH] Fix python error reporting for some storage operations
by Cole Robinson 07 Mar '25

07 Mar '25

In the python bindings, all vir* classes expect to be passed a virConnect object when instantiated. Before the storage stuff, these classes were only instantiated in virConnect methods, so the generator is hardcoded to pass 'self' as the connection instance to these classes. Problem is there are some methods that return pool or vol instances which aren't called from virConnect: you can lookup a storage volume's associated pool, and can lookup volumes from a pool. In these cases passing 'self' doesn't give the vir* instance a connection, so when it comes time to raise an exception crap hits the fan. Rather than rework the generator to accomodate this edge case, I just fixed the init functions for virStorage* to pull the associated connection out of the passed value if it's not a virConnect instance. Thanks, Cole diff --git a/python/generator.py b/python/generator.py index 01a17da..c706b19 100755 --- a/python/generator.py +++ b/python/generator.py @@ -962,8 +962,12 @@ def buildWrappers(): list = reference_keepers[classname] for ref in list: classes.write(" self.%s = None\n" % ref[1]) - if classname in [ "virDomain", "virNetwork", "virStoragePool", "virStorageVol" ]: + if classname in [ "virDomain", "virNetwork" ]: classes.write(" self._conn = conn\n") + elif classname in [ "virStorageVol", "virStoragePool" ]: + classes.write(" self._conn = conn\n" + \ + " if not isinstance(conn, virConnect):\n" + \ + " self._conn = conn._conn\n") classes.write(" if _obj != None:self._o = _obj;return\n") classes.write(" self._o = None\n\n"); destruct=None

4 3

[libvirt] Supporting vhost-net and macvtap in libvirt for QEMU
by Anthony Liguori 26 Oct '23

26 Oct '23

Disclaimer: I am neither an SR-IOV nor a vhost-net expert, but I've CC'd people that are who can throw tomatoes at me for getting bits wrong :-) I wanted to start a discussion about supporting vhost-net in libvirt. vhost-net has not yet been merged into qemu but I expect it will be soon so it's a good time to start this discussion. There are two modes worth supporting for vhost-net in libvirt. The first mode is where vhost-net backs to a tun/tap device. This is behaves in very much the same way that -net tap behaves in qemu today. Basically, the difference is that the virtio backend is in the kernel instead of in qemu so there should be some performance improvement. Current, libvirt invokes qemu with -net tap,fd=X where X is an already open fd to a tun/tap device. I suspect that after we merge vhost-net, libvirt could support vhost-net in this mode by just doing -net vhost,fd=X. I think the only real question for libvirt is whether to provide a user visible switch to use vhost or to just always use vhost when it's available and it makes sense. Personally, I think the later makes sense. The more interesting invocation of vhost-net though is one where the vhost-net device backs directly to a physical network card. In this mode, vhost should get considerably better performance than the current implementation. I don't know the syntax yet, but I think it's reasonable to assume that it will look something like -net tap,dev=eth0. The effect will be that eth0 is dedicated to the guest. On most modern systems, there is a small number of network devices so this model is not all that useful except when dealing with SR-IOV adapters. In that case, each physical device can be exposed as many virtual devices (VFs). There are a few restrictions here though. The biggest is that currently, you can only change the number of VFs by reloading a kernel module so it's really a parameter that must be set at startup time. I think there are a few ways libvirt could support vhost-net in this second mode. The simplest would be to introduce a new tag similar to <source network='br0'>. In fact, if you probed the device type for the network parameter, you could probably do something like <source network='eth0'> and have it Just Work. Another model would be to have libvirt see an SR-IOV adapter as a network pool whereas it handled all of the VF management. Considering how inflexible SR-IOV is today, I'm not sure whether this is the best model. Has anyone put any more thought into this problem or how this should be modeled in libvirt? Michael, could you share your current thinking for -net syntax? -- Regards, Anthony Liguori

8 26

[libvirt] inability to open local read-only connection
by Tavares, John 20 Aug '10

20 Aug '10

I have been experimenting with using libvirt (0.3.3) on a variety of systems (RHEL, CentOS and Oracle VM). I have run into an issue when I try to open a local read-only connection to the hypervisor that is failing only on Oracle VM server release 2.2.0. I have created a root owned setuid executable that is effectively running as root, but even so, still cannot open the local read-only connection of the hypervisor. It only works if I run it directly as root. This is not an option. I do not understand why it works as is on my RHEL and CentOS machines, but not my Oracle machine. It would seem as thought it is not checking if the effective uid is root, just the uid. Has anyone run into a similar issue or have any suggestions of what I might try to fix this issue or can tell me that this is a defect that needs (is) fixed?? Thanks.

4 23

[libvirt] Don't add iptables rules when creating networks
by Felix Schwarz 13 Jun '10

13 Jun '10

Hi, I just found out that libvirt always add some iptables rules if it creates a natted (or routed) network. There were a couple of mailing list posts about this so I'm pretty sure this is not news to you. I don't want to go into the debate if your approach is sensible or not (I guess there are some use cases where I kind of like it). However on my server machine I really need full control over my (rather complicated) firewall settings. Currently the newly added rules really create a lot of problems for me. For example if I manage to have a good configuration after startup and then start a libvirt network afterwards, it will inject its rules at the start of the FORWARD queue (even though the same parameters are already present at the end!). On every net start there will be more duplicated rules and they will take preference over my existing rules. Besides that specific issue I think this is only one tiny problem compared to others (central configuration of firewall rules, auditing requirements, ...). Therefore I would like to have some kind 'power user' flag that prevents libvirt from adding any filter rules. I'm fine with activating it manually as long as I don't have to patch libvirt. fs

3 6

[libvirt] cannot start a qemu64 model on an Intel host
by Dan Kenigsberg 12 Apr '10

12 Apr '10

If I specify <cpu match="exact"> <model>qemu64</model> </cpu> according to the new cpu schema, I get error: internal error guest CPU is not compatible with host CPU because qemu64 supports svm, and my host does not. However, the error remains when I explicitly ask to disable svm with <feature policy="disable" name="svm"/> I am not sure if this is a bug or an intended feature, but I'd expect cpu_disable taken into account when doing x86ModelCompare(host_model, cpu_require) Regards, Dan.

2 2

[libvirt] [PATCH] Avoid searching for windres when not building for cygwin or mingw.
by Diego Elio Pettenò 08 Apr '10

08 Apr '10

Just checking for a windres tool might hit even on Linux systems when building for Linux (e.g.: when using Gentoo and having built binutils with multitarget support), and will then fail to link properly at the end of the build. Check the host string before deciding whether to look for windres or not. --- configure.ac | 9 +++++++-- 1 files changed, 7 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 29c6396..e6122b9 100644 --- a/configure.ac +++ b/configure.ac @@ -1676,8 +1676,13 @@ AC_SUBST([CYGWIN_EXTRA_PYTHON_LIBADD]) AC_SUBST([MINGW_EXTRA_LDFLAGS]) dnl Look for windres to build a Windows icon resource. -AC_CHECK_TOOL([WINDRES], [windres], [no]) -AM_CONDITIONAL([WITH_WIN_ICON], [test "$WINDRES" != "no"]) +case "$host" in + *cygwin* | *mingw* ) + AC_CHECK_TOOL([WINDRES], [windres], []) + ;; +esac + +AM_CONDITIONAL([WITH_WIN_ICON], [test "$WINDRES" != ""]) -- 1.6.6.1

3 2

[libvirt] Two issues regarding TFTP support in virtual networks...
by Darryl L. Pierce 24 Mar '10

24 Mar '10

The first is just a wiki fix: the wiki says this functionality is available as of 0.7.1 of libvirt. The code though is only in the 0.7.2 tag and later. So the wiki should say 0.7.2 instead. The second regards how I'm using it and what I'm doing wrong. I'm creating a virtual network and pointing it to a temporary directory where I've run livecd-iso-to-pxeboot to setup an ISO file for PXE booting. So the network XML looks like this: (mcpierce@mcpierce-desktop:node-image)$ sudo virsh net-dumpxml testbr541 <network> <name>testbr541</name> <uuid>f389317f-8420-7516-df9d-756b7deb3d37</uuid> <forward mode='nat'/> <bridge name='testbr541' stp='on' delay='0' /> <ip address='192.168.31.1' netmask='255.255.255.0'> <tftp root='/tmp/tmp.3B8opJfBXw/tftpboot/' /> <dhcp> <range start='192.168.31.100' end='192.168.31.199' /> </dhcp> </ip> </network> When I start up the VM, I see it get an IP address within the range specified, but it never pxeboots the ISO image. To what directory should the root attribute be pointed? -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/

2 14

[libvirt] [PATCH 0/3] Refactor XML parsing code
by Jiri Denemark 23 Mar '10

23 Mar '10

Almost identical XML parsing code for either strings or files was copied 15 times. Since it was needed on two other places for parsing CPU XML strings with correct error reporting, I decided to factor the parsing code out to xml.c and used this one implementation in all other places. Jiri Denemark (3): Introduce XML parsing utility functions Use common XML parsing functions Fix error reporting when parsing CPU XML strings src/conf/domain_conf.c | 130 ++++++--------------------------------- src/conf/interface_conf.c | 93 ++++------------------------ src/conf/network_conf.c | 93 ++++------------------------ src/conf/node_device_conf.c | 60 +----------------- src/conf/secret_conf.c | 56 ++--------------- src/conf/storage_conf.c | 110 +++------------------------------- src/cpu/cpu.c | 11 ++- src/util/xml.c | 142 ++++++++++++++++++++++++++++++++++++++++++- src/util/xml.h | 19 ++++++ 9 files changed, 231 insertions(+), 483 deletions(-)

2 7

Re: [libvirt] FW: [PATCH 1/4] Addition of XenAPI support to libvirt
by Daniel Veillard 23 Mar '10

23 Mar '10

On Fri, Feb 19, 2010 at 11:33:36AM +0000, Sharadha Prabhakar (3P) wrote: > > thanks for the patch, just started to look at it. > > I assume that by libxenserver you mean the code to be added under src > in a following patch, right ? > > -> libxenserver is a library which provides APIs for performing various > Operations on the hypervisor. You can download it from > http://community.citrix.com/download/attachments/38633496/libxenserver-5.5.… > libxenserver folder should be in the same directory level of libvirt. Sorry that's not possible. Either the code is in libvirt, and in that case it doesn't have to be downloaded, but part of the patch submission (and managed on this list) , or it's a new external dependancy and it's availability must be checked by configure.ac. If we add a new dependancy, it must also be checked for Licence compatibility. So far we have always refused to use a third party library to access the hypervisor itself, libvirt(d) talking directly to the hypervisor components or launching it directly. For example we don't rely on the VMWare libraries to talk to ESX. > [...] > > +endif > > +#libvirt_driver_xenapi_la_LIBADD = $(XENAPI_LIBS) > > +libvirt_driver_xenapi_la_CFLAGS = $(XEN_CFLAGS) \ > > + $(shell xml2-config --cflags) \ > > + $(shell curl-config --cflags) > > +libvirt_driver_xenapi_la_LDFLAGS = -L@top_srcdir@/../libxenserver/ -lxenserver -g $(shell xml2-config --libs) \ > > + $(shell curl-config --libs) > > Hum, libxml2 is already fully detected in configure.ac, use the > LIBXML_* variables instead of trying to exec xml2-config. > > -> I've added the LIBXML_ flags in Makefile.am and posted the patch. okay, we will review this, but note that we start the feature freeze for 0.7.7 this week-end, so next week is more likely to be focused on bug fixes for already commited features. > Similary libcurl i looked at in configure.ac for ESX, this need > to be modified to be checked more generally and the LIBCURL_* > variables need to be used here too. > > -> I didn't quite understand the libcurl part you mentioned. I too noticed that ESX has > a piece of code in configure.ac to set the libcurl flags, do you want me to do add a similar > bit of code in configure.ac for XenAPI that defines LIBCURL flags and then add in my Makefile.am? the code to look for libcurl in configure.ac is currently only activated if esx support is on. It must be run if either esx or xen-api are selected, the ESX portion need to be modified accordingly, and your parts and Makefiles patches too. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/

3 3

[libvirt] 'build' on FS pool now unconditionally formats?
by Cole Robinson 16 Mar '10

16 Mar '10

Hi guys, Looking at the new FS pool build options and talking with Dave, I see that calling PoolBuild on an FS pool now unconditionally calls mkfs. This is really bad when mixed with virt-manager: previously, we assumed the FS build command was always non destructive (at most it created a directory), so we called it every time, and didn't even allow users to opt out, since there wasn't a use case that called for it. This new formatting behavior really needs to be opt in, otherwise all virt-manager versions creating an FS pool can destroy data. Just FYI, for disk pools (and certain LVM configurations) where this operation has always been destructive, we default to build=off, and loudly warn the user if they choose otherwise. We can do that with this new option as well, but the previous behavior really needs to be reinstated IMO (and before the new release). I fully accept that this could be a bug in virt-manager's assumptions of the build command, but even consider a virsh user: previously build just created a directory, now it formats a partition, without any XML change. Thanks, Cole

4 11