March 2007 - Devel - libvirt List Archives

[Libvir] [PATCH] Fix dom0 maxmem display for memmax not set case
by Atsushi SAKAI 16 Mar '07

16 Mar '07

Hi, This patch intends to fix dom0 maxmem display. If we do NOT set maximum memory, max_pages (in Xen) are set maximum value(0xFFFFFFFF). This display confuses user. For x86 cases, following data are shown on "virsh dominfo 0" (please case 4kb page size This case max_pages x 4 is output). Max memory: 4294967292 kB This patch fix as follows Max memory: no limit (This comment is taken from xentop :-)) This problem is already cared on xentop (Xen performance tool). Signed-off-by: Atsushi SAKAI <sakaia(a)jp.fujitsu.com> Thanks Atsushi SAKAI diff -urpN libvirt.orig/src/virsh.c libvirt/src/virsh.c --- libvirt.orig/src/virsh.c 2007-03-09 22:44:24.000000000 +0900 +++ libvirt/src/virsh.c 2007-03-15 20:13:04.000000000 +0900 @@ -1186,8 +1186,13 @@ cmdDominfo(vshControl * ctl, vshCmd * cm vshPrint(ctl, "%-15s %.1lfs\n", _("CPU time:"), cpuUsed); } - vshPrint(ctl, "%-15s %lu kB\n", _("Max memory:"), + if (info.maxMem != UINT_MAX) + vshPrint(ctl, "%-15s %lu kB\n", _("Max memory:"), info.maxMem); + else + vshPrint(ctl, "%-15s %-15s\n", _("Max memory:"), + _("no limit")); + vshPrint(ctl, "%-15s %lu kB\n", _("Used memory:"), info.memory); diff -urpN libvirt.orig/src/xen_internal.c libvirt/src/xen_internal.c --- libvirt.orig/src/xen_internal.c 2007-03-15 16:43:16.000000000 +0900 +++ libvirt/src/xen_internal.c 2007-03-15 19:38:17.000000000 +0900 @@ -1598,7 +1598,9 @@ xenHypervisorGetDomInfo(virConnectPtr co */ info->cpuTime = XEN_GETDOMAININFO_CPUTIME(dominfo); info->memory = XEN_GETDOMAININFO_TOT_PAGES(dominfo) * kb_per_pages; - info->maxMem = XEN_GETDOMAININFO_MAX_PAGES(dominfo) * kb_per_pages; + info->maxMem = XEN_GETDOMAININFO_MAX_PAGES(dominfo); + if(info->maxMem != UINT_MAX) + info->maxMem *= kb_per_pages; info->nrVirtCpu = XEN_GETDOMAININFO_CPUCOUNT(dominfo); return (0); }

2 3

[Libvir] [PATCH] Make libvirt build when xen-devel is not installed
by Hugh Brock 15 Mar '07

15 Mar '07

After the Capabilities patch went in, we discovered that although we could supposedly build libvirt without xen-devel installed, in fact we needed to be more aggressive with ifdefs (and conditionally turn off compilation of some tests that only test xen features). This patch makes it possible to compile libvirt with neither qemu nor xen-devel installed. Signed-off-by: Hugh Brock <hbrock(a)redhat.com> -- Red Hat Virtualization Group http://redhat.com/virtualization Hugh Brock | virt-manager http://virt-manager.org hbrock(a)redhat.com | virtualization library http://libvirt.org

2 1

[Libvir] virConnectGetCapabilities patch, 2007-03-15 (version 2)
by Richard W.M. Jones 15 Mar '07

15 Mar '07

This is the latest version of the capabilities patch, which should address all concerns which have been raised since the last version. Also attached, example XML produced by different backends. Note as before this has not been tested in the Xen case, because I don't have access to a working Xen machine (laptop still broken, desktop still lacking working SATA drivers, other desktop still lacking wired network...). Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759) <capabilities> <host> <cpu> <arch>x86_64</arch> </cpu> </host> <guest> <os_type>hvm</os_type> <arch name="x86_64"> <wordsize>64</wordsize> <emulator>/usr/bin/qemu-system-x86_64</emulator> <domain type="qemu"/> <machine>pc</machine> <machine>isapc</machine> <domain type="kqemu"/> <domain type="kvm"> <emulator>/usr/bin/qemu-kvm</emulator> </domain> </arch> </guest> <guest> <os_type>hvm</os_type> <arch name="i686"> <wordsize>32</wordsize> <emulator>/usr/bin/qemu</emulator> <domain type="qemu"/> <machine>pc</machine> <machine>isapc</machine> </arch> </guest> <guest> <os_type>hvm</os_type> <arch name="mips"> <wordsize>32</wordsize> <emulator>/usr/bin/qemu-system-mips</emulator> <domain type="qemu"/> <machine>mips</machine> </arch> </guest> <guest> <os_type>hvm</os_type> <arch name="mipsel"> <wordsize>32</wordsize> <emulator>/usr/bin/qemu-system-mipsel</emulator> <domain type="qemu"/> <machine>mips</machine> </arch> </guest> <guest> <os_type>hvm</os_type> <arch name="sparc"> <wordsize>32</wordsize> <emulator>/usr/bin/qemu-system-sparc</emulator> <domain type="qemu"/> <machine>sun4m</machine> </arch> </guest> <guest> <os_type>hvm</os_type> <arch name="ppc"> <wordsize>32</wordsize> <emulator>/usr/bin/qemu-system-ppc</emulator> <domain type="qemu"/> <machine>g3bw</machine> <machine>mac99</machine> <machine>prep</machine> </arch> </guest> </capabilities> <capabilities> <host> <cpu> <arch>x86_64</arch> </cpu> </host> <guest> <os_type>hvm</os_type> <arch name="x86_64"> <wordsize>64</wordsize> <emulator>/usr/bin/qemu-system-x86_64</emulator> <domain type="qemu"/> <machine>pc</machine> <machine>isapc</machine> </arch> </guest> <guest> <os_type>hvm</os_type> <arch name="i686"> <wordsize>32</wordsize> <emulator>/usr/bin/qemu</emulator> <domain type="qemu"/> <machine>pc</machine> <machine>isapc</machine> </arch> </guest> <guest> <os_type>hvm</os_type> <arch name="mips"> <wordsize>32</wordsize> <emulator>/usr/bin/qemu-system-mips</emulator> <domain type="qemu"/> <machine>mips</machine> </arch> </guest> <guest> <os_type>hvm</os_type> <arch name="mipsel"> <wordsize>32</wordsize> <emulator>/usr/bin/qemu-system-mipsel</emulator> <domain type="qemu"/> <machine>mips</machine> </arch> </guest> <guest> <os_type>hvm</os_type> <arch name="sparc"> <wordsize>32</wordsize> <emulator>/usr/bin/qemu-system-sparc</emulator> <domain type="qemu"/> <machine>sun4m</machine> </arch> </guest> <guest> <os_type>hvm</os_type> <arch name="ppc"> <wordsize>32</wordsize> <emulator>/usr/bin/qemu-system-ppc</emulator> <domain type="qemu"/> <machine>g3bw</machine> <machine>mac99</machine> <machine>prep</machine> </arch> </guest> </capabilities> <capabilities> <host> <cpu> <arch>i686</arch> <features> <pae/> <nonpae/> </features> </cpu> </host> <guest> <os_type>linux</os_type> <arch name="i686"> <wordsize>32</wordsize> <domain type="test"/> </arch> <features> <pae/> <nonpae/> </features> </guest> </capabilities>

1 0

[Libvir] Proposed XML format for capabilities, with examples [long]
by Richard W.M. Jones 15 Mar '07

15 Mar '07

Lots of people had various things to say about the first capabilities patches (see thread starting here: https://www.redhat.com/archives/libvir-list/2007-March/msg00153.html) So I thought I'd try to pull together ideas into a single thread, and post some information about what this is trying to achieve and some example proposed XML. Motivation ---------- At the moment there is a considerable amount of conditional code in libvirt clients. For example the following code from virt-manager (src/virtManager/create.py): if self.connection.get_type() == "QEMU": <------- 1 self.window.get_widget("virt-method-pv").set_sensitive(False) self.window.get_widget("virt-method-fv").set_active(True) self.window.get_widget("virt-method-fv-unsupported").hide() self.window.get_widget("virt-method-fv-disabled").hide() else: self.window.get_widget("virt-method-pv").set_sensitive(True) self.window.get_widget("virt-method-pv").set_active(True) if virtinst.util.is_hvm_capable(): <--------- 2 self.window.get_widget("virt-method-fv").set_sensitive(True) self.window.get_widget("virt-method-fv-unsupported").hide() self.window.get_widget("virt-method-fv-disabled").hide() This hopefully demonstrates two points which I'd like to fix: Firstly having code which requires knowledge of what a driver is capable of (line 1 above) is not scalable as we add more and more types of virtualisation (OpenVZ, VMWare, ...). Secondly the virtinst.util module does some probing to find out what the local hardware is capable of (line 2 above), and that won't work over remote connections. Thirdly, although you can only really connect to one driver at a time (except in the Xen case, but that's just weird), the <domain> description required by virDomainCreateLinux is to some extent driver-specific. So you need additional logic when creating domains, and for some of those (eg. qemu/kqemu/kvm) it's non-trivial and depends on information that you "just know" about the driver. The proposed new API ("virConnectGetCapabilities") would return an XML description of the capabilities of the driver / hypervisor. In the remote case, probing would be done on the remote machine. In either case the idea would be to remove conditional code from virt-manager, remove local hardware probing from virtinst, and provide some description of what optional features the <domain> XML supports. In the next two sections I'll analyse the problem areas in the current virtinst and virt-manager. You may want to skip the next two sections and go straight to the example XML. Analysis of virtinst -------------------- The main issue is with virtinst/util.py which contains the following functions which do local probing: (1) is_pae_capable: host supports PAE? Uses Linux-specific /proc/cpuinfo (2) is_hvm_capable: host supports HVM & enabled in Xen? Uses Xen-specific /sys/hypervisor/properties/capabilities (3) is_kqemu_capable: [Linux] kernel supports kqemu? Uses Linux-specific /dev/kqemu (4) is_kvm_capable: [Linux] kernel supports kvm? Uses Linux-specific /dev/kvm In virtinst/FullVirtGuest.py: (5) "emulator" and "loader" must be specified for Xen/QEMU and Xen guests respectively. They have architecture- and distro-specific paths which refer to files on the remote machine. In virtinst/ParaVirtGuest.py: (6) Uses "xm console" to connect to the console in the Xen case (but then this sort of paravirtualisation implies Xen). In virtinst/DistroManager.py: (7) We download the kernel and boot.iso files, and download and modify the initrd file. [Comment: I'm not sure that capabilities can solve this, but it does need to be fixed properly for the remote case to work]. Analysis of virt-manager ------------------------ In src/virtManager/create.py: (8) Tries to detect if VT-x/AMD-V is present in the hardware but disabled in the BIOS by doing some Xen-specific heuristics. (9) Paravirt and fullvirt dialogs are enabled based on the type of the connection (eg. if self.connection.get_type() == "QEMU" it disables paravirt). (10) CPU architecture combo box is enabled only for type == "QEMU". (11) Similarly, the "accelerate" checkbox is enabled only for type == "QEMU". [Comment: Dan tells me that this requirement comes about because kqemu is sometimes unreliable, so users need a way to disable it]. (12) Local media are required for FV installs. Also we use HAL to detect media inserted and removed. [Comment: Can be solved separately by abstracting storage]. In the *.glade files: (13) The list of CPU architectures for qemu is hard-coded in the interface description file. Other areas which are beyond the role of capabilities: * Remote console * Serial console * Saving images Proposed XML format ------------------- My thoughts are that capabilities need to return the following information about the underlying driver/hypervisor: * Host CPU flags (1,8) * List of guest architectures supported. For each of these: - Model of virtualised CPU (10,13) example: x86_64 - Name of the virtualised machine (if applic.) example: pc - Virtualised CPU features: PAE, ... - Fullvirt flag: can we run an unmodified OS as a guest? (2,9) or Paravirt: what sort of paravirt API does a guest need (eg. xen, pvops, VMI, ...)? - The <domain type='?'> for this guest example: kqemu - The <domain><os><type machine='?'> for this guest (if applic.) example: pc - Suggested emulator and loader paths (5) - Driver-specific flags which libvirt clients would not be required to understand, but could be used to enhance libvirt clients. examples: uses kqemu, uses kvm (3,4,11) (Notes: (a) I have flattened qemu's nested arch/machine list, because I there is not a natural hierarchy. (b) The guest architectures list is a Cartesian product, although at the moment the worst case (qemu) would only have about 14 entries. An alternate way to do this is discussed at the end. (c) The host CPU model is already provided by virNodeGetInfo). Example: Xen ------------ For Xen the primary source for capabilities are the files /sys/hypervisor/properties/capabilities and /proc/cpuinfo. A Xen driver might present the following description of its capabilities: <capabilities> <host> <cpu_flags> <cpu_flag> vmx </cpu_flag> <cpu_flag> pae </cpu_flag>  </cpu_flags> </host> <guest_architectures> <guest_architecture> <model> x86_64 </model> <paravirt> xen </paravirt> <domain_type> xen </domain_type> <emulator> /usr/lib/xen/bin/qemu-dm </emulator> </guest_architecture> <guest_architecture> <model> i686 </model> <pae/> <paravirt> xen </paravirt> <domain_type> xen </domain_type> <emulator> /usr/lib/xen/bin/qemu-dm </emulator> </guest_architecture> <guest_architecture> <model> i686 </model> <fullvirt/> <domain_type> xen </domain_type> <loader> /usr/lib/xen/boot/hvmloader </loader> <emulator> /usr/lib/xen/bin/qemu-dm </emulator> </guest_architecture> <guest_architecture> <model> i686 </model> <pae/> <fullvirt/> <domain_type> xen </domain_type> <loader> /usr/lib/xen/boot/hvmloader </loader> <emulator> /usr/lib/xen/bin/qemu-dm </emulator> </guest_architecture> <guest_architecture> <model> x86_64 </model> <fullvirt/> <domain_type> xen </domain_type> <loader> /usr/lib/xen/boot/hvmloader </loader> <emulator> /usr/lib/xen/bin/qemu-dm </emulator> </guest_architecture> </guest_architectures> </capabilities> Example: qemu + kqemu + kvm --------------------------- Qemu has by far the longest list of supported guest architectures. Out of the box it supports 10 distinct machine types and then you can add 4 extra machine types if the kernel can do kqemu and kvm, making 14 in all. Below I have abbreviated this list for clarity. <capabilities> <host> <cpu_flags> <cpu_flag> vmx </cpu_flag> <cpu_flag> pae </cpu_flag>  </cpu_flags> </host> <guest_architectures> <guest_architecture> <model> sparc </model> <machine> sun4m </machine> <fullvirt/> <domain_type> qemu </domain_type> <machine_type> sun4m </machine_type> <emulator> /usr/bin/qemu-system-sparc </emulator> </guest_architecture> <guest_architecture> <model> i686 </model> <machine> pc </machine> <fullvirt/> <domain_type> qemu </domain_type> <machine_type> pc </machine_type> <emulator> /usr/bin/qemu </emulator> </guest_architecture> <guest_architecture> <model> x86_64 </model> <machine> pc </machine> <fullvirt/> <domain_type> kqemu </domain_type> <machine_type> pc </machine_type> <emulator> /usr/bin/qemu </emulator> <qemu_uses_kqemu /> </guest_architecture> <guest_architecture> <model> x86_64 </model> <machine> pc </machine> <fullvirt/> <domain_type> kvm </domain_type> <machine_type> pc </machine_type> <emulator> /usr/bin/qemu-kvm </emulator> <qemu_uses_kvm /> </guest_architecture> </guest_architecture> </capabilities> Guest architectures: Cartesian product or UI builder? ----------------------------------------------------- Currently the list of guest architectures is a flat list, worst case 5 entries long for Xen and 14 entries long for qemu. Presenting this in user interfaces could be challenging. One suggestion is that the user interface looks like: [*] Show only fullvirt [*] Show only PC architectures [ ] Show 32 bit architectures [*] Show 64 bit architectures | Shorter list of architectures which match | the criteria checked above. | ... | Another is that we change the XML description so that it matches the UI. For instance: <guest_architecture> <models> <model> sparc </model> <model> ppc </model> ... Or: <pae> <can_enable/> <can_disable/> </pae> This is relatively easy to do with qemu, but the format of Xen's /sys/hypervisor/properties/capabilities makes it quite hard. i18n ---- Some proposed features may make translation challenging. For example qemu supports a whole list of machine types ("pc", "sun4m", etc.) and it would be nice for libvirt clients to be able to provide some sort of description for the user. It would not be wise to carry this description in the XML because it would not be possible to localise it. To avoid all libvirt clients duplicating and maintaining lists of machine types and descriptions, it may be worth adding a call to the API along the lines of: virConnectGetMachineDescription (const char *machine_name, const char *lang); (where lang == NULL would mean to use the current language). [EOF] -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)

2 5

[Libvir] virConnectGetCapabilities patch, 2007-03-15
by Richard W.M. Jones 15 Mar '07

15 Mar '07

The latest version is attached. This should satisfy all concerns which have been raised with the previous versions. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)

1 0

[Libvir] [PATCH]fix the judgment of the domain state between hypervisor and xend
by Kazuki Mizushima 15 Mar '07

15 Mar '07

Hi, According to the xm & virsh man page, I make a patch which fixes the judgment of the domain state between xenHypervisorDriver and xenDaemonDriver. Signed-off-by: Kazuki Mizushima <mizushima.kazuk(a)jp.fujitsu.com> Thanks, Kazuki Mizushima Index: xend_internal.c =================================================================== RCS file: /data/cvs/libvirt/src/xend_internal.c,v retrieving revision 1.101 diff -u -p -r1.101 xend_internal.c --- xend_internal.c 8 Mar 2007 14:12:06 -0000 1.101 +++ xend_internal.c 14 Mar 2007 10:42:16 -0000 @@ -1722,9 +1722,9 @@ sexpr_to_xend_domain_info(virDomainPtr d if (strchr(flags, 'c')) info->state = VIR_DOMAIN_CRASHED; else if (strchr(flags, 's')) - info->state = VIR_DOMAIN_SHUTDOWN; - else if (strchr(flags, 'd')) info->state = VIR_DOMAIN_SHUTOFF; + else if (strchr(flags, 'd')) + info->state = VIR_DOMAIN_SHUTDOWN; else if (strchr(flags, 'p')) info->state = VIR_DOMAIN_PAUSED; else if (strchr(flags, 'b'))

2 2

[Libvir] [PATCH] modular compilation of xen/qemu/test
by Daniel Veillard 14 Mar '07

14 Mar '07

The following patch adds 3 configure options to turn on or off the support for Xen, QEMU/KVM and the test driver, as the output of configure --help shows: ... --with-xen add XEN support (on) --with-qemu add QEMU/KVM support (on) --with-test add test driver support (on) ... It uses compile time flags, is not really intrusive, it just pointed out a few strangeness, one of which was fixed (a Xen include) and the remaining ones are: - xml.c doesn't depend on Xen except for virDomainXMLDevID calling xenStoreDomainGetNetworkID() - libvirt.c still calls xenDaemonDomainLookupByName_ids from virDomainGetUUID() , I'm not sure if this can be avoided In the tests directory, sexpr2xmltest.c and xmconfigtest.c still depends on code in xen specific modules, trying to add them without xen being present was more complex than the value it may add (it also makes the patch smaller to cut at the module level). Plan to commit this before the release, unless this raises a problem, Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ 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] Reliably detecting if Intel VT is disabled in the BIOS
by Richard W.M. Jones 14 Mar '07

14 Mar '07

VMXON is the instruction which turns on Intel VT extensions[1]. This instruction can be enabled and disabled by setting a bit in a CPU register. Moreover, this CPU register itself can be locked so that no changes can be made until the CPU is power-cycled. In detail, the register is the IA32_FEATURE_CONTROL (0x3A) MSR. The relevant bits are: bit 0 Lock bit (0 = unlocked, 1 = permanently locked) bit 1 Enable VMXON in Intel Safer Mode Extensions (SMX) bit 2 Enable VMXON in normal operation So to find out if VT is possible with the CPU, use CPUID (in practice, check if "vmx" is in /proc/cpuinfo flags). To find out if VT can be turned on in the host, check bit 2 in the above register. There is a handy tool called msr-tools[2] which you can use: # ./rdmsr 0x3a ff03 (bit 2 is clear, so VT is _not_ enabled on this host). It seems that the BIOS locks the register (by writing 1 to bit 0). To find out if the BIOS has locked the register, use rdmsr again and look at the lowest bit. In the example above you can see that the BIOS disabled VT and locked the register. Once the register is locked, the only way around it is to reboot. If the register is unlocked you can enable VT by writing a 1 to bit 2. If you don't want to use the msr-tools, then direct access to the register can be had through /dev/cpu/<id>/msr. For example this is an strace of rdmsr 0x3a: open("/dev/cpu/0/msr", O_RDONLY) = 3 pread(3, "\3\377\0\0\0\0\0\0", 8, 58) = 8 However you need to be root to open /dev/cpu/0/msr. On machines which don't support the IA32_FEATURE_CONTROL MSR you will get an EIO error: pread(3, 0x7ffff81ec810, 8, 58) = -1 EIO (Input/output error) Rich. Notes: [1] I don't think this is possible with AMD's Pacifica extensions. I'm not sure if it's possible to disable these in the BIOS & lock them. [2] http://www.kernel.org/pub/linux/utils/cpu/msr-tools/ Sources: * linux/drivers/kvm/vmx.c: function vmx_disabled_by_bios * "Intel® Trusted Execution Technology Preliminary Architecture Specification" section 2.1.2 (http://download.intel.com/technology/security/downloads/31516803.pdf) -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)

1 0

[Libvir] [PATCH] Add virConnectGetCapabilities call to return the capabilities of the driver / hypervisor
by Richard W.M. Jones 13 Mar '07

13 Mar '07

This patch: * Adds virConnectGetCapabilities which returns an XML description of the capabilities of the driver or hypervisor under this connection (see below for more about the XML format). * Adds virsh capabilities command. * Checks the Python binding works. Caveats: * Xen implementation (in xen_internal.c) is not tested because I don't have a working Xen machine right now. QEMU, test and remote work however. Example: $ virsh -c test:///default capabilities | tidy -xml -i -q <capabilities> <domain> <type>test</type> </domain> <host_features></host_features> <guest_architectures> <guest_architecture> <model>i686</model> <bits>32</bits> <guest_features> <accelerated /> <pae /> </guest_features> </guest_architecture> </guest_architectures> </capabilities> $ virsh -c qemu:///session capabilities | tidy -xml -i -q <capabilities> <domain> <type>qemu</type> </domain> <guest_architectures> <guest_architecture> <model>i686</model> <bits>32</bits> <features> <emulated /> </features> </guest_architecture> <guest_architecture> <model>x86_64</model> <bits>64</bits> <features> <emulated /> </features> </guest_architecture> [... other archs deleted ...] </guest_architectures> </capabilities> XML format: The <capabilities> node contains information about the host and a list of supported architectures for guests. About the host we return: <domain> <type> The default type acceptable when creating a domain. <host_features> <hvm> Does the host CPU support HVM? <type> Type of HVM (eg. "vmx") <bios_setting> "enabled" or "disabled" About the guest architectures we can return: <guest_architecture> <model> The (virtualised) CPU <bits> Bits <domain> <type> If different from the default type (eg. for kqemu) <features> <hvm> Full virt guest? <accelerated> Accelerated (eg. Xen or kqemu) <emulated> Emulated (eg. qemu or bochs) (and a few other esoteric flags here) Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)

4 13

[Libvir] virsh command is getting a connecting error
by Saori Fukuta 13 Mar '07

13 Mar '07

Hi, It was working fine on March 8th, but today it failed to do virsh command with an error message. # virsh list libvir: error : no support for hypervisor lt-virsh: error: failed to connect to the hypervisor This message is printed here because nb_network_drivers is 0. --- libvirt.c : virConnectOpen 317 if (ret->nb_drivers == 0 || ret->nb_network_drivers == 0) { 318 /* we failed to find an adequate driver */ 319 virLibConnError(NULL, VIR_ERR_NO_SUPPORT, name); 320 goto failed; 321 } I think the cause is because it failed to bind the socket at qemuOpenClientUNIX. --- qemu_internal.c : qemuOpenClientUNIX 232 /* 233 * now bind the socket to that address and listen on it 234 */ 235 if (connect(fd, (struct sockaddr *) &addr, sizeof(addr)) < 0) { They are setting members of sockaddr: {sun_family = 1, sun_path = "/usr/var/run/libvirt/qemud-sock", '\0'} and connect returned -1 with errno that was 2(ENOENT). Is there any problem? Please tell me how I can use current virsh command. Thanks, Saori Fukuta.

2 2

[Libvir] Inconsistent networking between Xen & QEMU
by Daniel P. Berrange 09 Mar '07

09 Mar '07

In Xen it is possible to configure a VIF to enslave with an arbitrary bridge device using a fragment of XML like: <interface type='bridge'> <source bridge='xenbr0'/> <mac address='00:16:3E:66:94:9C'/> </interface> In this example I've enslaved to xenbr0 which is created by the Xen networking script, but this will work with any bridge device really. In QEMU the only bridging is available via the 'virtual networks' support in libvirt, by referencing a named bridge. For example <interface type='network'> <source network='default'/> <mac address='00:16:3E:66:94:9C'/> </interface> Now 'default' is merely defined to be backed by a bridge device 'virbr0' (although it does not neccessary get backed by a bridge) so the basic impl is basically just enslaving a TAP device. Anyway, we now have two different syntaxes in the XML for defining what is more or less the same thing which is a real PITA for the tools. It is useful to have the distinct representations - one is for 'managed' bridges, and the other is for 'unmanaged' bridges - we can do some much more interesting things with managed bridges. To improve life for the tools though I'd like to do two things as a high priority - Support managed networks in Xen - we can simply lookup the bridge device associated with a network and tell Xen to use vif-bridge with this device. For the reverse Xen will tell us what bridge device a guest is using, and we can reverse lookup the corresponding network - Support non-managed networks in QEMU - we can simply enslave the QEMU tap device to an arbitrary user specific bridge device. Until one of these two options is done, its going to be a PITA to support networking across QEMU & Xen in virt-manager/virt-install. 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 10

[Libvir] [PATCH] Add a default network
by Mark McLoughlin 09 Mar '07

09 Mar '07

Hey, So, we want to install a default network which guests can connect to. This can be seen as e.g. a replacement for xenbr0 as the default bridge for xen guests. A few things concern me about the patch, see below for my thinking. However, I'm happy to punt on all of these issues for now and go ahead with the patch. 1) Ordering - we want the default network to have a predictable bridge name, so instead of relying on it being the first network and ending up auto-allocated vnet0, we use virbr0. The alternative is to actually have an ordering scheme, e.g. #define LIBVIRT_AUTOSTART_PRIORITY_DISABLE -1 #define LIBVIRT_AUTOSTART_PRIORITY_FIRST 0 #define LIBVIRT_AUTOSTART_PRIORITY_LAST 99 #define LIBVIRT_AUTOSTART_PRIORITY_DEFAULT 50 int virNetworkSetAutostart(virDomainPtr domain, int priority); autostart/00-default.xml -> ../default.xml autostart/99-MyNetwork.xml -> ../MyNetwork.xml Maybe that's useful, but probably moreso for guests than networks. The "virbr0" solution is fine, IMHO. 2) IP address choice - I've randomly chosen 192.168.122.1/24 as the IP address for the network, and this could happen to clash with an existing network. Since we masquerade outgoing traffic, I think the only problem this would cause in practice would be where the host machine is already on a 192.168.122/24 subnet and it could find itself connecting to a guest rather than another machine on the physical subnet. It's a default configuration choice which admins can change, and I don't see it causing huge problems in practice, so I'm not overly concerned. If it did turn out to be a problem, I'd probably add something like: <ip type="auto" /> But I'm not anxious to go down that route right now. 3) UUID generation - there's no UUID specified, so the default network will have a different UUID across reboots. We could trivially save the UUID at first boot, but we'd really need to put it in /var then. IMHO, it's something we can fix later if it turns out to be important. Cheers, Mark.

