- 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

[libvirt] [PATCH 0 of 2] [RFC] Add cgroup manipulation and LXC driver support
by Dan Smith 03 Oct '08

03 Oct '08

This patch set adds basic cgroup support to the LXC driver. It consists of a small internal cgroup manipulation API, as well as changes to the driver itself to utilize the support. Currently, we just set a memory limit and the allowed devices list. The cgroup.{c,h} interface can be easily redirected to libcgroup in the future if and when the decision to move in that direction is made. Some discussion on the following points is probably warranted, to help determine how deep we want to go with this internal implementation, in terms' of supporting complex system configurations, etc. - What to do if controllers are mounted in multiple places - What to do if memory and device controllers aren't present - What to do if the root group is set for exclusive cpuset behavior Some additional caveats are noted per-patch as well.

3 16

[libvirt] [PATCH 0 of 2] Add cgroup manipulation and LXC driver support
by Dan Smith 03 Oct '08

03 Oct '08

This is my updated set for cgroup manipulation. I think I have addressed all of the concerns and comments so far. There are no major caveats I'm aware of with this round.

3 15

[libvirt] [PATCH] Clean up some uses qemudDebug
by Cole Robinson 02 Oct '08

02 Oct '08

The patch cleans up some uses of qemudDebug, moving them over to use the DEBUG macros. There are still lots of uses of qemudDebug in qemud/*, but I don't know if they can/should be moved over to use DEBUG. Thanks, Cole

1 0

[libvirt] [PATCH] Fix > 1 char device for qemu VM
by Cole Robinson 02 Oct '08

02 Oct '08

Trying to start a qemu guest with more than 1 character device (serial or parallel, doesn't count for console) always times out. There was an error in the code that would strip the pty path qemu spits out, which confused the parsing after being called more than twice. The attached patch fixes this. I verified that guests with 0, 1, and 2 serial devices all boot fine. Thanks, Cole

3 4

[libvirt] ./configure issues
by David Brain 01 Oct '08

01 Oct '08

Hi, Trying to compile libvirt on Centos 5.2, get the following when running configure: .... checking for struct _xmlURI.query_raw... no checking gnutls/gnutls.h usability... yes checking gnutls/gnutls.h presence... yes checking for gnutls/gnutls.h... yes checking for gnutls_handshake in -lgnutls... no configure: error: You must install the GnuTLS library in order to compile and run libvirt It's definitely installed: Installed Packages gnutls.x86_64 1.4.1-3.el5_1 installed gnutls.i386 1.4.1-3.el5_1 installed gnutls-devel.i386 1.4.1-3.el5_1 installed gnutls-devel.x86_64 1.4.1-3.el5_1 installed gnutls-utils.x86_64 1.4.1-3.el5_1 installed xmlsec1-gnutls.x86_64 1.2.9-8.1 installed xmlsec1-gnutls.i386 1.2.9-8.1 installed xmlsec1-gnutls-devel.i386 1.2.9-8.1 installed xmlsec1-gnutls-devel.x86_64 1.2.9-8.1 installed Thanks, David.

2 2

[libvirt] Overriding vnetN with the <target> element in xml configuration not working
by Ahmed Medhat 01 Oct '08

01 Oct '08

Hello, I've been trying to dedicated a vnet interface to each virtual machine in order to be able to monitor their traffic, looking at http://libvirt.org/formatdomain.html#elementsNICSBridge it says that a virtual machine could have a specific vnetN specified in the xml element <target>, like <target dev='vnet7'/> . Unfortunately its not working and still it comes with vnet(current+1), here's my configuration for a qemu-kvm guest. <interface type='bridge'> <source bridge='virbr0'/> <target dev='vnet7'/> <mac address='00:16:3e:6c:1f:9d'/> </interface> I'm running on F9 x86_64, libvirt-0.4.4-2.fc9.x86_64 libvirt-python-0.4.4-2.fc9.x86_64 kvm-65-7.fc9.x86_64 qemu-0.9.1-6.fc9.x86_64 I haven't yet tested this with a RHEL box to know if it is version specific issue to open a bugzilla report, any input is appreciated. /* || Thanks, Ahmed Medhat || ultimatetux [at] gmail [dot] com || +2-012-4184768 || In a world without walls and fences, who needs Windows and Gates? */

2 4

[libvirt] [PATCH] fix network interface parsing
by Jim Fehlig 01 Oct '08

01 Oct '08

Hi All, While testing libvirt 0.4.5 and 0.4.6 I noticed only one network interface in domain xml for a xen guest regardless of number actually assigned. Turns out the last interface parsed is always placed on head of nets list instead of appending to tail. Patch attached. Cheers, Jim

2 1

Re: [libvirt] Release of libvirt-0.4.6
by Dale Bewley 30 Sep '08

30 Sep '08

----- "Daniel Veillard" <veillard(a)redhat.com> wrote: > On Fri, Sep 26, 2008 at 09:17:43AM -0700, Dale Bewley wrote: > > I see that 0.4.5 for F9 just made it through bodhi, but there is no > F8 build in bodhi. > > https://admin.fedoraproject.org/updates/F9/FEDORA-2008-7768 > > > > Please release a 0.4.6 F8 update for the benefit of us using F8 > dom0. I'm stuck on non-HVM hardware for the foreseeable future, so KVM > isn't an option for me. And F9 isn't an option for me since there is > no dom0 support. > > Well it wasn't clear that the new release would really fixes things > for the Xen users (which is as we all expect the community still > using Fedora 8), is there anything in particular you were looking for > in this specific release ? It was looking more risky than potentially > useful to update there. > > Daniel I'm on the last F8 update (0.4.4) and my problem[1] I would love to see fixed is the desynchronization that occurs between libvirtd and xend if I shutdown a guest. Until xend is restarted, libvirt utils can't find the domU. [1] https://www.redhat.com/archives/fedora-xen/2008-June/msg00059.html There were a lot of fixes listed[2] for 0.4.5. I don't know if they fix this problem, but some of them sound like they would come close in the code. [2] https://www.redhat.com/archives/libvir-list/2008-September/msg00186.html -- Dale Bewley - Unix Administrator - Shields Library - UC Davis GPG: 0xB098A0F3 0D5A 9AEB 43F4 F84C 7EFD 1753 064D 2583 B098 A0F3

2 1

Re: [libvirt] [PATCH] fix creating of openvz bridge device
by Evgeniy V. Sokolov 29 Sep '08

29 Sep '08

> > This behaviour contradicts with description found in docs (in which > <source> tag specify interface in host, not in container). I think, > the previous bridge must be specified as > <interface type='bridge'> > <mac address='00:16:3e:34:21:9e'/> > - <source bridge='eth10'/> > + <target dev='eth10'/> > </interface> > > You are right. It is bug. > > Well, here is the patch, that fixes that behaviour. Your patch is half of fix. It require to fix openvzReadNetworkConf() in openvz_conf.c. > > P.S. Are someone going to implement > <interface type='bridge'> > ... > <source bridge="..."> > ... > </interface> > part of openvz driver? :) I plan to implement it in a month. It will be fine if you are ready to develop the feature.

2 2

[libvirt] Release of libvirt-0.4.6
by Daniel Veillard 29 Sep '08

29 Sep '08

