On 31 May 2016 at 10:59, Ansis Atteka wrote:
>
>
> On 31 May 2016 at 09:36, Daniel P. Berrange wrote:
>
>> On Mon, May 30, 2016 at 01:27:46PM -0700, Ansis Atteka wrote:
>> > On Mon, May 30, 2016 at 12:29 AM, Christian Ehrhardt
>> > wrote:
>> > > On Tue, May 24, 2016 at 4:10 PM, Aaron Conole
>>
Since we support QEMU 0.12 and later, checking for support of specific flags
added prior to that isn't necessary.
Thus start with the base of having the "-o options" available for the
qemu-img create option and then determine whether we have the compat
option for qcow2 files (which would be necess
Move the module from qemu_command.c to a new module virqemu.c and
rename the API to virQEMUBuildObjectCommandline.
This API will then be shareable with qemu-img and the need to build
a security object for luks support.
Signed-off-by: John Ferlan
---
po/POTFILES.in | 1 +
src/Make
Rather than inline code secret lookup for rbd/iscsi, use the common function.
Signed-off-by: John Ferlan
---
src/Makefile.am | 1 +
src/storage/storage_backend_iscsi.c | 50 +
src/storage/storage_backend_rbd.c | 48 +++---
Rework the logic to remove the various levels of indirection between
qemuBuildSecretInfoProps and qemuBuildObjectSecretCommandLine. Merge
them into qemuBuildObjectSecinfoCommandLine which will do all the
work of building the secinfo secret object command line.
Signed-off-by: John Ferlan
---
src/
A common way to build a qemu secret object to be used by qemu_command.c in
the short term and a bit longer term by storage_backend.c for qemu-img.
Signed-off-by: John Ferlan
---
src/libvirt_private.syms | 1 +
src/util/virqemu.c | 69
src/u
In qemuBuildMasterKeyCommandLine, rather than inline code build the command
use virQEMUBuildSecretObjectProps to generate the JSON secret object and
then virQEMUBuildObjectCommandlineFromJSON to build the object.
This is just like qemuBuildSecretInfoProps which will now also use the
common functio
Move the enum into secret_util, rename it to be just virSecretLookupType.
This includes quite a bit of collateral damage, but the goal is to remove
the "virStorage*" and replace with the virSecretLookupType so that it's
easier to to add new lookups that aren't necessarily storage pool related.
Sig
v1: http://www.redhat.com/archives/libvir-list/2016-May/msg02017.html
Changes in v2:
Patch 1 - Move function to a new src/util/virqemu.c with adjustments
to other affected areas
Patches 2-4 - Similarly adjust the flow/name of the patches with an
adjustment so that patch 2 is just the new code in
On 05/31/2016 09:37 AM, Peter Krempa wrote:
> On Sat, May 28, 2016 at 09:55:12 -0400, John Ferlan wrote:
>> Rather than inline code secret lookup for rbd/iscsi, use the common function.
>>
>> Signed-off-by: John Ferlan
>> ---
>> This just makes the iscsi/rbd storage driver use the common functi
On Thu, May 19, 2016 at 10:27:17AM +0100, Daniel P. Berrange wrote:
> On Mon, May 16, 2016 at 04:58:48PM -0700, Stefan Hajnoczi wrote:
> > On Wed, May 11, 2016 at 03:42:34PM +0100, Daniel P. Berrange wrote:
> > > On Tue, May 10, 2016 at 01:03:48PM +0100, Stefan Hajnoczi wrote:
> > > > On Mon, May 0
On 05/30/2016 04:21 AM, Ján Tomko wrote:
> On Fri, May 27, 2016 at 04:20:09PM +0200, Tomáš Ryšavý wrote:
>> The function virDomainDefNewFull() in src/conf/domain_conf.c was a thin
>> wrapper around virDomainDefNew() that was only used in a few places in
>> the code. The function was removed and the
On Tue, May 31, 2016 at 11:55:09AM -0400, Laine Stump wrote:
Although dns host records are stored in a separate configuration file
that is reread by dnsmasq when it receives a SIGHUP, the txt and srv
records are directly in the dnsmasq .conf file which can't be reread
after initial dnsmasq startu
On Tue, May 31, 2016 at 08:06:06PM +0200, Fabian Freyer wrote:
At the moment the bootloader arguments never get formatted if the
bootloader is unset. However, in cases where the bootloader defaults to
a default value when unset, specifying bootloader arguments does make
sense.
Please wrap long
On 31 May 2016 at 09:36, Daniel P. Berrange wrote:
> On Mon, May 30, 2016 at 01:27:46PM -0700, Ansis Atteka wrote:
> > On Mon, May 30, 2016 at 12:29 AM, Christian Ehrhardt
> > wrote:
> > > On Tue, May 24, 2016 at 4:10 PM, Aaron Conole
> wrote:
> > >
> > >> Daniele Di Proietto writes:
> > >>
>
At the moment the bootloader arguments never get formatted if the bootloader is
unset. However, in cases where the bootloader defaults to a default value when
unset, specifying bootloader arguments does make sense.
---
src/conf/domain_conf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/
From: Derbyshev Dmitry
QEMU reports timestamp and available along with other memory statistics.
This information was not saved into domain statistics.
Changes since v1:
* Enum numeration fixed
* Macro getting "usage" field fixed
Derbyshev Dmitry (2):
qemu: expand domain memory statistics wi
From: Derbyshev Dmitry
'memtotal' field in virtio drivers and qemu corresponds to 'available' in
libvirt.
Because of that, 'available' is renamed into 'usable'.
Balloon statistics are not reported in hrf, so no modifications are made in
qemu_monitor_text.c.
Signed-off-by: Derbyshev Dmitry
---
From: Derbyshev Dmitry
QEMU reports timestamp along with other memory statistics, but this information
is not saved into domain statistics.
It could be useful to determine if the data reported is fresh or not.
Balloon statistics are not reported in hrf, so no modifications are made in
qemu_moni
pls ignore, merged incorrectly
5/31/2016 7:21 PM, Derbyshev Dmitriy пишет:
diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h
index b65dd33..002253f 100644
--- a/include/libvirt/libvirt-domain.h
+++ b/include/libvirt/libvirt-domain.h
@@ -603,6 +603,10 @@ typedef en
On 05/31/2016 10:10 AM, Peter Krempa wrote:
> On Tue, May 31, 2016 at 09:49:45 -0400, John Ferlan wrote:
>>
>>
>> On 05/31/2016 08:10 AM, Peter Krempa wrote:
>>> On Fri, May 27, 2016 at 09:57:08 -0400, John Ferlan wrote:
Need to commonalize the code a bit more in order to use a common functi
From: Derbyshev Dmitry
QEMU reports timestamp along with other memory statistics, but this information
is not saved into domain statistics. It could be useful to determine if the
data reported is fresh or not.
Balloon statistics are not reported in hrf, so no modifications are made in
qemu_monito
From: Derbyshev Dmitry
'memtotal' field in qemu corresponds to 'available' in libvirt.
Because of that, 'available' is renamed into 'usable'.
Balloon statistics are not reported in hrf, so no modifications are made in
qemu_monitor_text.c.
Signed-off-by: Derbyshev Dmitry
---
include/libvirt/lib
On Mon, May 30, 2016 at 01:27:46PM -0700, Ansis Atteka wrote:
> On Mon, May 30, 2016 at 12:29 AM, Christian Ehrhardt
> wrote:
> > On Tue, May 24, 2016 at 4:10 PM, Aaron Conole wrote:
> >
> >> Daniele Di Proietto writes:
> >>
> >> > Hi Aaron,
> >> >
> >> > I'm still a little bit nervous about cal
From: Derbyshev Dmitry
QEMU reports timestamp and available along with other memory statistics.
This information was not saved into domain statistics.
Derbyshev Dmitry (2):
qemu: expand domain memory statistics with 'usable'
qemu: expand domain memory statistics with 'last-update' timestamp
pleases ignore, we have similar patch, resending as patch series.
5/31/2016 3:26 PM, Derbyshev Dmitriy пишет:
QEMU reports timestamp along with other memory statistics, but this information
is not saved into domain statistics.
It could be useful to determine if the data reported is fresh or no
Although dns host records are stored in a separate configuration file
that is reread by dnsmasq when it receives a SIGHUP, the txt and srv
records are directly in the dnsmasq .conf file which can't be reread
after initial dnsmasq startup. This means that if an srv or txt record
is modified in a net
On Tue, May 31, 2016 at 03:24:50PM +0200, Markus Armbruster wrote:
> Eduardo Habkost writes:
>
> > On Mon, May 30, 2016 at 11:33:38AM +0200, Markus Armbruster wrote:
> [...]
> >> The new members encode an answer to the question whether a certain CPU
> >> usable with the current machine an acceler
On Tue, May 31, 2016 at 09:49:45 -0400, John Ferlan wrote:
>
>
> On 05/31/2016 08:10 AM, Peter Krempa wrote:
> > On Fri, May 27, 2016 at 09:57:08 -0400, John Ferlan wrote:
> >> Need to commonalize the code a bit more in order to use a common function
> >> to build the JSON property from either a
From: Derbyshev Dmitry
QEMU reports timestamp along with other memory statistics, but this information
is not saved into domain statistics.
It could be useful to determine if the data reported is fresh or not.
Balloon statistics are not reported in hrf, so no modifications are made in
qemu_moni
On 05/31/2016 08:10 AM, Peter Krempa wrote:
> On Fri, May 27, 2016 at 09:57:08 -0400, John Ferlan wrote:
>> Need to commonalize the code a bit more in order to use a common function
>> to build the JSON property from either a qemuDomainSecretInfoPtr or a
>> virSecretKeyDef
>>
>> Signed-off-by: Jo
On Tue, May 31, 2016 at 09:43:12 -0400, John Ferlan wrote:
>
>
> On 05/31/2016 07:56 AM, Peter Krempa wrote:
> > On Fri, May 27, 2016 at 09:57:07 -0400, John Ferlan wrote:
> >> Move the module from qemu_command.c to virjson.c and rename to
> >> virJSONBuildObjectCommandline.
> >>
> >> Nothing in
On 05/31/2016 07:56 AM, Peter Krempa wrote:
> On Fri, May 27, 2016 at 09:57:07 -0400, John Ferlan wrote:
>> Move the module from qemu_command.c to virjson.c and rename to
>> virJSONBuildObjectCommandline.
>>
>> Nothing in the API is "specific" to the qemuBuild* processing and it'll
>> be useful t
On Sat, May 28, 2016 at 09:55:12 -0400, John Ferlan wrote:
> Rather than inline code secret lookup for rbd/iscsi, use the common function.
>
> Signed-off-by: John Ferlan
> ---
> This just makes the iscsi/rbd storage driver use the common function...
> work that was started by pkrempa in commit
On Fri, May 27, 2016 at 17:45:15 +0200, Ján Tomko wrote:
> Remove the live attribute and mark the definition as transient
> whether the domain is runing or not.
>
> There were only two callers left calling with live=false:
> * testDomainStartState, where the domain already is active
> because we
Eduardo Habkost writes:
> On Mon, May 30, 2016 at 11:33:38AM +0200, Markus Armbruster wrote:
[...]
>> The new members encode an answer to the question whether a certain CPU
>> usable with the current machine an accelerator, and if no, why.
>> The possible answers are:
>>
>> (1) Don't know.
>> (2
On Fri, May 27, 2016 at 17:45:14 +0200, Ján Tomko wrote:
> Calling virDomainObjSetDefTransient with live=false is a no-op
> on an inactive domain.
>
> Only call it on an active domain, since this is the only place using
> the live bool.
> ---
> src/conf/domain_conf.c | 3 ++-
> 1 file changed, 2
On Fri, May 27, 2016 at 17:45:13 +0200, Ján Tomko wrote:
> Commit 45ec297d from November 2010:
> Make state driver device hotplug/update actually transient
> added virDomainObjSetDefTransient calls to the domain startup
> function in several drivers.
>
> In November 2011, commit 8866eed:
>
On Fri, May 06, 2016 at 12:30:27PM +0100, Daniel P. Berrange wrote:
On Fri, May 06, 2016 at 01:27:15PM +0200, Pavel Hrdina wrote:
On Thu, May 05, 2016 at 07:18:51PM -0400, John Ferlan wrote:
[...]
> Been sitting on list for a while
>
> Obviously I think you know you have to update to top
On Fri, May 27, 2016 at 09:57:08 -0400, John Ferlan wrote:
> Need to commonalize the code a bit more in order to use a common function
> to build the JSON property from either a qemuDomainSecretInfoPtr or a
> virSecretKeyDef
>
> Signed-off-by: John Ferlan
> ---
> src/qemu/qemu_command.c | 65
>
On Fri, Apr 29, 2016 at 08:52:50AM +0200, Peter Krempa wrote:
On Thu, Apr 28, 2016 at 16:56:55 +0200, Martin Kletzander wrote:
This option allows or disallows detection of zero-writes if it is set to
"on" or "off", respectively. It can be also set to "unmap" in which
case it will try discarding
On Fri, May 27, 2016 at 09:57:09 -0400, John Ferlan wrote:
> Move the function to secret_util.c and rename to virSecretBuildObjectProps.
> This then can be shared with impending storage backend changes that will
> need to build up a secret object to pass to qemu-img.
This should be squashed with t
On 31.05.2016 13:48, Peter Krempa wrote:
> On Tue, May 31, 2016 at 13:32:50 +0200, Michal Privoznik wrote:
>> On 31.05.2016 13:10, Peter Krempa wrote:
>>> On Tue, May 31, 2016 at 13:05:16 +0200, Michal Privoznik wrote:
On 31.05.2016 12:52, Peter Krempa wrote:
> On Tue, May 31, 2016 at 12:3
On Mon, May 30, 2016 at 11:33:38AM +0200, Markus Armbruster wrote:
> Eduardo Habkost writes:
>
> > Just noticed that I hadn't replied to this yet. Sorry for the
> > long delay!
> >
> > On Thu, May 12, 2016 at 09:46:25AM +0200, Markus Armbruster wrote:
> >> Eduardo Habkost writes:
> > [...]
> >>
On Fri, May 27, 2016 at 09:57:07 -0400, John Ferlan wrote:
> Move the module from qemu_command.c to virjson.c and rename to
> virJSONBuildObjectCommandline.
>
> Nothing in the API is "specific" to the qemuBuild* processing and it'll
> be useful to "share" with upcoming changes in the storage_backe
On Tue, May 31, 2016 at 13:32:50 +0200, Michal Privoznik wrote:
> On 31.05.2016 13:10, Peter Krempa wrote:
> > On Tue, May 31, 2016 at 13:05:16 +0200, Michal Privoznik wrote:
> >> On 31.05.2016 12:52, Peter Krempa wrote:
> >>> On Tue, May 31, 2016 at 12:33:26 +0200, Michal Privoznik wrote:
> A
On Tue, May 31, 2016 at 12:55:06 +0200, Peter Krempa wrote:
> On Tue, May 31, 2016 at 12:33:33 +0200, Michal Privoznik wrote:
> > Gcc fails to see that virDomainChrGetDomainPtrsInternal always
> > sets pointers to a non NULL value (except for
> > chr device type VIR_DOMAIN_CHR_DEVICE_TYPE_LAST whic
On 31.05.2016 13:10, Peter Krempa wrote:
> On Tue, May 31, 2016 at 13:05:16 +0200, Michal Privoznik wrote:
>> On 31.05.2016 12:52, Peter Krempa wrote:
>>> On Tue, May 31, 2016 at 12:33:26 +0200, Michal Privoznik wrote:
As unlikely as it might seem, func passed to this function can
return
On Tue, May 31, 2016 at 13:17:30 +0200, Michal Privoznik wrote:
> On 31.05.2016 13:06, Peter Krempa wrote:
> > On Tue, May 31, 2016 at 12:33:25 +0200, Michal Privoznik wrote:
> >> It may happen, that this function would dereference a NULL
> >> pointer:
> >>
> >> util/virnetdevbridge.c: In function
On Tue, May 31, 2016 at 12:33:27 +0200, Michal Privoznik wrote:
> So the idea is as follows: firstly we obtain a list of all the
> luns, then iterate over it trying to find the one we want to work
> with and after all the iterations we detect whether we have found
> something. Now, the last check i
On 31.05.2016 13:06, Peter Krempa wrote:
> On Tue, May 31, 2016 at 12:33:25 +0200, Michal Privoznik wrote:
>> It may happen, that this function would dereference a NULL
>> pointer:
>>
>> util/virnetdevbridge.c: In function 'virNetDevBridgeGetVlanFiltering':
>> util/virnetdevbridge.c:199:23: error:
On Tue, May 31, 2016 at 13:05:16 +0200, Michal Privoznik wrote:
> On 31.05.2016 12:52, Peter Krempa wrote:
> > On Tue, May 31, 2016 at 12:33:26 +0200, Michal Privoznik wrote:
> >> As unlikely as it might seem, func passed to this function can
> >> return NULL. And in some cases it indeed does so:
>
On Tue, May 31, 2016 at 12:33:25 +0200, Michal Privoznik wrote:
> It may happen, that this function would dereference a NULL
> pointer:
>
> util/virnetdevbridge.c: In function 'virNetDevBridgeGetVlanFiltering':
> util/virnetdevbridge.c:199:23: error: null pointer dereference
> [-Werror=null-deref
On 31.05.2016 12:52, Peter Krempa wrote:
> On Tue, May 31, 2016 at 12:33:26 +0200, Michal Privoznik wrote:
>> As unlikely as it might seem, func passed to this function can
>> return NULL. And in some cases it indeed does so:
>> virDomainDefGetVcpuSched and virDomainDefGetIOThreadSched.
>> However,
On Tue, May 31, 2016 at 12:33:28 +0200, Michal Privoznik wrote:
> There is no way for a guest_model to be NULL. But gcc fails to
> see that.
>
> cpu/cpu_ppc64.c: In function 'ppc64Compute':
> cpu/cpu_ppc64.c:620:27: error: potential null pointer dereference
> [-Werror=null-dereference]
> if
On Tue, May 31, 2016 at 12:33:33 +0200, Michal Privoznik wrote:
> Gcc fails to see that virDomainChrGetDomainPtrsInternal always
> sets pointers to a non NULL value (except for
> chr device type VIR_DOMAIN_CHR_DEVICE_TYPE_LAST which if occurs,
> we are in way bigger problem than NULL deref).
>
> I
On Tue, May 31, 2016 at 12:33:30 +0200, Michal Privoznik wrote:
> There's a bug in the function. We expect the following format for
> the data we are parsing here:
>
> key: value
>
> So we use strchr() to find ':' and then see if it is followed by
> space. Well, the condition which checks that
On Tue, May 31, 2016 at 12:33:26 +0200, Michal Privoznik wrote:
> As unlikely as it might seem, func passed to this function can
> return NULL. And in some cases it indeed does so:
> virDomainDefGetVcpuSched and virDomainDefGetIOThreadSched.
> However, the function I'm fixing blindly dereference va
Gcc fails to see that virDomainChrGetDomainPtrsInternal always
sets pointers to a non NULL value (except for
chr device type VIR_DOMAIN_CHR_DEVICE_TYPE_LAST which if occurs,
we are in way bigger problem than NULL deref).
In file included from conf/domain_conf.c:37:0:
conf/domain_conf.c: In functio
As unlikely as it might seem, func passed to this function can
return NULL. And in some cases it indeed does so:
virDomainDefGetVcpuSched and virDomainDefGetIOThreadSched.
However, the function I'm fixing blindly dereference value func
returned thus leading to SIGSEGV.
conf/domain_conf.c: In funct
There's a bug in the function. We expect the following format for
the data we are parsing here:
key: value
So we use strchr() to find ':' and then see if it is followed by
space. Well, the condition which checks that - we got it wrong.
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_monito
There is no way for a guest_model to be NULL. But gcc fails to
see that.
cpu/cpu_ppc64.c: In function 'ppc64Compute':
cpu/cpu_ppc64.c:620:27: error: potential null pointer dereference
[-Werror=null-dereference]
if (STRNEQ(guest_model->name, host_model->name)) {
~~~^~~
So the idea is as follows: firstly we obtain a list of all the
luns, then iterate over it trying to find the one we want to work
with and after all the iterations we detect whether we have found
something. Now, the last check is broken, because it compares a
value form previous iteration, not the o
Gcc fails to see that virDomainChrGetDomainPtrsInternal always
sets pointers to a non NULL value (except for
chr device type VIR_DOMAIN_CHR_DEVICE_TYPE_LAST which if occurs,
we are in way bigger problem than NULL deref).
In file included from conf/domain_conf.c:37:0:
conf/domain_conf.c: In functio
There's a bug in the function. We expect the following format for
the data we are parsing here:
key: value
So we use strchr() to find ':' and then see if it is followed by
space. Well, the condition which checks that - we got it wrong.
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_monito
Hopefully.
Michal Privoznik (6):
virNetDevBridgeGet: Avoid NULL dereference
virDomainFormatSchedDef: Handle case when func returns NULL
esxStorageVolGetXMLDesc: Lookup SCSI lun properly
qemuMonitorTextGetAllBlockStatsInfo: Fix line validation
ppc64Compute: Avoid false positive
domain_c
It may happen, that this function would dereference a NULL
pointer:
util/virnetdevbridge.c: In function 'virNetDevBridgeGetVlanFiltering':
util/virnetdevbridge.c:199:23: error: null pointer dereference
[-Werror=null-dereference]
ifr->ifr_data = (char*)&args;
~~^~
There is no way for a guest_model to be NULL. But gcc fails to
see that.
cpu/cpu_ppc64.c: In function 'ppc64Compute':
cpu/cpu_ppc64.c:620:27: error: potential null pointer dereference
[-Werror=null-dereference]
if (STRNEQ(guest_model->name, host_model->name)) {
~~~^~~
So the idea is as follows: firstly we obtain a list of all the
luns, then iterate over it trying to find the one we want to work
with and after all the iterations we detect whether we have found
something. Now, the last check is broken, because it compares a
value form previous iteration, not the o
Signed-off-by: Nikolay Shirokovskiy
---
src/vz/vz_sdk.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/vz/vz_sdk.c b/src/vz/vz_sdk.c
index 7eb78ca..d5e0746 100644
--- a/src/vz/vz_sdk.c
+++ b/src/vz/vz_sdk.c
@@ -888,6 +888,7 @@ prlsdkGetSerialInfo(PRL_HANDLE serialPort,
virDomainChr
Nikolay Shirokovskiy (2):
vz: add mode of unix socket serial device to xml dump
vz: add tcp and udp serial device support
src/vz/vz_sdk.c | 111
1 file changed, 96 insertions(+), 15 deletions(-)
--
1.8.3.1
--
libvir-list mailing list
vz supports only a subset of tcp and udp parameters.
1. tcp type supports only 'raw' protocol.
2. udp type supports only same parameters of 'host' and 'service'
for 'bind' and 'connect'.
Signed-off-by: Nikolay Shirokovskiy
---
src/vz/vz_sdk.c | 108 ++
On 31.05.2016 10:56, Daniel P. Berrange wrote:
> On Thu, May 26, 2016 at 06:01:03PM +0200, Michal Privoznik wrote:
>> Two public constants are to be introduced in libvirt. While
>> touching that are of code, update documentation to a constant
>> of the same origin.
>>
>> Michal Privoznik (2):
>>
On Thu, May 26, 2016 at 06:01:03PM +0200, Michal Privoznik wrote:
> Two public constants are to be introduced in libvirt. While
> touching that are of code, update documentation to a constant
> of the same origin.
>
> Michal Privoznik (2):
> Add PERF_PARAM_MBML and PERF_PARAM_MBMT constants
>
On 11/05/16 16:12, Daniel P. Berrange wrote:
> The logging framework has categories which can be selectively
> enabled/disabled by setting a suitable LIBVIRT_LOG_FILTERS
> environment variable or config file setting.
>
> Along side that we also have the LIBVIRT_DEBUG environment
> variable which u
On Mon, May 23, 2016 at 11:20:19AM -0400, Cole Robinson wrote:
> On 05/20/2016 01:16 PM, Daniel P. Berrange wrote:
> > On Fri, May 20, 2016 at 10:27:03AM -0400, Cole Robinson wrote:
> >> It's currently broken:
> >>
> >> Could not connect to the database: Can't connect to local MySQL server
> >>
76 matches
Mail list logo