3 8

[Libvir] Restarting of libvirt_qemud daemon
by Daniel P. Berrange 09 Mar '07

09 Mar '07

Thinking about later RPM upgrades I think we need to think about whether it will be possible to restart the libvirt_qemud while guests & networks are running. There's a couple of issues: - We do waitpid() to cleanup qemu & dnsmasq processes when we stop domains & networks, or to detect when they crash. For the former, we could may they daemons to avoid waitpid() cleanup, but we'd still need waitpid to be able to detect shutdowns. There is also the issue of enumerating running instances. - We always try to re-create a bridge device at startup, even if it already exists. Likewise we always try to add the IPtables rules & start dnsmasq. We can easily detect if the bridge already exists. I think we can probably double check iptables rulles too., The tricky one is figuring out whether a dnsmasq instance is still running. Dealing with theses not only helps planned restarts, but will also make it possible start up the daemon again after a crash without having to kill off all guests & networks manually. So I think it is worth investigating what we can do to enable restarts. It might be worth waiting until we sort out whether we'll merge libvirt_qemud with the generic libvirtd remote daemon though so we don't have to do the work twice over. 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 -=|

4 8

[Libvir] Stable UUID needed for default network
by Daniel P. Berrange 09 Mar '07

09 Mar '07

The UUID for the default network is not included in the example default config. So every time you restart the libvirt_qemud we get a randomly generated UUID. This isn't really in keeping with the idea of having a permanent UID :-) So I think we need to do two things: - In the 'make install' routine - if-and-only-if the $prefix/etc/libvirt/networks/default.xml file was newly installed, then stuff a random UUID into it, eg UUID=`uuidgen` sed -e "s,</name>,</name>\n <uuid>$UUID</uuid>," \ $prefix/etc/libvirt/networks/default.xml If the system doesn't have uuidgen, we can just ignore this step - In the RPM %post section we need to stuff in a UUID at install time if-and-only-if this is a new install - ie leave it alone during upgrades UUID=`uuidgen` sed -e "s,</name>,</name>\n <uuid>$UUID</uuid>," \ %(sysconfdir)/libvirt/networks/default.xml 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] Alternate dnsmasq command line args ?
by Daniel P. Berrange 09 Mar '07

