[libvirt] Google Summer of Code 2013 ideas wiki open
by Stefan Hajnoczi
I have created the Google Summer of Code 2013 wiki page where you can
add project ideas:
http://wiki.qemu.org/Google_Summer_of_Code_2013
Please add project ideas you are willing to mentor. If you have an
idea but cannot mentor this year, feel free to add it but please try
to find a mentor for it.
If you want to be a mentor, please see
http://wiki.qemu.org/Google_Summer_of_Code_2013#Information_for_mentors.
Background on Google Summer of Code:
Google Summer of Code is a scheme where Google funds university
students to work on open source projects for 12 weeks during the
summer. It has been held annually since 2005.
GSoC is an opportunity for students to experience open source
development. Organizations sometimes find long-term contributors, and
either way it's a fun experience.
Open source organizations can apply to take part. Those chosen will
be able to take on one or more students for the summer. Each student
is paired with a mentor who helps them and evaluates their progress.
Last year QEMU was not accepted but we were successful in years before
that. I believe Google will announce GSoC again this year (there is
no guarantee though) and I have created the wiki page so we can begin
organizing project ideas that students can choose from.
This way we'll be ready to put together a good organization application.
Stefan
11 years, 7 months
[libvirt] [PATCH 0/5] VirtualBox version 4.2 support for libvirt vbox driver
by ryan woodsmall
This patch set adds VirtualBox 4.2 initial support for the libvirt vbox driver.
I've tested enough to check capabilities, create a VM, destroy it, etc. Five
patches total:
- Patch 1 is the C API header file from Oracle, cleaned up for libvirt.
- Patch 2 is the version specific source file for version dependency.
- Patch 3 is the src/Makefile.am change to pick up the two new files.
- Patch 4 is the vbox driver support for the new VirtualBox API/version.
- Patch 5 is the vbox_tmpl.c template support for the new version.
A few things have changed in the VirtualBox API - some small (capitalizations
of things in function names like Ip to IP and Dhcp to DHCP) and some much larger
(FindMedium is superceded by OpenMedium). The biggest change for the sake of this
patch set is the signature of CreateMachine is quite a bit different. Using the
Oracle source as a guide, to spin up a VM with a given UUID, it looks like a text
flag has to be passed in a new argument to CreateMachine. This flag is built in the
VirtualBox 4.2 specific ifdefs and is kind of ugly but works. Additionally, there
is now (unused) VM groups support in CreateMachine and the previous 'osTypeId' arg
is currently set to nsnull as in the Oracle code.
The FindMedium to OpenMedium changes were more straightforward and are pretty clear.
The rest of the vbox template changes are basically spelling/capitalization changes
from the looks of things.
This probably isn't perfect, but it works on git and patched against 0.10.2 for a
few quick tests. Not currently on the list, so ping me directly if you need any
other info on these, or if anything could use additional work. Thanks! -r
ryan woodsmall (5):
vbox C API header for VirtualBox v4.2
vbox version-specific C file for VirtualBox v4.2
Makefile.am additions for VirtualBox v4.2
vbox driver support for VirtualBox v4.2
vbox template support for VirtualBox v4.2
src/Makefile.am | 3 +-
src/vbox/vbox_CAPI_v4_2.h | 8855 +++++++++++++++++++++++++++++++++++++++++++++
src/vbox/vbox_V4_2.c | 13 +
src/vbox/vbox_driver.c | 8 +
src/vbox/vbox_tmpl.c | 90 +-
5 files changed, 8958 insertions(+), 11 deletions(-)
create mode 100644 src/vbox/vbox_CAPI_v4_2.h
create mode 100644 src/vbox/vbox_V4_2.c
11 years, 7 months
[libvirt] [PATCH] Release VM lock before acquiring virDomainObjListPtr lock
by Daniel P. Berrange
From: "Daniel P. Berrange" <berrange(a)redhat.com>
When removing a VM from the virDomainObjListPtr, we must not
be holding the VM lock while acquiring the list lock. Re-order
code to ensure that we can release the VM lock early.
---
src/conf/domain_conf.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 5e16ddf..d92e54a 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -2115,11 +2115,10 @@ void virDomainObjListRemove(virDomainObjListPtr doms,
{
char uuidstr[VIR_UUID_STRING_BUFLEN];
- virObjectLock(doms);
virUUIDFormat(dom->def->uuid, uuidstr);
-
virObjectUnlock(dom);
+ virObjectLock(doms);
virHashRemoveEntry(doms->objs, uuidstr);
virObjectUnlock(doms);
}
--
1.8.1
11 years, 7 months
[libvirt] [libvirt-php PATCH 0/1] use LDFLAGS for libvirt-php.so
by stefan.kuhn＠foss-group.ch
I'm getting this warning:
* QA Notice: Files built without respecting LDFLAGS have been detected
* Please include the following list of files in your report:
* /usr/lib64/php5.3/lib/extensions/no-debug-non-zts-20090626/libvirt-php.so
The attached patch seems reasonable to me, please check it.
Thank you very much for the quick responses and for adding me to the authors! :-)
Stefan
Stefan Kuhn (1):
src/Makefile.am: use LDFLAGS for libvirt-php.so
src/Makefile.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
1.7.12.4
11 years, 7 months
[libvirt] [libvirt-php PATCH 0/1] Fix: mutlithreading compilation: set_error needs 2 params
by stefan.kuhn＠foss-group.ch
= Info =
Someone reports errors withing "PHP_FUNCTION(libvirt_domain_migrate)" due to "set_error":
libvirt-php.c: In function ‘zif_libvirt_domain_migrate’:
libvirt-php.c:5456:3: error: too few arguments to function ‘set_error’
= Background =
Michal Novotny already reacted to Gentoos bug:
Bug 437624 - =dev-php/libvirt-php-0.4.6: too few arguments to function ‘set_error’
https://bugs.gentoo.org/show_bug.cgi?id=437624
with commit:
bfca998ae921ab897f95025344fad71d9633ccf6
http://libvirt.org/git/?p=libvirt-php.git;a=commit;h=bfca998ae921ab897f95...
but some calls to "set_error" still lacked the 2nd param "TSRMLS_CC", especially in the "PHP_FUNCTION(libvirt_domain_migrate)".
= Patch =
Add 2nd param "TSRMLS_CC" to all calls of "set_error" where only 1 param was supplied.
Stefan Kuhn (1):
Fix: mutlithreading compilation: set_error needs 2 params
src/libvirt-php.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--
1.7.12.4
11 years, 7 months
[libvirt] libvirt<->QEMU interfaces for CPU models
by Eduardo Habkost
Hi,
After a long time trying to figure out the proper modelling inside QEMU,
I believe the plans are now clearer in QEMU, so it's time to coordinate
more closely with libvirt to try to make use of the new stuff.
I tried to enumerate the libvirt requirements and current problems, and
how we should be able to solve those problems using the X86CPU
subclasses and properties, on the following wiki page:
http://wiki.qemu.org/Features/CPUModels#Interfaces.2Frequirements_from_li...
I am pasting the section contents below, to facilitate discussion:
= Ensuring predictable set of guest features =
Requirement: libvirt needs to ensure all features required on the command-line
are present and exposed to the guest.
Current problem: libvirt doesn't use the "enforce" flag so it can't guarantee
that a given feature will be actually exposed to the guest.
Solution: use the "enforce" flag on the "-cpu" option.
Limitation: no proper machine-friendly interface to report which features
are missing.
Workaround: See "querying for host capabilities" below.
== Future plans ==
Machine-friendly reporting of missing host features/capabilities.
= Listing CPU models =
Requirement: libvirt needs to know which CPU models are available to be used
with the "-cpu" option.
Current problem: libvirt relies on help output parsing for that.
Solution: use QMP qom-list-types command.
Dependency: X86CPU subclasses.
Limitation: needs a live QEMU process for the query.
Solution: use QMP query-cpu-definitions command.
Limitation: needs a live QEMU process for the query.
== Future plans ==
It would be interesting to get rid of the requirement for a live QEMU process
(with a complete machine being created) to be already running.
= Getting information about CPU models =
Requirement: libvirt uses the predefined CPU models from QEMU, but it needs to
be able to query for CPU model details, to find out how it can create a VM that
matches what was requested by the user.
Current problem: libvirt has a copy of the CPU model definitions on its
cpu_map.xml file, and the copy can be out of sync in case CPU models in QEMU
change. libvirt also assumes that the set of features on each model is always
the same on all machine-types, which is not true.
Challenge: the resulting CPU features depend on lots of factors, including
the machine-type.
Workaround: start a paused VM and query for the CPU device information
after the CPU was created.
Solution: start a paused VM with no devices, but with the right
machine-type and right CPU model. Use QMP QOM commands to query for CPU
flags (especially the properties starting with the "f-" prefix).
Dependency: X86CPU feature properties ("f-*" properties).
Limitation: requires a live QEMU process with the right machine-type/
CPU-model to be started, to make the query.
Requirement: libvirt needs to know if a specific CPU model can be used in the
current host.
See "Ensuring predictable set of guest features" above
See "Querying host capabilities" below
= Querying host capabilities =
Requirement: libvirt needs to know which feature can really be enabled, before
it tries to start a VM, and before it tries to start a live-migration process.
The set of available capabilities depend on:
• Host CPU (hardware) capabilities;
• Kernel capabilities (reported by GET_SUPPORTED_CPUID);
• QEMU capabilities;
• Specific configuration options (e.g. in-kernel IRQ chip is required for
some features).
Current problem: libvirt uses the CPUID intruction directly and assumes that
the presence of a feature in the host CPU means it can be enabled and exposed
to the guest. This breaks when virtualization of a feature requires:
• Additional hardware support (e.g. INVPCID);
• Additional host kernel code (this applies to _all_ CPU features, that need
to be reported as supported by GET_SUPPORTED_CPUID);
• Additional QEMU-side code;
• Specific configuration options (e.g. in-kernel IRQ chip).
Challenge: QEMU doesn't have a generic capability-querying interface, and host
capability querying depends on KVM to be initialized.
Workaround: start a paused VM using the "host" CPU model, that has every
single CPU feature supported by the host enabled by default, and query for
the information about the CPU though QMP, using the QOM commands.
Current solution: start a paused VM with no devices but with "host" CPU model
and use QMP QOM commands to query for the enabled CPU features.
Dependency: X86CPU feature properties
== Future plans ==
It would be interesting to have a more generic capability-querying interface
that doesn't require starting a whole machine with a live QEMU process.
See also: -query-capabilities RFC series from Anthony
Message-Id: <1332169763-30665-9-git-send-email-aliguori(a)us.ibm.com>
--
Eduardo
11 years, 8 months
[libvirt] Problems with <filesystem type='block'>
by Lars Kellogg-Stedman
Using libvirt 1.0.1, I'm trying to start an LXC container using the
'<filesytem type="block">' syntax, like this:
<filesystem type="block" accessmode="passthrough">
<source dev="/dev/vg_files/vm-foobar-root" />
<target dir="/" />
</filesystem>
The specified block device exists:
# ls -lL /dev/vg_files/vm-foobar-root
brw-rw---- 1 root disk 253, 19 Dec 21 22:23 /dev/vg_files/vm-foobar-root
If I start the domain, it appears to start without any errors...
# virsh start foobar
Domain foobar started
...but it's not actually running. The log files (with loglevel=2)
don't seem to be very interesting; this is everything from the
instance log file:
2012-12-22 04:10:57.862+0000: starting up
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin LIBVIRT_DEBUG=2 LIBVIRT_LOG_OUTPUTS=2:stderr /usr/lib/libvirt/libvirt_lxc --name foobar --console 22 --security=none --handshake 25 --background --veth veth1
2012-12-22 04:10:57.967+0000: 1468: info : libvirt version: 1.0.1
2012-12-22 04:10:57.967+0000: 1468: info : lxcCapsInit:151 : No driver, not initializing security driver
PATH=/bin:/sbin TERM=linux container=lxc-libvirt container_uuid=9041e32e-1df2-00c2-4660-dfa5b41510b7 LIBVIRT_LXC_UUID=9041e32e-1df2-00c2-4660-dfa5b41510b7 LIBVIRT_LXC_NAME=foobar /sbin/init
2012-12-22 04:10:58.198+0000: 1: warning : lxcContainerDropCapabilities:1788 : libcap-ng support not compiled in, unable to clear capabilities
2012-12-22 04:10:58.198+0000: 1493: warning : lxcControllerClearCapabilities:679 : libcap-ng support not compiled in, unable to clear capabilities
Running an "strace" on the libvirtd process (strace -p <libvirtd_pid>
-f ...), it doesn't look like libvirt is ever trying to mount the
referenced filesystem.
Is this supposed to work? It seems like the support for having
libvirt mount the block device is relatively recent, and I haven't had
much luck finding examples of other folks using this capability.
Thanks,
-- Lars
11 years, 8 months
[libvirt] [PATCH 0/4] Multiple problems with saving to block devices
by Daniel P. Berrange
This patch series makes it possible to save to a block device,
instead of a plain file. There were multiple problems
- WHen save failed, we might de-reference a NULL pointer
- When save failed, we unlinked the device node !!
- The approach of using >> to append, doesn't work with block devices
- CGroups was blocking QEMU access to the block device when enabled
One remaining problem is not in libvirt, but rather QEMU. The QEMU
exec: based migration often fails to detect failure of the command
and will thus hang forever attempting a migration that'll never
succeed! Fortunately you can now work around this in libvirt using
the virsh domjobabort command
11 years, 8 months
[libvirt] [PATCH 00/13] Network disk improvements (NBD & libiscsi)
by Paolo Bonzini
This series improves support for NBD disks (patches 1-6), and adds
support for the libiscsi userspace initiator (patches 7-13).
Please review!
Paolo
Paolo Bonzini (13):
qemu: fix use-after-free when parsing NBD disk
qemu: do not support non-network disks without -drive
qemu: rewrite NBD command-line builder and parser
qemu: support named nbd exports
qemu: support NBD with Unix sockets
qemu: support URI syntax for NBD
domain: add support for iscsi network disks
qemu: add support for libiscsi
qemu: support LUN numbers for iSCSI disks
domain: make port optional for network disks
secret: add iscsi to possible usage types
domain: parse XML for iscsi authorization credentials
qemu: pass iscsi authorization credentials
docs/formatdomain.html.in | 42 +-
docs/formatsecret.html.in | 12 +
docs/schemas/domaincommon.rng | 37 +-
docs/schemas/secret.rng | 10 +
include/libvirt/libvirt.h.in | 1 +
src/conf/domain_conf.c | 51 ++-
src/conf/domain_conf.h | 3 +
src/conf/secret_conf.c | 22 +-
src/conf/secret_conf.h | 1 +
src/qemu/qemu_command.c | 432 ++++++++++++++-------
src/secret/secret_driver.c | 8 +
tests/qemuargv2xmltest.c | 5 +
.../qemuxml2argv-disk-drive-network-gluster.args | 2 +-
...qemuxml2argv-disk-drive-network-iscsi-auth.args | 1 +
.../qemuxml2argv-disk-drive-network-iscsi-auth.xml | 31 ++
.../qemuxml2argv-disk-drive-network-iscsi.args | 1 +
.../qemuxml2argv-disk-drive-network-iscsi.xml | 34 ++
...qemuxml2argv-disk-drive-network-nbd-export.args | 5 +
.../qemuxml2argv-disk-drive-network-nbd-export.xml | 33 ++
...ml2argv-disk-drive-network-nbd-ipv6-export.args | 5 +
...xml2argv-disk-drive-network-nbd-ipv6-export.xml | 33 ++
.../qemuxml2argv-disk-drive-network-nbd-ipv6.args | 5 +
.../qemuxml2argv-disk-drive-network-nbd-ipv6.xml | 33 ++
.../qemuxml2argv-disk-drive-network-nbd-unix.args | 5 +
.../qemuxml2argv-disk-drive-network-nbd-unix.xml | 33 ++
tests/qemuxml2argvtest.c | 12 +
tests/qemuxml2xmltest.c | 7 +
27 files changed, 687 insertions(+), 177 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-iscsi-auth.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-iscsi-auth.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-iscsi.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-iscsi.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-nbd-export.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-nbd-export.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-nbd-ipv6-export.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-nbd-ipv6-export.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-nbd-ipv6.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-nbd-ipv6.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-nbd-unix.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-nbd-unix.xml
--
1.8.1.2
11 years, 8 months
