- Devel - libvirt List Archives

[Libvir] Request for changing #include directives to conform to Linux standard
by Philippe Berthault 26 Jun '06

26 Jun '06

The 'virterror.h' file has an #include directive to "libvirt.h" which isn't correct because libvirt include files are installed on a sub-directory named 'libvirt'. i.e. when libvirt is compiled with configure --script=/usr, then libvirt files are installed in /usr/include/libvirt/.* To be standard with Linux usage of include files, the correct directive in virterror.h will be: #include <libvirt/libvirt.h> instead of: #include "libvirt.h" and in C/C++ source files using libvirt, there is just to include libvirt with: #include <libvirt/libvirt.h> #include <libvirt/virterror.h> This is conform to Linux usage of include files and this permit to simplify Makefile(s) because there is no need to add option -I/usr/include/libvirt to compile sources files. Regards.

2 2

[Libvir] Proposal for a new Libvirt function: change number of virtual CPUs
by michel.ponceau＠bull.net 23 Jun '06

23 Jun '06

For our administration, we need to dynamically reduce the number of virtual CPUs in each domain, in same way as Xen command "xm vcpu-set". It seems that no Libvirt function is currently provided for that purpose. I successfully tried some simple changes in libvirt.c an xend_internal.c, mainly the following: snprintf(buf, sizeof(buf), "%d", vcpus); return xend_op(domain->conn, domain->name, "op", "set_vcpus", "vcpus", buf, NULL); We suggest to add this new function "virDomainSetVcpus" to Libvirt. I have not tried the hypervisor and xen store accesses for this function. Do you think they would be necessary? I am also working on two other functions to reproduce "xm vcpu-pin" and "xm vcpu-list" from Libvirt.

2 1

[Libvir] libvirt documentation
by Philippe Berthault 23 Jun '06

23 Jun '06

You will find, joined with this mail, your libvirt v0.1.1 documentation in Windows CHM format which is very useful for users who have both Linux and Windows stations. Regards.

2 1

[Libvir] Release of libvir-0.1.1
by Daniel Veillard 21 Jun '06

21 Jun '06

I realized yesterday that Xen unstable changeset 10277 broke the hypervisor API on i686, which led to some interesting debugging and hopefully a clean solution for this problem. I think it is worth making a release then even if the 4 new APIs for defined but non-running domains are not complete (pending more information on Xend API changes). There is still some meat in this release. ftp://libvirt.org/libvirt/ One notable improvement is that it should be fairly simple to add support for new virtualization back-end now that the driver code has been cleaned up, the new test driver to do regression test from Daniel Berrange is a good example: * building fixes: - ncurses fallback (Jim Fehlig) - VPATH builds (Daniel P. Berrange) * driver cleanups: - new entry points - cleanup of libvirt.c (with Daniel P. Berrange) * Cope with API change introduced in Xen changeset 10277 * new test driver for regression checks (Daniel P. Berrange) * improvements: - added UUID to XML serialization - buffer usage (Karel Zak) - --connect argument to virsh (Daniel P. Berrange), * bug fixes: - uninitialized memory access in error reporting - S-Expr parsing (Jim Fehlig, Jeremy Katz) - virConnectOpen bug - remove a TODO in xs_internal.c * documentation: - Python examples (David Lutterkort) - new Perl binding URL - man page update (Karel Zak) thanks to everybody who helped with this release, with code, patches, bug reports, etc... Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

1 0

[Libvir] bug in the virSetErrorFunc() function
by Philippe Berthault 16 Jun '06

16 Jun '06

I've written a program based on libvirt (release 0.1.0) in which I uses the virSetErrorFunc() function to avoid messages on the screen but one message is always displayed (on stderr) and isn't trapped by the virSetErrorFunc() function. This message is "Unimplemented block at xs_internal.c:255" Thanks,

2 2

[Libvir] State of driver backend infrastructure
by Daniel P. Berrange 14 Jun '06

14 Jun '06

