- Devel - libvirt List Archives

[Libvir] Connecting to remote hypervisors?
by Nick Devito 13 Jul '06

13 Jul '06

I might be overlooking something, but, I don't see anything on the libvirt site about it. Does libvirt support connecting to a remote hypervisor, if so, how? Thanks, Nick Devito

3 2

[Libvir] Updated snapshot of virt-manager GUI application
by Daniel P. Berrange 12 Jul '06

12 Jul '06

I have just pushed out RPM / tar.gz of a new development (alpha) snapshot of the virt-manager GUI application. The changes in this snapshot are: * Fixed DBus service activation & general brokeness * Added a display of virtual CPU count in summary view * Fixed alignment of status label in details page * Make hardware config panel resizeable * Switch detailed graph rendering to use sparkline code instead of matplotlib, removing a huge RPM dependancy chain * Switch to use filled sparkline graphs instead of outline Although I didn't increment the RPM dependancy, I strongly recommend using libvirt 0.1.3 if your host is running > 5 guest domains. This reduces the number of HTTP GETs made by an order of magnitude, improving the response time / scalability of the virt-manager refresh. 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 -=|

1 0

[Libvir] Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs
by michel.ponceau＠bull.net 11 Jul '06

11 Jul '06

1) PinVcpu : I consider the size of CPU map in bytes, that is (max_nb_CPUs + 7) / 8 . 2) CPU map cut into standard + extension : It would be more simple to let each Libvirt user modify the value of VIR_MAX_CPUS in private libvirt.h. It could be similar to the version number update, from libvirt.h.in to libvirt.h : #define LIBVIR_VERSION_NUMBER @LIBVIRT_VERSION_NUMBER@ Veuillez répondre à veillard(a)redhat.com Pour : michel.ponceau(a)bull.net cc : libvir-list(a)redhat.com Objet : Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs On Tue, Jul 11, 2006 at 04:14:12PM +0200, michel.ponceau(a)bull.net wrote: > Corrections on proposal: > 1) PinVcpus > Replace: > * @cpumap: pointer to a bit map of real CPUs (format in virVcpuInfo) > * @maplen: length of cpumap, in 8-bit bytes > by: > * @cpumap: pointer to a bit map of real CPUs (in 8-bit bytes). > * Each bit set to 1 means that corresponding CPU is usable. > * Bytes are stored in little-endian order: CPU0-7, 8-15... > * In each byte, lowest CPU number is least significant bit. > * @maplen: number of bytes in cpumap, from 1 up to size of CPU map in > * underlying virtualization system (Xen...). > * If maplen < size, missing bytes are set to zero. > * If maplen > size, failure code is returned. Okay, that's sensible I guess except for maplen it can go from 1 to size + 7 div 8 not up to size , right ? > 2) GetVcpu > Add 4rth argument: > * @maplen: number of bytes in cpumap field of virVcpuInfo > virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int maxinfo, > int maplen) > > 3) Structure VcpuInfo > Suppress: #define VIR_MAX_CPUS 256 > Replace: > unsigned char cpumap[VIR_MAX_CPUS/8]; /* Bit map of usable real CPUs. > by: > unsigned char cpumap[]; /* Bit map of usable real CPUs. > Variable length: it may be less or greater than size of CPU map in > underlying virtualization system (Xen...). Hum, I could see compilers righteously complaining about unsigned char cpumap[]; in a structure. Maybe we should default to 256 / 8 but allow at the API level to grow over that value. What we could do is define a default of 256 available in the structure and allow an extra parameter which could point to a larger array like the following: - restore VIR_MAX_CPUS as VIR_STD_MAX_CPUS 256 - virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int maxinfo, char *lcpumap, int lmaplen); lcpumap and lmaplen being extra arguments for very large arrays for most use case, we will fit in 256 processors, those will be respectively NULL and 0, but assuming we have more than 256 processors: + maxinfo > VIR_STD_MAX_CPUS + lcpumap points to a array of bytes, they are interpreted as an array of cpumap of ((maxinfo + 7) div 8) bytes each. So if lmaplen != ((maxinfo + 7) div 8) * maxinfo then there is an error. in that case the cpumap structures of info are not filled on return. We still have a relatively simple API for the common case, and for special cases we have an extension capability with relatively clear definitions. it's a bitstrange but I think that should cover most case as best as possible > 4) Accessor macros: to be defined later. okay, 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/

2 1

