Re: [libvirt] [PATCH] libxl: Check for regcomp failure
On 04.09.2013 22:18, Eric Blake wrote: > On 09/04/2013 02:03 PM, Jim Fehlig wrote: >>> >>> Yeah, good question. I found a few occurrences of regcomp() and friends >>> throughout the sources and most seem to do regfree() even when regcomp() >>> fails. The man page is not very clear, but the notes on regfree() >>> suggest it is not necessary >>> >>> POSIX Pattern Buffer Freeing >>> Supplying regfree() with a precompiled pattern buffer, preg will >>> free the memory allocated to the pattern buffer by the compiling >>> process, regcomp(). >>> >>> But does the pattern buffer contain any allocated memory when regcomp() >>> fails? The notes on regcomp() are not clear about this. > > Thankfully, we can read the source :) > > In glibc, regcomp assigns into preg, but is careful to undo any > allocation on failure; it is also careful to make regfree() a no-op on > an already-freed buffer (whether by calling regfree() twice in a row, or > using it on preg after a failed regcomp). Gnulib copies this behavior. > But it is not universally standard: Question then is: if regcomp(®, ...) fails, reg == NULL, right? But passing the @reg to regerror: regerror(errcode, ®, ...) doesn't make much sense then. It can make, if regcomp would free all mem allocated, but set @reg to different values (each of them representing different cause of error). If that is the case, this is what I call the design! Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 6/n] spec: make client-only testing easier
On 04.09.2013 23:08, Eric Blake wrote:
> Several recent patches cleaned up 'make rpm' for the situation
> when client_only is true; these were done by manual spec file
> editing (since it's relatively hard to come by a RHEL 5 s390
> box). Make it easier to do in the future via a simpler command
> line override.
>
> * libvirt.spec.in (client_only): Allow for override.
>
> Signed-off-by: Eric Blake
> ---
> libvirt.spec.in | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libvirt.spec.in b/libvirt.spec.in
> index e4b8329..a55e87c 100644
> --- a/libvirt.spec.in
> +++ b/libvirt.spec.in
> @@ -13,12 +13,13 @@
> # touch configure.ac or Makefile.am.
> %{!?enable_autotools:%define enable_autotools 0}
>
> # A client only build will create a libvirt.so only containing
> # the generic RPC driver, and test driver and no libvirtd
> -# Default to a full server + client build
> -%define client_only0
> +# Default to a full server + client build, but with the possibility
> +# of a command-line or ~/.rpmmacros override for client-only.
> +%{!?client_only:%define client_only 0}
>
> # Now turn off server build in certain cases
>
> # RHEL-5 builds are client-only for s390, ppc
> %if 0%{?rhel} == 5
>
ACK
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] conf: Don't deref NULL actual network in virDomainNetGetActualHostdev()
On 09/04/13 17:45, Eric Blake wrote: > On 09/04/2013 09:37 AM, Peter Krempa wrote: >> In commit 991270db99690 I've used virDomainNetGetActualHostdev() to get >> the actual hostdev from a network when removing the network from the >> list to avoid leaving the hostdev in the list. I didn't notice that this >> function doesn't check if the actual network is allocated and >> dereferences it. This crashes the daemon when cleaning up a domain >> object in early startup phases when the actual network definition isn't >> allocated. When the actual definition isn't present, the hostdev that >> might correspond to it won't be present anyways so it's safe to return >> NULL. >> >> Thanks to Cole Robinson for noticing this problem. >> --- >> src/conf/domain_conf.c | 1 + >> 1 file changed, 1 insertion(+) > > ACK. > Pushed; Thanks. Peter signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] [RFC] docs: Add OpenStack into references
On 05/09/13 14:20, Martin Kletzander wrote: On 09/04/2013 03:56 PM, Osier Yang wrote: On 04/09/13 20:50, Eric Blake wrote: On 09/04/2013 01:26 AM, Martin Kletzander wrote: diff --git a/docs/apps.html.in b/docs/apps.html.in index 46e5dca..9f22df8 100644 --- a/docs/apps.html.in +++ b/docs/apps.html.in @@ -244,6 +244,15 @@ integrates libvirt for VM monitoring, live migration, and life-cycle management. + + http://www.openstack.org";>OpenStack + +OpenStack is a "cloud operating system" usable for both public +and private clouds. Its various parts take care of compute, +storage and networking resources and iterface with the user s/iterface/interface/ +using a dashboard. Compute part uses libvirt to manage VM +life-cycle, monitoring and so on. Not sure if we should mention libvirt is one module of nova's vm management, except using libvirt to manage vms, it also supports to manage the vms with the hypervisor's apis directly, e.g. xenapi, vmwareapi, hyperv. Since it might have potential meaning "nova only uses libvirt". Never mind if it's too picky. I must admin I don't understand completely what you mean, but feel free to propose a different description. Check the nova source code. + ACK with spelling fixed. Spelling fixed and pushed, thanks. Martin -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 0/3] Improve PPC CPU driver
ping ? On 2013年09月03日 14:28, Li Zhang wrote: From: Li Zhang Currently, PPC CPU driver doesn't support to parse guest data. It can't pass CPU parameters to Qemu command line. This patchset is to implement .guestData to support to parse guest CPU configuration and .update to support host-model and host-passthrough. The guest CPU configuration is as the following: POWER7_v2.3 IBM v2 -> v1: * Remove features functions calling for non-x86 platform (Doug Goldstein) * Improve update code. * Merge update code with guestData. Li Zhang (3): Remove CPU features check for non-x86 platform. cpu: Implement guestData and update for PPC cpu: Add cpu test cases for PPC CPU driver. src/cpu/cpu_powerpc.c | 178 - src/qemu/qemu_command.c| 16 +- tests/cputest.c| 9 ++ tests/cputestdata/ppc64-baseline-1-result.xml | 3 + .../ppc64-baseline-incompatible-vendors.xml| 14 ++ .../ppc64-baseline-no-vendor-result.xml| 3 + tests/cputestdata/ppc64-baseline-no-vendor.xml | 7 + tests/cputestdata/ppc64-exact.xml | 3 + tests/cputestdata/ppc64-guest-nofallback.xml | 4 + tests/cputestdata/ppc64-guest.xml | 4 + .../ppc64-host+guest,ppc_models-result.xml | 5 + ...st-nofallback,ppc_models,POWER7_v2.1-result.xml | 5 + tests/cputestdata/ppc64-host.xml | 6 + tests/cputestdata/ppc64-strict.xml | 3 + .../qemuxml2argv-pseries-cpu-exact.args| 7 + .../qemuxml2argv-pseries-cpu-exact.xml | 21 +++ tests/qemuxml2argvtest.c | 1 + 17 files changed, 279 insertions(+), 10 deletions(-) create mode 100644 tests/cputestdata/ppc64-baseline-1-result.xml create mode 100644 tests/cputestdata/ppc64-baseline-incompatible-vendors.xml create mode 100644 tests/cputestdata/ppc64-baseline-no-vendor-result.xml create mode 100644 tests/cputestdata/ppc64-baseline-no-vendor.xml create mode 100644 tests/cputestdata/ppc64-exact.xml create mode 100644 tests/cputestdata/ppc64-guest-nofallback.xml create mode 100644 tests/cputestdata/ppc64-guest.xml create mode 100644 tests/cputestdata/ppc64-host+guest,ppc_models-result.xml create mode 100644 tests/cputestdata/ppc64-host+guest-nofallback,ppc_models,POWER7_v2.1-result.xml create mode 100644 tests/cputestdata/ppc64-host.xml create mode 100644 tests/cputestdata/ppc64-strict.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-cpu-exact.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-cpu-exact.xml -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/2] libxl: Compile regular expression where it is used
On 05.09.2013 00:40, Jim Fehlig wrote:
> Jim Fehlig wrote:
>> The regular expression used to determine guest capabilities
>> was compiled in libxlCapsInitHost() but used in libxlCapsInitGuests().
>> Move compilation to libxlCapsInitGuests() where it is used, and free
>> the compiled regex after use. Ensure not to free the regex if
>> compilation fails.
>>
>> Signed-off-by: Jim Fehlig
>> ---
>> src/libxl/libxl_conf.c | 29 +++--
>> 1 file changed, 15 insertions(+), 14 deletions(-)
>>
>> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
>> index fcb278b..c7be7aa 100644
>> --- a/src/libxl/libxl_conf.c
>> +++ b/src/libxl/libxl_conf.c
>> @@ -61,8 +61,7 @@ struct guest_arch {
>> int ia64_be;
>> };
>>
>> -static const char *xen_cap_re =
>> "(xen|hvm)-[[:digit:]]+\\.[[:digit:]]+-(x86_32|x86_64|ia64|powerpc64)(p|be)?";
>> -static regex_t xen_cap_rec;
>> +#define XEN_CAP_REGEX
>> "(xen|hvm)-[[:digit:]]+\\.[[:digit:]]+-(x86_32|x86_64|ia64|powerpc64)(p|be)?";
>>
>
> Opps, that's not quite right. The version I actually compiled and
> tested doesn't have the trailing ';' on the #define :).
>
Yep, gcc caught that. ACK series (with this change).
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Add '' element to '' network schemas
Commits 905629f4 and 1716e7a6 have added support for specifying
an IPv4 range and a port range to be used by NAT:
https://bugzilla.redhat.com/show_bug.cgi?id=1004364
---
docs/schemas/network.rng | 26 +
docs/schemas/networkcommon.rng | 7 ++
.../nat-network-forward-nat-address.xml| 26 +
.../nat-network-forward-nat-address.xml| 27 ++
tests/networkxml2xmltest.c | 1 +
5 files changed, 87 insertions(+)
create mode 100644 tests/networkxml2xmlin/nat-network-forward-nat-address.xml
create mode 100644 tests/networkxml2xmlout/nat-network-forward-nat-address.xml
diff --git a/docs/schemas/network.rng b/docs/schemas/network.rng
index ab183f1..d7edb09 100644
--- a/docs/schemas/network.rng
+++ b/docs/schemas/network.rng
@@ -160,6 +160,32 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/schemas/networkcommon.rng b/docs/schemas/networkcommon.rng
index e60f1fc..e26b7f3 100644
--- a/docs/schemas/networkcommon.rng
+++ b/docs/schemas/networkcommon.rng
@@ -217,4 +217,11 @@
+
+
+
+ 1
+ 65535
+
+
diff --git a/tests/networkxml2xmlin/nat-network-forward-nat-address.xml
b/tests/networkxml2xmlin/nat-network-forward-nat-address.xml
new file mode 100644
index 000..403d058
--- /dev/null
+++ b/tests/networkxml2xmlin/nat-network-forward-nat-address.xml
@@ -0,0 +1,26 @@
+
+ default
+ 81ff0d90-c91e-6742-64da-4a736edb9a9b
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/tests/networkxml2xmlout/nat-network-forward-nat-address.xml
b/tests/networkxml2xmlout/nat-network-forward-nat-address.xml
new file mode 100644
index 000..faeba24
--- /dev/null
+++ b/tests/networkxml2xmlout/nat-network-forward-nat-address.xml
@@ -0,0 +1,27 @@
+
+ default
+ 81ff0d90-c91e-6742-64da-4a736edb9a9b
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/tests/networkxml2xmltest.c b/tests/networkxml2xmltest.c
index 675a862..d04039d 100644
--- a/tests/networkxml2xmltest.c
+++ b/tests/networkxml2xmltest.c
@@ -108,6 +108,7 @@ mymain(void)
DO_TEST("nat-network-dns-srv-record-minimal");
DO_TEST("nat-network-dns-hosts");
DO_TEST("nat-network-dns-forward-plain");
+DO_TEST("nat-network-forward-nat-address");
DO_TEST("8021Qbh-net");
DO_TEST("direct-net");
DO_TEST("host-bridge-net");
--
1.8.1.5
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/3] Keep original file label
On 28.08.2013 12:27, Michal Privoznik wrote: > 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 > Ping? -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] [RFC] docs: Add OpenStack into references
On Thu, Sep 05, 2013 at 08:20:41AM +0200, Martin Kletzander wrote: > On 09/04/2013 03:56 PM, Osier Yang wrote: > > On 04/09/13 20:50, Eric Blake wrote: > >> On 09/04/2013 01:26 AM, Martin Kletzander wrote: > >>> diff --git a/docs/apps.html.in b/docs/apps.html.in > >>> index 46e5dca..9f22df8 100644 > >>> --- a/docs/apps.html.in > >>> +++ b/docs/apps.html.in > >>> @@ -244,6 +244,15 @@ > >>> integrates libvirt for VM monitoring, live migration, and > >>> life-cycle > >>> management. > >>> > >>> + > >>> + http://www.openstack.org";>OpenStack > >>> + > >>> +OpenStack is a "cloud operating system" usable for both public > >>> +and private clouds. Its various parts take care of compute, > >>> +storage and networking resources and iterface with the user > >> s/iterface/interface/ > >> > >>> +using a dashboard. Compute part uses libvirt to manage VM > >>> +life-cycle, monitoring and so on. > > > > Not sure if we should mention libvirt is one module of nova's vm > > management, > > except using libvirt to manage vms, it also supports to manage the vms with > > the hypervisor's apis directly, e.g. xenapi, vmwareapi, hyperv. Since it > > might > > have potential meaning "nova only uses libvirt". > > > > Never mind if it's too picky. > > > > I must admin I don't understand completely what you mean, but feel free > to propose a different description. I think it is ok, but if you wanted to, you could change it to say this OpenStack is a "cloud operating system" usable for both public and private clouds. Its various parts take care of compute, storage and networking resources and iterface with the user using a dashboard. The Nova Compute services uses libvirt to manage KVM, QEMU, LXC and Xen guests. Daniel -- |: 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] LXC: Don't mount securityfs when user namespace enabled
On Wed, Sep 04, 2013 at 10:23:17AM +0800, Gao feng wrote: > Right now, securityfs is disallowed to be mounted in > un init user namespace, we should avoid to mount securityfs > in the container which enables user namespace. > > Signed-off-by: Gao feng > --- > src/lxc/lxc_container.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) ACK, pushing this shortly. Daniel -- |: 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] domain_conf: Delete the USB controller check from the USB Device checklist on virDomainDeviceIsUSB
On 05.09.2013 04:40, Liuji (Jeremy) wrote: > When using "virsh attach-device" to attach a device, the > virDomainDefCompatibleDevice function will check the compatibility. > If the device is a USB device, but the VM don't have any USB controller, the > execution of "virsh attach-device" will fails. > It considers the USB controller as a USB device on virDomainDeviceIsUSB, so > we can't use "virsh attach-device" to attach a > USB controller for a VM which don't have any other USB controller. > > >>From ec3257407a9c4aadcd4554dcaad00d40387cf488 Mon Sep 17 00:00:00 2001 > From: Liu Ji > Date: Thu, 5 Sep 2013 09:56:42 +0800 > Subject: [PATCH] domain_conf: Delete the USB controller check from the USB > Device checklist on virDomainDeviceIsUSB > > Delete the USB controller check from the USB Device checklist on > virDomainDeviceIsUSB, otherwise we > can't use "virsh attach-device" to attach a USB controller for a VM which > don't have any other USB controller. > > Signed-off-by: Liu Ji > --- > src/conf/domain_conf.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c > index e3aec69..ffb3254 100644 > --- a/src/conf/domain_conf.c > +++ b/src/conf/domain_conf.c > @@ -16899,8 +16899,6 @@ virDomainDeviceIsUSB(virDomainDeviceDefPtr dev) > int t = dev->type; > if ((t == VIR_DOMAIN_DEVICE_DISK && > dev->data.disk->bus == VIR_DOMAIN_DISK_BUS_USB) || > -(t == VIR_DOMAIN_DEVICE_CONTROLLER && > - dev->data.controller->type == VIR_DOMAIN_CONTROLLER_TYPE_USB) || > (t == VIR_DOMAIN_DEVICE_INPUT && > dev->data.input->type == VIR_DOMAIN_INPUT_BUS_USB) || > (t == VIR_DOMAIN_DEVICE_HOSTDEV && > Although this won't help you to attach the usb controller (the only controller that can be hotplugged currently is scsi), the USB controller certainly isn't an USB device but PCI device instead. Having said that, I'm rewording the commit message a bit. ACKed and pushed. Congratulations on your first libvirt commit! Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] systemd: add debug message when virDBusCallMethod failed
On Wed, Sep 04, 2013 at 10:58:23AM +0800, Gao feng wrote:
> Generate debug message when systemd doesn't support
> interface org.freedesktop.machine1.Manager.
>
> Signed-off-by: Gao feng
> ---
> src/util/virsystemd.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/util/virsystemd.c b/src/util/virsystemd.c
> index 3e69ef6..c631557 100644
> --- a/src/util/virsystemd.c
> +++ b/src/util/virsystemd.c
> @@ -233,6 +233,7 @@ int virSystemdCreateMachine(const char *name,
> if (err->code == VIR_ERR_DBUS_SERVICE &&
> STREQ(err->str2, "org.freedesktop.DBus.Error.ServiceUnknown")) {
> virResetLastError();
> +VIR_DEBUG("systemd doesn't support interface
> org.freedesktop.machine1.Manager");
Is this really needed ? The virRaiseError call will have already reported
this scenario surely ?
Daniel
--
|: 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 :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 1/3] qemu: Remove CPU features functions calling for non-x86 platform.
On Tue, Sep 03, 2013 at 02:28:23PM +0800, Li Zhang wrote:
> From: Li Zhang
>
> CPU features are not supported on non-x86 and hasFeatures will be NULL.
>
> This patch is to remove CPU features functions calling to avoid errors.
>
> Signed-off-by: Li Zhang
> ---
> src/qemu/qemu_command.c | 16 ++--
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
> index f8fccea..3b6ba7a 100644
> --- a/src/qemu/qemu_command.c
> +++ b/src/qemu/qemu_command.c
> @@ -6349,7 +6349,6 @@ qemuBuildCpuArgStr(const virQEMUDriverPtr driver,
> (def->cpu->mode != VIR_CPU_MODE_CUSTOM || def->cpu->model)) {
> virCPUCompareResult cmp;
> const char *preferred;
> -int hasSVM;
>
> if (!host ||
> !host->model ||
> @@ -6389,10 +6388,13 @@ qemuBuildCpuArgStr(const virQEMUDriverPtr driver,
> /* Only 'svm' requires --enable-nesting. The nested
> * 'vmx' patches now simply hook off the CPU features
> */
> -hasSVM = cpuHasFeature(data, "svm");
> -if (hasSVM < 0)
> -goto cleanup;
> -*hasHwVirt = hasSVM > 0 ? true : false;
> +if (def->os.arch == VIR_ARCH_X86_64 ||
> +def->os.arch == VIR_ARCH_I686) {
> +int hasSVM = cpuHasFeature(data, "svm");
> +if (hasSVM < 0)
> +goto cleanup;
> +*hasHwVirt = hasSVM > 0 ? true : false;
> +}
>
> if (cpu->mode == VIR_CPU_MODE_HOST_PASSTHROUGH) {
> const char *mode = virCPUModeTypeToString(cpu->mode);
This bit looks good.
> @@ -10575,7 +10577,9 @@ qemuParseCommandLineCPU(virDomainDefPtr dom,
> model = NULL;
> }
>
> -if (virCPUDefAddFeature(cpu, feature, policy) < 0)
> +if ((dom->os.arch == VIR_ARCH_X86_64 ||
> +dom->os.arch == VIR_ARCH_I686) &&
> +virCPUDefAddFeature(cpu, feature, policy) < 0)
> goto cleanup;
> }
> } else if (STRPREFIX(tokens[i], "hv_")) {
For this, I think we should virReportError() if we find a CPU flag on
the command line for non-x86 arches, instead of silently ignoring it.
I think I'd also like to split this patch in two. I'll apply the first
chunk of it now.
Daniel
--
|: 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 :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 2/3] cpu: Implement guestData and update for PPC
On Tue, Sep 03, 2013 at 02:28:24PM +0800, Li Zhang wrote: > From: Li Zhang > > On Power platform, Power7+ can support Power7 guest. > It needs to define XML configuration to specify guest's CPU model. > > For exmaple: > > POWER7_v2.1 > IBM > > > Signed-off-by: Li Zhang > --- > src/cpu/cpu_powerpc.c | 178 > -- > 1 file changed, 174 insertions(+), 4 deletions(-) ACK Daniel -- |: 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 3/3] cpu: Add cpu test cases for PPC CPU driver.
On Tue, Sep 03, 2013 at 02:28:25PM +0800, Li Zhang wrote: > From: Li Zhang > > This patch is to add cpu test casses for PPC CPU driver. > > Signed-off-by: Li Zhang > --- > tests/cputest.c | 9 + > tests/cputestdata/ppc64-baseline-1-result.xml | 3 +++ > .../ppc64-baseline-incompatible-vendors.xml | 14 ++ > .../cputestdata/ppc64-baseline-no-vendor-result.xml | 3 +++ > tests/cputestdata/ppc64-baseline-no-vendor.xml | 7 +++ > tests/cputestdata/ppc64-exact.xml | 3 +++ > tests/cputestdata/ppc64-guest-nofallback.xml| 4 > tests/cputestdata/ppc64-guest.xml | 4 > .../ppc64-host+guest,ppc_models-result.xml | 5 + > ...est-nofallback,ppc_models,POWER7_v2.1-result.xml | 5 + > tests/cputestdata/ppc64-host.xml| 6 ++ > tests/cputestdata/ppc64-strict.xml | 3 +++ > .../qemuxml2argv-pseries-cpu-exact.args | 7 +++ > .../qemuxml2argv-pseries-cpu-exact.xml | 21 > + > tests/qemuxml2argvtest.c| 1 + > 15 files changed, 95 insertions(+) > create mode 100644 tests/cputestdata/ppc64-baseline-1-result.xml > create mode 100644 tests/cputestdata/ppc64-baseline-incompatible-vendors.xml > create mode 100644 tests/cputestdata/ppc64-baseline-no-vendor-result.xml > create mode 100644 tests/cputestdata/ppc64-baseline-no-vendor.xml > create mode 100644 tests/cputestdata/ppc64-exact.xml > create mode 100644 tests/cputestdata/ppc64-guest-nofallback.xml > create mode 100644 tests/cputestdata/ppc64-guest.xml > create mode 100644 tests/cputestdata/ppc64-host+guest,ppc_models-result.xml > create mode 100644 > tests/cputestdata/ppc64-host+guest-nofallback,ppc_models,POWER7_v2.1-result.xml > create mode 100644 tests/cputestdata/ppc64-host.xml > create mode 100644 tests/cputestdata/ppc64-strict.xml > create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-cpu-exact.args > create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-cpu-exact.xml ACK Daniel -- |: 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH V3] Use loop-control to allocate loop device.
On Tue, Sep 03, 2013 at 11:45:51AM -0700, Ian Main wrote:
> This patch changes virFileLoopDeviceOpen() to use the new loop-control
> device to allocate a new loop device. If this behavior is unsupported
> we fall back to the previous method of searching /dev for a free device.
>
> With this patch you can start as many image based LXC domains as you
> like (well almost).
>
> Fixes bug https://bugzilla.redhat.com/show_bug.cgi?id=995543
>
> V2:
> - Modified to use a dedicated error return for loop-control allocation
> function.
> - Only do fallback if /dev/loop-control does not exist, otherwise return
> error.
>
> V3:
> - Remove warning about falling back to search technique.
>
> Signed-off-by: Ian Main
> ---
> configure.ac | 12 ++
> src/util/virfile.c | 70
> +-
> 2 files changed, 81 insertions(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index ac8cfa1..10cd872 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -913,6 +913,18 @@ if test "$with_lxc" = "yes" || test "$with_lxc" =
> "check"; then
> AC_MSG_ERROR([Required kernel features for LXC were not found])
> fi
> ])
> +AC_LINK_IFELSE([AC_LANG_PROGRAM(
> +[[
> +#include
> +#include
> +#include
> +]], [[
> +unshare(!(LOOP_CTL_GET_FREE));
> +]])], [
> + AC_DEFINE([HAVE_DECL_LOOP_CTL_GET_FREE], [1],
> + [Define to 1 if you have the declaration of `LOOP_CTL_GET_FREE',
> + and to 0 if you don't.])
> +])
> fi
> if test "$with_lxc" = "yes" ; then
> AC_DEFINE_UNQUOTED([WITH_LXC], 1, [whether LXC driver is enabled])
> diff --git a/src/util/virfile.c b/src/util/virfile.c
> index 2b07ac9..9d42380 100644
> --- a/src/util/virfile.c
> +++ b/src/util/virfile.c
> @@ -528,7 +528,56 @@ int virFileUpdatePerm(const char *path,
>
>
> #if defined(__linux__) && HAVE_DECL_LO_FLAGS_AUTOCLEAR
> -static int virFileLoopDeviceOpen(char **dev_name)
> +
> +#if HAVE_DECL_LOOP_CTL_GET_FREE
> +
> +/* virFileLoopDeviceOpenLoopCtl() returns -1 when a real failure has occured
> + * while in the process of allocating or opening the loop device. On success
> + * we return 0 and modify the fd to the appropriate file descriptor.
> + * If /dev/loop-control does not exist, we return 0 and do not set fd. */
> +
> +static int virFileLoopDeviceOpenLoopCtl(char **dev_name, int *fd)
> +{
> +int devnr;
> +int ctl_fd;
> +char *looppath = NULL;
> +
> +VIR_DEBUG("Opening loop-control device");
> +if ((ctl_fd = open("/dev/loop-control", O_RDWR)) < 0) {
> +virReportSystemError(errno, "%s",
> + _("Unable to open /dev/loop-control"));
> +if (errno == ENOENT) {
> +return 0;
> +}
The virReportSystemError needs to come after the errno check
so we only report the error in the fatal code path.
> +return -1;
> +}
> +
> +if ((devnr = ioctl(ctl_fd, LOOP_CTL_GET_FREE)) < 0) {
> +virReportSystemError(errno, "%s",
> + _("Unable to get free loop device via ioctl"));
> +close(ctl_fd);
> +return -1;
> +}
> +close(ctl_fd);
> +
> +VIR_DEBUG("Found free loop device number %i", devnr);
> +
> +if (virAsprintf(&looppath, "/dev/loop%i", devnr) < 0)
> +return -1;
> +
> +if ((*fd = open(looppath, O_RDWR)) < 0) {
> +virReportSystemError(errno,
> +_("Unable to open %s"), looppath);
> +VIR_FREE(looppath);
> +return -1;
> +}
> +
> +*dev_name = looppath;
> +return 0;
> +}
> +#endif /* HAVE_DECL_LOOP_CTL_GET_FREE */
> +
> +static int virFileLoopDeviceOpenSearch(char **dev_name)
> {
> int fd = -1;
> DIR *dh = NULL;
> @@ -601,6 +650,25 @@ cleanup:
> return fd;
> }
>
> +static int virFileLoopDeviceOpen(char **dev_name)
> +{
> +int loop_fd = -1;
> +
> +#ifdef HAVE_DECL_LOOP_CTL_GET_FREE
s/ifdef/if/ since HAVE_* is either 0 or 1, never undefined
> +if (virFileLoopDeviceOpenLoopCtl(dev_name, &loop_fd) < 0)
> +return -1;
> +
> +VIR_DEBUG("Return from loop-control got fd %d\n", loop_fd);
> +
> +if (loop_fd >= 0)
> +return loop_fd;
> +#endif /* HAVE_DECL_LOOP_CTL_GET_FREE */
> +
> +/* Without the loop control device we just use the old technique. */
> +loop_fd = virFileLoopDeviceOpenSearch(dev_name);
> +
> +return loop_fd;
> +}
>
> int virFileLoopDeviceAssociate(const char *file,
> char **dev)
I made the two changes and pushed this.
BTW, run 'make syntax-check' for patches on libvirt - it would have
told you about the second error.
Regards,
Daniel
--
|: 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-
Re: [libvirt] [PATCH] Add '' element to '' network schemas
On 05.09.2013 11:24, Ján Tomko wrote: > Commits 905629f4 and 1716e7a6 have added support for specifying > an IPv4 range and a port range to be used by NAT: > > > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1004364 > --- > docs/schemas/network.rng | 26 + > docs/schemas/networkcommon.rng | 7 ++ > .../nat-network-forward-nat-address.xml| 26 + > .../nat-network-forward-nat-address.xml| 27 > ++ > tests/networkxml2xmltest.c | 1 + > 5 files changed, 87 insertions(+) > create mode 100644 tests/networkxml2xmlin/nat-network-forward-nat-address.xml > create mode 100644 > tests/networkxml2xmlout/nat-network-forward-nat-address.xml ACK Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v2 0/3] expose baselabel for each sec model/virt type
Now each security model can define its own base label, that describes the default security context used by libvirt to run an hypervisor process. This information is exposed to users trough the host capabilities XML. Giuseppe Scrivano (3): security: add new internal function "virSecurityManagerGetBaseLabel" capabilities: add baselabel per sec driver/virt type to secmodel capabilities: document and test "" docs/schemas/capability.rng | 8 src/conf/capabilities.c | 60 +++- src/conf/capabilities.h | 14 +++ src/libvirt_private.syms | 2 + src/qemu/qemu_conf.c | 11 +++-- src/security/security_apparmor.c | 7 src/security/security_dac.c | 26 +++- src/security/security_driver.h | 3 ++ src/security/security_manager.c | 15 +++ src/security/security_manager.h | 2 + src/security/security_nop.c | 9 + src/security/security_selinux.c | 9 + src/security/security_stack.c| 8 tests/capabilityschemadata/caps-qemu-kvm.xml | 2 + tests/capabilityschemadata/caps-test3.xml| 2 + 15 files changed, 172 insertions(+), 6 deletions(-) -- 1.8.3.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v2 1/3] security: add new internal function "virSecurityManagerGetBaseLabel"
virSecurityManagerGetBaseLabel queries the default settings used by
a security model.
Signed-off-by: Giuseppe Scrivano
---
src/libvirt_private.syms | 1 +
src/security/security_apparmor.c | 7 +++
src/security/security_dac.c | 26 +-
src/security/security_driver.h | 3 +++
src/security/security_manager.c | 15 +++
src/security/security_manager.h | 2 ++
src/security/security_nop.c | 9 +
src/security/security_selinux.c | 9 +
src/security/security_stack.c| 8
9 files changed, 79 insertions(+), 1 deletion(-)
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 35f0f1b..aea7e94 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -1033,6 +1033,7 @@ virSecurityDriverLookup;
# security/security_manager.h
virSecurityManagerClearSocketLabel;
virSecurityManagerGenLabel;
+virSecurityManagerGetBaseLabel;
virSecurityManagerGetDOI;
virSecurityManagerGetModel;
virSecurityManagerGetMountOptions;
diff --git a/src/security/security_apparmor.c b/src/security/security_apparmor.c
index adc9918..6f95ce5 100644
--- a/src/security/security_apparmor.c
+++ b/src/security/security_apparmor.c
@@ -931,6 +931,11 @@ AppArmorGetMountOptions(virSecurityManagerPtr mgr
ATTRIBUTE_UNUSED,
return opts;
}
+static const char *
+AppArmorGetBaseLabel(virSecurityManagerPtr mgr ATTRIBUTE_UNUSED)
+{
+return "";
+}
virSecurityDriver virAppArmorSecurityDriver = {
.privateDataLen = 0,
@@ -972,4 +977,6 @@ virSecurityDriver virAppArmorSecurityDriver = {
.domainSetSecurityTapFDLabel= AppArmorSetFDLabel,
.domainGetSecurityMountOptions = AppArmorGetMountOptions,
+
+.getBaseLabel = AppArmoryGetBaseLabel,
};
diff --git a/src/security/security_dac.c b/src/security/security_dac.c
index 6876bd5..d5e93fa 100644
--- a/src/security/security_dac.c
+++ b/src/security/security_dac.c
@@ -47,6 +47,7 @@ struct _virSecurityDACData {
gid_t *groups;
int ngroups;
bool dynamicOwnership;
+char *baselabel;
};
void
@@ -217,6 +218,7 @@ virSecurityDACClose(virSecurityManagerPtr mgr)
{
virSecurityDACDataPtr priv = virSecurityManagerGetPrivateData(mgr);
VIR_FREE(priv->groups);
+VIR_FREE(priv->baselabel);
return 0;
}
@@ -1114,8 +1116,9 @@ virSecurityDACGetProcessLabel(virSecurityManagerPtr mgr
ATTRIBUTE_UNUSED,
virSecurityLabelDefPtr secdef =
virDomainDefGetSecurityLabelDef(def, SECURITY_DAC_NAME);
-if (!secdef || !seclabel)
+if (!secdef || !seclabel) {
return -1;
+}
if (secdef->label)
ignore_value(virStrcpy(seclabel->label, secdef->label,
@@ -1170,6 +1173,25 @@ virSecurityDACGetMountOptions(virSecurityManagerPtr mgr
ATTRIBUTE_UNUSED,
return NULL;
}
+static const char *
+virSecurityDACGetBaseLabel(virSecurityManagerPtr mgr ATTRIBUTE_UNUSED)
+{
+uid_t user;
+gid_t group;
+virSecurityDACDataPtr priv = virSecurityManagerGetPrivateData(mgr);
+if (priv->baselabel)
+return priv->baselabel;
+
+if (virGetUserID(QEMU_USER, &user) < 0 ||
+virGetGroupID(QEMU_GROUP, &group) < 0 ||
+virAsprintf(&priv->baselabel, "%u:%u",
+(unsigned int) priv->user,
+(unsigned int) priv->group) < 0)
+return NULL;
+
+return priv->baselabel;
+}
+
virSecurityDriver virSecurityDriverDAC = {
.privateDataLen = sizeof(virSecurityDACData),
.name = SECURITY_DAC_NAME,
@@ -1212,4 +1234,6 @@ virSecurityDriver virSecurityDriverDAC = {
.domainSetSecurityTapFDLabel= virSecurityDACSetTapFDLabel,
.domainGetSecurityMountOptions = virSecurityDACGetMountOptions,
+
+.getBaseLabel = virSecurityDACGetBaseLabel,
};
diff --git a/src/security/security_driver.h b/src/security/security_driver.h
index 8735558..64bd307 100644
--- a/src/security/security_driver.h
+++ b/src/security/security_driver.h
@@ -46,6 +46,7 @@ typedef int (*virSecurityDriverClose) (virSecurityManagerPtr
mgr);
typedef const char *(*virSecurityDriverGetModel) (virSecurityManagerPtr mgr);
typedef const char *(*virSecurityDriverGetDOI) (virSecurityManagerPtr mgr);
+typedef const char *(*virSecurityDriverGetBaseLabel) (virSecurityManagerPtr
mgr);
typedef int (*virSecurityDriverPreFork) (virSecurityManagerPtr mgr);
@@ -154,6 +155,8 @@ struct _virSecurityDriver {
virSecurityDomainGetMountOptions domainGetSecurityMountOptions;
virSecurityDomainSetHugepages domainSetSecurityHugepages;
+
+virSecurityDriverGetBaseLabel getBaseLabel;
};
virSecurityDriverPtr virSecurityDriverLookup(const char *name,
diff --git a/src/security/security_manager.c b/src/security/security_manager.c
index 92fb504..8535c8e 100644
--- a/src/security/security_manager.c
+++ b/src/security/security_manager.c
@@ -273,6 +273,21 @@ vir
[libvirt] [PATCH v2 3/3] capabilities: document and test ""
Signed-off-by: Giuseppe Scrivano --- docs/schemas/capability.rng | 8 tests/capabilityschemadata/caps-qemu-kvm.xml | 2 ++ tests/capabilityschemadata/caps-test3.xml| 2 ++ 3 files changed, 12 insertions(+) diff --git a/docs/schemas/capability.rng b/docs/schemas/capability.rng index 65c7c72..aee03d7 100644 --- a/docs/schemas/capability.rng +++ b/docs/schemas/capability.rng @@ -60,6 +60,14 @@ + + + + + + + + diff --git a/tests/capabilityschemadata/caps-qemu-kvm.xml b/tests/capabilityschemadata/caps-qemu-kvm.xml index 1fbc22b..066ec71 100644 --- a/tests/capabilityschemadata/caps-qemu-kvm.xml +++ b/tests/capabilityschemadata/caps-qemu-kvm.xml @@ -25,6 +25,8 @@ selinux 0 + system_u:system_r:svirt_t:s0 + system_u:system_r:svirt_t:s0 diff --git a/tests/capabilityschemadata/caps-test3.xml b/tests/capabilityschemadata/caps-test3.xml index e6c56c5..d359f25 100644 --- a/tests/capabilityschemadata/caps-test3.xml +++ b/tests/capabilityschemadata/caps-test3.xml @@ -82,6 +82,8 @@ dac 0 + 0:0 + 0:0 -- 1.8.3.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v2 2/3] capabilities: add baselabel per sec driver/virt type to secmodel
Expand the "secmodel" XML fragment of "host" with a sequence of
baselabel's which describe the default security context used by
libvirt with a specific security model and virtualization type:
selinux
0
system_u:system_r:svirt_t:s0
system_u:system_r:svirt_t:s0
dac
0
0:0
0:0
"baselabel" is driver-specific information, e.g. in the DAC security
model, it indicates USER_ID:GROUP_ID.
Signed-off-by: Giuseppe Scrivano
---
src/conf/capabilities.c | 60 ++--
src/conf/capabilities.h | 14 +++
src/libvirt_private.syms | 1 +
src/qemu/qemu_conf.c | 11 ++---
4 files changed, 81 insertions(+), 5 deletions(-)
diff --git a/src/conf/capabilities.c b/src/conf/capabilities.c
index 1acc936..b0e2ff9 100644
--- a/src/conf/capabilities.c
+++ b/src/conf/capabilities.c
@@ -184,6 +184,20 @@ virCapabilitiesFreeNUMAInfo(virCapsPtr caps)
}
static void
+virCapabilitiesFreeSecModel(virCapsHostSecModelPtr secmodel)
+{
+size_t i;
+for (i = 0; i < secmodel->nlabels; i++) {
+VIR_FREE(secmodel->labels[i].type);
+VIR_FREE(secmodel->labels[i].label);
+}
+
+VIR_FREE(secmodel->labels);
+VIR_FREE(secmodel->model);
+VIR_FREE(secmodel->doi);
+}
+
+static void
virCapabilitiesDispose(void *object)
{
virCapsPtr caps = object;
@@ -204,8 +218,7 @@ virCapabilitiesDispose(void *object)
VIR_FREE(caps->host.migrateTrans);
for (i = 0; i < caps->host.nsecModels; i++) {
-VIR_FREE(caps->host.secModels[i].model);
-VIR_FREE(caps->host.secModels[i].doi);
+virCapabilitiesFreeSecModel(&caps->host.secModels[i]);
}
VIR_FREE(caps->host.secModels);
@@ -507,6 +520,44 @@ virCapabilitiesAddGuestFeature(virCapsGuestPtr guest,
}
/**
+ * virCapabilitiesHostSecModelAddBaseLabel
+ * @secmodel: Security model to add a base label for
+ * @type: virtualization type
+ * @label: base label
+ *
+ * Returns non-zero on error.
+ */
+extern int
+virCapabilitiesHostSecModelAddBaseLabel(virCapsHostSecModelPtr secmodel,
+const char *type,
+const char *label)
+{
+char *t = NULL, *l = NULL;
+
+if (type == NULL || label == NULL)
+return -1;
+
+if (VIR_STRDUP(t, type) < 0)
+goto no_memory;
+
+if (VIR_STRDUP(l, label) < 0)
+goto no_memory;
+
+if (VIR_EXPAND_N(secmodel->labels, secmodel->nlabels, 1) < 0)
+goto no_memory;
+
+secmodel->labels[secmodel->nlabels - 1].type = t;
+secmodel->labels[secmodel->nlabels - 1].label = l;
+
+return 0;
+
+no_memory:
+VIR_FREE(l);
+VIR_FREE(t);
+return -1;
+}
+
+/**
* virCapabilitiesSupportsGuestArch:
* @caps: capabilities to query
* @arch: Architecture to search for
@@ -826,6 +877,11 @@ virCapabilitiesFormatXML(virCapsPtr caps)
caps->host.secModels[i].model);
virBufferAsprintf(&xml, " %s\n",
caps->host.secModels[i].doi);
+for (j = 0; j < caps->host.secModels[i].nlabels; j++) {
+virBufferAsprintf(&xml, " %s\n",
+ caps->host.secModels[i].labels[j].type,
+ caps->host.secModels[i].labels[j].label);
+}
virBufferAddLit(&xml, "\n");
}
diff --git a/src/conf/capabilities.h b/src/conf/capabilities.h
index 88ec454..5bc7bb5 100644
--- a/src/conf/capabilities.h
+++ b/src/conf/capabilities.h
@@ -104,11 +104,20 @@ struct _virCapsHostNUMACell {
virCapsHostNUMACellCPUPtr cpus;
};
+typedef struct _virCapsHostSecModelLabel virCapsHostSecModelLabel;
+typedef virCapsHostSecModelLabel *virCapsHostSecModelLabelPtr;
+struct _virCapsHostSecModelLabel {
+char *type;
+char *label;
+};
+
typedef struct _virCapsHostSecModel virCapsHostSecModel;
typedef virCapsHostSecModel *virCapsHostSecModelPtr;
struct _virCapsHostSecModel {
char *model;
char *doi;
+size_t nlabels;
+virCapsHostSecModelLabelPtr labels;
};
typedef struct _virCapsHost virCapsHost;
@@ -225,6 +234,11 @@ virCapabilitiesAddGuestFeature(virCapsGuestPtr guest,
int toggle);
extern int
+virCapabilitiesHostSecModelAddBaseLabel(virCapsHostSecModelPtr secmodel,
+const char *type,
+const char *label);
+
+extern int
virCapabilitiesSupportsGuestArch(virCapsPtr caps,
virArch arch);
extern int
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index aea7e94..cdf9e58 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -58,6 +58,7 @@ virCapabilitiesFormatXML;
virCapabilitiesFreeMachines;
virCapabilitiesFreeNUMAInfo;
virCapabilitiesGetCpusForNodemask;
+virCapabilitiesHostSecModelAddBaseLabel;
virCapabilitiesNew;
virCapabilitiesSetHostCPU;
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf
[libvirt] [ libvirt ] [ PATCH ] Added support for ARMv7 Big Endian
Hi All,
Could you please review below patch, I have successfully tested patch on
ARM Versatile Express V2P Board.
From: Yogesh Tillu
Date: Thu, 5 Sep 2013 17:07:55 +0530
Subject: [PATCH] [ PATCH ] Added Support for ARMv7 Big Endian
Signed-off-by: Yogesh Tillu
---
src/util/virarch.c | 1 +
src/util/virarch.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/src/util/virarch.c b/src/util/virarch.c
index 81558e5..b4e06da 100644
--- a/src/util/virarch.c
+++ b/src/util/virarch.c
@@ -37,6 +37,7 @@ static const struct virArchData {
{ "alpha",64, VIR_ARCH_BIG_ENDIAN },
{ "armv6l", 32, VIR_ARCH_LITTLE_ENDIAN },
{ "armv7l", 32, VIR_ARCH_LITTLE_ENDIAN },
+{ "armv7b", 32, VIR_ARCH_BIG_ENDIAN },
{ "cris", 32, VIR_ARCH_LITTLE_ENDIAN },
{ "i686", 32, VIR_ARCH_LITTLE_ENDIAN },
diff --git a/src/util/virarch.h b/src/util/virarch.h
index 0d8ae25..dd25679 100644
--- a/src/util/virarch.h
+++ b/src/util/virarch.h
@@ -29,6 +29,7 @@ typedef enum {
VIR_ARCH_ALPHA,/* Alpha 64 BE
http://en.wikipedia.org/wiki/DEC_Alpha */
VIR_ARCH_ARMV6L, /* ARMv6 32 LE
http://en.wikipedia.org/wiki/ARM_architecture */
VIR_ARCH_ARMV7L, /* ARMv7 32 LE
http://en.wikipedia.org/wiki/ARM_architecture */
+VIR_ARCH_ARMV7B, /* ARMv7 32 BE
http://en.wikipedia.org/wiki/ARM_architecture */
VIR_ARCH_CRIS, /* ETRAX 32 LE
http://en.wikipedia.org/wiki/ETRAX_CRIS */
VIR_ARCH_I686, /* x86 32 LE
http://en.wikipedia.org/wiki/X86 */
--
1.8.1.2
Test Performed:
# virsh nodeinfo
CPU model: armv7b
CPU(s): 1
CPU frequency: 48 MHz
CPU socket(s): 1
Core(s) per socket: 5
Thread(s) per core: 1
NUMA cell(s):1
Memory size: 1029784 KiB
Regards,
Yogesh Tillu
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Change 'shortforward' to bool.
---
Pushed as trivial.
src/conf/network_conf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/conf/network_conf.c b/src/conf/network_conf.c
index d54f2aa..654919e 100644
--- a/src/conf/network_conf.c
+++ b/src/conf/network_conf.c
@@ -2552,7 +2552,7 @@ virNetworkDefFormatInternal(virBufferPtr buf,
unsigned char *uuid;
char uuidstr[VIR_UUID_STRING_BUFLEN];
size_t i;
-int shortforward;
+bool shortforward;
virBufferAddLit(buf, "connections > 0)) {
--
1.8.1.5
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Fix a typo in network XML docs
--- Pushed as trivial. docs/formatnetwork.html.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/formatnetwork.html.in b/docs/formatnetwork.html.in index e1482db..36c381a 100644 --- a/docs/formatnetwork.html.in +++ b/docs/formatnetwork.html.in @@ -155,7 +155,7 @@ ... -An singe IPv4 address can be set by setting +A single IPv4 address can be set by setting start and end attributes to the same value. -- 1.8.1.5 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Add '' element to '' network schemas
On 09/05/2013 01:43 PM, Michal Privoznik wrote: > On 05.09.2013 11:24, Ján Tomko wrote: >> Commits 905629f4 and 1716e7a6 have added support for specifying >> an IPv4 range and a port range to be used by NAT: >> >> >> >> >> >> >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1004364 >> --- >> docs/schemas/network.rng | 26 >> + >> docs/schemas/networkcommon.rng | 7 ++ >> .../nat-network-forward-nat-address.xml| 26 >> + >> .../nat-network-forward-nat-address.xml| 27 >> ++ >> tests/networkxml2xmltest.c | 1 + >> 5 files changed, 87 insertions(+) >> create mode 100644 >> tests/networkxml2xmlin/nat-network-forward-nat-address.xml >> create mode 100644 >> tests/networkxml2xmlout/nat-network-forward-nat-address.xml > > ACK > > Michal > Thanks, pushed now. Jan -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv5 1/5] domifaddr: Implement the public APIs
On Wed, Sep 4, 2013 at 8:05 PM, Osier Yang wrote: > On 04/09/13 03:13, Eric Blake wrote: > > On 09/03/2013 01:07 PM, Eric Blake wrote: > > On 09/01/2013 07:43 AM, Nehal J Wani wrote: > > Define a new API virDomainInterfaceAddresses, which returns > the address information of a running domain's interfaces(s). > If no interface name is specified, it returns the information > of all interfaces, otherwise it only returns the information > of the specificed interface. The address information includes > the MAC and IP addresses. > > Define helper function virDomainInterfaceFree, which allows > the upper layer application to free the domain interface object > conveniently. > > The API is going to provide multiple methods by flags, e.g. > > * Query guest agent > * Parse lease file of dnsmasq > * DHCP snooping > > But at this stage, it will only work with guest agent, and flags > won't be supported. > > That worries me a bit. Ultimately, we want our interfaces to behave as > sane as possible when flags==0; rather than making the behavior be that > 'flags==0' implies 'only guest agent probe', I'd rather introduce a flag > right away up front that says 'include guest agent probe in the set of > attempted methods', and then document that 'flags==0 is shorthand for > letting the hypervisor choose the best method(s) out of supported > possibilities)'. In other words, I want to make sure that this API will > be similar to virDomainShutdownFlags, where a flags of 0 lets the > hypervisor choose between methods, a single explicit flag forces the > hypervisor to use that method alone, and more than one flag can be OR'd > together to let the hypervisor choose among that subset of flags. > > Hmm. I'm replying to myself - is that a good sign? > > If the guest agent returns names that are provided by the guest, and > don't necessarily correspond to the domain XML, then maybe it's best to > NEVER return guest results by default, but to make the user always > explicitly request agent interaction. > > > Hm, yes, the MAC address returned by guest agent might not > match what the domain config specifies. It reminds me something, > both the leases file and snooping will returns the interface name > like "vnetN", which is different with what guest agent returns (like > ethN or emN). And since the MAC address from guest agent might > be different with what domain config specifies, we have no way to > convert it into the names in domain config. That says we will have > different name styles for guest agent and the other two methods, > which will need quite documentations to explain. > > That is, even if 'flags==0' is > used to select between parsing the lease file vs. DHCP snoop results > (both of which tie perfectly to guest XML naming), the agent approach > can seriously confuse users if they passed flags==0 and don't know if > they are getting XML names or guest-provided names. Which argues that > guest results should ALWAYS be an explicit non-zero flag, never an > automatic action. > > > > -- > libvir-list mailing list > libvir-list@redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list > > Daniel, would like to throw some light on the discussion? -- Nehal J Wani -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] systemd: add debug message when virDBusCallMethod failed
On 09/05/13 13:03, Daniel P. Berrange wrote:
> On Wed, Sep 04, 2013 at 10:58:23AM +0800, Gao feng wrote:
>> Generate debug message when systemd doesn't support
>> interface org.freedesktop.machine1.Manager.
>>
>> Signed-off-by: Gao feng
>> ---
>> src/util/virsystemd.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/src/util/virsystemd.c b/src/util/virsystemd.c
>> index 3e69ef6..c631557 100644
>> --- a/src/util/virsystemd.c
>> +++ b/src/util/virsystemd.c
>> @@ -233,6 +233,7 @@ int virSystemdCreateMachine(const char *name,
>> if (err->code == VIR_ERR_DBUS_SERVICE &&
>> STREQ(err->str2, "org.freedesktop.DBus.Error.ServiceUnknown")) {
>> virResetLastError();
>> +VIR_DEBUG("systemd doesn't support interface
>> org.freedesktop.machine1.Manager");
>
> Is this really needed ? The virRaiseError call will have already reported
> this scenario surely ?
Yes, it will. It is actually spamming the log with "error" messages
every time you start a VM on a non-systemd host even when it is later
successful using the old approach.
Peter
signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv5 1/5] domifaddr: Implement the public APIs
On Tue, Sep 03, 2013 at 01:13:20PM -0600, Eric Blake wrote: > On 09/03/2013 01:07 PM, Eric Blake wrote: > > On 09/01/2013 07:43 AM, Nehal J Wani wrote: > >> Define a new API virDomainInterfaceAddresses, which returns > >> the address information of a running domain's interfaces(s). > >> If no interface name is specified, it returns the information > >> of all interfaces, otherwise it only returns the information > >> of the specificed interface. The address information includes > >> the MAC and IP addresses. > >> > >> Define helper function virDomainInterfaceFree, which allows > >> the upper layer application to free the domain interface object > >> conveniently. > >> > >> The API is going to provide multiple methods by flags, e.g. > >> > >> * Query guest agent > >> * Parse lease file of dnsmasq > >> * DHCP snooping > >> > >> But at this stage, it will only work with guest agent, and flags > >> won't be supported. > > > > That worries me a bit. Ultimately, we want our interfaces to behave as > > sane as possible when flags==0; rather than making the behavior be that > > 'flags==0' implies 'only guest agent probe', I'd rather introduce a flag > > right away up front that says 'include guest agent probe in the set of > > attempted methods', and then document that 'flags==0 is shorthand for > > letting the hypervisor choose the best method(s) out of supported > > possibilities)'. In other words, I want to make sure that this API will > > be similar to virDomainShutdownFlags, where a flags of 0 lets the > > hypervisor choose between methods, a single explicit flag forces the > > hypervisor to use that method alone, and more than one flag can be OR'd > > together to let the hypervisor choose among that subset of flags. > > Hmm. I'm replying to myself - is that a good sign? > > If the guest agent returns names that are provided by the guest, and > don't necessarily correspond to the domain XML, then maybe it's best to > NEVER return guest results by default, but to make the user always > explicitly request agent interaction. That is, even if 'flags==0' is > used to select between parsing the lease file vs. DHCP snoop results > (both of which tie perfectly to guest XML naming), the agent approach > can seriously confuse users if they passed flags==0 and don't know if > they are getting XML names or guest-provided names. Which argues that > guest results should ALWAYS be an explicit non-zero flag, never an > automatic action. Yes, that sounds like a good idea. The other reason to return DHCP snoop results by default is that those will work for any guest without requiring an agent installed. Regards, Daniel -- |: 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv5 1/5] domifaddr: Implement the public APIs
On Wed, Sep 04, 2013 at 10:35:34PM +0800, Osier Yang wrote: > On 04/09/13 03:13, Eric Blake wrote: > >On 09/03/2013 01:07 PM, Eric Blake wrote: > >>On 09/01/2013 07:43 AM, Nehal J Wani wrote: > >>>Define a new API virDomainInterfaceAddresses, which returns > >>>the address information of a running domain's interfaces(s). > >>>If no interface name is specified, it returns the information > >>>of all interfaces, otherwise it only returns the information > >>>of the specificed interface. The address information includes > >>>the MAC and IP addresses. > >>> > >>>Define helper function virDomainInterfaceFree, which allows > >>>the upper layer application to free the domain interface object > >>>conveniently. > >>> > >>>The API is going to provide multiple methods by flags, e.g. > >>> > >>> * Query guest agent > >>> * Parse lease file of dnsmasq > >>> * DHCP snooping > >>> > >>>But at this stage, it will only work with guest agent, and flags > >>>won't be supported. > >>That worries me a bit. Ultimately, we want our interfaces to behave as > >>sane as possible when flags==0; rather than making the behavior be that > >>'flags==0' implies 'only guest agent probe', I'd rather introduce a flag > >>right away up front that says 'include guest agent probe in the set of > >>attempted methods', and then document that 'flags==0 is shorthand for > >>letting the hypervisor choose the best method(s) out of supported > >>possibilities)'. In other words, I want to make sure that this API will > >>be similar to virDomainShutdownFlags, where a flags of 0 lets the > >>hypervisor choose between methods, a single explicit flag forces the > >>hypervisor to use that method alone, and more than one flag can be OR'd > >>together to let the hypervisor choose among that subset of flags. > >Hmm. I'm replying to myself - is that a good sign? > > > >If the guest agent returns names that are provided by the guest, and > >don't necessarily correspond to the domain XML, then maybe it's best to > >NEVER return guest results by default, but to make the user always > >explicitly request agent interaction. > > Hm, yes, the MAC address returned by guest agent might not > match what the domain config specifies. It reminds me something, > both the leases file and snooping will returns the interface name > like "vnetN", which is different with what guest agent returns (like > ethN or emN). And since the MAC address from guest agent might > be different with what domain config specifies, we have no way to > convert it into the names in domain config. That says we will have > different name styles for guest agent and the other two methods, > which will need quite documentations to explain. Such is life. We just have to document these naming limitations. Regards, Daniel -- |: 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] systemd: add debug message when virDBusCallMethod failed
On Thu, Sep 05, 2013 at 02:21:53PM +0200, Peter Krempa wrote:
> On 09/05/13 13:03, Daniel P. Berrange wrote:
> > On Wed, Sep 04, 2013 at 10:58:23AM +0800, Gao feng wrote:
> >> Generate debug message when systemd doesn't support
> >> interface org.freedesktop.machine1.Manager.
> >>
> >> Signed-off-by: Gao feng
> >> ---
> >> src/util/virsystemd.c | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/src/util/virsystemd.c b/src/util/virsystemd.c
> >> index 3e69ef6..c631557 100644
> >> --- a/src/util/virsystemd.c
> >> +++ b/src/util/virsystemd.c
> >> @@ -233,6 +233,7 @@ int virSystemdCreateMachine(const char *name,
> >> if (err->code == VIR_ERR_DBUS_SERVICE &&
> >> STREQ(err->str2,
> >> "org.freedesktop.DBus.Error.ServiceUnknown")) {
> >> virResetLastError();
> >> +VIR_DEBUG("systemd doesn't support interface
> >> org.freedesktop.machine1.Manager");
> >
> > Is this really needed ? The virRaiseError call will have already reported
> > this scenario surely ?
>
> Yes, it will. It is actually spamming the log with "error" messages
> every time you start a VM on a non-systemd host even when it is later
> successful using the old approach.
We likely need to invoke org.freedesktop.DBus.ListActivatableNames
and/or org.freedesktop.DBus.NameHasOwner to find out if systemd is
available without triggering an error.
Daniel
--
|: 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 :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] libxl: Check for regcomp failure
On 09/05/2013 01:49 AM, Michal Privoznik wrote:
>> In glibc, regcomp assigns into preg, but is careful to undo any
>> allocation on failure; it is also careful to make regfree() a no-op on
>> an already-freed buffer (whether by calling regfree() twice in a row, or
>> using it on preg after a failed regcomp). Gnulib copies this behavior.
>> But it is not universally standard:
>
> Question then is: if regcomp(®, ...) fails, reg == NULL, right?
No. You, the caller, supplied reg (typically stack allocated). As in:
regex_t reg;
int ret;
if ((ret = regcomp(®, str, flags))) {
regerror(ret, ®, buf, len);
} else {
regexec(...)
...
regfree(®);
}
The only thing that regfree() does is free any pointers _within_ the
regex_t struct. Remember, regex_t is a semi-opaque struct - POSIX only
documents that it contains a re_nsub member (and portable code therefore
cannot use any of its other members directly), but you ARE promised that
it is not an incomplete type, and that it is larger than a simple
pointer. It is _because_ regex_t is a struct with non-pointer members,
and where _you_ allocate the storage for the struct, that the struct can
contain useful information even after a failed regcomp() so that
regerror(®) can give a nicer message than regerror(NULL). But
ultimately, as long as regcomp() leaves no allocated data in the
remaining unnamed members, then there is nothing for regfree() to clean
up after failure.
You know, maybe I should ask the Austin Group (the people in charge of
POSIX) to clarify whether regfree() can/must be used after regcomp
failure, since the current wording isn't very clear.
> But
> passing the @reg to regerror: regerror(errcode, ®, ...) doesn't make
> much sense then. It can make, if regcomp would free all mem allocated,
> but set @reg to different values (each of them representing different
> cause of error). If that is the case, this is what I call the
> design!
>
> Michal
>
>
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] build: shut up automake warnings
On 09/05/2013 12:08 AM, Martin Kletzander wrote: > On Wed 04 Sep 2013 06:48:46 PM CEST, Eric Blake wrote: >> I'm tired of seeing screenfuls of messages like these when using >> automake 1.13 (Fedora 19): >> >> configure.ac:2121: warning: The 'AM_PROG_MKDIR_P' macro is deprecated, and >> its use is discouraged. >> configure.ac:2121: You should use the Autoconf-provided 'AC_PROG_MKDIR_P' >> macro instead, >> configure.ac:2121: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your >> Makefile.am files. >> daemon/Makefile.am:19: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' >> (or '*_CPPFLAGS') >> > > These were driving me crazy, but I thought we had no other option than > to leave this due to compatibility. Thanks for finding the way out of this. > > Unfortunately, 1.14 complains about subdir-objects way more than about > anything else and I still haven't found the way out of that one. Ouch - rawhide is currently still stuck on 1.13.4 [so much for the perception of rawhide being bleeding-edge]; I'll have to manually install from automake.git to play with subdir-objects (it may be easiest to just unconditionally turn it on, after testing that RHEL 5's 1.9 can handle it), as a followup patch. >> -# Use the silent-rules feature when possible. >> -m4_ifndef([AM_SILENT_RULES], [m4_define([AM_SILENT_RULES],[])]) >> -AM_SILENT_RULES([yes]) >> +# Default to using the silent-rules feature when possible. Formatting >> +# chosen to bypass 'grep' checks that cause older automake to warn. >> +# Users (include rpm) can still change the default at configure time. >> +m4_ifndef([AM_SILENT_RULES], >> + [m4_define([AM_SILENT_RULES],[])])AM_SILENT_RULES([yes]) >> > > Funny that only simple grep is used to identify these. Newer automake has been taught to use more-reliable m4 tracing instead of raw grep - but newer automake is the one that doesn't issue the warning. Yeah, I was rather shocked that this worked to shut up the warning on RHEL 5 :) > > ACK, Thanks; pushed. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 6/n] spec: make client-only testing easier
On 09/05/2013 01:51 AM, Michal Privoznik wrote: > On 04.09.2013 23:08, Eric Blake wrote: >> Several recent patches cleaned up 'make rpm' for the situation >> when client_only is true; these were done by manual spec file >> editing (since it's relatively hard to come by a RHEL 5 s390 >> box). Make it easier to do in the future via a simpler command >> line override. >> >> * libvirt.spec.in (client_only): Allow for override. >> >> Signed-off-by: Eric Blake >> --- >> libvirt.spec.in | 5 +++-- >> 1 file changed, 3 insertions(+), 2 deletions(-) > > ACK Thanks; pushed. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] storage: new backend: btrfs subvolumes
On Mon, Sep 02, 2013 at 02:48:12PM +0300, Oskari Saarenmaa wrote: > This commit adds a new storage pool driver, btrfs, which can be used to > manage btrfs subvolumes on an existing btrfs filesystem. The driver can > create new blank subvolumes and snapshots of existing subvolumes as well > as delete existing subvolumes. > > The subvolumes created are automatically made visible on the host side > and can be attached to domains using the tags as defined in > 'format domain' documentation. > > Libvirt volumes do not implement quotas at the moment because the current > (btrfs-progs-0.20.rc1.20130501git7854c8b-4.fc20.x86_64) support for quota > management in btrfs-progs is lacking the necessary features, for example > it's not possible to see the quota assigned to a certain subvolume and > usage information is only updated on syncfs(2). Quota support will be > implemented once the tools gain the necessary features. > > Signed-off-by: Oskari Saarenmaa You're going to hate me, but having played around with this, I don't believe it should be a separate pool driver. I think it should be part of the 'storage_fs.c' driver. The way I see it, a btrfs subvolume is just a special kind of volume in a directory. eg given a directory located on btrnfs /foo/bar it is perfectly valid to want to support /foo/bar/somedir (plain directory) /foo/bar/voldir (subvolume directory) /foo/var/somefile.qcow2 (qcow2 file) etc. I'd suggest that we should make it possible to create directories in the FS storage pool, but supporting use of a new attribute type='file|network|dir' on the top level element. Then distinguish between plain directories, and those backed by a subvolme using the element, So, eg to create a btrfs subvolume use wizz /mnt/btr/wizz 0 0 /mnt/btr/wizz This is a more generic approach that will work if any other FS grow support for subvolumes like btrfs has. Regards, Daniel -- |: 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Add support for enabling SASL for SPICE guests
From: "Daniel P. Berrange"
QEMU has support for SASL auth for SPICE guests, but libvirt
has no way to enable it. Following the example from VNC where
it is globally enabled via qemu.conf
Signed-off-by: Daniel P. Berrange
---
src/qemu/libvirtd_qemu.aug | 2 ++
src/qemu/qemu.conf | 16
src/qemu/qemu_command.c| 10 ++
src/qemu/qemu_conf.c | 3 +++
src/qemu/qemu_conf.h | 2 ++
src/qemu/test_libvirtd_qemu.aug.in | 2 ++
6 files changed, 35 insertions(+)
diff --git a/src/qemu/libvirtd_qemu.aug b/src/qemu/libvirtd_qemu.aug
index cd13d53..118d4c7 100644
--- a/src/qemu/libvirtd_qemu.aug
+++ b/src/qemu/libvirtd_qemu.aug
@@ -38,6 +38,8 @@ module Libvirtd_qemu =
| bool_entry "spice_tls"
| str_entry "spice_tls_x509_cert_dir"
| str_entry "spice_password"
+ | bool_entry "spice_sasl"
+ | str_entry "spice_sasl_dir"
let nogfx_entry = bool_entry "nographics_allow_host_audio"
diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf
index 5fd6263..6d4e99e 100644
--- a/src/qemu/qemu.conf
+++ b/src/qemu/qemu.conf
@@ -140,6 +140,22 @@
#spice_password = "XYZ12345"
+# Enable use of SASL encryption on the SPICE server. This requires
+# a SPICE client which supports the SASL protocol extension.
+#
+# It is necessary to configure /etc/sasl2/qemu.conf to choose
+# the desired SASL plugin (eg, GSSPI for Kerberos)
+#
+#spice_sasl = 1
+
+# The default SASL configuration file is located in /etc/sasl2/
+# When running libvirtd unprivileged, it may be desirable to
+# override the configs in this location. Set this parameter to
+# point to the directory, and create a qemu.conf in that location
+#
+#spice_sasl_dir = "/some/directory/sasl2"
+
+
# By default, if no graphical front end is configured, libvirt will disable
# QEMU audio output since directly talking to alsa/pulseaudio may not work
# with various security settings. If you know what you're doing, enable
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 91ca86a..5e4ebc8 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -7065,6 +7065,16 @@ qemuBuildGraphicsSPICECommandLine(virQEMUDriverConfigPtr
cfg,
virBufferAsprintf(&opt, "tls-port=%u", tlsPort);
}
+if (cfg->spiceSASL) {
+virBufferAddLit(&opt, ",sasl");
+
+if (cfg->spiceSASLdir)
+virCommandAddEnvPair(cmd, "SASL_CONF_DIR",
+ cfg->spiceSASLdir);
+
+/* TODO: Support ACLs later */
+}
+
switch (virDomainGraphicsListenGetType(graphics, 0)) {
case VIR_DOMAIN_GRAPHICS_LISTEN_TYPE_ADDRESS:
listenAddr = virDomainGraphicsListenGetAddress(graphics, 0);
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index 1f57f72..41ca7a3 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -266,6 +266,7 @@ static void virQEMUDriverConfigDispose(void *obj)
VIR_FREE(cfg->spiceTLSx509certdir);
VIR_FREE(cfg->spiceListen);
VIR_FREE(cfg->spicePassword);
+VIR_FREE(cfg->spiceSASLdir);
VIR_FREE(cfg->hugetlbfsMount);
VIR_FREE(cfg->hugepagePath);
@@ -379,6 +380,8 @@ int virQEMUDriverConfigLoadFile(virQEMUDriverConfigPtr cfg,
GET_VALUE_BOOL("spice_tls", cfg->spiceTLS);
GET_VALUE_STR("spice_tls_x509_cert_dir", cfg->spiceTLSx509certdir);
+GET_VALUE_BOOL("spice_sasl", cfg->spiceSASL);
+GET_VALUE_STR("spice_sasl_dir", cfg->spiceSASLdir);
GET_VALUE_STR("spice_listen", cfg->spiceListen);
GET_VALUE_STR("spice_password", cfg->spicePassword);
diff --git a/src/qemu/qemu_conf.h b/src/qemu/qemu_conf.h
index 206f2c6..cbd7053 100644
--- a/src/qemu/qemu_conf.h
+++ b/src/qemu/qemu_conf.h
@@ -111,6 +111,8 @@ struct _virQEMUDriverConfig {
bool spiceTLS;
char *spiceTLSx509certdir;
+bool spiceSASL;
+char *spiceSASLdir;
char *spiceListen;
char *spicePassword;
diff --git a/src/qemu/test_libvirtd_qemu.aug.in
b/src/qemu/test_libvirtd_qemu.aug.in
index ea770dc..1a9fb20 100644
--- a/src/qemu/test_libvirtd_qemu.aug.in
+++ b/src/qemu/test_libvirtd_qemu.aug.in
@@ -15,6 +15,8 @@ module Test_libvirtd_qemu =
{ "spice_tls" = "1" }
{ "spice_tls_x509_cert_dir" = "/etc/pki/libvirt-spice" }
{ "spice_password" = "XYZ12345" }
+{ "spice_sasl" = "1" }
+{ "spice_sasl_dir" = "/some/directory/sasl2" }
{ "nographics_allow_host_audio" = "1" }
{ "remote_display_port_min" = "5900" }
{ "remote_display_port_max" = "65535" }
--
1.8.3.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 3/3] security_dac: Favour ACLs over chown()
On Wed, Aug 28, 2013 at 12:27:40PM +0200, Michal Privoznik wrote: > On filesystems supporting ACLs we don't need to do a chown but we > can just set ACLs to gain access for qemu. However, since we are > setting these on too low level, where we don't know if disk is > just a read only or read write, we set read write access > unconditionally. > > >From implementation POV, a reference counter is introduced, so ACL is > restored only on the last restore attempt in order to not cut off other > domains. And since a file may had an ACL for a user already set, we need > to keep this as well. Both these, the reference counter and original ACL > are stored as extended attributes named trusted.libvirt.dac.refCount and > trusted.libvirt.dac.oldACL respectively. > > However, some filesystems doesn't support ACLs, XATTRs, or both. So the > code is made to favour ACLs among with tracking the reference count. If > this fails, we fall back to chown() with best effort to remember the > original owner of file. > > Signed-off-by: Michal Privoznik > --- > src/security/security_dac.c | 297 > +++- > 1 file changed, 268 insertions(+), 29 deletions(-) > > diff --git a/src/security/security_dac.c b/src/security/security_dac.c > index 8cbb083..913b68e 100644 > --- a/src/security/security_dac.c > +++ b/src/security/security_dac.c > @@ -37,6 +37,9 @@ > > #define VIR_FROM_THIS VIR_FROM_SECURITY > #define SECURITY_DAC_NAME "dac" > +#define SECURITY_DAC_XATTR_OLD_ACL "trusted.libvirt.dac.oldACL" > +#define SECURITY_DAC_XATTR_OLD_OWNER "trusted.libvirt.dac.oldOwner" > +#define SECURITY_DAC_XATTR_REFCOUNT "trusted.libvirt.dac.refCount" Use of "trusted." is non-portable, per the long mail thread last time this was posted[1]. The discussion there was never resolved in any way, so NACK to this patch as is. Daniel [1] https://www.redhat.com/archives/libvir-list/2013-March/msg01610.html -- |: 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] domain_conf: Delete the USB controller check from the USB Device checklist on virDomainDeviceIsUSB
On 09/04/2013 08:40 PM, Liuji (Jeremy) wrote: > When using "virsh attach-device" to attach a device, the > virDomainDefCompatibleDevice function will check the compatibility. > If the device is a USB device, but the VM don't have any USB controller, the > execution of "virsh attach-device" will fails. > It considers the USB controller as a USB device on virDomainDeviceIsUSB, so > we can't use "virsh attach-device" to attach a > USB controller for a VM which don't have any other USB controller. > > Signed-off-by: Liu Ji Your mail From "Liuji (Jeremy)" differs from your S-o-B "Liu Ji". For the sake of a clean 'git shortlog', I'd like to know which form you prefer, so we can stick an entry in .mailmap to clean up the discrepancy. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/2] libxl: Compile regular expression where it is used
Michal Privoznik wrote:
> On 05.09.2013 00:40, Jim Fehlig wrote:
>
>> Jim Fehlig wrote:
>>
>>> The regular expression used to determine guest capabilities
>>> was compiled in libxlCapsInitHost() but used in libxlCapsInitGuests().
>>> Move compilation to libxlCapsInitGuests() where it is used, and free
>>> the compiled regex after use. Ensure not to free the regex if
>>> compilation fails.
>>>
>>> Signed-off-by: Jim Fehlig
>>> ---
>>> src/libxl/libxl_conf.c | 29 +++--
>>> 1 file changed, 15 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
>>> index fcb278b..c7be7aa 100644
>>> --- a/src/libxl/libxl_conf.c
>>> +++ b/src/libxl/libxl_conf.c
>>> @@ -61,8 +61,7 @@ struct guest_arch {
>>> int ia64_be;
>>> };
>>>
>>> -static const char *xen_cap_re =
>>> "(xen|hvm)-[[:digit:]]+\\.[[:digit:]]+-(x86_32|x86_64|ia64|powerpc64)(p|be)?";
>>> -static regex_t xen_cap_rec;
>>> +#define XEN_CAP_REGEX
>>> "(xen|hvm)-[[:digit:]]+\\.[[:digit:]]+-(x86_32|x86_64|ia64|powerpc64)(p|be)?";
>>>
>>>
>> Opps, that's not quite right. The version I actually compiled and
>> tested doesn't have the trailing ';' on the #define :).
>>
>>
>
> Yep, gcc caught that. ACK series (with this change).
>
Thanks. I added link to the thread which inspired this series in patch
1 commit message and pushed.
Regards,
Jim
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] virsh domstate output when kvm killed vs guest OS panic
On 09/05/2013 12:47 PM, Chris Friesen wrote: > Hi, > > If I kill a libvirt-managed kvm process with "kill -9", running "virsh > domstate --reason " gives > > shut off (crashed) > > Looking at the code, that corresponds to > VIR_DOMAIN_SHUTOFF/VIR_DOMAIN_SHUTOFF_CRASHED. The comment says that > VIR_DOMAIN_SHUTOFF_CRASHED corresponds to "domain crashed". Is this > supposed to be a crash of the hypervisor, or of the guest OS? Both. Any case where a crash has transitioned the domain into a shutoff state (no qemu process exists any more), in such a way that libvirt knows that it is a crash. > > If I trigger a panic in the guest, it sits there in the panicked state > doing nothing and "virsh domstate" gives > > running (booted) Depending on what version of kernel you have and what version of qemu you are using, you can set things up so that qemu exposes '-device pvpanic' to the guest, and Linux guests can then write to that device on kernel panic, so that qemu then forwards a crash event to libvirt. (Theoretically, someone could write a windows driver so that Windows guests could also trigger the qemu event, but to date, no one has done that). With that in place, a guest panic would no longer show up as running(booted), but as crashed(panicked). But right now, since qemu 1.6 botched the implementation of '-device pvpanic', we are waiting for qemu 1.7 to stabilize the design, so there is no easy way to pass -device pvpanic on the qemu command line except using XML extensions that take you into the realm of unsupportedness. > > So what's the point of VIR_DOMAIN_CRASHED/VIR_DOMAIN_CRASHED_PANICKED? To differentiate between the qemu panic event (the qemu process still exists) and the completely dead qemu (your kill -9 attempt), if you are using the pvpanic device. Trust me, this whole area is a big mess, that has been drawn out in several long debates on both qemu and libvirt lists, for more than a year now. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] virsh domstate output when kvm killed vs guest OS panic
Hi, If I kill a libvirt-managed kvm process with "kill -9", running "virsh domstate --reason " gives shut off (crashed) Looking at the code, that corresponds to VIR_DOMAIN_SHUTOFF/VIR_DOMAIN_SHUTOFF_CRASHED. The comment says that VIR_DOMAIN_SHUTOFF_CRASHED corresponds to "domain crashed". Is this supposed to be a crash of the hypervisor, or of the guest OS? If I trigger a panic in the guest, it sits there in the panicked state doing nothing and "virsh domstate" gives running (booted) So what's the point of VIR_DOMAIN_CRASHED/VIR_DOMAIN_CRASHED_PANICKED? Chris -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 1/2] build: avoid obsolete AC_HELP_STRING
Autoconf states that AC_HELP_STRING is obsolete, and that new programs should use AS_HELP_STRING. We also had instances of not properly quoting the macro usage, and not relying on autoconf's word-wrapping abilities to avoid long lines. I validated that this commit has no impact to the generated configure file. * configure.ac (AC_ARG_WITH, AC_ARG_ENABLE): Autoconf recommends the use of AS_HELP_STRING. Also, use proper quoting and wrap long lines. * m4/virt-apparmor.m4 (LIBVIRT_CHECK_APPARMOR): Likewise. * m4/virt-selinux.m4 (LIBVIRT_CHECK_SELINUX): Likewise. Signed-off-by: Eric Blake --- configure.ac| 219 +++- m4/virt-apparmor.m4 | 4 +- m4/virt-selinux.m4 | 3 +- 3 files changed, 151 insertions(+), 75 deletions(-) diff --git a/configure.ac b/configure.ac index a639f59..0631c59 100644 --- a/configure.ac +++ b/configure.ac @@ -361,11 +361,11 @@ AC_DEFINE_UNQUOTED([SCRUB],["$SCRUB"], [Location or name of the scrub program (for wiping algorithms)]) dnl Specific dir for HTML output ? -AC_ARG_WITH([html-dir], [AC_HELP_STRING([--with-html-dir=path], +AC_ARG_WITH([html-dir], [AS_HELP_STRING([--with-html-dir=path], [path to base html directory, default $datadir/doc/html])], [HTML_DIR=$withval], [HTML_DIR='$(datadir)/doc']) -AC_ARG_WITH([html-subdir], [AC_HELP_STRING([--with-html-subdir=path], +AC_ARG_WITH([html-subdir], [AS_HELP_STRING([--with-html-subdir=path], [directory used under html-dir, default $PACKAGE-$VERSION/html])], [test "x$withval" != "x" && HTML_DIR="$HTML_DIR/$withval"], [HTML_DIR="$HTML_DIR/\$(PACKAGE)-\$(VERSION)/html"]) @@ -373,7 +373,7 @@ AC_SUBST([HTML_DIR]) dnl Specific XML catalog file for validation of generated html AC_ARG_WITH([xml-catalog-file], -[AC_HELP_STRING([--with-xml-catalog-file=path], +[AS_HELP_STRING([--with-xml-catalog-file=path], [path to XML catalog file for validating generated html, default /etc/xml/catalog])], [XML_CATALOG_FILE=$withval], @@ -431,46 +431,77 @@ AM_CONDITIONAL([WITH_FREEBSD], [test "$with_freebsd" = "yes"]) dnl Allow to build without Xen, QEMU/KVM, test or remote driver AC_ARG_WITH([xen], - AC_HELP_STRING([--with-xen], [add XEN support @<:@default=check@:>@]),[],[with_xen=check]) + [AS_HELP_STRING([--with-xen], +[add XEN support @<:@default=check@:>@])], + [],[with_xen=check]) AC_ARG_WITH([xen-inotify], - AC_HELP_STRING([--with-xen-inotify], [add XEN inotify support @<:@default=check@:>@]),[],[with_xen_inotify=check]) + [AS_HELP_STRING([--with-xen-inotify], +[add XEN inotify support @<:@default=check@:>@])], + [],[with_xen_inotify=check]) AC_ARG_WITH([qemu], - AC_HELP_STRING([--with-qemu], [add QEMU/KVM support @<:@default=yes@:>@]),[],[with_qemu=yes]) + [AS_HELP_STRING([--with-qemu], +[add QEMU/KVM support @<:@default=yes@:>@])], + [],[with_qemu=yes]) AC_ARG_WITH([uml], - AC_HELP_STRING([--with-uml], [add UML support @<:@default=check@:>@]),[],[with_uml=check]) + [AS_HELP_STRING([--with-uml], +[add UML support @<:@default=check@:>@])], + [],[with_uml=check]) AC_ARG_WITH([openvz], - AC_HELP_STRING([--with-openvz], [add OpenVZ support @<:@default=check@:>@]),[],[with_openvz=check]) + [AS_HELP_STRING([--with-openvz], +[add OpenVZ support @<:@default=check@:>@])], + [],[with_openvz=check]) AC_ARG_WITH([vmware], - AC_HELP_STRING([--with-vmware], [add VMware support @<:@default=yes@:>@]),[],[with_vmware=yes]) + [AS_HELP_STRING([--with-vmware], +[add VMware support @<:@default=yes@:>@])], + [],[with_vmware=yes]) AC_ARG_WITH([phyp], - AC_HELP_STRING([--with-phyp], [add PHYP support @<:@default=check@:>@]),[],[with_phyp=check]) + [AS_HELP_STRING([--with-phyp], +[add PHYP support @<:@default=check@:>@])], + [],[with_phyp=check]) AC_ARG_WITH([xenapi], - AC_HELP_STRING([--with-xenapi], [add XenAPI support @<:@default=check@:>@]),[],[with_xenapi=check]) + [AS_HELP_STRING([--with-xenapi], +[add XenAPI support @<:@default=check@:>@])], + [],[with_xenapi=check]) AC_ARG_WITH([libxl], - AC_HELP_STRING([--with-libxl], [add libxenlight support @<:@default=check@:>@]),[],[with_libxl=check]) + [AS_HELP_STRING([--with-libxl], +[add libxenlight support @<:@default=check@:>@])], + [],[with_libxl=check]) AC_ARG_WITH([vbox], - AC_HELP_STRING([--with-vbox=@<:@PFX@:>@], - [VirtualBox XPCOMC location @<:@default=yes@:>@]),[], - [with_vbox=yes]) + [AS_HELP_STRING([--with-vbox=@<:@PFX@:>@], +[VirtualBox XPCOMC location @<:@default=yes@:>@])], + [],[with_vbox=yes]) AC_ARG_WITH([lxc], - AC_HELP_STRING([--with-lxc], [add Linux Container support @<:@default=check@:>@]),[],[with_lxc=check]) + [AS_HELP_STRING([--with-lxc], +[add Linux Container support @<:@default=check@:>@])], + [],[with_lxc=check]) AC_ARG_WITH([esx], - AC_HELP_STRING([--with-
[libvirt] [PATCH 2/2] build: fix regression in requiring yajl for new enough qemu
Jonathan Leban reported an issue to me off-list about his build failing to use qemu because he failed to install yajl-devel. But I recalled specifically tweaking configure.ac to die in that situation (commits 350583c, ba9c38b). After a bit more head-scratching, we found the cause of the regression: commit 654c709 rearranged things so that the qemu version check now occurs before AC_ARG_WITH has had a chance to set either $with_qemu or $with_yajl. Coincidentally, this fix aligns with a documentation patch that was just posted to the autoconf mailing list :) http://thread.gmane.org/gmane.comp.sysutils.autoconf.patches/8324 * m4/virt-lib.m4 (LIBVIRT_CHECK_LIB, LIBVIRT_CHECK_LIB_ALT) (LIBVIRT_CHECK_PKG): Populate defaults earlier. * configure.ac (AC_ARG_WITH): Likewise for drivers. Signed-off-by: Eric Blake --- configure.ac | 72 +- m4/virt-lib.m4 | 12 +- 2 files changed, 42 insertions(+), 42 deletions(-) diff --git a/configure.ac b/configure.ac index 0631c59..3735c92 100644 --- a/configure.ac +++ b/configure.ac @@ -432,77 +432,77 @@ AM_CONDITIONAL([WITH_FREEBSD], [test "$with_freebsd" = "yes"]) dnl Allow to build without Xen, QEMU/KVM, test or remote driver AC_ARG_WITH([xen], [AS_HELP_STRING([--with-xen], -[add XEN support @<:@default=check@:>@])], - [],[with_xen=check]) +[add XEN support @<:@default=check@:>@])]) +m4_divert_text([DEFAULTS], [with_xen=check]) AC_ARG_WITH([xen-inotify], [AS_HELP_STRING([--with-xen-inotify], -[add XEN inotify support @<:@default=check@:>@])], - [],[with_xen_inotify=check]) +[add XEN inotify support @<:@default=check@:>@])]) +m4_divert_text([DEFAULTS], [with_xen_inotify=check]) AC_ARG_WITH([qemu], [AS_HELP_STRING([--with-qemu], -[add QEMU/KVM support @<:@default=yes@:>@])], - [],[with_qemu=yes]) +[add QEMU/KVM support @<:@default=yes@:>@])]) +m4_divert_text([DEFAULTS], [with_qemu=yes]) AC_ARG_WITH([uml], [AS_HELP_STRING([--with-uml], -[add UML support @<:@default=check@:>@])], - [],[with_uml=check]) +[add UML support @<:@default=check@:>@])]) +m4_divert_text([DEFAULTS], [with_uml=check]) AC_ARG_WITH([openvz], [AS_HELP_STRING([--with-openvz], -[add OpenVZ support @<:@default=check@:>@])], - [],[with_openvz=check]) +[add OpenVZ support @<:@default=check@:>@])]) +m4_divert_text([DEFAULTS], [with_openvz=check]) AC_ARG_WITH([vmware], [AS_HELP_STRING([--with-vmware], -[add VMware support @<:@default=yes@:>@])], - [],[with_vmware=yes]) +[add VMware support @<:@default=yes@:>@])]) +m4_divert_text([DEFAULTS], [with_vmware=yes]) AC_ARG_WITH([phyp], [AS_HELP_STRING([--with-phyp], -[add PHYP support @<:@default=check@:>@])], - [],[with_phyp=check]) +[add PHYP support @<:@default=check@:>@])]) +m4_divert_text([DEFAULTS], [with_phyp=check]) AC_ARG_WITH([xenapi], [AS_HELP_STRING([--with-xenapi], -[add XenAPI support @<:@default=check@:>@])], - [],[with_xenapi=check]) +[add XenAPI support @<:@default=check@:>@])]) +m4_divert_text([DEFAULTS], [with_xenapi=check]) AC_ARG_WITH([libxl], [AS_HELP_STRING([--with-libxl], -[add libxenlight support @<:@default=check@:>@])], - [],[with_libxl=check]) +[add libxenlight support @<:@default=check@:>@])]) +m4_divert_text([DEFAULTS], [with_libxl=check]) AC_ARG_WITH([vbox], [AS_HELP_STRING([--with-vbox=@<:@PFX@:>@], -[VirtualBox XPCOMC location @<:@default=yes@:>@])], - [],[with_vbox=yes]) +[VirtualBox XPCOMC location @<:@default=yes@:>@])]) +m4_divert_text([DEFAULTS], [with_vbox=yes]) AC_ARG_WITH([lxc], [AS_HELP_STRING([--with-lxc], -[add Linux Container support @<:@default=check@:>@])], - [],[with_lxc=check]) +[add Linux Container support @<:@default=check@:>@])]) +m4_divert_text([DEFAULTS], [with_lxc=check]) AC_ARG_WITH([esx], [AS_HELP_STRING([--with-esx], -[add ESX support @<:@default=check@:>@])], - [],[with_esx=check]) +[add ESX support @<:@default=check@:>@])]) +m4_divert_text([DEFAULTS], [with_esx=check]) AC_ARG_WITH([hyperv], [AS_HELP_STRING([--with-hyperv], -[add Hyper-V support @<:@default=check@:>@])], - [],[with_hyperv=check]) +[add Hyper-V support @<:@default=check@:>@])]) +m4_divert_text([DEFAULTS], [with_hyperv=check]) AC_ARG_WITH([parallels], [AS_HELP_STRING([--with-parallels], -[add Parallels Cloud Server support @<:@default=check@:>@])], - [],[with_parallels=check]) +[add Parallels Cloud Server support @<:@default=check@:>@])]) +m4_divert_text([DEFAULTS], [with_parallels=check]) AC_ARG_WITH([test], [AS_HELP_STRING([--with-test], -[add test driver support @<:@default=yes@:>@])], - [],[with_test=yes]) +[add test driver support @<:@default=yes@:>@])]) +m4_divert_text([DEFAULTS], [with_test=yes]) AC_ARG_WITH([remote], [AS_HELP_STRING([--with-remote], -[add remote driver support @<:@default=yes@:>@])], - [],[with_remote=yes]) +[add remote driver support @<:@default=ye
[libvirt] [PATCH 0/2] fix configure to require yajl if qemu is new enough
After yet another debug session on IRC about failure to use qemu because yajl-devel wasn't installed, I came up with these patches. The first is just preparation (no change to generated code); and with the second, I validated that uninstalling yajl-devel and then trying to configure once again gives me the desired: checking for yajl_tree_parse in -lyajl... no configure: error: You must install the libyajl library & headers to compile libvirt [I can't claim build-breaker or trivial rule for either of these patches, but as I am also the autoconf guru around here, I won't be surprised if the extent of other's reviews is "yep, I installed it and it did what you said"...] And yes, I tested on RHEL 5 that it still works with autoconf 2.59. Eric Blake (2): build: avoid obsolete AC_HELP_STRING build: fix regression in requiring yajl for new enough qemu configure.ac| 221 +++- m4/virt-apparmor.m4 | 4 +- m4/virt-lib.m4 | 12 +-- m4/virt-selinux.m4 | 3 +- 4 files changed, 158 insertions(+), 82 deletions(-) -- 1.8.3.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] domain_conf: Delete the USB controller check from the USB Device checklist on virDomainDeviceIsUSB
Sorry, I did not notice this discrepancy. I prefer the "Liuji (Jeremy)" form. Next time, I will change the name of S-o-B from "Liu Ji" to "Liuji (Jeremy)". Thanks. > -Original Message- > From: Eric Blake [mailto:ebl...@redhat.com] > Sent: Thursday, September 05, 2013 10:08 PM > To: Liuji (Jeremy) > Cc: libvir-list@redhat.com; pkre...@redhat.com; Jinbo (Justin); Luohao > (brian); Haofeng > Subject: Re: [libvirt] [PATCH] domain_conf: Delete the USB controller check > from the USB Device checklist on virDomainDeviceIsUSB > > On 09/04/2013 08:40 PM, Liuji (Jeremy) wrote: > > When using "virsh attach-device" to attach a device, the > virDomainDefCompatibleDevice function will check the compatibility. > > If the device is a USB device, but the VM don't have any USB controller, the > execution of "virsh attach-device" will fails. > > It considers the USB controller as a USB device on > > virDomainDeviceIsUSB, so we can't use "virsh attach-device" to attach a USB > controller for a VM which don't have any other USB controller. > > > > > Signed-off-by: Liu Ji > > Your mail From "Liuji (Jeremy)" differs from your S-o-B "Liu Ji". For the > sake of a > clean 'git shortlog', I'd like to know which form you prefer, so we can stick > an > entry in .mailmap to clean up the discrepancy. > > -- > Eric Blake eblake redhat com+1-919-301-3266 > Libvirt virtualization library http://libvirt.org -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Docs: fix a typo in virt-login-shell.pod
Thanks and pushed now. -- Regards, Alex - Original Message - From: "Peter Krempa" To: "Alex Jia" Cc: libvir-list@redhat.com Sent: Tuesday, September 3, 2013 3:35:43 PM Subject: Re: [libvirt] [PATCH] Docs: fix a typo in virt-login-shell.pod On 09/03/13 05:52, Alex Jia wrote: > > Signed-off-by: Alex Jia > --- > tools/virt-login-shell.pod |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/tools/virt-login-shell.pod b/tools/virt-login-shell.pod > index e27d500..bcd7855 100644 > --- a/tools/virt-login-shell.pod > +++ b/tools/virt-login-shell.pod > @@ -11,7 +11,7 @@ B > The B program is a setuid shell that is used to join > an LXC container that matches the user's name. If the container is not > running, virt-login-shell will attempt to start the container. > -virt-sandbox-shell is not allowed to be run by root. Normal users will get > +virt-login-shell is not allowed to be run by root. Normal users will get > added to a container that matches their username, if it exists, and they are > configured in /etc/libvirt/virt-login-shell.conf. > > ACK. Peter -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] LXC:fix typo in lxc_container.c
From: Chen Hanxiao
fix typo in lxc_container.c
Signed-off-by: Chen Hanxiao
---
src/lxc/lxc_container.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c
index 8abaea0..cf096f3 100644
--- a/src/lxc/lxc_container.c
+++ b/src/lxc/lxc_container.c
@@ -1145,7 +1145,7 @@ lxcContainerMountDetectFilesystem(const char *src
ATTRIBUTE_UNUSED,
#endif /* ! WITH_BLKID */
/*
- * This functions attempts to do automatic detection of filesystem
+ * This function attempts to do automatic detection of filesystem
* type following the same rules as the util-linux 'mount' binary.
*
* The main difference is that we don't (currently) try to use
@@ -1600,7 +1600,7 @@ static int lxcContainerResolveSymlinks(virDomainDefPtr
vmDef)
}
/*
- * This is running as the 'init' process insid the container.
+ * This is running as the 'init' process inside the container.
* It removes some capabilities that could be dangerous to
* host system, since they are not currently "containerized"
*/
@@ -1750,7 +1750,7 @@ static int lxcContainerChild(void *data)
if (lxcContainerSendContinue(argv->handshakefd) < 0) {
virReportSystemError(errno, "%s",
-_("failed to send continue signal to controller"));
+_("Failed to send continue signal to controller"));
goto cleanup;
}
--
1.8.2.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] qemu: Remove unnecessary variable assignment
Remove unnecessary 'addrs = NULL' in
qemuDomainAssignS390Addresses() and
qemuDomainAssignPCIAddresses() due to
the related Free function in label cleanup.
---
src/qemu/qemu_command.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 643532f..3cc9c1d 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -1320,7 +1320,6 @@ qemuDomainAssignS390Addresses(virDomainDefPtr def,
qemuDomainCCWAddressSetFree(priv->ccwaddrs);
priv->persistentAddrs = 1;
priv->ccwaddrs = addrs;
-addrs = NULL;
} else {
priv->persistentAddrs = 0;
}
@@ -1901,7 +1900,6 @@ qemuDomainAssignPCIAddresses(virDomainDefPtr def,
qemuDomainPCIAddressSetFree(priv->pciaddrs);
priv->persistentAddrs = 1;
priv->pciaddrs = addrs;
-addrs = NULL;
} else {
priv->persistentAddrs = 0;
}
--
1.7.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 1/3] qemu: Remove CPU features functions calling for non-x86 platform.
On 2013年09月05日 19:08, Daniel P. Berrange wrote:
On Tue, Sep 03, 2013 at 02:28:23PM +0800, Li Zhang wrote:
From: Li Zhang
CPU features are not supported on non-x86 and hasFeatures will be NULL.
This patch is to remove CPU features functions calling to avoid errors.
Signed-off-by: Li Zhang
---
src/qemu/qemu_command.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index f8fccea..3b6ba7a 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -6349,7 +6349,6 @@ qemuBuildCpuArgStr(const virQEMUDriverPtr driver,
(def->cpu->mode != VIR_CPU_MODE_CUSTOM || def->cpu->model)) {
virCPUCompareResult cmp;
const char *preferred;
-int hasSVM;
if (!host ||
!host->model ||
@@ -6389,10 +6388,13 @@ qemuBuildCpuArgStr(const virQEMUDriverPtr driver,
/* Only 'svm' requires --enable-nesting. The nested
* 'vmx' patches now simply hook off the CPU features
*/
-hasSVM = cpuHasFeature(data, "svm");
-if (hasSVM < 0)
-goto cleanup;
-*hasHwVirt = hasSVM > 0 ? true : false;
+if (def->os.arch == VIR_ARCH_X86_64 ||
+def->os.arch == VIR_ARCH_I686) {
+int hasSVM = cpuHasFeature(data, "svm");
+if (hasSVM < 0)
+goto cleanup;
+*hasHwVirt = hasSVM > 0 ? true : false;
+}
if (cpu->mode == VIR_CPU_MODE_HOST_PASSTHROUGH) {
const char *mode = virCPUModeTypeToString(cpu->mode);
This bit looks good.
@@ -10575,7 +10577,9 @@ qemuParseCommandLineCPU(virDomainDefPtr dom,
model = NULL;
}
-if (virCPUDefAddFeature(cpu, feature, policy) < 0)
+if ((dom->os.arch == VIR_ARCH_X86_64 ||
+dom->os.arch == VIR_ARCH_I686) &&
+virCPUDefAddFeature(cpu, feature, policy) < 0)
goto cleanup;
}
} else if (STRPREFIX(tokens[i], "hv_")) {
For this, I think we should virReportError() if we find a CPU flag on
the command line for non-x86 arches, instead of silently ignoring it.
Okay, I will change it.
Thanks.
I think I'd also like to split this patch in two. I'll apply the first
chunk of it now.
Daniel
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemu: Remove unnecessary variable assignment
On 09/06/2013 07:35 AM, Hongwei Bi wrote: > Remove unnecessary 'addrs = NULL' in > qemuDomainAssignS390Addresses() and > qemuDomainAssignPCIAddresses() due to > the related Free function in label cleanup. But it is necessary, because we assign the value of addrs to priv->ccwaddrs. If we didn't set addrs to NULL, it would get freed by that function in the cleanup: section and priv->ccwaddrs would point to freed memory. Jan -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 1/1] qemu: avoid users specifying CPU features for non-x86 plaftorm.
From: Li Zhang
Currently, only X86 provides users CPU features with CPUID instruction.
If users specify the features for non-x86, it should tell users to
remove them.
This patch is to report one error if features are specified by
users for non-x86 platform.
Signed-off-by: Li Zhang
---
src/qemu/qemu_command.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 91ca86a..1a158e4 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -10644,6 +10644,14 @@ qemuParseCommandLineCPU(virDomainDefPtr dom,
if (*feature == '\0')
goto syntax;
+if (dom->os.arch != VIR_ARCH_X86_64 &&
+dom->os.arch != VIR_ARCH_I686) {
+virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("%s platform doesn't support CPU features'"),
+ virArchToString(dom->os.arch));
+goto cleanup;
+ }
+
if (STREQ(feature, "kvmclock")) {
bool present = (policy == VIR_CPU_FEATURE_REQUIRE);
size_t j;
--
1.8.1.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
