May 2011 - Devel - libvirt List Archives

[libvirt] [PATCH] tests: avoid compiler warning
by Eric Blake 03 May '11

03 May '11

../../tests/xmconfigtest.c: In function 'testCompareParseXML': ../../tests/xmconfigtest.c:49:19: error: 'conn' may be used uninitialized in this function [-Wuninitialized] * tests/xmconfigtest.c (testCompareParseXML): Initialize variable. --- Pushing under the build-breaker rule. tests/xmconfigtest.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tests/xmconfigtest.c b/tests/xmconfigtest.c index 02a8900..6022621 100644 --- a/tests/xmconfigtest.c +++ b/tests/xmconfigtest.c @@ -46,7 +46,7 @@ testCompareParseXML(const char *xmcfg, const char *xml, int xendConfigVersion) char *gotxmcfgData = NULL; virConfPtr conf = NULL; int ret = -1; - virConnectPtr conn; + virConnectPtr conn = NULL; int wrote = 4096; struct _xenUnifiedPrivate priv; virDomainDefPtr def = NULL; -- 1.7.4.4

1 0

[libvirt] Libvirt 0.9.1 week freeze, RC1 version to test
by Daniel Veillard 02 May '11

02 May '11

So we are entering the week freeze for the new version. I have made an rc1 tarball available at: ftp://libvirt.org/libvirt/libvirt-0.9.1-rc1.tar.gz I have tried it locally and basic operations seems to work fine, please give it a try too, thanks ! 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/

4 7

[libvirt] [PATCH] qemu: fix uninitialized variable warning
by Christophe Fergeau 02 May '11

02 May '11

This commit fixes qemu/qemu_driver.c: In function 'qemuDomainModifyDeviceFlags': qemu/qemu_driver.c:4041:8: warning: 'ret' may be used uninitialized in this function [-Wuninitialized] qemu/qemu_driver.c:4013:9: note: 'ret' was declared here The variable is set to -1 so that the error paths are taken when the code to set it didn't get a chance to run. Without initializing it, we could return some an undefined value from this function. While I was at it, I made a trivial whitespace change in the same function to improve readability. --- src/qemu/qemu_driver.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index a19c4a7..16d869d 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -4010,11 +4010,11 @@ qemuDomainChangeDiskMediaLive(virDomainObjPtr vm, { virDomainDiskDefPtr disk = dev->data.disk; virCgroupPtr cgroup = NULL; - int ret; + int ret = -1; if (qemuCgroupControllerActive(driver, VIR_CGROUP_CONTROLLER_DEVICES)) { if (virCgroupForDomain(driver->cgroup, - vm->def->name, &cgroup, 0) !=0 ) { + vm->def->name, &cgroup, 0) != 0) { qemuReportError(VIR_ERR_INTERNAL_ERROR, _("Unable to find cgroup for %s"), vm->def->name); -- 1.7.5

2 1

[libvirt] Libvirt and IPSec (was: What about Trusted Virtual Domains???)
by Paolo Smiraglia 02 May '11

02 May '11