As promised after we discovered a couple of serious bugs in 0.4.5, a new release was in order, so I pushed 0.4.6 yesterday evening, it's available as usual at ftp://libvirt.org/libvirt/ There is no major change in this release, just the bug fixes a few improvements and some cleanup: * Documentation: - fix some comments in API (Anton Protopopov) - cleanup and extension of bindings and windows pages (Richard Jones) * Portability: - missing include file (Richard Jones) * Bug fixes: - avoid a segfault if missing qemu emulator (Cole Robinson) - reading vncdisplay from xend domain (Cole Robinson) - segfault in OpenVZ (Evgeniy Sokolov) - fix parsing of pool without a source (Chris Lalancette and Daniel Berrange) * Improvements: - add storage disk volume delete (Cole Robinson) - KVM dynamic max CPU detection (Guido Günther) - spec file improvement for minimal builds (Ben Guthro) - improved error message in XM configuration module (Richard Jones) - network config in OpenVZ support (Evgeniy Sokolov) - enable stopping a pool in logical storage backend and cleanup deletion of pool (Chris Lalancette) * Cleanups: - deadcode removal (Nguyen Anh Quynh) - fix one test case (Daniel Berrange) - various strings and space cleanups (Daniel Berrange) - structure initialization cleanup (Chris Lalancette) Thanks everybody for the patches and feedback ! 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 6

[libvirt] [PATCH] fix creating of openvz bridge device
by Anton Protopopov 26 Sep '08

26 Sep '08

> > > This behaviour contradicts with description found in docs (in which >> <source> tag specify interface in host, not in container). I think, >> the previous bridge must be specified as >> <interface type='bridge'> >> <mac address='00:16:3e:34:21:9e'/> >> - <source bridge='eth10'/> >> + <target dev='eth10'/> >> </interface> >> > You are right. It is bug. Well, here is the patch, that fixes that behaviour. P.S. Are someone going to implement <interface type='bridge'> ... <source bridge="..."> ... </interface> part of openvz driver? :)

1 0

[libvirt] openvz support in libvirt
by Anton Protopopov 26 Sep '08

26 Sep '08

Hello. To start with, I have the following questions: Does libvirt support the xml format for openvz driver described in the next thread? http://www.redhat.com/archives/libvir-list/2008-July/msg00312.html (I think, that it does not. But will it support it in future? :)) What libvirt functionality does openvz driver support? (Openvz does not mentioned in http://libvirt.org/hvsupport.html) Anton.

4 6

[libvirt] [PATCH] Some virsh(1) man page fixes
by Mark McLoughlin 25 Sep '08

25 Sep '08

Hi, Just looking at virsh(1), I noticed a reference to xm that should have referred to virsh. Found some other things as I fixed: - Explanation of run states was after the bit about the freecell command - State codes like 'r' for running aren't displayed with virsh - Reference to "xm pause" instead of "virsh suspend" - "virsh create" explanation confusing and references "xm create"; fixed it up to what I think was the original intention - Some of the command sections were over-indented - References to xmdomain.cfg - Make "see also" reference virt-install, virt-top, virt-mem and virt-df manpages rather than xmdomain.cfg and xentop Cheers, Mark. Index: docs/virsh.pod =================================================================== RCS file: /data/cvs/libvirt/docs/virsh.pod,v retrieving revision 1.17 diff -u -p -r1.17 docs/virsh.pod --- docs/virsh.pod 1 Aug 2008 14:30:41 -0000 1.17 +++ docs/virsh.pod 25 Sep 2008 10:12:48 -0000 @@ -148,65 +148,62 @@ B<virsh> list Name is the name of the domain. ID the domain numeric id. - State is the run state (see below). - -=item B<freecell> optional I<cellno> - -Prints the available amount of memory on the machine or within a -NUMA cell if I<cellno> is provided. +State is the run state (see below). =over 4 B<STATES> +The State field lists 6 states for a domain, and which ones the +current domain is in. -The State field lists 6 states for a Xen Domain, and which ones the -current Domain is in. - -=item B<r - running> +=item B<running> The domain is currently running on a CPU -=item B<b - blocked> +=item B<blocked> The domain is blocked, and not running or runnable. This can be caused because the domain is waiting on IO (a traditional wait state) or has gone to sleep because there was nothing else for it to do. -=item B<p - paused> +=item B<paused> The domain has been paused, usually occurring through the administrator -running B<xm pause>. When in a paused state the domain will still +running B<virsh suspend>. When in a paused state the domain will still consume allocated resources like memory, but will not be eligible for -scheduling by the Xen hypervisor. +scheduling by the hypervisor. -=item B<s - shutdown> +=item B<shutdown> The domain is in the process of shutting down, i.e. the guest operating system has been notified and should be in the process of stopping its operations gracefully. -=item B<c - crashed> +=item B<crashed> The domain has crashed, which is always a violent ending. Usually this state can only occur if the domain has been configured not to -restart on crash. See L<xmdomain.cfg> for more info. +restart on crash. -=item B<d - dying> +=item B<dying> The domain is in process of dying, but hasn't completely shutdown or crashed. =back +=item B<freecell> optional I<cellno> + +Prints the available amount of memory on the machine or within a +NUMA cell if I<cellno> is provided. + =head1 DOMAIN COMMANDS The following commands manipulate domains directly, as stated previously most commands take domain-id as the first parameter. The I<domain-id> can be specified as an short integer, a name or a full UUID. -=over 4 - =item B<autostart> optional I<--disable> I<domain-id> Configure a domain to be automatically started at boot. @@ -219,7 +216,7 @@ Connect the virtual serial console for t =item B<create> I<FILE> -Create a domain from an XML <file> an easy way to create one if you have a pre-existing xen guest created via B<xm> create <XMLFILE>. +Create a domain from an XML <file>. An easy way to create the XML <file> is to use the B<dumpxml> command to obtain the definition of a pre-existing guest. B<Example> @@ -303,9 +300,8 @@ command run from the console. The comma executed the reboot action, which may be significantly before the domain actually reboots. -For xen vm the behavior of what happens to a domain when it reboots is set by the -I<on_reboot> parameter of the xmdomain.cfg file when the domain was -created. +The exact behavior of a domain when it reboots is set by the +I<on_reboot> parameter in the domain's XML definition. =item B<restore> I<state-file> @@ -360,9 +356,8 @@ to perform graceful shutdown, so there i succeed, and may take a variable length of time depending on what services must be shutdown in the domain. -For a xen guest vm the behavior of what happens to a domain when it reboots is set by the -I<on_shutdown> parameter of the xmdomain.cfg file when the domain was -created. +The exact behavior of a domain when it shuts down is set by the +I<on_shutdown> parameter in the domain's XML definition. =item B<start> I<domain-name> @@ -404,8 +399,6 @@ and I<cpulist> is a comma separated list Output the IP address and port number for the VNC display. If the information is not available the processes will provide an exit code of 1. -=back - =head1 DEVICES COMMANDS The following commands manipulate devices associated to domains. @@ -414,8 +407,6 @@ To better understand the values allowed reading the documentation at L<http://libvirt.org/format.html> on the format of the device sections to get the most accurate set of accepted values. -=over 4 - =item B<attach-device> I<domain-id> I<FILE> Attach a device to the domain, using a device definition in an XML file. @@ -456,8 +447,6 @@ I<type> can be either I<network> to indi It is recommended to use the I<mac> option to distinguish between the interfaces if more than one are present on the domain. -=back - =head1 VIRTUAL NETWORKS COMMANDS The following commands manipulate networks. Libvirt has the capability to @@ -467,8 +456,6 @@ see the documentation at L<http://libvir of the command for virtual networks are similar to the one used for domains, but the way to name a virtual network is either by its name or UUID. -=over 4 - =item B<net-autostart> I<network> optional I<--disable> Configure a virtual network to be automatically started at boot. @@ -528,29 +515,23 @@ Undefine the configuration for an inacti Convert a network name to network UUID. -=back - =head1 ENVIRONMENT -=over 4 - =item VIRSH_DEFAULT_CONNECT_URI The hypervisor to connect to by default. Set this to a URI, in the same format as accepted by the B<connect> option. -=back - =head1 SEE ALSO -L<xm(1)>, L<xmdomain.cfg(5)>, L<xentop(1)> , L<http://www.libvirt.org/> +L<virt-install(1)>, L<xm(1)>, L<virt-top(1)>, L<virt-mem(1)>, L<virt-df(1)>, L<http://www.libvirt.org/> =head1 AUTHOR Andrew Puch <apuch @ redhat.com> Daniel Veillard <veillard @ redhat.com> - Based on the xm man paged by + Based on the xm man page by: Sean Dague <sean at dague dot net> Daniel Stekloff <dsteklof at us dot ibm dot com>