I'm looking to get more of the test driver backend working, and so decided it was time to audit the state of the driver backend infrastructure. There are a couple of areas which could do with some work: * Driver specific data. The virConnect & virDomain structs have explicit fields for Xen related data: virConnect: int handle; /* internal handle used for hypercall */ struct xs_handle *xshandle; /* handle to talk to the xenstore */ virDomain: int handle; /* internal handle for the domnain ID */ One idea for resolving this is to have an array of slots, one per drivers in which drivers can store data they need. void **handles Or perhaps, to allow simple int type too void union { int num; void *ptr } *handles * Connect URIs. The 'virDomainOpen' and 'virDomainOpenReadOnly' methods have an optional parameter 'name'. The Xen drivers currently ignore this, or expect it to be NULL / the string "Xen". For sake of back-compat we'll ned to preserve existing behaviour for NULL, but we should hook up URI parsing for the XenD backend to allow non local connections to work. This gives the question of what format should the URI be for Xen domains ? Although 'http://' is the protocol XenD uses, this isn't likely a good idea, because a later VMWare driver might also use a http based protocol. So, perhaps we should use generic URIs:? xend://somehost:port/ * Driver method hookup. The libvirt.c file has alot of methods which are either not hooked up to the driver backend, or hooked up, but still have duplicated (redundant?) Xen specific calls. Here is the complete status: virGetVersion: - Hardcodes support for Xen HV. No virConnectPtr handle, so how would we call out to driver backends ? virConnectOpen - OK virConnectOpenReadOnly - OK virConnectClose: - Does not call out to driver backends, simply free's struct virConnectGetType: - Does not call out to driver backends, hardcodes Xen HV virConnectGetVersion - Does not call out to driver backends, hardcodes Xen HV virConnectListDomains - Calls out to drivers, but also has duplicated code for XenD & XenStore virConnectNumOfDomains - Calls out to drivers, but also has duplicated code for XenD & XenStore virDomainCreateLinux - Does not call out to driver backends, hardcodes XenD virDomainLookupByID - Calls out to drivers, but also has duplicated code for XenD & XenStore virDomainLookupByUUID - Calls out to drivers, but also has duplicated code for XenD & XenStore virDomainLookupByUUIDString - OK (but delegates to virDomainLookupByUUID) virDomainLookupByName - Calls out to drivers, but also has duplicated code for XenD & XenStore virDomainDestroy - Does not call out to driver backends, hardcodes XenD & Xen HV virDomainFree - Does not call out to driver backends, simply free's struct virDomainSuspend - Does not call out to driver backends, hardcodes XenD & Xen HV virDomainResume - Does not call out to driver backends, hardcodes XenD & Xen HV virDomainSave - Does not call out to driver backends, hardcodes XenD virDomainRestore - Does not call out to driver backends, hardcodes XenD virDomainShutdown - Does not call out to driver backends, hardcodes XenD virDomainReboot - Does not call out to driver backends, hardcodes XenD virDomainGetName - OK virDomainGetUUID - Does not call out to driver backends, hardcodes XenD virDomainGetUUIDString - OK (but delegates to virDomainGetUUID) virDomainGetOSType - Does not call out to driver backends, calls function in XenStore driver virDomainGetMaxMemory - Does not call out to driver backends, hardcodes XenD, Xen HV, XenStore virDomainSetMaxMemory - OK virDomainSetMemory - OK virDomainGetInfo - Calls out to drivers, but also has duplicated code for XenD & XenStore virDomainGetXMLDesc - Does not call out to driver backends, hardcodes XenD virNodeGetInfo - OK virDomainDefineXML - OK virDomainUndefineXML - OK virDomainListDefinedDomains - No implemented virDomainCreate - No implemented My immediate needs for testing, are to hook up more of the methods which aren't connected to the driver backends. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

3 6

[Libvir] A question about libvirt usage
by Philippe Berthault 13 Jun '06

13 Jun '06

Is there a notion of session in libvirt ? In other words, is it possible, between virConnectOpen() and virConnectClose(), that some Xen domains will be started, stopped, destroyed, etc.. by another operator using the xm command ou by another binary command based on libvirt. If the response is yes, is it possible to introduce a global lock in Xen (or in libvirt ?) to avoid conflict between libvirt and xm command or between several libvirt based commands. Thanks, Philippe Berthault.

2 1

[Libvir] Patch to 'ping' XenD when opening connection
by Daniel P. Berrange 13 Jun '06

13 Jun '06

Currently the XenD driver's implementation of the 'open' method will return success, regardless of whether XenD is even present. The attached patch makes the open method do a 'ping' to see if XenD is actually there, returning failure if it is not. This ensures that the XenD driver backend doesn't get activated when connecting to alternate non-Xen backends, such as the test backend I committed last week. The current 'ping' is simply to call the xenDaemonGetVersion() method since that's a pretty simle & low-overhead way to testing livliness of XenD. Any suggestions for a better ping - if not I'll go ahead & commit this change Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 3