09 Mar '07

Currently we launch dnsmasq with a command line looking like: dnsmasq --keep-in-foreground --bind-interfaces --pid-file --conf-file --except-interface lo --listen-address 192.168.122.1 --dhcp-range 192.168.122.2,192.168.122.254 This causes DNSMASQ to listen on any network interface configured with an IP address of '192.168.122.1', except for loopback. I know it would be kind of unusual, but it is possible two interface might be both configured with the same address. I think it may be safer if we explicitly tell it to use virbr0 instead eg --interface virbr0 --except-interface lo Yes, the --except-interface lo is still needed due to wierd ass dnsmasq rules which make it always use loopback unless you tell it not to. I'm also not clear why we use --conf-file - we're not actually telling it about any config file so this seems redundant ? 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 2

[Libvir] Generate python binding for network APIs
by Daniel P. Berrange 09 Mar '07

09 Mar '07

I was about to make use of the new networking APIs in virt-manager/virt-install when I discovered we don't have any python binding for it. Attached is the quickest patch I could write to support it - I basically copied all the virDomain related bits & s/Domain/Network/ throughout. A simple demo script works: #!/usr/bin/python import libvirt con = libvirt.open(None) n = con.listNetworks() print str(n) for name in n: net = con.lookupByName(name) print net.XMLDesc(0) print net.bridgeName() I think there are a couple more methods which need manual implementations though - eg UUIDString() is generated incorrectly - in fact the UUIDString() impl for virDomains is already broken, and so is the binding for VCPU pinning. 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 3