3 3

[libvirt] Some Windows binaries
by Richard W.M. Jones 25 Sep '08

25 Sep '08

This is not an official distribution, but if you add the following repository to any Fedora 8 / 9 or Rawhide box, then you will get the latest MinGW packages. The mingw32-libvirt package contains Windows binaries, libvirt-0.dll and virsh.exe. http://www.annexia.org/tmp/mingw/fedora-9/i386/ or http://www.annexia.org/tmp/mingw/fedora-9/x86_64/ Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top

1 0

[libvirt] [PATCH] avoid problem for parallel buld in python subdir
by Daniel Veillard 25 Sep '08

25 Sep '08

Seems very hard to hit but one could get a problem with generation of the python bindings, https://bugzilla.redhat.com/show_bug.cgi?id=463733 the enclosed patch is by Dan Berrange 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/

2 1

[libvirt] [PATCH] Sanitize qemu monitor reads
by Cole Robinson 24 Sep '08

24 Sep '08

Reading from the qemu monitor pulls in a whole bunch of useless control characters. For example, sending the command 'somecomm' to the monitor returns: somecomm unknown command: 'somecomm' (qemu) Which is 36 characters, however we end up reading over 200. The amount we read actually grows quadratically as a function of the command length. This prevents us from reporting monitor output to the user (incase some command fails) and seriously diminishes the value of the domain logfiles. The attached patch tries to sanitize this a bit. After reading all the output, we search for the first occurrence of the full command string. If found, we search from there for the first newline (which marks the beginning of the monitor response). If these are found, we only return the command, and everything after the newline. If only the command is found, we just drop everything before it. I've tested this on f9 and f8, there didn't seem to be any problems. I think this should be pretty future proof as well, so we hopefully won't be throwing out anything valuable. Thanks, Cole

2 2

[libvirt] [PATCH] Log virRun command output, return with error
by Cole Robinson 24 Sep '08

24 Sep '08

The attached patch adds some extra logging to the virRun command. The full argv is now logged with DEBUG, as well as the commands stdout and stderr (if anything is found). Also, if the command returns an error, we raise the stderr content with the reported error msg. This will significantly help with debugging certain issues, particularly with the storage driver which makes heavy use of virRun. Thanks, Cole

4 3

[libvirt] [PATCH] fix spec file when building without qemu
by Daniel Veillard 24 Sep '08

24 Sep '08

While trying to build libvirt 0.4.6 for Fedora, I got an error when building on ppc64 which is the only architecture where qemu support is disabled. Files which were conditional to qemu were installed nonetheless in the build root: Checking for unpackaged file(s): /usr/lib/rpm/check-files /builddir/build/BUILDROOT/libvirt-0.4.6-1.fc10.ppc64 error: Installed (but unpackaged) file(s) found: /etc/libvirt/qemu/networks/autostart/default.xml /etc/libvirt/qemu/networks/default.xml /usr/share/augeas/lenses/libvirtd_qemu.aug /usr/share/augeas/lenses/tests/test_libvirtd_qemu.aug The following patch doesn't look ideal but allows to fix the problem. 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/

2 1

[libvirt] [PATCH 3/3]: Implement logical stopPool and deletePool more fully
by Chris Lalancette 23 Sep '08

23 Sep '08

This patch does a few things. 1) Clean up a bunch of comments which I believe are no longer valid, or just slightly wrong 2) Enable the stopPool command for the logical backend. The comment in the code worries about a situation where you try to "stop" the logical volume that your rootfs is on, for example. However, that situation is already taken care of by the LVM tools; if the logical volume you try to stop is active, it will throw an error saying that the LV is in use, and won't stop it. Therefore, it should be pretty safe to try to stop logical volumes; it will fail for ones that are in use, but will stop volumes that have been properly torn down ahead of time. 3) In deletePool, remove the -f from the vgremove command. Besides the fact that we probably don't usually want to force things, the -f option doesn't exist prior to F-9, so this would fail on F-8, RHEL-5, etc. 4) In deletePool, implement pvremove of all source devices. Note that this should also be relatively safe; it will only pvremove devices that we had previously pvcreate'd in createPool, which means they were all under control of libvirt. It will not pvremove devices on an LVM that you previously created, but were just scanning with libvirt. Signed-off-by: Chris Lalancette <clalance(a)redhat.com>

3 5

[libvirt] Monitoring guest state (xen hvms)
by Matthew Donovan 23 Sep '08

23 Sep '08

I would like to be able to monitor the state of a Xen guest OS via virDomainGetInfo (and Domain.getInfo() in the Java bindings.) When I start, pause, and resume the guest via the libvirt API, it works as expected. However, if I shutdown the guest vm by opening a VNC window and actually selecting "shutdown" via the OS's favorite mechanism (e.g. Start -> Shutdown in Windows), I lose the state. In other words, virDomainGetInfo() returns NOSTATE. There was some conversation on this list a while ago about virDomainGetInfo() returning NOSTATE so I added some code and recompiled libvirt to print the value of the domain_flags returned from the xen hypervisor. _When_ it printed this value, it was always zero. I stress the "when" part because after the OS completely shuts down, the value of domain_flags is no longer printed. I started virsh and did a list of VMs and the guest is gone. However, if I look at "xm list", the domain is still there. Is there a reliable way to monitor the guest state when the guest is shutdown internally (i.e. via the guest OS itself)? Thanks -matthew

1 0

[libvirt] [RFC] Events API
by David Lively 23 Sep '08

23 Sep '08

Hi - We have some folks looking into the implementation of events (just VM state transition events, for now) in libvirtd. I've been assuming that events will be XML strings, something like: <event type="domain-state-transition" timestamp="xxxxx"> <domain-id>22</domain-id> <old-state>nostate</old-state> <new-state>running</new-state> </event> where the contents of the <event> element are determined by the event type, and the attributes type and timestamp are required. Originally, I was thinking one would listen for events by registering a callback, something like: int virConnectAddEventHandler(virConnPtr conn, char **filter, virEventHandler handler, void *arg) where filter is either NULL, indicating interest in all events, or else a NULL-terminated vector of event type names, allowing filtering by event type. void handler(conn, const char *eventXML, arg) would be called for each matching event. I'm a little concerned that a vector of event type names isn't really adequate for specifying a filter. Does this need to be more general (XPathString exprs??) But my larger concern is that an asynchronous callback mechanism (as proposed above) assumes the presence of some thread / process from which to make the callbacks. This works fine in the libvirtd context, but not outside of it. For instance, we build a "client only" version of libvirt with ONLY the remote driver, which currently doesn't require pthreads at all. Introducing asynchronous callbacks into the API means pthreads is now required for this. I'm not sure how much requiring this extra thread matters. If it does, we could always define a synchronous delivery mechanism instead. For instance, we could have a virDeliverEvents(conn) call to make the callbacks for any outstanding events. Or we could just dispense with callbacks altogether, and return a readable (pipe) fd from which the client can read events. Comments?? Dave P.S. We'll also need an internal API for sending events (most likely, an extension of the existing virEvent stuff), but let's get the basic shape of the external interface agreed upon first.