[Libvir] A 'mock' driver enabling application unit testing
by Daniel P. Berrange 06 Jun '06

06 Jun '06

The attached patch adds a new driver which provides a 'mock' hypervisor connection. The idea behind this is to provide a completely predictable and isolated hypervisor implementation, which will facilitate creation of unit tests in applications using libvirt. The code attached is not a complete implementation, providing support only for connecting, listing domains, getting a domain by id/uuid/name, getting domain info, getting node info. Further work will hook up methods for creating domains, exporting XML & the other various libvirt APIs. The driver is intended to operate as a black box, closed system - the only interaction an application will have is via the libVirt entry points. It starts off with a single domain present, and fixed node info, and updates domain CPU time based on elapsed wall clock time. When the domain create API is hooked up this will let apps create new dummy domains within the context of the process. As I said, I delibrately implemented this driver to only have process local state. When the process shuts down all state is discarded. This keeps application usage very simple. Longer term I think it would be useful to have a 2nd, dynamic, which would allow fault injection, cross-process interaction & more to allow advanced scripting of a test scenario. I don't have time to create such a driver myself though, so I stuck with the simplest possible impl which will allow 95% of application unit testing needs to be satisfied. To use this driver, simply pass 'TestSimple' as the name parameter to virConnectOpen / virConnectOpenReadonly instead of NULL. If you are using 'virsh' then my previous patch will let you call 'virsh --connect TestSimple' I've also tested this with the 'gnome-vm-applet' panel applet. The only problem I have found is that the 'xend_internal.c' driver will always return success from its 'xenDaemonOpen' method, regardless of whether there is actually a Xen Daemon present. So when using the test driver, every method will first try to ue the XenD driver impl, fail (printing an error message) and then go onto use the test driver. The xenDaemonOpen method really needs to be fixed to only succeed when Xen is actually present. Or perhaps it should only try to run when the 'name' passed to virConnectOpen is NULL or 'Xen' - ie be a no op if the name is 'TestSimple' / QEMU / any other driver implementation. I'm not sure whether we want to commit this to the libvirt codebae just, since there is a fair bit more work to be done to hook up additional methods. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 4

[Libvir] Added 'domuuid' to virsh & --connect command lin arg
by Daniel P. Berrange 31 May '06

31 May '06

The attached patch makes two changes to the virsh command: * Adds a 'domuuid' command to display the printable UUID of a domain * Adds a '--connect NAME' argument allowing the name of a hypervisor to be passed through to 'virConnect' / 'virConnectReadOnly' Although libvirt only has a Xen backend at the moment, I'm working on a 'mock' hypervisor backend to enable unit testing of applications built on libvirt without requiring the test suite to interface with the real Xen hypervisor. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

3 2

[Libvir] Connect up more internal driver methods
by Daniel P. Berrange 29 May '06

29 May '06

The attached patch connects up more of the internal driver methods, as the final step preparing for a minimally operational test driver. * src/hash.c, src/internal.h: Switch the uuid parameter in virGetDomain to be of type 'unsigned char' since its a raw UUID we're passing in, not a printable one. * src/libvirt.c: Remove bogus "unsigned char" -> "char" type casts. Hook up the "domainLookupByID", "domainLookupByUUID", "domainLookupByName" and "domainGetInfo" driver backend functions. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 1

[Libvir] A few bug fix patches
by Daniel P. Berrange 29 May '06

29 May '06

Attached are two small bug fix patches: - libvirt-vpath.patch - fix test suite include path for VPATH builds - libvirt-symbols.patch - add some missing symbols to the libraries exported symbol table to make the python bindings work again Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 1

[Libvir] uuid string format
by Karel Zak 23 May '06

23 May '06

Hello, I've found that we use in our XML dump: <uuid>%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x</uuid> it's strange format of the UUID string representation. Is there any reason for this format? I think normal (rfc4122) is format: "%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x" it means with '-'. Karel -- Karel Zak <kzak(a)redhat.com>

3 3

[Libvir] BUG: virDomainLookupByID fails in libvirt-0.1.0
by Michel Gauthier 05 May '06

05 May '06

Hi, I tried to execute the info1 C code example on my redhat distribution with Xen installed. It fails due to the virDomainLookupByID API wich returns NULL. The problem seems to be in the internal function xenDaemonListDomains called after xs_get_domain_path inside the API. For the domain 0, xs_get_domain_path returns path=/local/domain/0. Then, the call to xenDaemonListDomains function logs the error message: "libvir: Xen Daemon error : could not connect to Xen Daemon" and returns names=NULL. A bug present in the release 0.0.6 has been fixed for the release 0.1.0. But this bug seems still present! Regards.