[Libvir] PATCH: Fix QEMU autostart/network behaviour
by Daniel P. Berrange 08 Mar '07

08 Mar '07

In my testing there appeared to be a couple of bugs with the QEMU driver and the interaction with networking - It was auto-starting the daemon even with qemu://system - It was opening the QEMU connection twice due to inverted check, and not opening it at all in the non-QEMU hv case. - Once that is fixed, then it SEGVs when using a Xen connection as uri->scheme is NULL That attached patch rectifies those flaws - Mark can you double check this just in case I've missed some edge case for the networking stuff - I have strace'd virsh when doing virsh list (as root & non-root) virsh --connect test://default list (as root & non-root) virsh --connect xen list (as root & non-root) virsh --connect qemu://session list (as non-root) virsh --connect qemu://system list (as root) virsh --connect qemu://session --readonly list (as non-root) virsh --connect qemu://system --readonly list (as root & non-root) And it appears to now be making the correct connectiosn to the QEMU daemons in all 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 1

[Libvir] [PATCH] libvirt.c: warning: dereferencing type-punned pointer will break strict-aliasing rules
by Richard W.M. Jones 08 Mar '07

08 Mar '07

I'm currently trying to get libvirt to compile with -Werror. One problem which came up early is the warning in $SUBJECT. The gcc info page (see -fstrict-aliasing) is pretty unclear about what exactly causes this problem, so the attached patch rewrites the code quite conservatively to avoid the problem. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)