[Libvir] Release of libvirt-0.1.2
by Daniel Veillard 11 Jul '06

11 Jul '06

Available at ftp://libvirt.org/libvirt/ This release includes only a couple of things: - fix the header include problem reported last week - add a proxy based driver for read only access from non-root users In a nutshell the proxy goal is to allow monitoring from unpriviledged users by running a proxy which is a small binary running as root accepting connections from libvirt instances and implementing then using either xend RPCs or hypervisor calls. Only read-only operations are implemented i.e. it is useful for monitoring. This requires the (xend-unix-server yes) option to be set in /etc/xen/xend-config.sxp since the proxy connects to xend with the httpdu local socket, that done one can disable the xend-http-server . The proxy itself is started and stopped automatically by the library on-demand. The communication between libvirt instances and the proxy is custom, currently only synchronous operations are implemented but it should be possible to add asynchronous event passing if libvirt is extended this way. The next things I will focuse on are: the 4 unimplemented yet APIs for defined but non-running domains, the CPU extensions which have been proposed last week and the HVM (fully virtualized) Xen domain support sent by Jim Fehlig. 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 1

[Libvir] Updated patch for hvm guests
by Jim Fehlig 11 Jul '06

11 Jul '06

Attached is an updated patch providing some support for HVM guests. I have tested listing info on running guests and creating guests. cdrom support for HVM guests still needs some work, as does graphics options. Guests using graphics type 'sdl' still need some work. Using type 'vnc' is functional, but you must then manually use e.g. "vncviewer localhost:<dom_id>" to view. I've also included a patch that backs out some optimizations done xend_internal.c. There is a bug in xend (from testing - I think Anthony fixed it and patch got applied to unstable) that does not close the connection after initial create op causing libvirt to block indefinitely. Backing out the optimizations allowed me to use the hvm patch on _testing branch of xen. I've included it for anyone else that may want to experiment with the hvm patch on _testing xen. Finally, the attached archive contains: 1. a sample xml input file for hvm guest, 2. corresponding s-expr sent to xend, and 3. s-expr returned from xend when getting info on the running guest. I will be on vacation and not have access to network until July 9. I will improve this work after returning. Enjoy, Jim

3 9

[Libvir] Proposal : add 3 functions to Libvirt API, for virtual CPUs
by michel.ponceau＠bull.net 10 Jul '06

10 Jul '06

For our administration, we need the following actions, while concerned domain is running: 1) Change the number of virtual CPUs. 2) Change the pinning (affinity) of a virtual CPU on real CPUs. 3) Get detailed information for each virtual CPU. Currently there is no Libvirt function provided for that. We suggest to add the following 3 functions (in libvirt.c): /** * virDomainSetVcpus: * @domain: pointer to domain object, or NULL for Domain0 * @nvcpus: the new number of virtual CPUs for this domain * * Dynamically change the number of virtual CPUs used by the domain. * Note that this call may fail if the underlying virtualization hypervisor * does not support it or if growing the number is arbitrary limited. * This function requires priviledged access to the hypervisor. * * Returns 0 in case of success, -1 in case of failure. */ int virDomainSetVcpus(virDomainPtr domain, unsigned int nvcpus) /** * virDomainPinVcpu: * @domain: pointer to domain object, or NULL for Domain0 * @vcpu: virtual CPU number * @cpumap: pointer to a bit map of real CPUs (format in virVcpuInfo) * @maplen: length of cpumap, in 8-bit bytes * * Dynamically change the real CPUs which can be allocated to a virtual CPU. * This function requires priviledged access to the hypervisor. * * Returns 0 in case of success, -1 in case of failure. */ int virDomainPinVcpu(virDomainPtr domain, unsigned int vcpu, unsigned char *cpumap, int maplen) /** * virDomainGetVcpus: * @domain: pointer to domain object, or NULL for Domain0 * @info: pointer to an array of virVcpuInfo structures * @maxinfo: number of structures in info array * * Extract information about virtual CPUs of a domain, store it in info array. * * Returns the number of info filled in case of success, -1 in case of failure. */ int virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int maxinfo) with the following structure (in libvirt.h): /** * virVcpuInfo: structure for information about a virtual CPU in a domain. */ #define VIR_MAX_CPUS 256 typedef enum { VIR_VCPU_OFFLINE = 0, /* the virtual CPU is offline */ VIR_VCPU_RUNNING = 1, /* the virtual CPU is running */ VIR_VCPU_BLOCKED = 2, /* the virtual CPU is blocked on resource */ } virVcpuState; typedef struct _virVcpuInfo virVcpuInfo; struct _virVcpuInfo { unsigned int number; /* virtual CPU number */ int state; /* value from virVcpuState */ unsigned long long cpuTime; /* CPU time used, in nanoseconds */ int cpu; /* real CPU number, or -1 if offline */ unsigned char cpumap[VIR_MAX_CPUS/8]; /* Bit map of usable real CPUs. Each bit set to 1 means that corresponding CPU is usable. Bytes are stored in little-endian order: CPU0-7, 8-15... In each byte, lowest CPU number is least significant bit */ }; typedef virVcpuInfo *virVcpuInfoPtr; I have successfully tried those functions via Xen hypervisor, except for the first (SetVcpus) where hypervisor operation DOM0_MAX_VCPUS fails (maybe it is not possible on a running domain ?). That function was successful via Xen daemon.