3 2

[Libvir] Re: support for hvm guests
by Jim Fehlig 04 May '06

04 May '06

>>>> Anthony Liguori <aliguori(a)us.ibm.com> 05/03/06 6:47 PM >>> > >>>> Currently I can get info on hvm domains but unable to create them. >>>> The create request is sent to xend but then blocks reading from xend >>>> in xend_req(). No problem creating the domain using xm. I have >>>> looked at the config coming into xend and it is identical between xm >>>> and virsh/libvirt. Need to poke around xend and see why there is no >>>> response to the virsh/libvirt create request for hvm domains. >>>> >>> >>> Hum, basically to debug this kind of things I spend my time in >>> /var/log/xend.log especially since it prints what it received at >>> creation >>> time, you can at least check the informations coming from libvirt and >>> from xm look alike. >>> Unfortunately I won't be able to help you, first because I'm about to >>> take vacations for 3 weeks :-), second because I don't have one of those >>> new Intel CPUs, but I am sure others will give an hand if needed. >>> >>> >> >> Well, I have found the problem but not a fix :-). When posting the >> create op to xend, the libvirt code currently waits for a response >> from xend (xend_req() is called after posting in xend_post()). For >> hvm guests, xend does not respond and libvirt blocks indefinitely on >> read. If I skip over the call to xend_req() for the create operation, >> wait_for_devices() and subsequently unpause() are called and the hvm >> guest is launched. > >What do you mean by Xend does not respond? I post a request such as: op=create&config=(vm%20(name%20'j_sles10b9_full')(memory%20512)(vcpus%201)(on_poweroff%20'destroy')(on_reboot%20'destroy')(on_crash%20'destroy')(image%20(hvm%20(kernel%20'/usr/lib/xen/boot/hvmloader')(device_model%20'/usr/lib/xen/bin/qemu-dm')(boot%20c)(sdl%201)(stdvga%201)(vcpus%201)))(device%20(vbd%20(dev%20'ioemu:hda')(uname%20'file:/var/lib/xen/images/j_sles10b9_full/hda')(mode%20'w')))(device%20(vif%20(mac%20'00:16:3e:b2:68:1d')(bridge%20'xenbr0')(script%20'vif-bridge')(type%20'ioemu')))) to xend from xend_post() in libvirt's xend_internal.c, which then expects to read a response from xend but it never arrives and blocks the read in libvirt. >Can you give me a very concrete test case for this? The exact >parameters being passed to domain_create() (it should just be an >S-Expression config). The sexpr is: (vm (name 'j_sles10b9_full')(memory 512)(vcpus 1)(on_poweroff 'destroy')(on_reboot 'destroy')(on_crash 'destroy')(image (hvm (kernel '/usr/lib/xen/boot/hvmloader')(device_model '/usr/lib/xen/bin/qemu-dm')(boot c)(sdl 1)(stdvga 1)(vcpus 1)))(device (vbd (dev 'ioemu:hda')(uname 'file:/var/lib/xen/images/j_sles10b9_full/hda')(mode 'w')))(device (vif (mac '00:16:3e:b2:68:1d')(bridge 'xenbr0')(script 'vif-bridge')(type 'ioemu')))) The url-encoded request sent from libvirt is also provided above. Below is the relevent content in xend.log. Thanks, Jim [2006-05-02 10:58:13 xend.XendDomainInfo] DEBUG (XendDomainInfo:180) XendDomainInfo.create(['vm', ['name', 'j_sles10b9_full'], ['memory', '512'], ['maxmem', '512'], ['vcpus', '1'], ['on_poweroff', 'destroy'], ['on_reboot', 'destroy'], ['on_crash', 'destroy'], ['image', ['hvm', ['kernel', '/usr/lib/xen/boot/hvmloader'], ['device_model', '/usr/lib/xen/bin/qemu-dm'], ['boot', 'c'], ['cdrom', '/tests/iso/SLES-10-i386-Beta9.iso'], ['sdl', '1'], ['stdvga', '1'], ['vcpus', '1']]], ['device', ['vbd', ['dev', 'ioemu:hda'], ['uname', 'file:/var/lib/xen/images/j_sles10b9_full/hda'], ['mode', 'w']]], ['device', ['vif', ['mac', '00:16:3e:b2:68:1d'], ['bridge', 'xenbr0'], ['script', 'vif-bridge'], ['type', 'ioemu']]]]) [2006-05-02 10:58:13 xend.XendDomainInfo] DEBUG (XendDomainInfo:286) parseConfig: config is ['vm', ['name', 'j_sles10b9_full'], ['memory', '512'], ['maxmem', '512'], ['vcpus', '1'], ['on_poweroff', 'destroy'], ['on_reboot', 'destroy'], ['on_crash', 'destroy'], ['image', ['hvm', ['kernel', '/usr/lib/xen/boot/hvmloader'], ['device_model', '/usr/lib/xen/bin/qemu-dm'], ['boot', 'c'], ['cdrom', '/tests/iso/SLES-10-i386-Beta9.iso'], ['sdl', '1'], ['stdvga', '1'], ['vcpus', '1']]], ['device', ['vbd', ['dev', 'ioemu:hda'], ['uname', 'file:/var/lib/xen/images/j_sles10b9_full/hda'], ['mode', 'w']]], ['device', ['vif', ['mac', '00:16:3e:b2:68:1d'], ['bridge', 'xenbr0'], ['script', 'vif-bridge'], ['type', 'ioemu']]]] [2006-05-02 10:58:13 xend.XendDomainInfo] DEBUG (XendDomainInfo:382) parseConfig: result is {'ssidref': None, 'uuid': None, 'on_crash': 'destroy', 'on_reboot': 'destroy', 'localtime': None, 'image': ['hvm', ['kernel', '/usr/lib/xen/boot/hvmloader'], ['device_model', '/usr/lib/xen/bin/qemu-dm'], ['boot', 'c'], ['cdrom', '/tests/iso/SLES-10-i386-Beta9.iso'], ['sdl', '1'], ['stdvga', '1'], ['vcpus', '1']], 'on_poweroff': 'destroy', 'cpus': None, 'name': 'j_sles10b9_full', 'backend': [], 'cpu': None, 'vcpus': 1, 'cpu_weight': None, 'vcpu_avail': None, 'memory': 512, 'device': [('vbd', ['vbd', ['dev', 'ioemu:hda'], ['uname', 'file:/var/lib/xen/images/j_sles10b9_full/hda'], ['mode', 'w']]), ('vif', ['vif', ['mac', '00:16:3e:b2:68:1d'], ['bridge', 'xenbr0'], ['script', 'vif-bridge'], ['type', 'ioemu']])], 'bootloader': None, 'root': None, 'bootentry': None, 'maxmem': 512} [2006-05-02 10:58:13 xend.XendDomainInfo] DEBUG (XendDomainInfo:1189) XendDomainInfo.construct: None 0 [2006-05-02 10:58:13 xend.XendDomainInfo] DEBUG (XendDomainInfo:1221) XendDomainInfo.initDomain: 29 1.0 [2006-05-02 10:58:13 xend] DEBUG (image:266) args: cdrom, val: /tests/iso/SLES-10-i386-Beta9.iso [2006-05-02 10:58:13 xend] DEBUG (image:266) args: boot, val: c [2006-05-02 10:58:13 xend] DEBUG (image:266) args: fda, val: None [2006-05-02 10:58:13 xend] DEBUG (image:266) args: fdb, val: None [2006-05-02 10:58:13 xend] DEBUG (image:266) args: nic-ne2000, val: None [2006-05-02 10:58:13 xend] DEBUG (image:266) args: enable-audio, val: None [2006-05-02 10:58:13 xend] DEBUG (image:266) args: localtime, val: None [2006-05-02 10:58:13 xend] DEBUG (image:266) args: serial, val: None [2006-05-02 10:58:13 xend] DEBUG (image:266) args: std-vga, val: 1 [2006-05-02 10:58:13 xend] DEBUG (image:266) args: isa, val: None [2006-05-02 10:58:13 xend] DEBUG (image:266) args: vcpus, val: 1 [2006-05-02 10:58:13 xend] DEBUG (balloon:177) Balloon: free 2267; need 518; done. [2006-05-02 10:58:13 xend] INFO (image:135) buildDomain os=hvm dom=29 vcpus=1 [2006-05-02 10:58:13 xend] DEBUG (image:224) dom = 29 [2006-05-02 10:58:13 xend] DEBUG (image:225) image = /usr/lib/xen/boot/hvmloader [2006-05-02 10:58:13 xend] DEBUG (image:226) store_evtchn = 1 [2006-05-02 10:58:13 xend] DEBUG (image:227) memsize = 512 [2006-05-02 10:58:13 xend] DEBUG (image:228) vcpus = 1 [2006-05-02 10:58:13 xend] DEBUG (image:229) pae = 0 [2006-05-02 10:58:13 xend] DEBUG (image:230) acpi = 0 [2006-05-02 10:58:13 xend] DEBUG (image:231) apic = 0 [2006-05-02 10:58:13 xend] DEBUG (image:409) hvm shutdown watch registered [2006-05-02 10:58:13 xend] DEBUG (blkif:24) exception looking up device number for hda: [Errno 2] No such file or directory: '/dev/hda' [2006-05-02 10:58:13 xend] DEBUG (DevController:103) DevController: writing {'state': '1', 'backend-id': '0', 'backend': '/local/domain/0/backend/vbd/29/768'} to /local/domain/29/device/vbd/768. [2006-05-02 10:58:13 xend] DEBUG (DevController:105) DevController: writing {'domain': 'j_sles10b9_full', 'frontend': '/local/domain/29/device/vbd/768', 'dev': 'ioemu:hda', 'state': '1', 'params': '/var/lib/xen/images/j_sles10b9_full/hda', 'mode': 'w', 'frontend-id': '29', 'type': 'file'} to /local/domain/0/backend/vbd/29/768. [2006-05-02 10:58:13 xend] DEBUG (DevController:103) DevController: writing {'state': '1', 'backend-id': '0', 'backend': '/local/domain/0/backend/vif/29/0'} to /local/domain/29/device/vif/0. [2006-05-02 10:58:13 xend] DEBUG (DevController:105) DevController: writing {'bridge': 'xenbr0', 'domain': 'j_sles10b9_full', 'handle': '0', 'script': '/etc/xen/scripts/vif-bridge', 'state': '1', 'frontend': '/local/domain/29/device/vif/0', 'mac': '00:16:3e:b2:68:1d', 'frontend-id': '29', 'type': 'ioemu'} to /local/domain/0/backend/vif/29/0. [2006-05-02 10:58:13 xend] INFO (image:355) spawning device models: /usr/lib/xen/bin/qemu-dm ['/usr/lib/xen/bin/qemu-dm', '-d', '29', '-m', '512', '-cdrom', '/tests/iso/SLES-10-i386-Beta9.iso', '-boot', 'c', '-std-vga', '-vcpus', '1', '-domain-name', 'j_sles10b9_full', '-hda', '/var/lib/xen/images/j_sles10b9_full/hda', '-macaddr', '00:16:3e:b2:68:1d', '-bridge', 'xenbr0', '-nics', '1'] [2006-05-02 10:58:13 xend] INFO (image:357) device model pid: 3496 [2006-05-02 10:58:13 xend.XendDomainInfo] DEBUG (XendDomainInfo:675) Storing VM details: {'ssidref': '0', 'uuid': 'a3fc6694-3959-b4bf-85b3-0364c231c504', 'on_reboot': 'destroy', 'start_time': '1146589093.41', 'on_poweroff': 'destroy', 'name': 'j_sles10b9_full', 'vcpus': '1', 'vcpu_avail': '1', 'memory': '512', 'on_crash': 'destroy', 'image': '(hvm (kernel /usr/lib/xen/boot/hvmloader) (device_model /usr/lib/xen/bin/qemu-dm) (boot c) (cdrom /tests/iso/SLES-10-i386-Beta9.iso) (sdl 1) (stdvga 1) (vcpus 1))', 'maxmem': '512'} [2006-05-02 10:58:13 xend.XendDomainInfo] DEBUG (XendDomainInfo:700) Storing domain details: {'console/port': '2', 'name': 'j_sles10b9_full', 'console/limit': '1048576', 'vm': '/vm/a3fc6694-3959-b4bf-85b3-0364c231c504', 'domid': '29', 'cpu/0/availability': 'online', 'memory/target': '524288', 'store/ring-ref': '682307', 'store/port': '1'} [2006-05-02 10:58:13 xend] DEBUG (image:432) hvm_shutdown fired, shutdown reason=None [2006-05-02 10:58:13 xend.XendDomainInfo] DEBUG (XendDomainInfo:881) XendDomainInfo.handleShutdownWatch