3 5

[Libvir] [RFC] Check host's minimum memory.
by Masayuki Sunou 08 Mar '07

08 Mar '07

Hi The minimum value of the memory guarded with virsh setmem is 4096KB(4MB). In general, when host's memory is set to 4MB, the host stops. Therefore, I propose the patch to which host's minimum value of the memory is guarded by 256MB. Signed-off-by: Masayuki Sunou <fj1826dm(a)aa.jp.fujitsu.com> Thanks, Masayuki Sunou. libvirt-0.2.0 -------------------------------------------------------------------------------- Index: libvirt/src/xend_internal.c =================================================================== RCS file: /data/cvs/libvirt/src/xend_internal.c,v retrieving revision 1.97 diff -u -p -r1.97 xend_internal.c --- libvirt/src/xend_internal.c 2 Mar 2007 20:19:08 -0000 1.97 +++ libvirt/src/xend_internal.c 6 Mar 2007 01:42:44 -0000 @@ -2243,6 +2243,9 @@ xenDaemonDomainSetMemory(virDomainPtr do if (domain->id < 0 && domain->conn->xendConfigVersion < 3) return(-1); + if (domain->id == 0 && memory < (256 * 1024)) + return(-1); + snprintf(buf, sizeof(buf), "%lu", memory >> 10); return xend_op(domain->conn, domain->name, "op", "mem_target_set", "target", buf, NULL); Index: libvirt/src/xm_internal.c =================================================================== RCS file: /data/cvs/libvirt/src/xm_internal.c,v retrieving revision 1.14 diff -u -p -r1.14 xm_internal.c --- libvirt/src/xm_internal.c 23 Feb 2007 08:51:30 -0000 1.14 +++ libvirt/src/xm_internal.c 6 Mar 2007 01:42:46 -0000 @@ -1025,6 +1025,9 @@ int xenXMDomainSetMemory(virDomainPtr do if (domain->id != -1) return (-1); + if (domain->id == 0 && memory < (256 * 1024)) + return(-1); + if (!(filename = virHashLookup(nameConfigMap, domain->name))) return (-1); Index: libvirt/src/xs_internal.c =================================================================== RCS file: /data/cvs/libvirt/src/xs_internal.c,v retrieving revision 1.32 diff -u -p -r1.32 xs_internal.c --- libvirt/src/xs_internal.c 23 Feb 2007 08:51:30 -0000 1.32 +++ libvirt/src/xs_internal.c 6 Mar 2007 01:42:46 -0000 @@ -434,6 +434,10 @@ xenStoreDomainSetMemory(virDomainPtr dom } if (domain->id == -1) return(-1); + + if (domain->id == 0 && memory < (256 * 1024)) + return(-1); + snprintf(value, 19, "%lu", memory); value[19] = 0; ret = virDomainDoStoreWrite(domain, "memory/target", &value[0]); --------------------------------------------------------------------------------

4 9

[Libvir] [PATCH] export virConf* symbols (second version)
by Richard W.M. Jones 08 Mar '07

08 Mar '07

Second version of that patch. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)

3 3

[Libvir] [PATCH] Can specify VNC port number 5900
by Nobuhiro Itou 08 Mar '07

08 Mar '07

Hi The libvirt cannot specify VNC port number 5900. Currently if we specify the port 5900, The port number set to 5900+DomID. This patch fixes the port number from 5900+DomID to 5900 for this case. Signed-off-by: Nobuhiro Itou <fj0873gn(a)aa.jp.fujitsu.com> Thanks, Nobuhiro Itou. Index: xml.c =================================================================== RCS file: /data/cvs/libvirt/src/xml.c,v retrieving revision 1.62 diff -u -p -r1.62 xml.c --- xml.c 6 Mar 2007 20:00:17 -0000 1.62 +++ xml.c 8 Mar 2007 04:23:03 -0000 @@ -251,7 +251,7 @@ static int virDomainParseXMLGraphicsDesc long port = strtol((const char *)vncport, NULL, 10); if (port == -1) virBufferAdd(buf, "(vncunused 1)", 13); - else if (port > 5900) + else if (port >= 5900) virBufferVSprintf(buf, "(vncdisplay %d)", port - 5900); xmlFree(vncport); } @@ -315,7 +315,7 @@ static int virDomainParseXMLGraphicsDesc long port = strtol((const char *)vncport, NULL, 10); if (port == -1) virBufferAdd(buf, "(vncunused 1)", 13); - else if (port > 5900) + else if (port >= 5900) virBufferVSprintf(buf, "(vncdisplay %d)", port - 5900); xmlFree(vncport); }