Hi to everyone! First of all, sorry for the thread subject change. Due to the several issues of the Libvirt implementation of the Trusted Virtual Domains (TVD), I decided to approach the topic in a modular manner. I think that the first step should be to define the IPSec support or, more in general, the secure tunnel support for Libvirt. I see the implementation divided in two step: 1. define a new driver called 'sectunnel' which describes a generic secure tunnel that will be established using several technologies (for now using only ipsec) 2. modify the existing 'network' driver by adding the possibility to specify the 'sectunnel' that the network have to use in the virtual network definition As an example, you can see below a possible XML definition of the network which use a secure tunnel and the corresponding 'sectunnel' XML definition: NETWORK DEFINITION ================== <network> <name>sec-net</name> <uuid>3e3fce45-4f53-4fa7-bb32-11f34168b82b</uuid> <bridge name='virbr0' /> <domain name='example' /> ... <sectunnel name='sec-tun' /> <--(specify the 'sectunnel' to use) </network> SECTUNNEL DEFINITION ==================== <sectunnel type='ipsec'> <name>sec-tun</name> <uuid>8b7fd1b0-4463-43b7-8b6e-8006344aeb66</uuid>  <sa> <secret uuid='...' /> <--(specify the 'secret' which contains the pre-shared key) </sa>  <sp> <src_range address='10.0.0.1' prefixlen='30' port='5000' /> <dst_range address='10.0.0.2' prefixlen='30' port='5000' /> <upperspec protocol='any' /> <policy direction='out' action='ipsec'> <rule protocol='esp' mode='tunnel' level='require'> <src address='192.168.0.1' port='55055' /> <dst address='192.168.0.2' port='55055' /> </rule> </policy> </sp> <sp> <src_range address='10.0.0.2' prefixlen='30' port='5000' /> <dst_range address='10.0.0.1' prefixlen='30' port='5000' /> <upperspec protocol='any' /> <policy direction='in' action='ipsec'> <rule protocol='esp' mode='tunnel' level='require'> <src address='192.168.0.2' port='55055' /> <dst address='192.168.0.1' port='55055' /> </rule> </policy> </sp> </sectunnel> As you can see in the 'sectunnel' XML definition, I use a 'secret' element. This element is a Libvirt secret [1] and it stores the pre-shared key used by IPSec to establish the Security Associations (SA). Obviously this feature requires to define a new usage category in the 'secret' driver definition. Another possible way to establish the SA is to use the X.509 certificates. To this purpose, I think that the certificates already used by Libvirt to setup SSL/TLS remote connections, might be used. That's all! :-) What do you think about this possible IPSec implementation? Thanks in advance for the replies! Best regards, PAOLO LINK LIST --------- [1] http://libvirt.org/formatsecret.html -- PAOLO SMIRAGLIA Department of Control and Computer Engineering Mobile: +39 (333) 527 3593 Email: paolo.smiraglia(a)polito.it

3 12

[libvirt] RFC: virInterface change transaction API
by Laine Stump 02 May '11

02 May '11

