New maint release version numbers of just A.B.C format, not the old
A.B.C.D format. Adjust the check that dynamically changes the Source
URL for maint releases
---
libvirt.spec.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index
> On 4 May 2017, at 17:03, Michal Privoznik wrote:
>> 2. Please add new columns to virsh list (for —details):
>> a) CPUs
>> b) MaxMem
>> c) Flags: p-persistent, t-transient, a-autostart, m-managed save, s-with
>> snapshot(s)
>> and total sum for column vCPUs and Mem.
>>
>>
On Mon, May 1, 2017 at 6:25 PM, Matthias Bolte
wrote:
>
> 2017-04-24 20:19 GMT+02:00 Sri Ramanujam :
> > This commit introduces functionality for creating and working with
> > invoke parameters. This commit does not include any code for
On 04/20/2017 06:01 AM, Michal Privoznik wrote:
> This is a special type of stream packet, that is bidirectional
> and will contain information on how much bytes are both sides
"...how many bytes both sides are..."
> skipping in the stream.
>
> Signed-off-by: Michal Privoznik
On 04/20/2017 06:01 AM, Michal Privoznik wrote:
> This is going to be RPC representation for virStreamSkip.
>
> Signed-off-by: Michal Privoznik
> ---
> src/rpc/virnetprotocol.x | 4
> src/virnetprotocol-structs | 3 +++
> 2 files changed, 7 insertions(+)
>
As you
$subj:
Add new flag to daemonCreateClientStream and virNetClientStreamNew
FWIW:
Kind of a big hit, but neither skippable nor skipable passes muster with
spell check. How about using "allowSkip" for the name.
On 04/20/2017 06:01 AM, Michal Privoznik wrote:
> Even though there's no way to make
On 04/20/2017 06:01 AM, Michal Privoznik wrote:
> This has no real added value right now,
> but is going to be very helpful later.
Add a virStreamPtr pointer to the _virNetClientStream in order to
reverse track the parent stream.
>
> Signed-off-by: Michal Privoznik
> ---
On 04/20/2017 06:01 AM, Michal Privoznik wrote:
> This is just an internal API, that calls corresponding function
s/API,/API (e.g. no need for the comma)
s/calls/calls the/
> in stream driver. This function will set @data=1 if the
s/in/in the/
> underlying file is in data section, or
On 04/20/2017 06:01 AM, Michal Privoznik wrote:
> This is just a wrapper over new function that have been just
> introduced: virStreamSkip() . It's very similar to
> virStreamSendAll() except it handles sparse streams well.
You could have some changes here due to previous API name changes.
On 04/20/2017 06:01 AM, Michal Privoznik wrote:
> This is just a wrapper over new functions that have been just
> introduced: virStreamRecvFlags(), virStreamHoleSize(). It's very
> similar to virStreamRecvAll() except it handles sparse streams
> well.
You could have some API name adjustments
On 04/20/2017 06:01 AM, Michal Privoznik wrote:
> This flag is for virStreamRecvFlags API. Its purpose is to stop
> reading from the stream if a hole occurred as holes are to be
> threated separately.
Consider:
Add a new flag to virStreamRecvFlags in order to handle being able to
stop reading
On 04/20/2017 06:01 AM, Michal Privoznik wrote:
> This function is basically a counterpart for virStreamSkip. If
> one side of a stream called virStreamSkip() the other should call
s/should/would need to/
> virStreamHoleSize() to get the size of the hole.
>
> Signed-off-by: Michal Privoznik
On 04/20/2017 06:01 AM, Michal Privoznik wrote:
> This API can be used to tell the other side of the stream to skip
s/can be/is (unless it can be used for something else ;-))
> some bytes in the stream. This can be used to create a sparse
> file on the receiving side of a stream.
>
> It
On 04/20/2017 06:01 AM, Michal Privoznik wrote:
> We have three virStreamDriver-s currently in our tree.
> virFDStream, remote driver and ESX driver.f or now, support for
> remote driver and ESX driver is sufficient, because
> implementation for virFDStream is going to be supplied later as
> it
On 04/20/2017 06:01 AM, Michal Privoznik wrote:
> Although we already have virStreamRecv, just like some other
> older APIs it is missing @flags argument. This means, the
> function is not that flexible and therefore we need
> virStreamRecvFlags. The latter is going to be needed when we will
>
ping, ref <
https://www.redhat.com/archives/libvir-list/2017-April/msg01073.html>
On Thu, Apr 27, 2017 at 12:35 PM, Ryan Goodfellow wrote:
> Hi Daniel,
>
> I have addressed the issues you brought up in the commit titled 'remove
> superfluous state & omitempty entries' that has
On 05/04/2017 11:03 AM, Erik Skultety wrote:
> So, because mingw is somehow OK with dereferencing a pointer within a
> VIR_DEBUG macro, compared to outside of it to which it complained with a
> "potential NULL pointer dereference" error (still a false positive), we
> can make the code a tiny bit
On 05/04/2017 11:42 AM, Michal Privoznik wrote:
> When adding a nwfilter onto the list in
> virNWFilterObjListAssignDef() this array is re-allocated to match
> demand for new size. However, it is never freed leading to a
> leak:
>
> ==26535== 136 bytes in 1 blocks are definitely lost in loss
When adding a nwfilter onto the list in
virNWFilterObjListAssignDef() this array is re-allocated to match
demand for new size. However, it is never freed leading to a
leak:
==26535== 136 bytes in 1 blocks are definitely lost in loss record 1,079 of
1,250
==26535==at 0x4C2E2BE: realloc
On Thu, May 04, 2017 at 17:03:00 +0200, Michal Privoznik wrote:
> On 05/03/2017 01:48 PM, Przemysław Sztoch wrote:
> > Hello,
> >
> > 1. Please add —description parameter to virsh list command. It should be
> > similar to —title.
> > It will be very helpful for administrators who like to leave
On 05/03/2017 01:48 PM, Przemysław Sztoch wrote:
> Hello,
>
> 1. Please add —description parameter to virsh list command. It should be
> similar to —title.
> It will be very helpful for administrators who like to leave the order and
> documentation after their work.
Yeah, this one makes sense.
So, because mingw is somehow OK with dereferencing a pointer within a
VIR_DEBUG macro, compared to outside of it to which it complained with a
"potential NULL pointer dereference" error (still a false positive), we
can make the code a tiny bit cleaner.
Sighed-by: Erik Skultety
On 05/04/2017 04:41 PM, Daniel P. Berrange wrote:
> On Thu, May 04, 2017 at 04:32:50PM +0200, Michal Privoznik wrote:
>> After bdcf6e481 there is a crasher in libvirt. The commit assumes
>> that priv->perf is always set. That is not true. For inactive
>> domains, the priv->perf is not allocated as
On Thu, May 04, 2017 at 04:32:50PM +0200, Michal Privoznik wrote:
> After bdcf6e481 there is a crasher in libvirt. The commit assumes
> that priv->perf is always set. That is not true. For inactive
> domains, the priv->perf is not allocated as it is set in
> qemuProcessLaunch(). Now, usually we
On 05/04/2017 01:55 PM, Michal Privoznik wrote:
> On 05/03/2017 05:02 PM, Daniel Veillard wrote:
>>
>> Due to some Red Hat Summit event, I got severely distracted yesterday and
>> forgot to tag RC2, this is now done, there is signed tarball and rpms at
>> the usual place:
>>
>>
After bdcf6e481 there is a crasher in libvirt. The commit assumes
that priv->perf is always set. That is not true. For inactive
domains, the priv->perf is not allocated as it is set in
qemuProcessLaunch(). Now, usually we differentiate between
accesses to inactive and active definition and it
On Thu, May 04, 2017 at 01:41:19PM +0200, Peter Krempa wrote:
> On Thu, May 04, 2017 at 13:32:35 +0200, Erik Skultety wrote:
> > This patch fixes the following MinGW error (although actually being a
> > false positive):
> >
> > ../../src/util/virmdev.c: In function
On Thu, May 04, 2017 at 03:04:33PM +0300, Vasiliy Tolstov wrote:
> 2017-05-04 15:01 GMT+03:00 Daniel P. Berrange :
> > That doesn't really help memory usage, as you still have todo the XDR
> > encode step to create the data that you then feed to the compressor.
> > It only
On 05/04/2017 02:04 PM, Vasiliy Tolstov wrote:
> 2017-05-04 15:01 GMT+03:00 Daniel P. Berrange :
>> That doesn't really help memory usage, as you still have todo the XDR
>> encode step to create the data that you then feed to the compressor.
>> It only saves on amount of data
2017-05-04 15:01 GMT+03:00 Daniel P. Berrange :
> That doesn't really help memory usage, as you still have todo the XDR
> encode step to create the data that you then feed to the compressor.
> It only saves on amount of data going over the wire, at the cost of
> burning CPU
On Thu, May 04, 2017 at 02:55:26PM +0300, Vasiliy Tolstov wrote:
> 2017-05-04 14:49 GMT+03:00 Daniel P. Berrange :
> >
> > So I think it is reasonable to simply increase the buffer size as
> > we have done before.
> >
> > That said, we should bear this problem in mind before
2017-05-04 14:49 GMT+03:00 Daniel P. Berrange :
>
> So I think it is reasonable to simply increase the buffer size as
> we have done before.
>
> That said, we should bear this problem in mind before adding more
> "bulk query" APIs, as it isn't sensible to carry on increasing
>
On 05/03/2017 05:02 PM, Daniel Veillard wrote:
>
> Due to some Red Hat Summit event, I got severely distracted yesterday and
> forgot to tag RC2, this is now done, there is signed tarball and rpms at
> the usual place:
>
>ftp://libvirt.org/libvirt/
>
>
> Things seems to look fine, there
On Thu, May 04, 2017 at 01:39:17PM +0200, Michal Privoznik wrote:
> Dear list,
>
> maybe you've seen us raising limit for various parts of RPC messages
> (for eaxmple: d15b29be, 66bfc7cc61ca0, e914dcfd, etc.). It usually
> happens when we receive a report that current limits are not enough.
>
On Thu, May 04, 2017 at 13:32:35 +0200, Erik Skultety wrote:
> This patch fixes the following MinGW error (although actually being a
> false positive):
>
> ../../src/util/virmdev.c: In function 'virMediatedDeviceListMarkDevices':
> ../../src/util/virmdev.c:453:21: error: potential null pointer
>
Dear list,
maybe you've seen us raising limit for various parts of RPC messages
(for eaxmple: d15b29be, 66bfc7cc61ca0, e914dcfd, etc.). It usually
happens when we receive a report that current limits are not enough.
Well, we just did:
https://bugzilla.redhat.com/show_bug.cgi?id=1440683
The
This patch fixes the following MinGW error (although actually being a
false positive):
../../src/util/virmdev.c: In function 'virMediatedDeviceListMarkDevices':
../../src/util/virmdev.c:453:21: error: potential null pointer
dereference [-Werror=null-dereference]
const char *mdev_path =
On Wed, 2017-05-03 at 18:16 +0200, Ján Tomko wrote:
[...]
> > +
> > + If this step is not performed, when the data length matches the
> > + chunk size the decryption routines will misinterpret the last
> > byte
> > + of data as the padding lenght and fail to
On Thu, May 04, 2017 at 08:28:03AM +0800, lu.zhip...@zte.com.cn wrote:
> I'm worried that the network packet loss rate will increase after
> reversing the order.
I don't see why that is relevant - we're killing the guest or unplugging
the NIC, so there's no traffic being sent on this tap device.
On 05/03/2017 11:13 PM, John Ferlan wrote:
>
>
> On 04/30/2017 02:43 AM, Michal Privoznik wrote:
>> On 04/29/2017 06:46 PM, John Ferlan wrote:
>>>
>>>
>>> On 04/20/2017 06:01 AM, Michal Privoznik wrote:
This function takes a FD and determines whether the current
position is in data
On Wed, May 03, 2017 at 11:25:30AM -0400, Laine Stump wrote:
> On 04/28/2017 03:46 AM, Erik Skultety wrote:
> > The problem resides in virHostdevUpdateActiveMediatedDevices which gets
> > called during qemuProcessReconnect. The issue here is that
> > virMediatedDeviceListAdd takes a pointer to the
41 matches
Mail list logo