3 2

[Libvir] [PATCH] check the maximum of virtual CPU
by Masayuki Sunou 08 Mar '07

08 Mar '07

Hi The maximum of virtual CPU is not guarded in virsh setvcpus now. Then, when 32767 was set to virtual CPU of virsh setvcpus, the problem that Xend became abnormal was detected. example: ---------------------------------------------------------------------- # virsh setvcpus 0 32767 libvir: Xen Daemon error : POST operation failed: (xend.err "(9, 'Bad file descriptor')") libvir: Xen error : failed Xen syscall ioctl 3166208 libvir: error : library call virDomainSetVcpus failed, possibly not supported # xm list -l Error: (9, 'Bad file descriptor') Usage: xm list [options] [Domain, ...] List information about all/some domains. -l, --long Output all VM details in SXP --label Include security labels --state=<state> Select only VMs with the specified state ---------------------------------------------------------------------- Therefore, I propose the correction that adjusts the maximum of virtual CPU to the same value as Xen. This patch is over 200lines. If you request, I am ready to repost it with split this patch. Signed-off-by: Masayuki Sunou <fj1826dm(a)aa.jp.fujitsu.com> Thanks, Masayuki Sunou. libvirt-0.2.0 ---------------------------------------------------------------------- diff -rup a/include/libvirt/libvirt.h b/include/libvirt/libvirt.h --- a/include/libvirt/libvirt.h 2007-02-23 17:51:30.000000000 +0900 +++ b/include/libvirt/libvirt.h 2007-03-01 03:02:20.000000000 +0900 @@ -233,6 +233,7 @@ int virConnectGetVersion (virConnectPt unsigned long *hvVer); int virNodeGetInfo (virConnectPtr conn, virNodeInfoPtr info); +int virGetCpuMax (virConnectPtr conn); /* * Gather list of running domains diff -rup a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in --- a/include/libvirt/libvirt.h.in 2007-02-23 17:51:30.000000000 +0900 +++ b/include/libvirt/libvirt.h.in 2007-03-01 03:02:50.000000000 +0900 @@ -233,6 +233,7 @@ int virConnectGetVersion (virConnectPt unsigned long *hvVer); int virNodeGetInfo (virConnectPtr conn, virNodeInfoPtr info); +int virGetCpuMax (virConnectPtr conn); /* * Gather list of running domains diff -rup a/src/driver.h b/src/driver.h --- a/src/driver.h 2007-02-23 17:51:30.000000000 +0900 +++ b/src/driver.h 2007-03-01 03:09:32.000000000 +0900 @@ -140,6 +140,8 @@ typedef int typedef int (*virDrvDomainSetAutostart) (virDomainPtr domain, int autostart); +typedef int + (*virDrvGetCpuMax) (void); typedef struct _virDriver virDriver; typedef virDriver *virDriverPtr; @@ -191,6 +193,7 @@ struct _virDriver { virDrvDomainDetachDevice domainDetachDevice; virDrvDomainGetAutostart domainGetAutostart; virDrvDomainSetAutostart domainSetAutostart; + virDrvGetCpuMax cpumax; }; typedef int diff -rup a/src/libvirt.c b/src/libvirt.c --- a/src/libvirt.c 2007-02-23 17:51:30.000000000 +0900 +++ b/src/libvirt.c 2007-03-01 02:16:49.000000000 +0900 @@ -1670,6 +1670,35 @@ virNodeGetInfo(virConnectPtr conn, virNo return(0); } +/** + * virDrvGetCpuMax: + * + * Returns the maximum of CPU defined by Hypervisor. + * + * Returns the maximum of CPU or 0 in case of error. + */ +int +virGetCpuMax(virConnectPtr conn) { + int i; + int ret = -1; + + if (!VIR_IS_CONNECT(conn)) { + virLibConnError(conn, VIR_ERR_INVALID_CONN, __FUNCTION__); + return (0); + } + + for (i = 0;i < conn->nb_drivers;i++) { + if ((conn->drivers[i] != NULL) && + (conn->drivers[i]->cpumax != NULL)) { + ret = conn->drivers[i]->cpumax(); + if (ret != 0) + return(ret); + } + } + virLibConnError(conn, VIR_ERR_CALL_FAILED, __FUNCTION__); + return (-1); +} + /************************************************************************ * * * Handling of defined but not running domains * diff -rup a/src/libvirt_sym.version b/src/libvirt_sym.version --- a/src/libvirt_sym.version 2007-02-23 17:51:30.000000000 +0900 +++ b/src/libvirt_sym.version 2007-03-01 02:17:18.000000000 +0900 @@ -52,6 +52,7 @@ virConnResetLastError; virDefaultErrorFunc; virNodeGetInfo; + virGetCpuMax; virDomainSetVcpus; virDomainPinVcpu; diff -rup a/src/proxy_internal.c b/src/proxy_internal.c --- a/src/proxy_internal.c 2007-02-23 17:51:30.000000000 +0900 +++ b/src/proxy_internal.c 2007-03-01 02:17:40.000000000 +0900 @@ -83,6 +83,7 @@ static virDriver xenProxyDriver = { NULL, /* domainDetachDevice */ NULL, /* domainGetAutostart */ NULL, /* domainSetAutostart */ + NULL, /* cpumax */ }; /** diff -rup a/src/qemu_internal.c b/src/qemu_internal.c --- a/src/qemu_internal.c 2007-02-23 21:46:35.000000000 +0900 +++ b/src/qemu_internal.c 2007-03-01 02:18:02.000000000 +0900 @@ -1200,6 +1200,7 @@ static virDriver qemuDriver = { NULL, /* domainDetachDevice */ qemuDomainGetAutostart, /* domainGetAutostart */ qemuDomainSetAutostart, /* domainSetAutostart */ + NULL, /* cpumax */ }; static virNetworkDriver qemuNetworkDriver = { diff -rup a/src/test.c b/src/test.c --- a/src/test.c 2007-02-23 17:51:30.000000000 +0900 +++ b/src/test.c 2007-03-01 02:18:53.000000000 +0900 @@ -127,6 +127,7 @@ static virDriver testDriver = { NULL, /* domainDetachDevice */ NULL, /* domainGetAutostart */ NULL, /* domainSetAutostart */ + NULL, /* cpumax */ }; typedef struct _testDev { diff -rup a/src/virsh.c b/src/virsh.c --- a/src/virsh.c 2007-02-28 00:35:50.000000000 +0900 +++ b/src/virsh.c 2007-03-01 02:19:59.000000000 +0900 @@ -1383,6 +1383,7 @@ cmdSetvcpus(vshControl * ctl, vshCmd * c { virDomainPtr dom; int count; + int maxcpu; int ret = TRUE; if (!vshConnectionUsability(ctl, ctl->conn, TRUE)) @@ -1397,6 +1398,18 @@ cmdSetvcpus(vshControl * ctl, vshCmd * c return FALSE; } + maxcpu = virGetCpuMax(ctl->conn); + if (!maxcpu) { + virDomainFree(dom); + return FALSE; + } + + if (count > maxcpu) { + vshError(ctl, FALSE, _("Too many virtual CPU's.")); + virDomainFree(dom); + return FALSE; + } + if (virDomainSetVcpus(dom, count) != 0) { ret = FALSE; } diff -rup a/src/xend_internal.c b/src/xend_internal.c --- a/src/xend_internal.c 2007-02-28 00:50:03.000000000 +0900 +++ b/src/xend_internal.c 2007-03-01 02:21:34.000000000 +0900 @@ -99,6 +99,7 @@ static virDriver xenDaemonDriver = { xenDaemonDetachDevice, /* domainDetachDevice */ NULL, /* domainGetAutostart */ NULL, /* domainSetAutostart */ + NULL, /* cpumax */ }; /** diff -rup a/src/xen_internal.c b/src/xen_internal.c --- a/src/xen_internal.c 2007-02-23 17:51:30.000000000 +0900 +++ b/src/xen_internal.c 2007-02-28 18:06:08.000000000 +0900 @@ -456,6 +456,7 @@ static virDriver xenHypervisorDriver = { NULL, /* domainDetachDevice */ NULL, /* domainGetAutostart */ NULL, /* domainSetAutostart */ + xenHypervisorGetCpuMax, /* cpumax */ }; #endif /* !PROXY */ @@ -1824,6 +1825,17 @@ xenHypervisorGetVcpus(virDomainPtr domai } #endif +/** + * xend_get_cpu_max: + * + * Returns the maximum of CPU defined by Xen. + */ +int +xenHypervisorGetCpuMax(void) +{ + return MAX_VIRT_CPUS; +} + /* * Local variables: * indent-tabs-mode: nil diff -rup a/src/xen_internal.h b/src/xen_internal.h --- a/src/xen_internal.h 2006-08-04 19:41:05.000000000 +0900 +++ b/src/xen_internal.h 2007-03-01 02:21:13.000000000 +0900 @@ -55,6 +55,7 @@ int xenHypervisorGetVcpus (virDomainPtr int maxinfo, unsigned char *cpumaps, int maplen); +int xenHypervisorGetCpuMax (void); #ifdef __cplusplus } diff -rup a/src/xm_internal.c b/src/xm_internal.c --- a/src/xm_internal.c 2007-02-23 17:51:30.000000000 +0900 +++ b/src/xm_internal.c 2007-03-01 02:23:54.000000000 +0900 @@ -108,6 +108,7 @@ static virDriver xenXMDriver = { NULL, /* domainDetachDevice */ NULL, /* domainGetAutostart */ NULL, /* domainSetAutostart */ + NULL, /* cpumax */ }; static void diff -rup a/src/xs_internal.c b/src/xs_internal.c --- a/src/xs_internal.c 2007-02-23 17:51:30.000000000 +0900 +++ b/src/xs_internal.c 2007-03-01 02:24:20.000000000 +0900 @@ -77,6 +77,7 @@ static virDriver xenStoreDriver = { NULL, /* domainDetachDevice */ NULL, /* domainGetAutostart */ NULL, /* domainSetAutostart */ + NULL, /* cpumax */ }; /**