3 2

[Libvir] Scability / performance fix for virDomainLookupByID
by Daniel P. Berrange 10 Jul '06

10 Jul '06

Attached is a patch to significantly increase scalability / performance of the xenDaemonLookupByID method. The current implementation would get a list of all domain names from XenD, and then iterate doing a HTTP GET on /xend/domain/[name] until the domain with match ID was found. THis had O(n) complexity, with the result that when running on a system with 20 actives domains, 'virsh list' would have O(n^2) complexity needing ~230 HTTP calls, giving a runtime of ~9 seconds. The patch is to make the code do a HTTP GET on /xend/domain/[id] which we just discovered is a valid URL to access. This makes the method call O(1), and 'virsh list' is now a saner O(n), and completes in ~1 second. While still not great performance, this is certainly much better. I think it ought to be possible to optimize the code still further so that XenD is avoided altogether for simple commands which can be fullfilled purely with data available from Hypervisor, but that will need further investigation. Please review the patch in case I missed any bugs / edge cases 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 5

[Libvir] support for hvm guests
by Jim Fehlig 03 Jul '06

03 Jul '06

Daniel, FYI, I'm working on a patch to support hvm guests. Attached is the work thus far. Calling "virsh dumpxml some_hvm_guest" will (almost) correctly dump xml config info on hvm guests. Needs to handle "type=ioemu" component of VIF specification. Currently in the XML there is a type attribute for the interface element that specifies bridge, route, etc. How would you like to structure the interface element and its children to account for hvm guests? Using "virsh create file" where file contains XML config for hvm guests may be close to working but I haven't tested it yet. There are several options that need to be added to the XML to support hvm guests. If we can agree on the structure I can add the functionality. Regards, Jim

6 25

[Libvir] Xen/libVirt GUI app: "Virtual Machine Manager"
by Daniel P. Berrange 28 Jun '06

28 Jun '06

I'm pleased to make available the code for an early *development snapshot* of a graphical application for managing virtual machines. This application is using libvirt as its backend API for managing virtual machines, while the user interface is built in Python and GTK/Glade. The application allows monitoring of guest VM resource utilization / allocation. There are basic controls for controlling the run state of guest. There is also a VNC client widget (written in pure Python!) for displaying the virtual guest framebuffer on fully-virt machines: http://people.redhat.com/berrange/virt-manager/index.html This is a very early snapshot - lots of functionality isn't hooked up yet, the error handling is mostly not there, and there are certainly plenty of bugs. It should none-the-less give a reasonable feel for the kind of direction the application will evolve in. Furthermore the website includes the UI mockups done by our user interaction designers to show some of the ideas considered in ongoing development of the application. The RPMs linked to from the website should install on both Fedora Core 5[1] and Fedora Core 6 test1. The FAQ contains a list of explicit dependancies which should facilitate people trying to get it running on non-Fedora Linux distros. Regards, Dan. [1] You'll need libvirt-0.1.1 from updates-testing -- |=- 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 -=|

1 0

[Libvir] just a question about virDomainLookupByName function
by Philippe Berthault 28 Jun '06

28 Jun '06

An ID may be passed to virDomainLookupByName function. In exemple: virDomainLookupByName(conn, "1") is equivalent to virDomainLookupByID(conn, 1) This functionality is very useful but isn't written in the libvirt documentation. Is this functionality will continue to exist in future versions of libvirt or not ? Thanks, Philippe Berthault.

2 1