1 0

Re: [Libvir] Request for additional entry points
by Bret McMillan 27 Apr '06

27 Apr '06

On Thu, 2006-04-13 at 12:00 -0400, libvir-list-request(a)redhat.com wrote: > We've discussed this before and I think the most compelling argument for > passive domain support in libvirt (and even at a lower level such as > Xend) is the following scenario: > > Let's say a user creates a virtual FC6 virtual machine that she is going > to use to test her apps under Gnome (she's a KDE user). The machine > isn't always there b/c she rarely needs it. She created it with some > nifty KDE tool that has yet to be written. > > Of course, she finds out about this neat applet that you can use to > managing running domains. If there isn't a common way of accessing > passive domains then she won't see the FC6 VM. > > Now, I don't think that *all* domains should have to have passive > equivalents (which is a requirement in the CIM provider today) because > of some of the scenarios you outlined. However, I think not attempting > to have a common API for passive domains is going to creative a mess as > we get a larger number of management tools. I think we're confusing the notion of what a passive domain is with what config files happen to be sitting on / exposed to the dom0 machine. I could very easily look at having an rdbms store the info about the passive domain, hand that down to the dom0 via rpc, and directly call the createLinux call. To me, that's still a passive domain, even though it's configs haven't touched disk yet. I guess I'm also struggling to understand why you'd toss this into xenstore... it just seems this is a higher level concept that needs to be tracked in too specific a way by management systems. --Bret

6 12

[Libvir] Perl API for using libvirt
by Daniel P. Berrange 26 Apr '06

26 Apr '06

Hi Folks, I had a couple of hours spare, so I put together a set of Perl bindings for libvirt. I'm currently calling the module Sys::Virt which seems to be the most appropriate location in the CPAN namespace, but I'm open to suggestions if people think that sucks. I've currently got near 100% coverage of the C APIs, but not exposed all the static constants yet. There are a couple of trivial example programs illustrating use of the API for extracting info about domains.=20 For now you can grab a snapshot of the source for the binding using=20 Mercurial from the URL: http://hg.berrange.com/libraries/sys-virt When I've tested it more completely I'll upload it to CPAN Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 3

RE: [Libvir] Problems installing libvir
by Subrahmanian, Raj 25 Apr '06

25 Apr '06

Daniel, This was more of a hurried hack just changing all curses to ncurses :-) I know it's no excuse, but I was in a hurry to start linking to libvirt. I will work on a cleaner change to configure.in and forward it to you later today? Thanks Raj PS. Didn't Jim Fehlig mention that he has already fixed this? -----Original Message----- From: Daniel Veillard [mailto:veillard@redhat.com] Sent: Tuesday, April 25, 2006 4:06 AM To: Subrahmanian, Raj Cc: libvir-list(a)redhat.com Subject: Re: [Libvir] Problems installing libvir On Mon, Apr 24, 2006 at 09:25:45PM -0400, Subrahmanian, Raj wrote: > > ncurses vs. curses ? > Ohh, and I was looking right at it! > Sorry folks. > I hacked the configure file to look for ncurses and sure enough it > worked. Can you send the diff you made to configure.in so we can fix configure to work with both libraries ? Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