7 19

[libvirt] [PATCH 1/3]: Cleanup the virStorageDriver structs
by Chris Lalancette 23 Sep '08

23 Sep '08

This patch just cleans up the virStorageDriver structs so that they use the .functionPointer = functionname syntax of gcc. This makes it much easier to grep in the code later. This patch also re-arranges the order of the function pointers in remote_internal so that it matches the definition of virStorageDriver in src/driver.h. While not strictly necessary, it does make it a little more sane when looking at it in the future. Signed-off-by: Chris Lalancette <clalance(a)redhat.com>

4 5

[libvirt] [PATCH 2/3]: Fix storage_conf parsing for empty <source>
by Chris Lalancette 22 Sep '08

22 Sep '08

This patch fixes a minor bug in the storage_conf parsing. Creating logical volume pool XML without a source definition is a valid operation (for example, if you just want to scan an already existing LVM group), but this bug was making the parser reject that XML. Bugfix from Dan Berrange, tested by me. Signed-off-by: Chris Lalancette <clalance(a)redhat.com>

4 3

[libvirt] [PATCH] Add libvirt.h to ignore files
by James Morris 22 Sep '08

22 Sep '08

Shouldn't libvirt.h be ignored by SCMS ? ---- libvirt.h is automatically generated: it should be ignored by SCM tools. Signed-off-by: James Morris <jmorris(a)namei.org> --- diff --git a/include/libvirt/.cvsignore b/include/libvirt/.cvsignore index 282522d..7bd42da 100644 --- a/include/libvirt/.cvsignore +++ b/include/libvirt/.cvsignore @@ -1,2 +1,3 @@ Makefile Makefile.in +libvirt.h diff --git a/include/libvirt/.gitignore b/include/libvirt/.gitignore index 282522d..7bd42da 100644 --- a/include/libvirt/.gitignore +++ b/include/libvirt/.gitignore @@ -1,2 +1,3 @@ Makefile Makefile.in +libvirt.h

2 1

[libvirt] [PATCH] read network config in OpenVZ driver
by Evgeniy Sokolov 22 Sep '08

22 Sep '08

This patch add possibility to load network configuration for container in OpenVZ driver. It support routing network and bridge devices. This types is currently supported in create/define command. Also, patch contain fix to small bug in openvzReadConfigParam method.

4 9

RE: [libvirt] pausing / unpausing guests with libvirt
by Matthew Donovan 22 Sep '08

22 Sep '08

Looks like that did it. I can pause and resume Linux and Windows guests with this method. Thanks a lot! -matthew > -----Original Message----- > From: Daniel P. Berrange [mailto:berrange@redhat.com] > Sent: Monday, September 22, 2008 4:17 AM > To: Matthew Donovan > Cc: libvir-list(a)redhat.com > Subject: Re: [libvirt] pausing / unpausing guests with libvirt > > On Sun, Sep 21, 2008 at 05:16:32PM -0400, Matthew Donovan wrote: > > > > DEBUG: libvirt.c: virDomainCreate (domain=0x92bd1e0) > > DEBUG: libvirt.c: virDomainSuspend (domain=0x92bd1e0) > > virDomainSuspend() failed: 0 > > I think this is a bug in the Xen driver - the virDomainCreate > api is not updating the internal 'id' parameter of the virDomainPtr > object, so when you then call virDomainSuspend() with the same > virDomainPtr it doesn't have the id it needs > > The easy workaround is to just get rid of your existing dom object > and lookup a new one with 'virDomainLoopByUUID' after starting it. > > virDomainPtr dom; > char uuid[VIR_UUID_BUFLEN]; > > virDomainCreate(dom); > > virDomainGetUUID(dom, uuid); > virDomainFree(dom); > dom = virDomainLookupByUUID(conn, uuid); > > virDomainSuspend(dom); > > 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 :| >

1 0

RE: [libvirt] pausing / unpausing guests with libvirt
by Matthew Donovan 22 Sep '08

22 Sep '08

