- Devel - libvirt List Archives

[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