5 14

[Libvir] Remote patch, 2007-02-28
by Richard W.M. Jones 07 Mar '07

07 Mar '07

http://www.annexia.org/tmp/libvirt-tls-20070228.patch Not an enormous amount of difference between this and the patch from two days ago. This patch correctly logs/audits new connections and fixes a whole collection of different bugs which used to happen when the server rejected a client connection. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)

6 22

[Libvir] Reason for daemons?
by Shuveb Hussain 07 Mar '07

07 Mar '07

Hi, Any reason why actual requests are serviced by daemons? Is it just to increase the stability of the applications that link to libvirt or are there other reasons? I have started implementing OpenVZ support. Should I follow the same path and implement a daemon as well? Regards, -- Shuveb Hussain. I blog at http://binarykarma.org Spread the Karma.

2 1

[Libvir] [RFC] Host and guest capabilities
by Richard W.M. Jones 07 Mar '07

07 Mar '07

I've been looking into the parts of virtinst which try to probe the capabilities of the host directly, rather than being abstracted through libvirt (for example, opening and parsing /sys/hypervisor/properties/capabilities directly). Attached is a proposed API for probing the capabilities and supported guest architectures of the hypervisor / driver. I've implemented the virCapabilities part already. My original implementation of the guest architectures had virCapabilities containing a list of supported architectures, but that doesn't nearly cover the richness of what the underlying drivers could support, so I'm currently separating that out into a separate virConnectGetGuestArchitectures call. Let me know your opinions of this API. As an aside, the current virt-manager "choose paravirt / fullvirt" screen doesn't really capture the full, shall I say, ugliness of the possible choices for architecture, particularly when we add qemu, kqemu, and emulation in the mix. I suspect that presenting a list of architectures here, perhaps with some options to show only paravirt, show only fullvirt, show only accelerated ... Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)

3 6