April 2007 - Devel - libvirt List Archives

[Libvir] [Q] about Missing type converters in python/generator.py
by Atsushi SAKAI 11 Apr '07

11 Apr '07

Hi, I try to make a python bindings. But I run the python/generator.py. The following messages are appeared. (Missing type converters:) Is there any advice to solve this? ================== /usr/lib/python2.4/xmllib.py:9: DeprecationWarning: The xmllib module is obsolete. Use xml.sax instead. warnings.warn("The xmllib module is obsolete. Use xml.sax instead.", DeprecationWarning) Found 79 functions in libvirt-api.xml Found 1 functions in libvirt-python-api.xml Generated 67 wrapper functions, 9 failed, 4 skipped Missing type converters: virErrorPtr:4 virVcpuInfoPtr:1 void *:2 unsigned long *:2 ================== Thanks Atsushi SAKAI

2 2

[Libvir] [PATCH] Add xenUnifiedRegister Comment for xml files
by Atsushi SAKAI 10 Apr '07

10 Apr '07

Hi, I run apibuild.py on docs, following messages are appeared. Missing comment for function xenUnifiedDriver This patch fixes this. If comments are not appropriate, please change it. Thanks Atsushi SAKAI --- libvirt.0410/src/xen_unified.c 2007-04-04 23:19:49.000000000 +0900 +++ libvirt.xenuni/src/xen_unified.c 2007-04-10 13:30:56.000000000 +0900 @@ -762,6 +762,13 @@ static virDriver xenUnifiedDriver = { .domainSetAutostart = xenUnifiedDomainSetAutostart, }; +/** + * xenUnifiedRegister: + * + * Register xen related drivers + * + * Returns the driver priority or -1 in case of error. + */ int xenUnifiedRegister (void) {

2 2

[Libvir] Virtual network iptables rules
by Daniel P. Berrange 05 Apr '07

05 Apr '07

Warning, this is a long & complicated email with lots of horrible details :-) I've long been a little confused with the way iptables & bridging interacts, so set out to do some experiments. I added a -j LOG rule to every single chain in both the filter & nat tables, and then tried various traffic patterns, to see which chains were traversed & in which order. There are 2 types of config I considered - virtual networking, and shared physical device. For both these I tried with net.bridge.bridge-nf-call-iptables on & off. This gave 4 scenarios to test with. For the test I simply did 'ping -c 1 <ip addr>', which gives a simple roundtrip with a single packet in each direction. The results were as follows.... Scenario 1: Virtual network =========================== net.bridge.bridge-nf-call-iptables = 0 Host: eth0 -> Internet virbr0 -> MASQUERADE to eth0 Guest: vif1.0 -> virbr0 Traffic: Guest -> Google ------------------------ Out: NAT-PREROUTING IN=virbr0 OUT= SRC=192.168.122.47 DST=64.233.167.99 FORWARD IN=virbr0 OUT=eth0 SRC=192.168.122.47 DST=64.233.167.99 NAT-POSTROUTING IN= OUT=eth0 SRC=192.168.122.47 DST=64.233.167.99 Back: FORWARD IN=eth0 OUT=virbr0 SRC=64.233.167.99 DST=192.168.122.47 Traffic: Guest -> Host ---------------------- Out: NAT-PREROUTING IN=virbr0 OUT= SRC=192.168.122.47 DST=192.168.122.1 INPUT IN=virbr0 OUT= SRC=192.168.122.47 DST=192.168.122.1 Back: OUTPUT IN= OUT=virbr0 SRC=192.168.122.1 DST=192.168.122.47 Traffic: Host -> Guest ---------------------- Out: NAT-OUTPUT IN= OUT=virbr0 SRC=192.168.122.1 DST=192.168.122.47 OUTPUT IN= OUT=virbr0 SRC=192.168.122.1 DST=192.168.122.47 NAT-POSTROUTING IN= OUT=virbr0 SRC=192.168.122.1 DST=192.168.122.47 Back: INPUT IN=virbr0 OUT= SRC=192.168.122.47 DST=192.168.122.1 Scenario 2: Virtual network =========================== net.bridge.bridge-nf-call-iptables = 1 Host: eth0 -> Internet virbr0 -> MASQUERADE to eth0 Guest: vif1.0 -> virbr0 Traffic: Guest -> Google ------------------------ Out: NAT-PREROUTING IN=virbr0 OUT= PHYSIN=vif1.0 SRC=192.168.122.47 DST=64.233.167.99 FORWARD IN=virbr0 OUT=eth0 PHYSIN=vif1.0 SRC=192.168.122.47 DST=64.233.167.99 NAT-POSTROUTING IN= OUT=eth0 PHYSIN=vif1.0 SRC=192.168.122.47 DST=64.233.167.99 Back: FORWARD IN=eth0 OUT=virbr0 SRC=64.233.167.99 DST=192.168.122.47 Traffic: Guest -> Host ---------------------- Out: NAT-PREROUTING IN=virbr0 OUT= PHYSIN=vif1.0 SRC=192.168.122.47 DST=192.168.122.1 INPUT IN=virbr0 OUT= PHYSIN=vif1.0 SRC=192.168.122.47 DST=192.168.122.1 Back: OUTPUT IN= OUT=virbr0 SRC=192.168.122.1 DST=192.168.122.47 Traffic: Host -> Guest ---------------------- Out: NAT-OUTPUT IN= OUT=virbr0 SRC=192.168.122.1 DST=192.168.122.47 OUTPUT IN= OUT=virbr0 SRC=192.168.122.1 DST=192.168.122.47 NAT-POSTROUTING IN= OUT=virbr0 SRC=192.168.122.1 DST=192.168.122.47 Back: INPUT IN=virbr0 OUT= PHYSIN=vif1.0 SRC=192.168.122.47 DST=192.168.122.1 Scenario 3: Shared physical device ================================== net.bridge.bridge-nf-call-iptables = 0 Host: peth1 -> Internet xenbr0 -> peth1 Guest: vif2.0 -> xenbr0 Traffic: Guest -> Google ------------------------ Nada Traffic: Guest -> Host ---------------------- Out: NAT-PREROUTING IN=eth1 OUT= SRC=192.168.254.120 DST=192.168.254.132 INPUT IN=eth1 OUT= SRC=192.168.254.120 DST=192.168.254.132 Back: OUTPUT IN= OUT=eth1 SRC=192.168.254.132 DST=192.168.254.120 Traffic: Host -> Guest ---------------------- Out: NAT-OUTPUT IN= OUT=eth1 SRC=192.168.254.132 DST=192.168.254.120 OUTPUT IN= OUT=eth1 SRC=192.168.254.132 DST=192.168.254.120 NAT-POSTROUTING IN= OUT=eth1 SRC=192.168.254.132 DST=192.168.254.120 Back: INPUT IN=eth1 OUT= SRC=192.168.254.120 DST=192.168.254.132 Scenario 4: Shared physical device ================================== net.bridge.bridge-nf-call-iptables = 1 Host: peth1 -> Internet xenbr0 -> peth1 Guest: vif2.0 -> xenbr0 Traffic: Guest -> Google ------------------------ Out: NAT-PREROUTING IN=xenbr1 OUT= PHYSIN=vif2.0 SRC=192.168.254.120 DST=64.233.167.99 FORWARD IN=xenbr1 OUT=xenbr1 PHYSIN=vif2.0 PHYSOUT=peth1 SRC=192.168.254.120 DST=64.233.167.99 NAT-POSTROUTING IN= OUT=xenbr1 PHYSIN=vif2.0 PHYSOUT=peth1 SRC=192.168.254.120 DST=64.233.167.99 Back: FORWARD IN=xenbr1 OUT=xenbr1 PHYSIN=peth1 PHYSOUT=vif2.0 SRC=64.233.167.99 DST=192.168.254.120 Traffic: Guest -> Host ---------------------- Out: NAT-PREROUTING IN=xenbr1 OUT= PHYSIN=vif2.0 SRC=192.168.254.120 DST=192.168.254.132 FORWARD IN=xenbr1 OUT=xenbr1 PHYSIN=vif2.0 PHYSOUT=vif0.1 SRC=192.168.254.120 DST=192.168.254.132 NAT-POSTROUTING IN= OUT=xenbr1 PHYSIN=vif2.0 PHYSOUT=vif0.1 SRC=192.168.254.120 DST=192.168.254.132 INPUT IN=eth1 OUT= SRC=192.168.254.120 DST=192.168.254.132 Back: OUTPUT IN= OUT=eth1 SRC=192.168.254.132 DST=192.168.254.120 FORWARD IN=xenbr1 OUT=xenbr1 PHYSIN=vif0.1 PHYSOUT=vif2.0 SRC=192.168.254.132 DST=192.168.254.120 Traffic: Host -> Guest ---------------------- Out: NAT-OUTPUT IN= OUT=eth1 SRC=192.168.254.132 DST=192.168.254.120 OUTPUT IN= OUT=eth1 SRC=192.168.254.132 DST=192.168.254.120 NAT-POSTROUTING IN= OUT=eth1 SRC=192.168.254.132 DST=192.168.254.120 FORWARD IN=xenbr1 OUT=xenbr1 PHYSIN=vif0.1 PHYSOUT=vif2.0 SRC=192.168.254.132 DST=192.168.254.120 Back: FORWARD IN=xenbr1 OUT=xenbr1 PHYSIN=vif2.0 PHYSOUT=vif0.1 SRC=192.168.254.120 DST=192.168.254.132 INPUT IN=eth1 OUT= SRC=192.168.254.120 DST=192.168.254.132 Now in this email I'm really only concerned with the first 2 virtual network scernaios. The shared physical device stuff can be ignored henceforth, basically because it 'just works(tm)'. For virtual networks there are basically 3 types of networking config we need to represent in terms of iptables rules, and these need to work for scenrios 1 & 2 - ie regardless of the magic sysctl knob. Here is what we currently implement...... Type 1: Isolated virtual network -------------------------------- - We don't add anything here Type 2: Forwarding to a specific NIC only ----------------------------------------- Chain POSTROUTING (policy ACCEPT 345 packets, 32627 bytes) pkts bytes target prot opt in out source destination 0 0 MASQUERADE all -- * eth1 0.0.0.0/0 0.0.0.0/0 PHYSDEV match ! --physdev-is-bridged Chain FORWARD (policy ACCEPT 29 packets, 2244 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- eth1 vnet0 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT all -- vnet0 eth1 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * eth1 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in vnet0 Chain INPUT (policy ACCEPT 80483 packets, 382M bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT udp -- vnet0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 ACCEPT tcp -- vnet0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 0 0 ACCEPT udp -- vnet0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:67 0 0 ACCEPT tcp -- vnet0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:67 Type 3: Forwarding to any active NIC ------------------------------------ Chain POSTROUTING (policy ACCEPT 360 packets, 33843 bytes) pkts bytes target prot opt in out source destination 2 476 MASQUERADE all -- * * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match ! --physdev-is-bridged Chain FORWARD (policy ACCEPT 29 packets, 2244 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * virbr0 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT all -- virbr0 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in virbr0 Chain INPUT (policy ACCEPT 80884 packets, 382M bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 0 0 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:67 0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:67 So how do these shape up, given the traversal scenarios & the overall desire to be as restrictive as possible with traffic. Problem: The INPUT rules are missing altogether for the isolated virtual network so potentially DHCP/DNS will be blocked Solution: Add them - simple bug. Problem: The POSTROUTING rule is too generic so it matches pretty much any kind of traffic, from any virtual network, or even from VPN devices setup by VPNC. Solution: Only masquerade traffic whose source address is within the netmask associated with the virtual network in question Problem: The FORWARD rule is too generic, forwarding traffic to/from the virtual network regardless of whether the dest/src IP address is within the netmask associated with the virtual network. Assuming the first problem is setup to only masquerade valid IP addresses from the virtual network, this rule would then allow guests to spoof their IP and have it forwarded off-host. Solution: Only forward packets whose IP address is within the netmask associated with the virtual network Problem: The policy of the FORWARD rule is ACCEPT, and/or later user defined rules may inadvertently match on traffic from the virtual network, again allowing through spoof traffic, or traffic from what should be an isolated virtual network Solution: There needs to be a catch-all REJECT rule associated with every bridge device, in both directions Problem: There is an extra physdev match per bridge device, and per guest device. This is basically unneccessary since the previous rule sets will already have allowed through the traffic. The physdev matches also only work if net.bridge.bridge-nf-call-iptables = 1 Solution: Simply remove the per-device matches Problem: The POSTROUTING rule has a physdev match applied, which only works if net.bridge.bridge-nf-call-iptables = 1. Solution: Remove physdev match & masquerade based on network address associated with the virtual network If we apply all solution outlined here, we'll end up with a set of rules which look like this.......... Type 1: Isolated virtual network -------------------------------- Chain POSTROUTING (policy ACCEPT 273 packets, 26341 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 29 packets, 2244 bytes) pkts bytes target prot opt in out source destination 0 0 REJECT all -- * vnet2 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 0 0 REJECT all -- vnet2 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable Chain INPUT (policy ACCEPT 76724 packets, 366M bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT udp -- vnet2 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 ACCEPT tcp -- vnet2 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 0 0 ACCEPT udp -- vnet2 * 0.0.0.0/0 0.0.0.0/0 udp dpt:67 0 0 ACCEPT tcp -- vnet2 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:67 Type 2: Forwarding to a specific NIC only ----------------------------------------- Chain POSTROUTING (policy ACCEPT 273 packets, 26341 bytes) pkts bytes target prot opt in out source destination 0 0 MASQUERADE all -- * eth1 192.168.200.0/24 0.0.0.0/0 Chain FORWARD (policy ACCEPT 29 packets, 2244 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- eth1 vnet3 0.0.0.0/0 192.168.200.0/24 state RELATED,ESTABLISHED 0 0 ACCEPT all -- vnet3 eth1 192.168.200.0/24 0.0.0.0/0 0 0 REJECT all -- * vnet3 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 0 0 REJECT all -- vnet3 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable Chain INPUT (policy ACCEPT 76724 packets, 366M bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT udp -- vnet3 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 ACCEPT tcp -- vnet3 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 0 0 ACCEPT udp -- vnet3 * 0.0.0.0/0 0.0.0.0/0 udp dpt:67 0 0 ACCEPT tcp -- vnet3 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:67 Type 3: Forwarding to any active NIC ------------------------------------ Chain POSTROUTING (policy ACCEPT 273 packets, 26341 bytes) pkts bytes target prot opt in out source destination 16 1292 MASQUERADE all -- * * 192.168.122.0/24 0.0.0.0/0 Chain FORWARD (policy ACCEPT 29 packets, 2244 bytes) pkts bytes target prot opt in out source destination 44 20200 ACCEPT all -- * virbr0 0.0.0.0/0 192.168.122.0/24 state RELATED,ESTABLISHED 56 3676 ACCEPT all -- virbr0 * 192.168.122.0/24 0.0.0.0/0 0 0 REJECT all -- * virbr0 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 0 0 REJECT all -- virbr0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable Chain INPUT (policy ACCEPT 76724 packets, 366M bytes) pkts bytes target prot opt in out source destination 28 1728 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 5 1640 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:67 0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:67 So in summary: - Every single network type has the 4 INPUT rules for DHCP/DNS - Every single network type has catch all REJECT rules in FORWARD chain for both directions of traffic - A network forwarding to any device, has ACCEPT rules which allow through traffic associated with the virtual network IP range to/from any device - A network forwarding to a specific device, has ACCEPT rules which allow through traffic associated with the virtual network IP range to/from that specific device. - A network forwarding to any device, has MASQUERADE rule to translate source address which matches the virtual network & destined for any dev - A network forwarding to a specific device, has MASQUERADE rule to translate source address which matches the virutal network & destinaed for that specific device - There are no physdev matches needed. Hopefully at least one person has read this far through the email and still understands what is going on.... I'm attaching a patch which implements all this. BTW, there is also a bug in the vif-bridge script for Xen which adds a per-guest VIF physdev match rule. This needs to be removed too. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

4 12

[Libvir] [PATCH] Remote patch, 2007-04-04
by Richard W.M. Jones 04 Apr '07

04 Apr '07

This is a version of the remote patch -- I'm going to call it "oldremote" because it includes the SunRPC code which we agreed to drop in favour of just using XDR (see [1]). So this patch is just posted here for public record. It applies against the latest CVS. Rich. [1] https://www.redhat.com/archives/libvir-list/2007-March/thread.html#00333 -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)

1 0

[Libvir] Unified Xen patch (third and hopefully final version)
by Richard W.M. Jones 04 Apr '07

04 Apr '07

This is the third version of the unified Xen driver patch[1]. It includes Dan's fixes[2] and a minor fix of my own to fix compiles --without-xen. I've checked this and I'm happy with proposing it for inclusion in libvirt. Rich. [1] https://www.redhat.com/archives/libvir-list/2007-March/thread.html#00409 [2] https://www.redhat.com/archives/libvir-list/2007-April/msg00007.html -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)

3 3

[Libvir] [PATCH] Fix substitution of QEMUD_PID_FILE
by Richard W.M. Jones 04 Apr '07

04 Apr '07

This fixes the bug I raised in my previous email. Use AC_SUBST instead of AC_DEFINE because we want autoconf to substitute the value into the Makefile, not into config.h. Then add @QEMUD_PID_FILE@ to CFLAGS. This seems to be the correct thing to do, according to my understanding of http://tinyurl.com/34gtdj . Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)

2 4

[Libvir] xend_internal reads in bytes?
by Richard W.M. Jones 03 Apr '07

03 Apr '07

[Just an observation here - I'm busy with something else but may be able to take a closer look at this later.] Not only does xend_internal open a new connection for every HTTP request it makes, but it also reads the headers in as single bytes (but the body as a whole, presumably once it has Content-Length): connect(15, {sa_family=AF_FILE, path="/var/lib/xend/xend-socket"}, 27) = 0 write(15, "GET ", 4) = 4 write(15, "/xend/node/", 11) = 11 write(15, " HTTP/1.1\r\n", 11) = 11 write(15, "Host: localhost:8000\r\nAccept-Enc"..., 100) = 100 read(15, "H", 1) = 1 read(15, "T", 1) = 1 read(15, "T", 1) = 1 read(15, "P", 1) = 1 read(15, "/", 1) = 1 read(15, "1", 1) = 1 read(15, ".", 1) = 1 read(15, "1", 1) = 1 read(15, " ", 1) = 1 read(15, "2", 1) = 1 read(15, "0", 1) = 1 read(15, "0", 1) = 1 read(15, " ", 1) = 1 read(15, "O", 1) = 1 read(15, "K", 1) = 1 read(15, "\r", 1) = 1 read(15, "\n", 1) = 1 read(15, "C", 1) = 1 read(15, "o", 1) = 1 read(15, "n", 1) = 1 read(15, "t", 1) = 1 [...] read(15, "\n", 1) = 1 read(15, "\r", 1) = 1 read(15, "\n", 1) = 1 read(15, "(node (system Linux) (host oiras"..., 747) = 747 close(15) = 0 Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)

2 1

[Libvir] [PATCH] Add help to qemu daemon, and a small bug
by Richard W.M. Jones 03 Apr '07

03 Apr '07

This patch adds command-line help to the libvirt qemu daemon. One small bug: On my machine at least, QEMUD_PID_FILE is defined as (literally) "${prefix}/var/run/libvirt_qemud.pid". It shouldn't have the "${prefix}" at the beginning, and even if that is fixed it looks like this could result in a path like "/usr/var/run/..." which would be wrong. I fiddled with AC_DEFINE_UNQUOTED and the quoting of the string itself inside configure.in and I couldn't work out how to get the quoting right. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)

1 0

[Libvir] Added python binding for autostart flag
by Daniel P. Berrange 03 Apr '07

03 Apr '07

The vir{Domain,Network}GetAutostart() methods are missing from the python binding because they used an int * as a parameter. The attached patch adds a hand-written impl of these two APIs for the python binding. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 1

[Libvir] Unified Xen patch (incomplete, for discussion)
by Richard W.M. Jones 02 Apr '07

02 Apr '07

I've spent the last day or so producing a unified Xen patch. In such a model a connection contains only a single underlying driver, and it is the responsibility of the (unified) Xen driver to try all the different methods it knows. Attached is an incomplete patch for this, for discussion, plus the two extra files of the unified driver itself (for some reason CVS won't give me a diff including these added files). Some points to note: The new structure of the drivers is: <pre> libvirt.c | +------- xen_unified.c | | | +--- xen_internal.c (hypervisor) | | | +--- proxy_internal.c * (proxy) | | | +--- xend_internal.c * (XenD) | | | +--- xs_internal.c (XenStore) | | | +--- xm_internal.c * (inactive domains) | +-------- qemu_internal.c * | +-------- test.c * = not updated yet, so these don't compile </pre> I haven't renamed the Xen sub-drivers. That's really to make the patch easier to read. There is definitely a case for renaming the drivers more logically to reflect the structure above. All Xen-specific hacks in libvirt.c have been moved to xen_unified.c Error handling in the case where a driver doesn't support a libvirt function is now considerably better. Each driver keeps its private data private. At the moment xen_unified pretty much does the "try the drivers in a loop until one succeeds" strategy which used to be in libvirt.c. There is a case for making it do direct calls to the "right" driver, but for simplicity I haven't gone that far. Again for simplicity the Xen sub-drivers still use struct virDriver. They should use their own custom 'struct virXenDriver' or whatever. The effects of this are slight but noticable - some parameters are now no longer used in the sub-drivers, so marked ATTRIBUTE_UNUSED. There is also a single networkDriver pointer in the connect struct. We should modify the functions to handle the case where this is NULL because we couldn't bring up the network functions (all network functions in this case would just return an error). libvirt in CVS fails to run if libvirtd isn't up. I won't be able to get back to this before tomorrow afternoon, so plenty of time for discussion! Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)

3 8