[libvirt] [PATCH 3/7] Add smbios element to schema and configuration
by Daniel Veillard
the element has a mode attribute allowing only 3 values:
- emulate: use the smbios emulation from the hypervisor
- host: try to use the smbios values from the node
- sysinfo: grab the values from the <sysinfo> fields
* docs/schemas/domain.rng: extend the schemas
* src/conf/domain_conf.h: add the flag to the domain config
* src/conf/domain_conf.h: parse and serialize the smbios if present
Signed-off-by: Daniel Veillard <veillard(a)redhat.com>
---
docs/schemas/domain.rng | 16 ++++++++++++++++
src/conf/domain_conf.c | 17 +++++++++++++++++
src/conf/domain_conf.h | 11 +++++++++++
3 files changed, 44 insertions(+), 0 deletions(-)
13 years, 11 months
[libvirt] Allow nbd-backed disk images?
by Adam Litke
I am trying to use a qcow image with libvirt where the backing 'file' is
a qemu-nbd server. Unfortunately the security code assumes that
backingStore is always a real file so something like 'nbd:0:3333' is
rejected because a file with that name cannot be accessed. A simple
patch like the following works around the problem -- are there any
suggestions on how to do this properly? Note that I am not worried
about directly using nbd images. That would require a new disk type
with XML markup, etc. I only want it to be permitted as a backingStore.
diff --git a/src/util/storage_file.c b/src/util/storage_file.c
index 6f48b10..7c0ea9a 100644
--- a/src/util/storage_file.c
+++ b/src/util/storage_file.c
@@ -292,6 +292,13 @@ qcowXGetBackingStore(char **res,
return BACKING_STORE_INVALID;
if (size + 1 == 0)
return BACKING_STORE_INVALID;
+
+ /* Short-circuit nbd backing files */
+ if (size >= 4 && STRPREFIX((const char *)(buf + offset), "nbd:")) {
+ return BACKING_STORE_OK;
+ }
+
if (VIR_ALLOC_N(*res, size + 1) < 0) {
virReportOOMError();
return BACKING_STORE_ERROR;
--
Thanks,
Adam
13 years, 11 months
[libvirt] [PATCH v2] macvtap: libvirtd forgot macvtap device name during a shutdown/restart cycle
by Stefan Berger
V2:
- removed change from virDomainNetDefFormat. The reported problem
also does not occur.
During a shutdown/restart cycle libvirtd forgot the macvtap device name
that it had created on behalf of a VM so that a stale macvtap device
remained on the host when the VM terminated. Libvirtd has to actively
tear down a macvtap device and it uses its name for identifying which
device to tear down.
The solution is to not blank out the <target dev='...'/> completely, but
only blank it out on VMs that are not active. So, if a VM is active, the
device name makes it into the XML and is also being parsed. If a VM is
not active, the device name is discarded.
Signed-off-by: Stefan Berger <stefanb(a)us.ibm.com>
---
src/conf/domain_conf.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: libvirt-acl/src/conf/domain_conf.c
===================================================================
--- libvirt-acl.orig/src/conf/domain_conf.c
+++ libvirt-acl/src/conf/domain_conf.c
@@ -2343,7 +2343,8 @@ virDomainNetDefParseXML(virCapsPtr caps,
def->data.direct.linkdev = dev;
dev = NULL;
- VIR_FREE(ifname);
+ if ((flags & VIR_DOMAIN_XML_INACTIVE))
+ VIR_FREE(ifname);
break;
13 years, 11 months
[libvirt] [PATCH] tests: fix daemon-conf testing failure
by Osier Yang
libvirtd.conf uses "libvirt" as the value of "unix_sock_group",
however, group "libvirt" may not exist on system, in this case
the case will always be failed, which will cause 'make check'
, and 'make rpm' always be failed further more.
As a solution, replace "libvirt" with "root" in "tmp.conf".
* tests/daemon-conf
---
tests/daemon-conf | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/tests/daemon-conf b/tests/daemon-conf
index 6c91d96..225f84c 100755
--- a/tests/daemon-conf
+++ b/tests/daemon-conf
@@ -25,6 +25,9 @@ grep -v '\"PARAMETER = VALUE\"' "$conf" | grep '[a-z_] *= *[^ ]' | grep -vE '^
# Start with the sample libvirtd.conf file, uncommenting all real directives.
sed -n 's/^#\([^ #]\)/\1/p' "$conf" > tmp.conf
+sed -e 's/^\(unix_sock_group =\).*/\1 "root"/g' tmp.conf > k
+mv k tmp.conf
+
# Iterate through that list of directives, corrupting one RHS at a
# time and running libvirtd with the resulting config. Each libvirtd
# invocation must fail.
--
1.7.2.3
13 years, 11 months
[libvirt] PCI/USB devices documentation
by Zdenek Styblik
Hello,
so far unsuccessfully, I'm trying to attach PCI/USB devices to Guests
(via virt-manager, soon via virsh because - whatever :]).
Anyway, there is <hostdev managed='yes'> where I'm wondering what
'managed' means, because it's not documented here[1].
Is it a bug or is it documented elsewhere?
btw also, 'Node devices XML format'[2] page is empty
Thanks,
Zdenek
References:
---
[1] http://libvirt.org/formatdomain.html#elementsUSB
[2] http://libvirt.org/formatnode.html
PS: I haven't forgotten about Slackware SSH how-to, but- *sigh* I promise!
--
Zdenek Styblik
Net/Linux admin
OS TurnovFree.net
email: stybla(a)turnovfree.net
jabber: stybla(a)jabber.turnovfree.net
13 years, 11 months
[libvirt] [PATCH] Fix virPipeReadUntilEOF on more than 1024 bytes of data
by Daniel Veillard
This is a bug I found while testing the smbios support, it uses
virPipeReadUntilEOF to read the stdout of the exec'ed dmidecode
process and this failed to capture the full output. It read only
1024 bytes.
The problem is that this is based on a poll loop, and in the
loop we read at most 1024 bytes per filedescriptor, but we also
note in the loop if poll indicates that the process won't output
more than that on that fd by setting finished[i] = 1.
The simplest way is that if we read a full buffer make sure
finished[i] is still 0 because we will need another pass in the
loop.
Daniel
diff --git a/src/util/util.c b/src/util/util.c
index f7c7d32..a059675 100644
--- a/src/util/util.c
+++ b/src/util/util.c
@@ -984,6 +984,9 @@ virPipeReadUntilEOF(int outfd, int errfd,
got = read(fds[i].fd, data, sizeof(data));
+ if (got == sizeof(data))
+ finished[i] = 0;
+
if (got == 0) {
finished[i] = 1;
continue;
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
13 years, 11 months
[libvirt] Changing the default for qcow2 creation
by Matthew Booth
I've recently been investigating a severe performance issue I noticed
when writing to a qcow2-backed image. When virt-v2v is doing a format
conversion from raw to qcow2, it does the following:
1. Create a new qcow2 image
2. Launch a libguestfs appliance (kvm) using the new image
3. Write the source raw data to the appliance's block device
I noticed that the same process writing to a raw image rather than a
qcow2 image was adequately fast, and decided to do some testing. I've
attached my simple test program.[1] It does the following:
1. Start an appliance with test.img as a disk.
2. Format test.img with ext2.
3. Create a file /test
4. Write 256M of data to /test in 2M chunks
Only step 4 is timed. I ran the program against test.img prepared in 4
different ways:
1. A sparse raw file: 15.3 seconds
truncate --size 300M test.img
2. A preallocated raw file: 14.8 seconds
fallocate -l 300M test.img
3. A sparse qcow2 file: 223.0 seconds
qemu-img create -f qcow2 test.img 300M
4. A metadata preallocated qcow2 file: 14.5 seconds
qemu-img create -f qcow2 -o preallocated=metadata test.img 300M
With the exception of (3), I ran the test 3 times and took the middle
time rounded to 1DP. I saw about 5-10% variation. I only ran the test
against (3) once.
The precise ordering of 1, 2 and 4 is surprising, but given the
variation probably not that interesting: they're all about the same. The
interesting thing is that the overhead of qcow2 metadata creation during
the test seems to account for a 15x performance penalty.
I had a cursory look at metadata preallocation, which I hadn't been
aware of before today. Creating a qcow2 image of any size with no
preallocation results in a 136k file. If you preallocate the metadata, a
sparse file is created large enough to accomodate the entire image, with
>136k actually used. In the above 300M case this is 204k. On a slightly
more practical 20G image, 3.3M is preallocated. It's also worth noting
that the image takes considerably longer to create. On my laptop,
creation without preallocation is 'instantaneous' at any size. With
preallocation, a 20G image takes 6 seconds to create, and a 100G image
takes 26 seconds.
libvirt's qemu driver doesn't currently preallocate qcow2 metadata when
creating a new image. Given the tiny disk space overhead of the metadata
(0.02%) and the small processing overhead of pre-creation relative to
subsequent creation on-the-fly, I suggest that the libvirt qemu driver
is updated to pre-allocate metadata by default.
Thoughts?
Matt
[1] Note that I'm running this against libguestfs from git, which uses
virtio-serial rather than usermode networking for appliance<->host
communication. This change alone improved the performance of this test
by about 10x. If your numbers don't match mine, that's probably why. I
don't know off the top of my head if this change has made it into F14
yet. It's definitely not in F13.
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
13 years, 11 months
[libvirt] New PHP bindings
by Arnar Mar Sig
Hi
There are few PHP libvirt bindings out there, but all I found are procedural based and incomplete.
To address this I created another binding that is OO based and in large part generated from libvirt-api.xml.
The extension already supports most of the API, split into 6 classes: virConnect, virDomain, virInterface, virNetwork, virStoragePool, and virStorageVol.
Snapshot of the current code can be found at:
http://libvirt-debian.vm.antab.is/files/php-libvirt.tar.bz2
Or using svn from:
http://svn.antab.is/php-libvirt/trunk
Build instructions are in the README file.
Documents can be found at http://libvirt-debian.vm.antab.is/
NOTE: Most of the docs are copied from libvirt.
It has mostly been tested with libvirt test backend and PHP unit tests (phpt) are used to test, covering about 40% of basic usage.
It is by no means complete and missing some functionality like classmaps (So virConnect::domainLookupBy* can return user defined class extended from virDomain) and probably leaks memory.
I would appreciate any input and comments.
Thanks
Arnar Mar Sig
13 years, 11 months
[libvirt] [PATCH 00/10] Allow access to text console with virStream APIs (v2)
by Daniel P. Berrange
An update of the patches in
http://www.redhat.com/archives/libvir-list/2010-August/msg00379.html
The end goal is to allow 'virsh console' to work unprivileged,
and/or over remote connections.
The main change in this version, is that the streams code has been
pulled out of the QEMU driver, into a 'fdstream.h' file, so that
90% of the code can be shared across LXC/UML/Xen drivers.
.x-sc_avoid_write | 1
daemon/remote.c | 95 +++++++
daemon/remote_dispatch_args.h | 2
daemon/remote_dispatch_prototypes.h | 16 +
daemon/remote_dispatch_table.h | 10
daemon/stream.c | 7
include/libvirt/libvirt.h.in | 16 +
include/libvirt/virterror.h | 3
src/Makefile.am | 1
src/driver.h | 10
src/esx/esx_driver.c | 1
src/fdstream.c | 472 ++++++++++++++++++++++++++++++++++++
src/fdstream.h | 44 +++
src/libvirt.c | 96 +++++++
src/libvirt_private.syms | 7
src/libvirt_public.syms | 2
src/lxc/lxc_driver.c | 66 +++++
src/opennebula/one_driver.c | 1
src/openvz/openvz_driver.c | 1
src/phyp/phyp_driver.c | 1
src/qemu/qemu_driver.c | 359 ++++++---------------------
src/remote/remote_driver.c | 324 +++++++++++++++++++++---
src/remote/remote_protocol.c | 37 ++
src/remote/remote_protocol.h | 28 ++
src/remote/remote_protocol.x | 21 +
src/remote_protocol-structs | 5
src/test/test_driver.c | 1
src/uml/uml_driver.c | 76 +++++
src/util/virterror.c | 3
src/vbox/vbox_tmpl.c | 1
src/xen/xen_driver.c | 58 ++++
src/xenapi/xenapi_driver.c | 1
tools/Makefile.am | 1
tools/console.c | 330 +++++++++++++++++++------
tools/console.h | 2
tools/virsh.c | 76 +----
36 files changed, 1712 insertions(+), 463 deletions(-)
Daniel
13 years, 11 months
[libvirt] [PATCH] xen: work with ia64 MAX_VIRT_CPUS of 64
by Eric Blake
* src/xen/xen_hypervisor.c (MAX_VIRT_CPUS): Move...
* src/xen/xen_driver.h (MAX_VIRT_CPUS): ...so all xen code can see
same value.
* src/xen/xend_internal.c (sexpr_to_xend_domain_info)
(xenDaemonDomainGetVcpusFlags, xenDaemonParseSxpr)
(xenDaemonFormatSxpr): Work if MAX_VIRT_CPUS is 64 on a platform
where long is 64-bits.
* src/xen/xm_internal.c (xenXMDomainConfigParse)
(xenXMDomainConfigFormat): Likewise.
---
On at least the xen/stable branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
we have the case where MAX_VIRT_CPUS is 32 for x86 but 64 for ia64.
That branch does not have XEN_LEGACY_MAX_VCPUS. But according
to our comments, other branches had only XEN_LEGACY_MAX_VCPUS,
which means that xm_internal.c would fail to compile without this
patch, when targetting xen headers that lack MAX_VIRT_CPUS.
src/xen/xen_driver.h | 8 ++++++++
src/xen/xen_hypervisor.c | 8 --------
src/xen/xend_internal.c | 17 +++++++++--------
src/xen/xm_internal.c | 9 +++++----
4 files changed, 22 insertions(+), 20 deletions(-)
diff --git a/src/xen/xen_driver.h b/src/xen/xen_driver.h
index 53f97d4..16d22f1 100644
--- a/src/xen/xen_driver.h
+++ b/src/xen/xen_driver.h
@@ -29,6 +29,14 @@
# include <winsock2.h>
# endif
+/* xen-unstable changeset 19788 removed MAX_VIRT_CPUS from public
+ * headers. Its semantic was retained with XEN_LEGACY_MAX_VCPUS.
+ * Ensure MAX_VIRT_CPUS is defined accordingly.
+ */
+# if !defined(MAX_VIRT_CPUS) && defined(XEN_LEGACY_MAX_VCPUS)
+# define MAX_VIRT_CPUS XEN_LEGACY_MAX_VCPUS
+# endif
+
extern int xenRegister (void);
# define XEN_UNIFIED_HYPERVISOR_OFFSET 0
diff --git a/src/xen/xen_hypervisor.c b/src/xen/xen_hypervisor.c
index 3797865..ec726fe 100644
--- a/src/xen/xen_hypervisor.c
+++ b/src/xen/xen_hypervisor.c
@@ -109,14 +109,6 @@ typedef privcmd_hypercall_t hypercall_t;
# define SYS_IFACE_MIN_VERS_NUMA 4
#endif
-/* xen-unstable changeset 19788 removed MAX_VIRT_CPUS from public
- * headers. Its semanitc was retained with XEN_LEGACY_MAX_VCPUS.
- * Ensure MAX_VIRT_CPUS is defined accordingly.
- */
-#if !defined(MAX_VIRT_CPUS) && defined(XEN_LEGACY_MAX_VCPUS)
-# define MAX_VIRT_CPUS XEN_LEGACY_MAX_VCPUS
-#endif
-
static int xen_ioctl_hypercall_cmd = 0;
static int initialized = 0;
static int in_init = 0;
diff --git a/src/xen/xend_internal.c b/src/xen/xend_internal.c
index 974e96b..614c036 100644
--- a/src/xen/xend_internal.c
+++ b/src/xen/xend_internal.c
@@ -2192,7 +2192,7 @@ xenDaemonParseSxpr(virConnectPtr conn,
}
def->maxvcpus = sexpr_int(root, "domain/vcpus");
- def->vcpus = count_one_bits(sexpr_int(root, "domain/vcpu_avail"));
+ def->vcpus = count_one_bits_l(sexpr_u64(root, "domain/vcpu_avail"));
if (!def->vcpus || def->maxvcpus < def->vcpus)
def->vcpus = def->maxvcpus;
@@ -2468,7 +2468,7 @@ sexpr_to_xend_domain_info(virDomainPtr domain, const struct sexpr *root,
}
info->cpuTime = sexpr_float(root, "domain/cpu_time") * 1000000000;
vcpus = sexpr_int(root, "domain/vcpus");
- info->nrVirtCpu = count_one_bits(sexpr_int(root, "domain/vcpu_avail"));
+ info->nrVirtCpu = count_one_bits_l(sexpr_u64(root, "domain/vcpu_avail"));
if (!info->nrVirtCpu || vcpus < info->nrVirtCpu)
info->nrVirtCpu = vcpus;
@@ -3706,7 +3706,7 @@ xenDaemonDomainGetVcpusFlags(virDomainPtr domain, unsigned int flags)
ret = sexpr_int(root, "domain/vcpus");
if (!(flags & VIR_DOMAIN_VCPU_MAXIMUM)) {
- int vcpus = count_one_bits(sexpr_int(root, "domain/vcpu_avail"));
+ int vcpus = count_one_bits_l(sexpr_u64(root, "domain/vcpu_avail"));
if (vcpus)
ret = MIN(vcpus, ret);
}
@@ -5770,10 +5770,11 @@ xenDaemonFormatSxpr(virConnectPtr conn,
virBufferVSprintf(&buf, "(memory %lu)(maxmem %lu)",
def->mem.cur_balloon/1024, def->mem.max_balloon/1024);
virBufferVSprintf(&buf, "(vcpus %u)", def->maxvcpus);
- /* Computing the vcpu_avail bitmask works because MAX_VIRT_CPUS is 32. */
- verify(MAX_VIRT_CPUS <= sizeof(1U) * CHAR_BIT);
+ /* Computing the vcpu_avail bitmask works because MAX_VIRT_CPUS is
+ either 32, or 64 on a platform where long is big enough. */
+ verify(MAX_VIRT_CPUS <= sizeof(1UL) * CHAR_BIT);
if (def->vcpus < def->maxvcpus)
- virBufferVSprintf(&buf, "(vcpu_avail %u)", (1U << def->vcpus) - 1);
+ virBufferVSprintf(&buf, "(vcpu_avail %lu)", (1UL << def->vcpus) - 1);
if (def->cpumask) {
char *ranges = virDomainCpuSetFormat(def->cpumask, def->cpumasklen);
@@ -5870,8 +5871,8 @@ xenDaemonFormatSxpr(virConnectPtr conn,
virBufferVSprintf(&buf, "(vcpus %u)", def->maxvcpus);
if (def->vcpus < def->maxvcpus)
- virBufferVSprintf(&buf, "(vcpu_avail %u)",
- (1U << def->vcpus) - 1);
+ virBufferVSprintf(&buf, "(vcpu_avail %lu)",
+ (1UL << def->vcpus) - 1);
for (i = 0 ; i < def->os.nBootDevs ; i++) {
switch (def->os.bootDevs[i]) {
diff --git a/src/xen/xm_internal.c b/src/xen/xm_internal.c
index f80e252..6c5df0f 100644
--- a/src/xen/xm_internal.c
+++ b/src/xen/xm_internal.c
@@ -776,7 +776,7 @@ xenXMDomainConfigParse(virConnectPtr conn, virConfPtr conf) {
def->maxvcpus = count;
if (xenXMConfigGetULong(conf, "vcpu_avail", &count, -1) < 0)
goto cleanup;
- def->vcpus = MIN(count_one_bits(count), def->maxvcpus);
+ def->vcpus = MIN(count_one_bits_l(count), def->maxvcpus);
if (xenXMConfigGetString(conf, "cpus", &str, NULL) < 0)
goto cleanup;
@@ -2336,10 +2336,11 @@ virConfPtr xenXMDomainConfigFormat(virConnectPtr conn,
if (xenXMConfigSetInt(conf, "vcpus", def->maxvcpus) < 0)
goto no_memory;
- /* Computing the vcpu_avail bitmask works because MAX_VIRT_CPUS is 32. */
- verify(MAX_VIRT_CPUS <= sizeof(1U) * CHAR_BIT);
+ /* Computing the vcpu_avail bitmask works because MAX_VIRT_CPUS is
+ either 32, or 64 on a platform where long is big enough. */
+ verify(MAX_VIRT_CPUS <= sizeof(1UL) * CHAR_BIT);
if (def->vcpus < def->maxvcpus &&
- xenXMConfigSetInt(conf, "vcpu_avail", (1U << def->vcpus) - 1) < 0)
+ xenXMConfigSetInt(conf, "vcpu_avail", (1UL << def->vcpus) - 1) < 0)
goto no_memory;
if ((def->cpumask != NULL) &&
--
1.7.2.3
13 years, 11 months