3 2

RE: [Libvir] Problems installing libvir
by Subrahmanian, Raj 25 Apr '06

25 Apr '06

> ncurses vs. curses ? Ohh, and I was looking right at it! Sorry folks. I hacked the configure file to look for ncurses and sure enough it worked. Thanks for the help. Raj

3 3

[Libvir] Re: [Xen-cim] LTC provider working on SLES/openwbem
by Jim Fehlig 25 Apr '06

25 Apr '06

Daniel Veillard wrote: >On Thu, Apr 20, 2006 at 04:24:28PM -0600, Jim Fehlig wrote: > > >>FYI, >> >>I have managed to get one of the LTC providers (Xen_ComputerSystem) >>working on SLES using openwbem cimom, the xm shim, and libvirt. The >>following changes were made: >> >>libvirt >>- changed xend_parse_sexp_desc() to not fail if kernel not found. sexp >>from xend does not contain kernel for domain 0. >> >> > > Makes sense, could you send that patch ? > > thanks, > >Daniel > > Attached. Jim

2 1

[Libvir] Problems installing libvir
by Subrahmanian, Raj 25 Apr '06

25 Apr '06

All, I am trying to install libvir on my SUSE box. The .configure command halts with the following message. ibxml2 xml2-config ... yes ('') checking for initscr in -lcurses... no configure: error: curses library not found But, I have installed curses, and cdk. linux:~/xen/libvirt-0.1.0 # whereis curses curses: /usr/include/curses.h /usr/include/curses What am I missing out here? thanks Raj

