- Devel - libvirt List Archives

[libvirt] [PATCH]: (trivial) getpwuid is not OOM
by Guido Günther 07 Oct '08

07 Oct '08

Hi, we shouldn't print an oom error message when actually getpwuid failed. Cheers, -- Guido

2 1

[libvirt] When bridge doesn't exist
by Anton Protopopov 07 Oct '08

07 Oct '08

Assume that we want to add a bridge to LAN to a guest. We saying to libvirt: ... <interface type="bridge"> <source bridge="BRIDGE"> </interface> ... What is the right behaviour of libvirt in case bridge BRIDGE doesn't exist---return an error or try to create that bridge? If it is the former, then who must create that bridge?

1 0

[libvirt] Routed Networking - Ubuntu Hardy KVM and LibVirt
by Barry Robinson 07 Oct '08

07 Oct '08

Gday, I have been searching for information on how to configure KVM guest OS' to do simple routing from their associated vnetX address to the host machine's ethernet network subnet (lets say eth0/192.168.0.0/24). I understand that by default the clients are NAT'ed to the Host's adapter. This is a handy feature, but it does not suit the setup I am trying to apply. Basically, I am trying to do simple routing from the host subnet (192.168.0.0/24) to the client's subnet (192.168.17.0/24), and back again. So I can talk to 192.168.0.0/24 addresses and they can talk to 192.168.17.0/24 (routing rule has been added so this is possible). There should be no NAT involved. The following is about as close as I have come to getting this solution. However, I still need to add in the iptables -A FORWARD -i vnetX -o eth0 -j ACCEPT rule in after the machine is booted. Is it possible to do this as part of the script process, or is there a post-ifup script that can be run? /etc/libvirt/qemu/network/routed-net.xml: <network> <name>routed-net</name> <uuid></uuid> <bridge name="virbr%d" /> <ip address="192.168.32.1" netmask="255.255.255.0"> <dhcp> <range start="192.168.32.33" end="192.168.32.63" /> </dhcp> </ip> </network> I have tried using the <forward='routed' /> option (under the bridge name option). This does add the forward rules, but for some reason still applies the MASQUERADE rule to the 192.168.17.0/24 network. (eg. 0 0 MASQUERADE all -- * * 192.168.32.0/24 0.0.0.0/0 ) libvirtd seems to hide it's firewall rulesets pretty well, cause I can't even find them to manually add/remove rules. Not in any place obvious (that I can find), like /etc. Any help would be appreciated. Apologies if this topic has been covered... can't find it anywhere using Google. Cheers, Barry Linseed Technologies Open Source IT Solutions Phone: 0415131452 Email: brobinson(a)linseed.com.au Website: http://www.linseed.com.au

2 1

[libvirt] PATCH: 0 of 5: Remove all linked lists
by Daniel P. Berrange 07 Oct '08

07 Oct '08

I've been doing some proof of concept work to make the libvirtd daemon multi-threaded, and this in turns mean that the QEMU / LXC / OpenVZ drivers need to have some degree of locking on their internal data structures. Unforatunately the internal domain/network/storage APIs make extensive use of linked lists for tracking objects. This makes it incredibly hard to do fine grained locking of individual objects - eg, deleting one object requires locking the object it points to, and one the pointing to it in the linked list, as well as the list itself. This would be so complex we'd inevitably introduce locking bugs. So the series of patches which follow replace all linked lists with explicitly sized arrays. This means I only need 2 levels of locks, one on the driver object, and one of the domain/network/storage object being manipulated. The semantics for this are nice & easy to define. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

2 13

[libvirt] [PATCH] Centralize use of DEBUG macros
by Cole Robinson 06 Oct '08

06 Oct '08

Currently the DEBUG and DEBUG0 macros are duplicated in every file that uses them. This patch moves the macros to internal.h, removes the needless duplication, and now every file gets them for free. Seems to work as expected in my testing. Thanks, Cole

3 6

[libvirt] [PATCH] Slim xmllint test output
by Cole Robinson 06 Oct '08

06 Oct '08

This patch simply slims down the output from the xmllint tests to not overrun a single line, only printing the relevant information about the xml file (parent directory and name, not fully qualified path). Purely cosmetic, but more useful IMO. Thanks, Cole

2 2

[libvirt] [PATCH] Fix possible segfault if starting qemu vm with an inactive virtual network
by Cole Robinson 06 Oct '08

06 Oct '08

The attached patch fixes a possible segfault if trying to start a domain which tries to use an inactive virtual network. We should explicitly catch that error and report it, but that's a separate patch. Thanks, Cole

3 3

[libvirt] [PATCH] use C99 initializers for virState
by Guido Günther 06 Oct '08

06 Oct '08

Hi, attached patch uses C99 initializers for virStateDriver. Makes reading easier and extending the structure less error prone. -- Guido

3 2

[libvirt] [PATCH] fix build in separate build-dir
by Guido Günther 06 Oct '08

06 Oct '08

Hi, building in a separate build dir is currently broken since the Makefile is looking for libvirt.policy in the wrong location. Fix attached. Cheers, -- Guido

2 1

[libvirt] [discuss] The new cgroup patches for libvirt
by Balbir Singh 03 Oct '08

03 Oct '08

Hi, Everyone, I've seen a new set of patches from Dan Smith, which implement cgroup support for libvirt. While the patches seem simple, there are some issues that have been pointed out in the posting itself. I hope that libvirt will switch over (may be after your concerns are addressed and definitely in the longer run) to using libcgroups rather than having an internal implementation of cgroups. The advantages of switching over would be using the functionality that libcgroup already provides libcgroups (libcg.sf.net) provides 1. Ability to configure and mount cgroups and controllers via initscripts and a configuration file 2. An API to control and read cgroups information 3. Thread safety around API calls 4. Daemons to automatically classify a task based on a certain set of rules 5. API to extract current cgroup classification (where is the task currently in the cgroup hierarchy) While re-implementing might sound like a cool thing to do, here are the drawbacks 1. It leads to code duplication and reduces code reuse 2. It leads to confused users I understand that in the past there has been a perception that libcgroups might not yet be ready, because we did not have ABI stability built into the library and the header file had old comments about things changing. I would urge the group to look at the current implementation of libcgroups (look at v0.32) and help us 1. Fix any issues you see or point them to us 2. Add new API or request for new API that can help us integrate better with libvirt -- Balbir

4 11