[Libvir] [PATCH] Fix dom0 maxmem display for memmax not set case
by Atsushi SAKAI
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);
}
17 years, 9 months
[Libvir] virConnectGetCapabilities patch, 2007-03-15 (version 2)
by Richard W.M. Jones
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>
17 years, 9 months
[Libvir] Proposed XML format for capabilities, with examples [long]
by Richard W.M. Jones
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> <!-- etc -->
</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> <!-- etc -->
</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)
17 years, 9 months
[Libvir] virConnectGetCapabilities patch, 2007-03-15
by Richard W.M. Jones
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)
17 years, 9 months
[Libvir] [PATCH]fix the judgment of the domain state between hypervisor and xend
by Kazuki Mizushima
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'))
17 years, 9 months
[Libvir] [PATCH] modular compilation of xen/qemu/test
by Daniel Veillard
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/
17 years, 9 months
[Libvir] Reliably detecting if Intel VT is disabled in the BIOS
by Richard W.M. Jones
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)
17 years, 9 months
[Libvir] [PATCH] Add virConnectGetCapabilities call to return the capabilities of the driver / hypervisor
by Richard W.M. Jones
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)
17 years, 9 months
[Libvir] virsh command is getting a connecting error
by Saori Fukuta
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.
17 years, 9 months