4 3

[Libvir] FC5 bug with kernel/initrd paths
by Daniel Hiltgen 21 Apr '06

21 Apr '06

I just started experimenting with libvirt on FC5 and ran into something that doesn't seem quite right. I've created a VM using the xenguest-install.py script. I've tried grabbing the XML from virsh using dumpxml, but the kernel and initrd paths are invalid. Specifically: ... <os> <type>linux</type> <kernel>/var/lib/xen/vmlinuz.276riA</kernel> <initrd>/var/lib/xen/initrd.z1bslj</initrd> <cmdline>ro root=/dev/VolGroup00/LogVol00 rhgb quiet</cmdline> </os> ... (I see the same bogus paths in xm list --long) If I shut down the VM and attempt to power it back on using the API and this XML definition, it fails with: libvir: Xen Daemon error : POST operation failed: No such domain guest1i Failed to get devices for domain guest1 error: Failed to create domain If I boot up the VM, and copy the kernel and initrd image out of it's /boot partition onto the main filesystem, and tweak the XML to point to those paths, I can boot the system through libvirt, but the files are automatically deleted after I boot. Also, every time I boot using xm create, I get a different bogus kernel/initrd path. Is this expected behavior, or is there a bug/mismatch between libvirt and the underlying Xen modules in FC5? Thanks, Daniel

