[libvirt] [PATCH 0/3] caps: expose the user and group owner of the HV
by Giuseppe Scrivano
virt-manager has no way to known the user/group that run the HV
process without requiring the user to manually set it trough setup.py
or assuming "root" as default value.
This series extends the Guest capabilities with "hv_user" and
"hv_group", to inform the libvirt user about the user/group (when qemu
is used) that run the HV process.
Giuseppe Scrivano (3):
caps: new internal function "virCapabilitiesSetHvUserAndGroup"
qemu: set hv_user/hv_group caps to the user/group which runs qemu
caps: add tests and documentation for hv_user and hv_group
docs/schemas/capability.rng | 10 +++++++
src/conf/capabilities.c | 46 +++++++++++++++++++++++++++++++
src/conf/capabilities.h | 7 +++++
src/libvirt_private.syms | 1 +
src/qemu/qemu_capabilities.c | 3 ++
tests/capabilityschemadata/caps-test2.xml | 4 +++
6 files changed, 71 insertions(+)
--
1.8.3.1
10 years, 8 months
[libvirt] [PATCH 0/3] Keep original file label
by Michal Privoznik
This is just a resurrection of my previous patchset. As of atomicity
problem, I just realized there is none. The qemuProcessHook (which is
responsible for locking the files) is called prior
virSecurityManagerSetAllLabel (responsible for chown()-ing). Anyway,
even if there's still one and it's pre-existing, it shouldn't block this
set, should it?
Michal Privoznik (3):
virFile: Add APIs for extended attributes handling
virfile: Introduce internal API for managing ACL
security_dac: Favour ACLs over chown()
configure.ac | 2 +
libvirt.spec.in | 1 +
m4/virt-acl.m4 | 9 ++
src/Makefile.am | 4 +-
src/libvirt_private.syms | 6 +
src/security/security_dac.c | 297 ++++++++++++++++++++++++++++++++++++++-----
src/util/virfile.c | 301 ++++++++++++++++++++++++++++++++++++++++++++
src/util/virfile.h | 28 +++++
8 files changed, 617 insertions(+), 31 deletions(-)
create mode 100644 m4/virt-acl.m4
--
1.8.1.5
10 years, 8 months
[libvirt] [PATCH 0/3] Fix and clean up multiple issues in virsh console handling
by Peter Krempa
This series has to be applied on top of "virsh: Handle interrupting of jobs manually".
Peter Krempa (3):
tools: rename console.[ch] to virsh-console.[ch] and fix coding style
virsh: Rename vshMakeStdinRaw to vshTTYMakeRaw and move it to virsh.c
virsh-console: Avoid using signal() in multithreaded application
cfg.mk | 2 +-
po/POTFILES.in | 2 +-
tools/Makefile.am | 2 +-
tools/{console.c => virsh-console.c} | 153 +++++++++++++++--------------------
tools/{console.h => virsh-console.h} | 11 ++-
tools/virsh-domain.c | 4 +-
tools/virsh.c | 50 +++++++++++-
tools/virsh.h | 1 +
8 files changed, 123 insertions(+), 102 deletions(-)
rename tools/{console.c => virsh-console.c} (76%)
rename tools/{console.h => virsh-console.h} (81%)
--
1.8.3.2
10 years, 8 months
[libvirt] [PATCH 00/12] Various libxl driver improvements
by Jim Fehlig
This series contains several improvements for the libxl driver.
Patches 1 and 2 are primarily code movement, putting code in
files that are more consistent with other drivers.
Patches 3 through 12 improve locking of the libxlDriverPrivate
struct, similar to the work done in the QEMU and LXC drivers
Obviously post-1.1.2 material, but would be nice to get it in
soon thereafter for testing throughout the 1.1.3 cycle...
Jim Fehlig (12):
libxl: Move detection of autoballoon to libxl_conf
libxl: Introduce libxl_domain.[ch]
libxl: Earlier detection of not running on Xen
libxl: Add libxl_version_info to libxlDriverPrivate
libxl: libxl: Use per-domain ctx in libxlMakeDomCreateInfo
libxl: User per-domain ctx in libxlDomainGetInfo
libxl: Introduce libxlDriverConfig object
libxl: Use atomic ops for driver->nactive
libxl: Add comments to libxlDriverPrivate fields
libxl: Move driver lock/unlock to libxl_conf
libxl: Remove unnecessary driver locking
libxl: Add libxlDomObjFromDomain
po/POTFILES.in | 1 +
src/Makefile.am | 1 +
src/libxl/libxl_conf.c | 149 +++++-
src/libxl/libxl_conf.h | 87 +--
src/libxl/libxl_domain.c | 469 ++++++++++++++++
src/libxl/libxl_domain.h | 61 +++
src/libxl/libxl_driver.c | 1329 ++++++++++------------------------------------
7 files changed, 1010 insertions(+), 1087 deletions(-)
create mode 100644 src/libxl/libxl_domain.c
create mode 100644 src/libxl/libxl_domain.h
--
1.8.1.4
10 years, 8 months
[libvirt] [PATCH] build: only create virt-login-shell for lxc builds
by Eric Blake
I noticed from an ./autobuild.sh run that we were installing a
virt-login-shell.exe binary when cross-building for mingw,
even though such a binary is necessarily worthless since the
code depends on lxc which is a Linux-only concept.
* tools/Makefile.am (conf_DATA, bin_PROGRAMS, dist_man1_MANS):
Make virt-login-shell installation conditional.
Signed-off-by: Eric Blake <eblake(a)redhat.com>
---
I'm debating about pushing this under the build-breaker rule.
tools/Makefile.am | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/tools/Makefile.am b/tools/Makefile.am
index 74fae2d..4a3338f 100644
--- a/tools/Makefile.am
+++ b/tools/Makefile.am
@@ -60,10 +60,10 @@ EXTRA_DIST = \
DISTCLEANFILES =
confdir = $(sysconfdir)/libvirt
-conf_DATA = virt-login-shell.conf
+conf_DATA =
bin_SCRIPTS = virt-xml-validate virt-pki-validate
-bin_PROGRAMS = virsh virt-host-validate virt-login-shell
+bin_PROGRAMS = virsh virt-host-validate
libexec_SCRIPTS = libvirt-guests.sh
if WITH_SANLOCK
@@ -71,12 +71,20 @@ sbin_SCRIPTS = virt-sanlock-cleanup
DISTCLEANFILES += virt-sanlock-cleanup
endif
+if WITH_LXC
+conf_DATA += virt-login-shell.conf
+bin_PROGRAMS += virt-login-shell
+endif WITH_LXC
+
+
dist_man1_MANS = \
virt-host-validate.1 \
virt-pki-validate.1 \
virt-xml-validate.1 \
- virt-login-shell.1 \
virsh.1
+if WITH_LXC
+dist_man1_MANS += virt-login-shell.1
+endif WITH_LXC
if WITH_SANLOCK
dist_man8_MANS = virt-sanlock-cleanup.8
endif
--
1.8.3.1
10 years, 8 months
Re: [libvirt] [PATCHv3 2/6] virsh: Add vshCmdCompleter and vshOptCompleter
by Eric Blake
[re-adding the list, which was accidentally omitted]
On 08/28/2013 05:26 AM, Tomas Meszaros wrote:
>> Per-option completions make sense. For example, 'virsh vol-key --pool
>> <TAB>' wants to use a pool completer, while 'virsh vol-key --vol <TAB>'
>> wants to use a volume completer; furthermore, 'virsh vol-key <TAB>'
>> should be the combination of the option completer (showing --vol and
>> --pool) AND the volume completer filtered to names not starting with '-'
>> (since virsh has the semantics that arguments are positional, where the
>> option '--vol' is implied if the argument that appears in that position
>> does not resemble an option).
>
> So If I get it right, you are suggesting that it should work like this:
>
> virsh # vol-key <TAB>
> vol1 vol2 pool1 pool2
>
> as you said, combination of --vol and --pool completers.
No, it should work like this:
virsh# vol-key <TAB>
vol1 vol2 --vol --pool
the combination of all (non-option) completions for the current
available mandatory option (volume completer), and of all possible
options that still make sense at this point in the command line.
Likewise:
virsh# vol-key vol <TAB>
pool1 pool2 --pool
virsh# vol-key -<TAB>
--vol --pool
virsh# vol-key v<TAB>
vol1 vol2
virsh# vol-key --pool <TAB>
pool1 pool2
virsh# vol-key --pool pool1 <TAB>
vol1 vol2 --vol
and so forth.
>
>
> I was initially thinking that completion should work like this:
>
> virsh # vol-key <TAB>
> vol1 vol2
>
> It is completing <vol> first becasue <vol> is only mandatory argument
> for this command.
It is a mandatory option, but mandatory options need not come first.
Remember, our option parser allows mandatory options to occur
positionally without an option name, OR to be interleaved in any other
order by including the option string.
>
>
> Only if someone type:
>
> virsh # vol-key --pool <TAB>
> pool1 pool2
>
> then call --pool completer.
This is correct - once an option is awaiting an argument, then the
option completer must return nothing at that point in time. But if you
look at it as the union of two completers - the set of options that are
still valid in the current context, and the set of strings that are
valid assuming positional semantics of the current option, you will
always get the right answer, without needing a per-command completer
(just per-option completers).
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
10 years, 8 months
[libvirt] RFC: Splitting python binding out into a separate repo & ading to PyPi
by Daniel P. Berrange
As everyone knows, we have historically always shipped the python binding
as part of the libvirt primary tar.gz distribution. In some ways that has
simplified life for people, since we know they'll always have a libvirt
python that matches their libvirt C library.
At the same time though, this policy of ours is causing increasing amounts
of pain for a number of our downstream users.
In OpenStack, in particular, their development and test environments aim
to be able to not rely on any system installed python packages. They use
a virtualenv and pip to install all python deps from PyPi (equivalent of
Perl's CPAN in Python world). This approach works for everything except
the libvirt Python code which is not available standalone on PyPi. This
is causing so much pain that people have suggested taking the libvirt
python code we ship and just uploading it to PyPi themselves[1]. This
would obviously be a somewhat hostile action to take, but the way we
distribute libvirt python is forcing OpenStack to consider such things.
In RHEL world too, bundling of libvirt + its python binding is causing
pain with the fairly recent concept of "software collections"[2]. This
allows users to install multiple versions of languages like Python, Perl,
etc on the same box in parallel. To use libvirt python with thse alternate
python installs though, requires that they recompile the entire libvirt
distribution just to get the Python binding. This is obviously not an
approach that works for most people, particularly if they're looking to
populate their software collection using 'pip' rather than RPM.
Looking on google there are a number of other people asking for libvirt
python as a separate module, eg on Stackoverflow[3].
I don't think these issues are going to go away, in fact I think they
will likely become more pressing, until the point where some 3rd party
takes the step of providing libvirt python bindings themselves. I don't
think we want to let ourselves drift into the situation where we loose
control over releasing libvirt python bindings.
IMHO we should / must listen to our users here before it is too late.
We can still release libvirt python at the same time as normal libvirt
releases, and require that people update the bindings whenever adding
new APIs (if the generator doesn't cope with them). We should simply
distribute python as a separate tar.gz, as we do for all other languages,
and upload it to PyPi, as well as libvirt.org FTP when doing a release.
Obviously there will be some work to separate things out, but I don't
see that being insurmountable, since all other language bindings manage
to be separate, even when doing code generation. We'd also want to
change to use distutils, rather than autoconf, since that's what the
python world wants.
Regards,
Daniel
[1] http://lists.openstack.org/pipermail/openstack-dev/2013-August/013187.html
[2] https://access.redhat.com/site/documentation/en-US/Red_Hat_Developer_Tool...
[3] http://stackoverflow.com/questions/14924460/is-there-any-way-to-install-l...
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
10 years, 8 months
[libvirt] [PATCH v2] kvm: warn if num cpus is greater than num recommended
by Andrew Jones
The comment in kvm_max_vcpus() states that it's using the recommended
procedure from the kernel API documentation to get the max number
of vcpus that kvm supports. It is, but by always returning the
maximum number supported. The maximum number should only be used
for development purposes. qemu should check KVM_CAP_NR_VCPUS for
the recommended number of vcpus. This patch adds a warning if a user
specifies a number of cpus between the recommended and max.
v2:
Incorporate tests for max_cpus, which specifies the maximum number
of hotpluggable cpus. An additional note is that the message for
the fail case was slightly changed, 'exceeds max cpus' to
'exceeds the maximum cpus'. If this is unacceptable change for
users like libvirt, then I'll need to spin a v3.
Signed-off-by: Andrew Jones <drjones(a)redhat.com>
---
kvm-all.c | 69 ++++++++++++++++++++++++++++++++++++---------------------------
1 file changed, 40 insertions(+), 29 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index a2d49786365e3..021f5f47e53da 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -1322,24 +1322,20 @@ static int kvm_irqchip_create(KVMState *s)
return 0;
}
-static int kvm_max_vcpus(KVMState *s)
+/* Find number of supported CPUs using the recommended
+ * procedure from the kernel API documentation to cope with
+ * older kernels that may be missing capabilities.
+ */
+static int kvm_recommended_vcpus(KVMState *s)
{
- int ret;
-
- /* Find number of supported CPUs using the recommended
- * procedure from the kernel API documentation to cope with
- * older kernels that may be missing capabilities.
- */
- ret = kvm_check_extension(s, KVM_CAP_MAX_VCPUS);
- if (ret) {
- return ret;
- }
- ret = kvm_check_extension(s, KVM_CAP_NR_VCPUS);
- if (ret) {
- return ret;
- }
+ int ret = kvm_check_extension(s, KVM_CAP_NR_VCPUS);
+ return (ret) ? ret : 4;
+}
- return 4;
+static int kvm_max_vcpus(KVMState *s)
+{
+ int ret = kvm_check_extension(s, KVM_CAP_MAX_VCPUS);
+ return (ret) ? ret : kvm_recommended_vcpus(s);
}
int kvm_init(void)
@@ -1347,11 +1343,19 @@ int kvm_init(void)
static const char upgrade_note[] =
"Please upgrade to at least kernel 2.6.29 or recent kvm-kmod\n"
"(see http://sourceforge.net/projects/kvm).\n";
+ struct {
+ const char *name;
+ int num;
+ } num_cpus[] = {
+ { "SMP", smp_cpus },
+ { "hotpluggable", max_cpus },
+ { NULL, }
+ }, *nc = num_cpus;
+ int soft_vcpus_limit, hard_vcpus_limit;
KVMState *s;
const KVMCapabilityInfo *missing_cap;
int ret;
int i;
- int max_vcpus;
s = g_malloc0(sizeof(KVMState));
@@ -1392,19 +1396,26 @@ int kvm_init(void)
goto err;
}
- max_vcpus = kvm_max_vcpus(s);
- if (smp_cpus > max_vcpus) {
- ret = -EINVAL;
- fprintf(stderr, "Number of SMP cpus requested (%d) exceeds max cpus "
- "supported by KVM (%d)\n", smp_cpus, max_vcpus);
- goto err;
- }
+ /* check the vcpu limits */
+ soft_vcpus_limit = kvm_recommended_vcpus(s);
+ hard_vcpus_limit = kvm_max_vcpus(s);
- if (max_cpus > max_vcpus) {
- ret = -EINVAL;
- fprintf(stderr, "Number of hotpluggable cpus requested (%d) exceeds max cpus "
- "supported by KVM (%d)\n", max_cpus, max_vcpus);
- goto err;
+ while (nc->name) {
+ if (nc->num > soft_vcpus_limit) {
+ fprintf(stderr,
+ "Warning: Number of %s cpus requested (%d) exceeds "
+ "the recommended cpus supported by KVM (%d)\n",
+ nc->name, nc->num, soft_vcpus_limit);
+
+ if (nc->num > hard_vcpus_limit) {
+ ret = -EINVAL;
+ fprintf(stderr, "Number of %s cpus requested (%d) exceeds "
+ "the maximum cpus supported by KVM (%d)\n",
+ nc->name, nc->num, hard_vcpus_limit);
+ goto err;
+ }
+ }
+ nc++;
}
s->vmfd = kvm_ioctl(s, KVM_CREATE_VM, 0);
--
1.8.1.4
10 years, 8 months
[libvirt] [PATCH 0/3] virsh: Handle interrupting of jobs manually
by Peter Krempa
Using Ctrl+C to abort migration has a side effect of killing
ssh transports used to execute the migration. Add manual handling
to avoid this issue.
Peter Krempa (3):
virsh-domain: rename print_job_progress to vshPrintJobProgress
virsh: Remember terminal state when starting and add helpers
virsh-domain: Avoid killing ssh transport tunnels when cancelling job
tools/virsh-domain.c | 65 +++++++++++++++++++++++++++++++++-------------------
tools/virsh.c | 54 +++++++++++++++++++++++++++++++++++++++++++
tools/virsh.h | 9 ++++++++
3 files changed, 105 insertions(+), 23 deletions(-)
--
1.8.3.2
10 years, 8 months
[libvirt] [PATCHv3 0/4] VMX: CD-ROM handling improvements
by Doug Goldstein
A user came into #virt the other day and was trying to get libvirtd
to work with VMWare Fusion 5, which is basically the Mac OS X version of
VMWare Workstation. In helping him out I noticed a few limitations of our
VMX parser so I've added support through this patchset. However I came
across the fact that we only support 2 types of CD-ROMs instead of the 3
types that VMWare has lead to adding support for a <driver> element to
CD-ROM drives.
v3:
* Dropped 'auto detect' support from series as it needs more work based on
feedback
* Added patch to combine virVMXFormatHardDisk and virVMXFormatCDROM into
one function.
* Converted to <disk type='block' device='lun'> instead of adding a
<driver> element to better match the behavior available via QEMU.
v2:
* Added additional test cases and fixed issues that arose from those
Doug Goldstein (4):
VMX: Create virVMXFormatDisk() from HD and CD-ROM
VMX: Add cdrom-raw dev type from VMWare Fusion
VMX: Add a VMWare Fusion 5 configuration for tests
VMX: Some serial ports are not actually connected
docs/formatdomain.html.in | 3 +-
src/libvirt_vmx.syms | 3 +-
src/vmx/vmx.c | 216 ++++++++-------------
src/vmx/vmx.h | 5 +-
tests/vmx2xmldata/vmx2xml-cdrom-ide-raw-device.vmx | 5 +
tests/vmx2xmldata/vmx2xml-cdrom-ide-raw-device.xml | 24 +++
.../vmx2xmldata/vmx2xml-cdrom-scsi-raw-device.vmx | 6 +
.../vmx2xmldata/vmx2xml-cdrom-scsi-raw-device.xml | 24 +++
tests/vmx2xmldata/vmx2xml-fusion-in-the-wild-1.vmx | 88 +++++++++
tests/vmx2xmldata/vmx2xml-fusion-in-the-wild-1.xml | 38 ++++
tests/vmx2xmltest.c | 4 +
tests/xml2vmxdata/xml2vmx-cdrom-ide-raw-device.vmx | 13 ++
tests/xml2vmxdata/xml2vmx-cdrom-ide-raw-device.xml | 14 ++
.../xml2vmxdata/xml2vmx-cdrom-scsi-raw-device.vmx | 14 ++
.../xml2vmxdata/xml2vmx-cdrom-scsi-raw-device.xml | 14 ++
tests/xml2vmxdata/xml2vmx-fusion-in-the-wild-1.vmx | 30 +++
tests/xml2vmxdata/xml2vmx-fusion-in-the-wild-1.xml | 40 ++++
tests/xml2vmxtest.c | 4 +
18 files changed, 400 insertions(+), 145 deletions(-)
create mode 100644 tests/vmx2xmldata/vmx2xml-cdrom-ide-raw-device.vmx
create mode 100644 tests/vmx2xmldata/vmx2xml-cdrom-ide-raw-device.xml
create mode 100644 tests/vmx2xmldata/vmx2xml-cdrom-scsi-raw-device.vmx
create mode 100644 tests/vmx2xmldata/vmx2xml-cdrom-scsi-raw-device.xml
create mode 100644 tests/vmx2xmldata/vmx2xml-fusion-in-the-wild-1.vmx
create mode 100644 tests/vmx2xmldata/vmx2xml-fusion-in-the-wild-1.xml
create mode 100644 tests/xml2vmxdata/xml2vmx-cdrom-ide-raw-device.vmx
create mode 100644 tests/xml2vmxdata/xml2vmx-cdrom-ide-raw-device.xml
create mode 100644 tests/xml2vmxdata/xml2vmx-cdrom-scsi-raw-device.vmx
create mode 100644 tests/xml2vmxdata/xml2vmx-cdrom-scsi-raw-device.xml
create mode 100644 tests/xml2vmxdata/xml2vmx-fusion-in-the-wild-1.vmx
create mode 100644 tests/xml2vmxdata/xml2vmx-fusion-in-the-wild-1.xml
--
1.8.1.5
10 years, 8 months