> Is it possible you could isolate whether the problem is with libvirt > or with the Java bindings? One way would be to shell out to 'virsh' > just to see if virsh fails to change the state (ie. a libvirt/C) or if > the problem is in the Java bindings. > > Pausing/resuming Xen domains is a very common and well-tested > operation so I would be surprised if it's a libvirt problem, but you > never know ... Using following C code does not work. The domain starts but does not suspend. When I call virConnGetLastError() error->code is 0 and error->message is NULL. I ran my code with LIBVIRT_DEBUG=1. The output is below the C code. I was able to suspend the guest with virsh. The guest was started with my C code below. You should be able to suspend the guest at any point, correct? virsh # suspend 65 DEBUG: libvirt.c: virDomainLookupByID (conn=0x882f208, id=65) DEBUG: hash.c: __virGetDomain (New hash entry 0x8846808) DEBUG: libvirt.c: virDomainSuspend (domain=0x8846808) Domain 65 suspended DEBUG: libvirt.c: virDomainFree (domain=0x8846808) DEBUG: hash.c: virUnrefDomain (unref domain 0x8846808 Linux2 1) DEBUG: hash.c: virReleaseDomain (release domain 0x8846808 Linux2) DEBUG: hash.c: virReleaseDomain (unref connection 0x882f208 xen:/// 2) Thanks -matthew #include <stdio.h> #include <unistd.h> #include <libvirt/libvirt.h> #include <libvirt/virterror.h> const char* xml = "<domain type='xen'>" "<name>Linux2</name>" "<os>" "<type>hvm</type>" "<loader>/usr/lib/xen/boot/hvmloader</loader>" "<boot dev='hd'/>" "</os>" "<memory>500000</memory>" "<vcpu>1</vcpu>" "<on_shutdown>shutdown</on_shutdown>" "<on_reboot>restart</on_reboot>" "<on_crash>restart</on_crash>" "<features>" "<pae/>" "<acpi/>" "<apic/>" "</features>" "<devices>" "<emulator>/usr/lib/xen/bin/qemu-dm</emulator>" "<input type='tablet' bus='usb'/>" "<graphics type='vnc' autoport='yes' listen='192.168.1.226'/>" "<serial type='pty'/>" "<disk type='block'>" "<source dev='/dev/vgvms/Linux2'/>" "<target dev='hda'/>" "</disk>" "<interface type='bridge'>" "<mac address='D6:5F:DF:05:45:BB'/>" "<source bridge='Bridge2'/>" "</interface>" "</devices>" "</domain>"; int main (int argc, char** argv) { virConnectPtr conn; virDomainPtr dom; if (virInitialize () < 0) { printf ("virInitialize() failed\n"); return -1; } conn = virConnectOpen ("xen:///"); if (!conn) { printf ("virConnectOpen() failed\n"); return -1; } dom = virDomainDefineXML (conn, xml); if (!dom) { printf ("virDomainDefineXML() failed\n"); return -1; } if (virDomainCreate (dom) < 0) { printf ("virDomainCreate() failed\n"); return -1; } sleep (30); if (virDomainSuspend (dom) < 0) { virErrorPtr error = virConnGetLastError (conn); printf ("virDomainSuspend() failed: %d\n", error->code); } sleep (60); if (virDomainResume (dom) < 0) { printf ("virDomainResume() failed\n"); } return 0; } [root@grape tmp]$ ./a.out DEBUG: libvirt.c: virInitialize (register drivers) DEBUG: xen_internal.c: xenHypervisorInit (Using new hypervisor call: 30001 ) DEBUG: xen_internal.c: xenHypervisorInit (Using hypervisor call v2, sys ver3 dom ver5 ) DEBUG: libvirt.c: virConnectOpen (name=xen:///) DEBUG: libvirt.c: do_open (name "xen:///" to URI components: scheme xen opaque (null) authority (null) server (null) user (null) port 0 path / ) DEBUG: libvirt.c: do_open (trying driver 0 (Test) ...) DEBUG: libvirt.c: do_open (driver 0 Test returned DECLINED) DEBUG: libvirt.c: do_open (trying driver 1 (Xen) ...) DEBUG: xen_unified.c: xenUnifiedOpen (Trying hypervisor sub-driver) DEBUG: xen_unified.c: xenUnifiedOpen (Activated hypervisor sub-driver) DEBUG: xen_unified.c: xenUnifiedOpen (Trying XenD sub-driver) DEBUG: xen_unified.c: xenUnifiedOpen (Activated XenD sub-driver) DEBUG: xen_unified.c: xenUnifiedOpen (Trying XS sub-driver) DEBUG: xen_unified.c: xenUnifiedOpen (Activated XS sub-driver) DEBUG: libvirt.c: do_open (driver 1 Xen returned SUCCESS) DEBUG: libvirt.c: do_open (network driver 0 Test returned DECLINED) DEBUG: libvirt.c: do_open (network driver 1 QEMU returned DECLINED) DEBUG: remote_internal.c: doRemoteOpen (proceeding with name = xen:///) DEBUG: libvirt.c: do_open (network driver 2 remote returned SUCCESS) DEBUG: libvirt.c: do_open (storage driver 0 Test returned DECLINED) DEBUG: libvirt.c: do_open (storage driver 1 storage returned DECLINED) DEBUG: libvirt.c: do_open (storage driver 2 remote returned SUCCESS) DEBUG: libvirt.c: virDomainDefineXML (conn=0x92ae478, xml=<domain type='xen'><name>Linux2</name><os><type>hvm</type><loader>/usr/lib/xen/boot/ hvmloader</loader><boot dev='hd'/></os><memory>500000</memory><vcpu>1</vcpu><on_shutdown>shutdown</o n_shutdown><on_reboot>restart</on_reboot><on_crash>restart</on_crash><featur es><pae/><acpi/><apic/></features><devices><emulator>/usr/lib/xen/bin/qemu-d m</emulator><input type='tablet' bus='usb'/><graphics type='vnc' autoport='yes' listen='192.168.1.226'/><serial type='pty'/><disk type='block'><source dev='/dev/vgvms/Linux2'/><target dev='hda'/></disk><interface type='bridge'><mac address='D6:5F:DF:05:45:BB'/><source bridge='Bridge2'/></interface></devices></domain>) DEBUG: xend_internal.c: xenDaemonDomainDefineXML (Defining w/ sexpr: (vm (name 'Linux2')(memory 488)(maxmem 488)(vcpus 1)(uuid '5d9f6df2-6930-b2b8-4f71-db8575faa3ae')(on_poweroff 'destroy')(on_reboot 'restart')(on_crash 'restart')(image (hvm (kernel '/usr/lib/xen/boot/hvmloader')(vcpus 1)(boot c)(acpi 1)(apic 1)(pae 1)(usb 1)(usbdevice tablet)(parallel none)(serial pty)(device_model '/usr/lib/xen/bin/qemu-dm')))(device (vbd (dev 'hda:disk')(uname 'phy:/dev/vgvms/Linux2')(mode 'w')))(device (vif (mac 'd6:5f:df:05:45:bb')(bridge 'Bridge2')(script 'vif-bridge')))(device (vkbd))(device (vfb (type vnc)(vncunused 1)(vnclisten '192.168.1.226'))))) DEBUG: libvirt.c: virDomainLookupByName (conn=0x92ae478, name=Linux2) DEBUG: hash.c: __virGetDomain (New hash entry 0x92bd1e0) DEBUG: libvirt.c: virDomainCreate (domain=0x92bd1e0) DEBUG: libvirt.c: virDomainSuspend (domain=0x92bd1e0) virDomainSuspend() failed: 0 > -----Original Message----- > From: Richard W.M. Jones [mailto:rjones@redhat.com] > Sent: Friday, September 19, 2008 2:21 PM > To: Matthew Donovan > Cc: libvir-list(a)redhat.com > Subject: Re: [libvirt] pausing / unpausing guests with libvirt > > On Fri, Sep 19, 2008 at 09:23:52AM -0400, Matthew Donovan wrote: > > I'm working on a management application that will control > Xen guest vms > > (HVMs) with libvirt Java bindings. I want to be able to > pause and unpause > > the VMs but doing so through the libvirt functions does not > seem to actually > > pause the VM. The suspend function returns true and > doesn't throw any > > exceptions, however, the guest VM is still running and responsive. > > > > Any pointers are greatly appreciated. > > Is it possible you could isolate whether the problem is with libvirt > or with the Java bindings? One way would be to shell out to 'virsh' > just to see if virsh fails to change the state (ie. a libvirt/C) or if > the problem is in the Java bindings. > > Pausing/resuming Xen domains is a very common and well-tested > operation so I would be surprised if it's a libvirt problem, but you > never know ... > > Rich. > > > -- > Richard Jones, Emerging Technologies, Red Hat > http://et.redhat.com/~rjones > virt-df lists disk usage of guests without needing to install any > software inside the virtual machine. Supports Linux and Windows. > http://et.redhat.com/~rjones/virt-df/ >

2 1

[libvirt] pausing / unpausing guests with libvirt
by Matthew Donovan 19 Sep '08

19 Sep '08