I've been asked to implement what some people have termed as a "transaction-oriented" API for host interface configuration (ie virInterface*()). The basic intent is to allow rollback to a known-good config if anything goes wrong when changing around the host network config with virInterface*() functions. The most straightforward way to achieve this is that prior to calling virInterfaceDefine/virInterfaceUndefine, the current state of the host's network configuration (ie the /etc/sysconfig/network-scripts/ifcfg-* files in the case of Fedora and RHEL) would be saved off somewhere, and kept around until we're sure the new config is good; once we know that, we can just eliminate the backup. If, however, the user of virInterface*() explicitly requests, we could copy the files back; alternately if the system is rebooted without these known-good files being erased, we would assume that something went wrong and restore the original config. As with all other virInterface functions, the details of all this will be handled by netcf (and below), but since libvirt is the main consumer of netcf, I figure this is the appropriate place to discuss how it gets done, so please let me know any opinions on any piece of this. I plan to start the implementation "soon", as I want to be finished before the end of May. I see 3 layers to this: 1) libvirt At the libvirt layer, this feature just requires 3 new APIs, which are directly passed through to netcf: virInterfaceChangeStart(virConnectPtr conn, unsigned int flags); virInterfaceChangeCommit(virConnectPtr conn, unsigned int flags); virInterfaceChangeRollback(virConnectPtr conn, unsigned int flags); For the initial implementation, these will be simple passthroughs to similarly named netcf functions. (in the future, it would be useful for the server side of libvirt to determine if client<->server connectivity was lost due to the network changes, and automatically tell netcf to do a rollback). 2) netcf The netcf api will have these same three APIs, just named slightly differently: ncf_change_start(struct netcf *ncf, unsigned int flags); There are two possibilities for this. Either: A) call the initscript described below to save all config files that might possibly be changed (snapshot_config) or B) set a flag in *ncf indicating that all future calls to netcf that would end up modifying a particular config file should save off that file *if it hasn't already been saved*. (A) is simpler, but relies on the initscript having exact/complete matching knowledge of what files netcf may change. Should we worry about that and deal with the complexities of (B), or is (A) good enough for now? ncf_change_rollback(struct netcf *ncf, unsigned int flags); Again, two possbilities: A) a) save the config of all current interfaces (in memory) b) call the initscript below to restore the config to its original state. c) compare the new config to the old, and: * bring down any interfaces that no longer exist (PROBLEM: once an interface has no config files, you can no longer operate on it with "ifdown") * bounce any interfaces that have changed * bring up any interfaces that have been re-added or B) a) ifdown all interfaces b) call initscript to restore previous config (rollback_config) c) ifup all interfaces. (A) is much simpler, but may lead to unnecessary difficulties when we bounce interfaces that didn't really need it. So, the same question oas for ncf_change_start() - is the more exact operation worth the extra complexity? ncf_change_commit(struct netcf *ncf, unsigned int flags); The simplest function - this will just call the initscript to erase the backup (commit_config). 3) initscript This initscript will at first live in (be installed by) netcf (called /etc/init.d/networking-config?), but hopefully it will eventually be accepted by the initscripts package (which includes the networking-related initscripts), as it is of general use. (Dan Kenigsberg already already took a stab at this script last year, but received no reply from the initscripts maintainers, implying they may not be too keen on the idea right now - it might take some convincing ;-) https://fedorahosted.org/pipermail/initscripts-devel/2010-February/000025.h… It will have three commands, one of which will be called automatically by "start" (the command called automatically at boot time): snapshot_config This will save a copy of (what the script believes are - is this problematic?) all network-config related files. It may or may not be called by netcf (see the notes in ncf_start_change() above. If this function finds that a snapshot has already been taken, it should fail. rollback_config (automatically called from "start" at boottime) This will move back (from the saved copies) all files that were changed/removed since snapshot, *and delete any files that have been added*. Note that this command doesn't need to worry about ifup/ifdown, because it will be called prior to any other networking startup (part of the reason that netcf will need to deal with that). I notice that Dan K's version saves the modified files to a "rollback-${date}" directory. Does this seem like a good idea? It's nice to not lose anything, but there is no provision for eliminating old versions, so it could grow without bound. commit_config This will just remove all the files in the save directory. So, the two problems I have right now: 1) Do we accept the inexact method of just saving all files that match a list of patterns during *start(), then in *rollback() erasing all files matching that pattern and copying the old file back? Or do we need to keep track of what files have been changed/removed and added, and copy back / delete only those files during rollback? (A version control system would keep track of this rather nicely, but that's too complex for something that's intended to be a failsafe (and that we would also like to eventually be in the base OS install). Dan B. at one point suggested using patchfiles if I wanted the save info to keep exact track of which files would need to be replaced/deleted on rollback, but on further thought this turns out to not be workable, since we would need to run diff (to create the patchfile) after all changes had been made, and any outside changes to any of the files would leave the patchfile un-appliable, thus causing our "failsafe" to fail :-( ). Therefore, we will need to rely on the list of globs to tell us what files need to be deleted, or keep our own list in a separate file.) 2) Is it going to be okay to ifdown all interfaces prior to the rollback, and ifup all interfaces afterwards? Or must we compare the new config to the original, and ifdown only those interfaces that had been previously added/changed, then ifup only those interfaces that had been previously removed/changed? 3) If anyone has ideas on making the initscript more palatable to the initscripts people, please speak up! :-) (one comment from an initscripts person was that 1) for the general case it would be difficult to draw the line on what parts of network connectivity should be included in this rollback functionality, and 2) at some point this becomes a general system config problem, and would really be better addressed by a general system wide config management system. These are both concerns that need well qualified answers. (I tend to think that this is intended as a failsafe to prevent unreachable systems, so it should be as simple as possible, and thus shouldn't be burdened with the complexity of a full system config management system (which could also co-exist at a higher level), but better answers are welcome.)

4 10

[libvirt] [PATCH v3 0/5] Add TXT record and hosts support for DNS service and dnsmasq command-line regression testing
by Michal Novotny 02 May '11

02 May '11

Hi, this is the patch to introduce the TXT record and DNS hosts support for the DNS service on the virtual network. This can be defined using the txt-record subelement in the dns element of the network XML description. The definition of TXT record names containing spaces is rejected with the error message that TXT record names in DNS doesn't support spaces. Also, regression testing for the dnsmasq command line has been added to test whether the dnsmasq command-line is correct or not. The new XML definition syntax is: <dns> <txt name="example" value="example value" /> <host ip='192.168.122.1'> <hostname>gateway</hostname> <hostname>host</hostname> </host> </dns> Where multiple host elements can be defined to put the aliases. The <dns> element have to be present on the <ip> level, i.e. one level upper than it was in version 2 of the patch since the definition affects all the IP addresses on the network. The patch series has been tested for the configuration and it was working fine and also RelaxNG schema with the tests have been both altered to add test cases to test those patches. All of the patches passed the all the tests and everything was working fine. Michal Signed-off-by: Michal Novotny <minovotn(a)redhat.com> Michal Novotny (5): Add TXT record support for virtual DNS service Network: Add regression tests for the command-line arguments Network: Move dnsmasqContext creation to networkSaveDnsmasqHostsfile() and pass to dnsmasq only if applicable Network: Add additional hosts internal infrastructure Network: Add support for DNS hosts definition to the network XML .gnulib | 2 +- docs/formatnetwork.html.in | 31 +++ docs/schemas/network.rng | 21 ++ src/Makefile.am | 7 +- src/conf/network_conf.c | 212 +++++++++++++++ src/conf/network_conf.h | 25 ++ src/libvirt_network.syms | 6 + src/libvirt_private.syms | 1 + src/network/bridge_driver.c | 118 ++++++--- src/network/bridge_driver.h | 3 + src/util/dnsmasq.c | 285 ++++++++++++++++++-- src/util/dnsmasq.h | 22 ++- tests/Makefile.am | 10 + tests/networkxml2argvdata/isolated-network.argv | 1 + tests/networkxml2argvdata/isolated-network.xml | 11 + .../networkxml2argvdata/nat-network-dns-hosts.argv | 1 + .../networkxml2argvdata/nat-network-dns-hosts.xml | 13 + .../nat-network-dns-txt-record.argv | 1 + .../nat-network-dns-txt-record.xml | 24 ++ tests/networkxml2argvdata/nat-network.argv | 1 + tests/networkxml2argvdata/nat-network.xml | 21 ++ tests/networkxml2argvdata/netboot-network.argv | 1 + tests/networkxml2argvdata/netboot-network.xml | 14 + .../networkxml2argvdata/netboot-proxy-network.argv | 1 + .../networkxml2argvdata/netboot-proxy-network.xml | 13 + tests/networkxml2argvdata/routed-network.argv | 1 + tests/networkxml2argvdata/routed-network.xml | 9 + tests/networkxml2argvtest.c | 115 ++++++++ .../nat-network-dns-txt-record.xml | 24 ++ .../nat-network-dns-txt-record.xml | 24 ++ tests/networkxml2xmltest.c | 2 + 31 files changed, 967 insertions(+), 53 deletions(-) create mode 100644 src/libvirt_network.syms create mode 100644 tests/networkxml2argvdata/isolated-network.argv create mode 100644 tests/networkxml2argvdata/isolated-network.xml create mode 100644 tests/networkxml2argvdata/nat-network-dns-hosts.argv create mode 100644 tests/networkxml2argvdata/nat-network-dns-hosts.xml create mode 100644 tests/networkxml2argvdata/nat-network-dns-txt-record.argv create mode 100644 tests/networkxml2argvdata/nat-network-dns-txt-record.xml create mode 100644 tests/networkxml2argvdata/nat-network.argv create mode 100644 tests/networkxml2argvdata/nat-network.xml create mode 100644 tests/networkxml2argvdata/netboot-network.argv create mode 100644 tests/networkxml2argvdata/netboot-network.xml create mode 100644 tests/networkxml2argvdata/netboot-proxy-network.argv create mode 100644 tests/networkxml2argvdata/netboot-proxy-network.xml create mode 100644 tests/networkxml2argvdata/routed-network.argv create mode 100644 tests/networkxml2argvdata/routed-network.xml create mode 100644 tests/networkxml2argvtest.c create mode 100644 tests/networkxml2xmlin/nat-network-dns-txt-record.xml create mode 100644 tests/networkxml2xmlout/nat-network-dns-txt-record.xml -- 1.7.3.2

1 5

Re: [libvirt] [libvirt-users] [Libvir] libvirt & vde_switch
by Laine Stump 02 May '11

02 May '11

On 04/28/2011 09:56 AM, Robert Šmol wrote: > For my needs I would like to see either vdeswitch or openvswitch > integrated in the project. Is there any preference from the > users/developers on which one of those I should start looking into? Are you volunteering to write some code? :-) There have been requests for both, and both should eventually be done, so I guess pick whichever one you like better :-) (since there's already a patch for VDE, albeit with different XML than we'd like, that may be quicker to finish.) You may want to follow development of the work I'll point out below, though, otherwise you could waste a lot of time. > > Also I would like to know how this should be integrated, from the > mails I can see devs prefers to have virtual switch present as a > network. Can someone describe how the integration should be done? > Support for additional features like vlan, QoS? Once we get into these kinds of questions, it's probably best to switch to the developers' list (libvir-list(a)redhat.com) to get better exposure to people writing the code. I'm Cc'ing this message there (and switching the Reply-To: as well). In particular, I recently send an RFC to libvir-list proposing an expansion of the <network> XML to remove the hard-coded connection between guest interface and host interface for macvtap (type='direct') interfaces: https://www.redhat.com/archives/libvir-list/2011-April/msg00591.html and in a followup message showed how we could expand on this work to provide support for openvswitch (or vde): https://www.redhat.com/archives/libvir-list/2011-April/msg00640.html I'm planning to have this code finished and tested within the next two months at most (hopefully considerably earlier). If you're interested in implementing a <network type='openvswitch'> or <network type='vde'> you should subscribe to libvir-list (if you aren't already) so that you can follow along. > > Robert > > On 04/06/2011 04:13 PM, Robert Šmol wrote: >> >> >> On 04/06/2011 04:00 PM, Nicolas Sebrecht wrote: >>> The 06/04/11, Robert Šmol wrote: >>>> On 04/06/2011 10:34 AM, Nicolas Sebrecht wrote: >>>>> The 05/04/11, Robert Šmol wrote: >>>>> >>>>>> I would like to ask about status of VDE and libvirt. I found a >>>>>> thread from >>>>>> http://www.redhat.com/archives/libvir-list/2008-February/msg00030.html. >>>>>> >>>>> AFAIK, vde_switch is still unsupported by libvirt and nobody seems to >>>>> work on it these days. >>>>> >>>>> Most people wanting vde_switch (or open vswitch) enough leave >>>>> libvirt. >>>>> >>>> On #IRC I got point to message: >>>> >>>> http://www.mail-archive.com/libvir-list@redhat.com/msg32081.html >>>> >>>> It seems there is a patch ready. I will test it against 0.9.0. What >>>> is the procedure to get the patch reviewed and eventually get into >>>> libvirt? >>> The patch wasn't merged but the why is a question to the maintainers. I >>> guess the way it was implemented did not convinced. This is what I >>> understand from the whole thread, at least. >>> >> From the thread it seems the maintainers would like to have a network >> based on VDE. To me it also looks like better idea (create vde >> network and then just attach the domain to a network. >> >

3 3