2 1

[Libvir] Add a timestamp to virDomainInfo ?
by Daniel P. Berrange 19 Apr '06

19 Apr '06

The primary use of the virDomainInfo data is in calculating resource utilization over time. The CPU runtime data, however, is represented as a counter, so to calulate utilization requires some transformations. Basically subtract the CPU runtime value for time X, from the value at time Y, and divide the result by Y-X. Obviously this requires us to know the times X & Y. Currently the virDomainInfo structure does not contain this information though, so apps have to call something like gettimeofday() before virDomainGetInfo(), to record the timestamp of each virDomainInfo record. The problem is that this is a pretty poor approximation - particularly if libvirt is talking via XenD, a non-trivial period of time can pass between the call to gettimeofday() and the values for virDomainInfo actually sampled. Thus I would like to suggest that the virtDomainInfo structure be expanded to add an extra data field of type 'struct timeval' to record a high resolution timestamp. Now currently this wouldn't help accuracy all that much, since libvirt would still be filling this in much the same way as the app did. It does however, open the door to having Xen itself provide an accurate timestamp back to libvirt, which would in turn benefit apps without requiring further code change. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 6

[Libvir] libvirt.org is down
by Daniel Veillard 18 Apr '06

18 Apr '06

I will try to get it restarted tomorrow morning, sorry for the annoyance. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

1 0

[Libvir] Request for additional entry points
by Jim Fehlig 13 Apr '06

13 Apr '06

As discussed on the xen-cim call on 3/31, the Xen CIM provider needs some additional entry points in libvirt. I would like to open a discussion about adding the following entry points to libvirt. virDomainSetConfig(virConnectPtr conn, const char *xmlDesc) Stores the domU config data in xenstore. The domU is not running yet but enumerating domains would return the config for the domain as well as any running domains. This would support the notion of a defined but inactive virtual machine. Daniel noted that the config could be cached in libvirt, preventing (to some degree) modifying the config out-of-band prior to activating the domain. Note that the current virConnectListDomains() implies enumerating only running domains since a list of domain IDs is returned. Perhaps virConnectListDomains() will have to be expanded to include defined domains or another entry point to enumerate defined domains. Related would be activating a defined domain. Would clients get the domain config (via virDomainGetXMLDesc()) and subsequently pass it to virDomainCreateLinux() or another entry point to create a defined domain? virDomainDeleteConfig(virConnectPtr conn, const char *name) Removed domU config from xenstore (or cache). DomU no longer "exists". What if domain is active upon invocation? virDomainSetCurrentMemory(virDomainPtr domain, unsigned long memory) Adjust the current memory usage for a domain. virDomainReboot(virDomainPtr domain) Reboot the domain. virDomainMigrate(virDomainPtr domain, const char *host) ?? Not sure what can of worms might be opened by this one :-). Thoughts? BTW, I can certainly help with the effort if an agreement is reached on adding this functionality. Regards, Jim

7 14