I'm working on a management application that will control Xen guest vms (HVMs) with libvirt Java bindings. I want to be able to pause and unpause the VMs but doing so through the libvirt functions does not seem to actually pause the VM. The suspend function returns true and doesn't throw any exceptions, however, the guest VM is still running and responsive. Any pointers are greatly appreciated. Thanks -matthew I'm using: libvirt 0.4.5 libvirt-java 0.2.1 Xen 3.1.2 The guest I'm working with is a Fedora Core 6 HVM (though I'd like it to work with any guest.) The host is Fedora Core 8. Code to define and create the domain: try { con = new Connect ("xen:///"); String xml = buildXMLConfig(config); // config is a string of XML shown below domain = con.domainDefineXML(xml); domain.create (); } catch (LibvirtException ex) { logger.error ("Error starting VM", ex); return false; } Code to pause the VM: public boolean pause() throws RemoteException { logger.info ("Pause operation in progress. domain = "+domain); if (domain == null) return false; try { synchronized (domain) { domain.suspend (); // using suspend() because there is no pause() function. } } catch (LibvirtException ex) { logger.error ("Could not suspend "+vm.getName(), ex); return false; } raiseComponentChangeEvent(new ComponentStateChangeEvent(State.PAUSED)); return true; } (The synchronized() statement is because I was running a second thread watching the state of the VM and I thought maybe that might be contributing to the problem. The VM is still not paused when there is only one thread running.) XML for the domain: <domain type='xen'> <name>Linux2</name> <os> <type>hvm</type> <loader>/usr/lib/xen/boot/hvmloader</loader> <boot dev='hd'/> </os> <memory>500000</memory> <vcpu>1</vcpu> <on_shutdown>shutdown</on_shutdown> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <features> <pae/> <acpi/> <apic/> </features> <devices> <emulator>/usr/lib/xen/bin/qemu-dm</emulator> <input type='tablet' bus='usb'/> <graphics type='vnc' autoport='yes' listen='192.168.1.226'/> <serial type='pty'/> <disk type='block'> <source dev='/dev/vgvms/Linux2'/> <target dev='hda'/> </disk> <interface type='bridge'> <mac address='D6:5F:DF:05:45:BB'/> <source bridge='Bridge2'/> </interface> </devices> </domain>

2 1

[libvirt] [FW: An introduction to libvirt's LXC (LinuX Container) support]
by Daniel P. Berrange 19 Sep '08

19 Sep '08

FYI this mail i just sent to containers(a)lists.linux-foundation.org where all the kernel container developers hang out. Daniel ----- Forwarded message from "Daniel P. Berrange" <berrange(a)redhat.com> ----- > Date: Wed, 17 Sep 2008 16:06:35 +0100 > From: "Daniel P. Berrange" <berrange(a)redhat.com> > To: containers(a)lists.linux-foundation.org > Subject: An introduction to libvirt's LXC (LinuX Container) support > > This is a short^H^H^H^H^H long mail to introduce / walk-through some > recent developments in libvirt to support native Linux hosted > container virtualization using the kernel capabilities the people > on this list have been adding in recent releases. We've been working > on this for a few months now, but not really publicised it before > now, and I figure the people working on container virt extensions > for Linux might be interested in how it is being used. > > For those who aren't familiar with libvirt, it provides a stable API > for managing virtualization hosts and their guests. It started with > a Xen driver, and over time has evolved to add support for QEMU, KVM, > OpenVZ and most recently of all a driver we're calling "LXC" short > for "LinuX Containers". The key is that no matter what hypervisor > you are using, there is a consistent set of APIs, and standardized > configuration format for userspace management applications in the > host (and remote secure RPC to the host). > > The LXC driver is the result of a combined effort from a number of > people in the libvirt community, most notably Dave Leskovec contributed > the original code, and Dan Smith now leads development along with my > own contributions to its architecture to better integrate with libvirt. > > We have a couple of goals in this work. Overall, libvirt wants to be > the defacto standard, open source management API for all virtualization > platforms and native Linux virtualization capabilities are a strong > focus. The LXC driver is attempting to provide a general purpose > management solution for two container virt use cases: > > - Application workload isolation > - Virtual private servers > > In the first use case we want to provide the ability to run an > application in primary host OS with partial restrictons on its > resource / service access. It will still run with the same root > directory as the host OS, but its filesystem namespace may have > some additional private mount points present. It may have a > private network namespace to restrict its connectivity, and it > will ultimately have restrictions on its resource usage (eg > memory, CPU time, CPU affinity, I/O bandwidth). > > In the second use case, we want to provide completely virtualized > operating system in the container (running the host kernel of > course), akin to the capabilities of OpenVZ / Linux-VServer. The > container will have a totally private root filesystem, private > networking namespace, whatever other namespace isolation the > kernel provides, and again resource restirctions. Some people > like to think of this as 'a better chroot than chroot'. > > In terms of technical implementation, at its core is direct usage > of the new clone() flags. By default all containers get created > with CLONE_NEWPID, CLONE_NEWNS, CLONE_NEWUTS, CLONE_NEWUSER, and > CLONE_NEWIPC. If private network config was requested they also > get CLONE_NEWNET. > > For the workload isolation case, after creating the container we > just add a number of filesystem mounts in the containers private > FS namespace. In the VPS case, we'll do a pivot_root() onto the > new root directory, and then add any extra filesystem mounts the > container config requested. > > The stdin/out/err of the process leader in the container is bound > to the slave end of a Psuedo TTY, libvirt owning the master end > so it can provide a virtual text console into the guest container. > Once the basic container setup is complete, libvirt exec the so > called 'init' process. Things are thus setup such that when the > 'init' process exits, the container is terminated / cleaned up. > > On the host side, the libvirt LXC driver creates what we call a > 'controller' process for each container. This is done with a small > binary /usr/libexec/libvirt_lxc. This is the process which owns the > master end of the Pseduo-TTY, along with a second Pseduo-TTY pair. > When the host admin wants to interact with the contain, they use > the command 'virsh console CONTAINER-NAME'. The LXC controller > process takes care of forwarding I/O between the two slave PTYs, > one slave opened by virsh console, the other being the containers' > stdin/out/err. If you kill the controller, then the container > also dies. Basically you can think of the libvirt_lxc controller > as serving the equivalent purpose to the 'qemu' command for full > machine virtualization - it provides the interface between host > and guest, in this case just the container setup, and access to > text console - perhaps more in the future. > > For networking, libvirt provides two core concepts > > - Shared physical device. A bridge containing one of your > physical network interfaces on the host, along with one or > more of the guest vnet interfaces. So the container appears > as if its directly on the LAN > > - Virtual network. A bridge containing only guest vnet > interfaces, and NO physical device from the host. IPtables > and forwarding provide routed (+ optionally NATed) > connectivity to the LAN for guests. > > The latter use case is particularly useful for machines without > a permanent wired ethernet - eg laptops, using wifi, as it lets > guests talk to each other even when there's no active host network. > Both of these network setups are fully supported in the LXC driver > in precense of a suitably new host kernel. > > That's a 100ft overview and the current functionality is working > quite well from an architectural/technical point of view, but there > is plenty more work we still need todo to provide an system which > is mature enough for real world production deployment. > > - Integration with cgroups. Although I talked about resource > restrictions, we've not implemented any of this yet. In the > most immediate timeframe we want to use cgroups' device > ACL support to prevent the container having any ability to > access to device nodes other than the usual suspects of > /dev/{null,full,zero,console}, and possibly /dev/urandom. > The other important one is to provide a memory cap across > the entire container. CPU based resource control is lower > priority at the moment. > > - Efficient query of resource utilization. We need to be able > to get the cumulative CPU time of all the processes inside > the container, without having to iterate over every PIDs' > /proc/$PID/stat file. I'm not sure how we'll do this yet.. > We want to get this data this for all CPUs, and per-CPU. > > - devpts virtualization. libvirt currently just bind mount the > host's /dev/pts into the container. Clearly this isn't a > serious impl. We've been monitoring the devpts namespace > patches and these look like they will provide the capabilities > we need for the full virtual private server use case > > - network sysfs virtualization. libvirt can't currently use the > CLONE_NEWNET flag in most Linux distros, since current released > kernel has this capability conflicting with SYSFS in KConfig. > Again we're looking forward to seeing this addressed in next > kernel > > - UID/GID virtualization. While we spawn all containers as root, > applications inside the container may witch to unprivileged > UIDs. We don't (neccessarily) want users in the host with > equivalent UIDs to be able to kill processes inside the > container. It would also be desirable to allow unprivileged > users to create containers without needing root on the host, > but allowing them to be root & any other user inside their > container. I'm not aware if anyone's working on this kind of > thing yet ? > > There're probably more things Dan Smith is thinking of but that > list is a good starting point. > > Finally, a 30 second overview of actually using LXC usage with > libvirt to create a simple VPS using busybox in its root fs... > > - Create a simple chroot environment using busybox > > mkdir /root/mycontainer > mkdir /root/mycontainer/bin > mkdir /root/mycontainer/sbin > cp /sbin/busybox /root/mycontainer/sbin > for cmd in sh ls chdir chmod rm cat vi > do > ln -s /root/mycontainer/bin/$cmd ../sbin/busybox > done > cat > /root/mycontainer/sbin/init <<EOF > #!/sbin/busybox > sh > EOF > > > - Create a simple libvirt configuration file for the > container, defining the root filesystem, the network > connection (bridged to br0 in this case), and the > path to the 'init' binary (defaults to /sbin/init if > omitted) > > # cat > mycontainer.xml <<EOF > <domain type='lxc'> > <name>mycontainer</name> > <memory>500000</memory> > <os> > <type>exe</type> > <init>/sbin/init</init> > </os> > <devices> > <filesystem type='mount'> > <source dir='/root/mycontainer'/> > <target dir='/'/> > </filesystem> > <interface type='bridge'> > <source network='br0'/> > <mac address='00:11:22:34:34:34'/> > </interface> > <console type='pty' /> > </devices> > </domain> > EOF > > - Load the configuration into libvirt > > # virsh --connect lxc:/// define mycontainer.xml > # virsh --connect lxc:/// list --inactive > Id Name State > ---------------------------------- > - mycontainer shutdown > > > > - Start the VM and query some information about it > > # virsh --connect lxc:/// start mycontainer > # virsh --connect lxc:/// list > Id Name State > ---------------------------------- > 28407 mycontainer running > > # virsh --connect lxc:/// dominfo mycontainer > Id: 28407 > Name: mycontainer > UUID: 8369f1ac-7e46-e869-4ca5-759d51478066 > OS Type: exe > State: running > CPU(s): 1 > Max memory: 500000 kB > Used memory: 500000 kB > > > NB. the CPU/memory info here is not enforce yet. > > - Interact with the container > > # virsh --connect lxc:/// console mycontainer > > NB, Ctrl+] to exit when done > > - Query the live config - eg to discover what PTY its > console is connected to > > > # virsh --connect lxc:/// dumpxml mycontainer > <domain type='lxc' id='28407'> > <name>mycontainer</name> > <uuid>8369f1ac-7e46-e869-4ca5-759d51478066</uuid> > <memory>500000</memory> > <currentMemory>500000</currentMemory> > <vcpu>1</vcpu> > <os> > <type arch='i686'>exe</type> > <init>/sbin/init</init> > </os> > <clock offset='utc'/> > <on_poweroff>destroy</on_poweroff> > <on_reboot>restart</on_reboot> > <on_crash>destroy</on_crash> > <devices> > <filesystem type='mount'> > <source dir='/root/mycontainer'/> > <target dir='/'/> > </filesystem> > <console type='pty' tty='/dev/pts/22'> > <source path='/dev/pts/22'/> > <target port='0'/> > </console> > </devices> > </domain> > > - Shutdown the container > > # virsh --connect lxc:/// destroy mycontainer > > There is lots more I could say, but hopefully this serves as > a useful introduction to the LXC work in libvirt and how it > is making use of the kernel's container based virtualization > support. For those interested in finding out more, all the > source is in the libvirt CVS repo, the files being those > named src/lxc_conf.c, src/lxc_container.c, src/lxc_controller.c > and src/lxc_driver.c. > > http://libvirt.org/downloads.html > > or via the GIT mirror of our CVS repo > > git clone git://git.et.redhat.com/libvirt.git > > Regards, > 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 :| > _______________________________________________ > Containers mailing list > Containers(a)lists.linux-foundation.org > https://lists.linux-foundation.org/mailman/listinfo/containers > ----- End forwarded message ----- -- |: 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 1

[libvirt] [PATCH] Improved error messages in XM conf module
by Richard W.M. Jones 19 Sep '08

19 Sep '08

The attached patch improves error handling in the XM config file parser (src/conf.c). Currently it has a custom error function called virConfError which has three problems. Firstly the conf argument is ignored and therefore pointless to even pass. Secondly the function takes a line number parameter (for reporting the line number where parsing failed), but this is swallowed and not printed in error messages. Thirdly, and most importantly, the name of the file where the error occurs is not printed by default unless the caller happens to print it. If there is an _empty_ file in /etc/xen we get this error: # virsh list --all libvir: error : failed to read configuration file /etc/xen/foobar but if the spurious file under /etc/xen is non-empty, like a script, you get completely anonymous errors such as: libvir: error : configuration file syntax error: expecting an assignment or: libvir: error : configuration file syntax error: expecting a value The patch fixes this by printing out the filename and line number if these are available from the parser context (and the parser context is passed to virConfError instead of the unused virConfPtr). With this patch you'll get errors for the second case like this: # virsh list --inactive libvir: error : /etc/xen/foobar:1: expecting a value Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/

3 2

[libvirt] [PATCH 0/3]: Cleanup LVM pool
by Chris Lalancette 19 Sep '08

19 Sep '08

All, The following patch series is a set of (simple) cleanups for the storage_backend_logical stuff. Most of it is uncontroversial, except for one bit in the 3'rd patch (which I'll point out there). Please review. Thanks, -- Chris Lalancette

1 0

[libvirt] [PATCH] rename "blocked" to "idle"
by John Levon 19 Sep '08

19 Sep '08

<movement> can we please please rename "blocked" to "idle" <movement> literally /everybody/ is confused by that ... <dansmith> I'm not opposed to changing it, mind you, because I feel the indirect pain of explaining it to others too :) <movement> actually, normally, the question is "my guest isn't running" <dansmith> yeah regards john Index: src/virsh.c =================================================================== RCS file: /data/cvs/libvirt/src/virsh.c,v retrieving revision 1.163 diff -r1.163 virsh.c 6275c6275 < return gettext_noop("blocked"); --- > return gettext_noop("idle"); 6297c6297 < return gettext_noop("blocked"); --- > return gettext_noop("idle");

3 4

[libvirt] [PATCH] Determine kvm max vcpus via version number
by Cole Robinson 19 Sep '08

19 Sep '08

The attached patch is a slimmed down version of a patch I posted a while back. This expands qemu help message parsing to look for a kvm version number, which can be used to determine maximum supported vcpus. A kvmVersion field is added to the qemu_driver structure, and a check to determine the version is added to the libvirtd start up routine. If the kvm version isn't found (say if kvm isn't installed), kvmVersion is set to 0. This is against Guido Gunther's patch "maxVCPU runtime detection": his method takes precendence in the code if it's available. Comments welcome. Thanks, Cole diff --git a/src/qemu_conf.c b/src/qemu_conf.c index 22a99ec..f79137f 100644 --- a/src/qemu_conf.c +++ b/src/qemu_conf.c @@ -418,13 +418,14 @@ virCapsPtr qemudCapsInit(void) { int qemudExtractVersionInfo(const char *qemu, unsigned int *retversion, + unsigned int *retkvmversion, unsigned int *retflags) { const char *const qemuarg[] = { qemu, "-help", NULL }; const char *const qemuenv[] = { "LC_ALL=C", NULL }; pid_t child; int newstdout = -1; - int ret = -1, status; - unsigned int major, minor, micro; + int ret = -1, scanret = -1, status; + unsigned int major, minor, micro, kvmver; unsigned int version; unsigned int flags = 0; @@ -443,10 +444,12 @@ int qemudExtractVersionInfo(const char *qemu, if (len < 0) goto cleanup2; - if (sscanf(help, "QEMU PC emulator version %u.%u.%u", - &major, &minor, &micro) != 3) { + scanret = sscanf(help, "QEMU PC emulator version %u.%u.%u (kvm-%u", + &major, &minor, &micro, &kvmver); + if (scanret == 3) + kvmver = 0; + else if (scanret != 4) goto cleanup2; - } version = (major * 1000 * 1000) + (minor * 1000) + micro; @@ -465,6 +468,8 @@ int qemudExtractVersionInfo(const char *qemu, if (retversion) *retversion = version; + if (retkvmversion) + *retkvmversion = kvmver; if (retflags) *retflags = flags; @@ -472,6 +477,7 @@ int qemudExtractVersionInfo(const char *qemu, qemudDebug("Version %d %d %d Cooked version: %d, with flags ? %d", major, minor, micro, version, flags); + qemudDebug("KVM version: %d", kvmver); cleanup2: VIR_FREE(help); @@ -500,28 +506,34 @@ rewait: return ret; } -int qemudExtractVersion(virConnectPtr conn, - struct qemud_driver *driver) { +int qemudExtractVersion(struct qemud_driver *driver) { const char *binary; struct stat sb; + struct utsname ut; if (driver->qemuVersion > 0) return 0; + uname (&ut); + if ((binary = virCapabilitiesDefaultGuestEmulator(driver->caps, "hvm", + ut.machine, + "kvm")) == NULL && + (binary = virCapabilitiesDefaultGuestEmulator(driver->caps, + "hvm", "i686", "qemu")) == NULL) return -1; if (stat(binary, &sb) < 0) { - qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR, - _("Cannot find QEMU binary %s: %s"), binary, - strerror(errno)); return -1; } - if (qemudExtractVersionInfo(binary, &driver->qemuVersion, NULL) < 0) { + if (qemudExtractVersionInfo(binary, + &driver->qemuVersion, + &driver->kvmVersion, + NULL) < 0) { return -1; } diff --git a/src/qemu_conf.h b/src/qemu_conf.h index 88dfade..8d429fb 100644 --- a/src/qemu_conf.h +++ b/src/qemu_conf.h @@ -50,6 +50,7 @@ enum qemud_cmd_flags { /* Main driver state */ struct qemud_driver { unsigned int qemuVersion; + unsigned int kvmVersion; int nextvmid; virDomainObjPtr domains; @@ -83,10 +84,10 @@ int qemudLoadDriverConfig(struct qemud_driver *driver, virCapsPtr qemudCapsInit (void); -int qemudExtractVersion (virConnectPtr conn, - struct qemud_driver *driver); +int qemudExtractVersion (struct qemud_driver *driver); int qemudExtractVersionInfo (const char *qemu, unsigned int *version, + unsigned int *kvmversion, unsigned int *flags); int qemudBuildCommandLine (virConnectPtr conn, diff --git a/src/qemu_driver.c b/src/qemu_driver.c index 0c04da6..d1b9d7c 100644 --- a/src/qemu_driver.c +++ b/src/qemu_driver.c @@ -240,6 +240,12 @@ qemudStartup(void) { if ((qemu_driver->caps = qemudCapsInit()) == NULL) goto out_of_memory; + // Dependent on capabilities being initialized + if (qemudExtractVersion(qemu_driver) < 0) { + qemudShutdown(); + return -1; + } + if (qemudLoadDriverConfig(qemu_driver, driverConf) < 0) { qemudShutdown(); return -1; @@ -923,7 +929,7 @@ static int qemudStartVMDaemon(virConnectPtr conn, } if (qemudExtractVersionInfo(vm->def->emulator, - NULL, + NULL, NULL, &qemuCmdFlags) < 0) { qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR, _("Cannot determine QEMU argv syntax %s"), @@ -1793,11 +1799,20 @@ static const char *qemudGetType(virConnectPtr conn ATTRIBUTE_UNUSED) { } -static int kvmGetMaxVCPUs(void) { - int maxvcpus = 1; +static int kvmGetMaxVCPUs(virConnectPtr conn) { + + struct qemud_driver *driver = (struct qemud_driver *)conn->privateData; + int maxvcpus = 1, r, fd; + + // KVM-30 added support for up to 4 vcpus + // KVM-62 raised this to 16 + if (driver->kvmVersion < 30) + maxvcpus = 1; + else if (driver->kvmVersion < 62) + maxvcpus = 4; + else + maxvcpus = 16; - int r, fd; - fd = open(KVM_DEVICE, O_RDONLY); if (fd < 0) { qemudLog(QEMUD_WARN, _("Unable to open " KVM_DEVICE ": %s\n"), strerror(errno)); @@ -1820,10 +1835,8 @@ static int qemudGetMaxVCPUs(virConnectPtr conn, const char *type) { if (STRCASEEQ(type, "qemu")) return 16; - /* XXX future KVM will support SMP. Need to probe - kernel to figure out KVM module version i guess */ if (STRCASEEQ(type, "kvm")) - return kvmGetMaxVCPUs(); + return kvmGetMaxVCPUs(conn); if (STRCASEEQ(type, "kqemu")) return 1; @@ -1993,7 +2006,7 @@ static virDomainPtr qemudDomainLookupByName(virConnectPtr conn, static int qemudGetVersion(virConnectPtr conn, unsigned long *version) { struct qemud_driver *driver = (struct qemud_driver *)conn->privateData; - if (qemudExtractVersion(conn, driver) < 0) + if (qemudExtractVersion(driver) < 0) return -1; *version = qemu_driver->qemuVersion; @@ -3035,7 +3048,7 @@ static int qemudDomainChangeEjectableMedia(virDomainPtr dom, } if (qemudExtractVersionInfo(vm->def->emulator, - NULL, + NULL, NULL, &qemuCmdFlags) < 0) { qemudReportError(dom->conn, dom, NULL, VIR_ERR_INTERNAL_ERROR, _("Cannot determine QEMU argv syntax %s"),

2 3

[libvirt] [PATCH] Don't remove devel files in spec
by Cole Robinson 18 Sep '08

18 Sep '08

The second iteration of the spec file enhancements didn't fully remove some pieces that were dependent on the devel package switch. The attached patch fixes 'make rpm' to work again. Thanks, Cole

3 2

[libvirt] cpu flags
by Ben Guthro 18 Sep '08

18 Sep '08

Hi, We're finding that we are going to be needing the cpu flags (as reported in /proc/cpuinfo) ...specifically to find out if we are a vmx enabled machine. So - off I went looking into this for a patch to submit upstream. Unfortunately, I ran into some questions which need answering before I really proceed with this It seems to me that this info would best be parsed in src/nodeinfo.c This is where other cpuinfo things are parsed...and stored in the nodeinfo struct Perhaps we store this as a bitmask encoded int, as defined in /usr/include/asm/cpufeature.h and tack this onto the end of sad struct. My concern is that adding to the nodeinfo struct breaks the API - such that the structs will be different sizes between versions. Also - this seems to be x86 specific. Are we primarily destined for x86? Or would this type of change be unacceptable due to not working on PPC, for example? Thoughts? Ben

5 12

[libvirt] [PATCH] Add documentation for C# "binding" and fix Windows documentation
by Richard W.M. Jones 18 Sep '08

18 Sep '08

This patch changes the bindings page so that the language names are emboldened and so that Java and C# are listed too. I've also listed Windows on that page, not strictly because it is a language, but because it's a platform. The existing documentation on building libvirt on Windows is bogus and possibly wrong. This patch also replaces that with a more accurate placeholder. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 68 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

2 1

[libvirt] [PATCH] Two safer versions of virDomainGetID
by Richard W.M. Jones 18 Sep '08

18 Sep '08

Two alternative versions of a safer virDomainGetID call in followups to this message. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 64 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

2 6

[libvirt] FYI: [PATCH] Missing include file
by Richard W.M. Jones 18 Sep '08

18 Sep '08

Just FYI, I applied the following minor patch which fixes the build when configured with --enable-compile-warnings=error. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 68 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

2 1

[libvirt] [PATCH] segfailt in openvz driver
by Evgeniy Sokolov 17 Sep '08

17 Sep '08

There was segmentation failt in openvz driver during 'create' command if domain with same id exist. Segfault was because of using structure (print warning with name of container) which is free. other: use openvzError instead of openvzLog.

2 4

[libvirt] Any outstanding patches?
by Richard W.M. Jones 17 Sep '08

17 Sep '08

While Daniel Veillard is away, if you have any outstanding patches which have been approved but not committed, please reply to this message with a pointer to the mailing list message or patch. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/

2 1