[libvirt] [PATCH] spec: Update version check for maint Source URL

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

Re: [libvirt] RFE: virsh list improvement (--description and --details)

> 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. >> >>

Re: [libvirt] [PATCH v3 1/5] hyperv: Functions to work with invocation parameters.

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

Re: [libvirt] [PATCH v2 20/38] Introduce VIR_NET_STREAM_SKIP message type

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

Re: [libvirt] [PATCH v2 19/38] RPC: Introduce virNetStreamSkip

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

Re: [libvirt] [PATCH v2 18/38] Track if stream is skippable

$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

Re: [libvirt] [PATCH v2 17/38] virNetClientStreamNew: Track origin stream

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 > ---

Re: [libvirt] [PATCH v2 16/38] Introduce virStreamInData

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

Re: [libvirt] [PATCH v2 15/38] Introduce virStreamSparseSendAll

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.

Re: [libvirt] [PATCH v2 14/38] Introduce virStreamSparseRecvAll

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

Re: [libvirt] [PATCH v2 13/38] Introduce VIR_STREAM_RECV_STOP_AT_HOLE flag

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

Re: [libvirt] [PATCH v2 12/38] Introduce virStreamHoleSize

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

Re: [libvirt] [PATCH v2 11/38] Introduce virStreamSkip

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

Re: [libvirt] [PATCH v2 10/38] Implement virStreamRecvFlags to some drivers

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

Re: [libvirt] [PATCH v2 09/38] Introduce virStreamRecvFlags

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 >

Re: [libvirt] [PATCH go-xml] add support for domain features

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

Re: [libvirt] [PATCH] mdev: Cleanup code after commits @daf5081b and @2739a983

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

Re: [libvirt] [PATCH] virNWFilterObjListFree: Don't leak nwfilters->objs

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

[libvirt] [PATCH] virNWFilterObjListFree: Don't leak nwfilters->objs

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

Re: [libvirt] RFE: virsh list improvement (--description and --details)

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

Re: [libvirt] RFE: virsh list improvement (--description and --details)

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.

[libvirt] [PATCH] mdev: Cleanup code after commits @daf5081b and @2739a983

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

Re: [libvirt] [PATCH] virPerfEventIsEnabled: Accept NULL @perf

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

Re: [libvirt] [PATCH] virPerfEventIsEnabled: Accept NULL @perf

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

Re: [libvirt] Availability of Candidate Release 2 of libvirt-3.3.0

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: >> >>

[libvirt] [PATCH] virPerfEventIsEnabled: Accept NULL @perf

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

Re: [libvirt] [PATCH] mdev: Fix mingw build by adding a check for non-NULL pointer

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

Re: [libvirt] Raising limits for our RPC messages

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

Re: [libvirt] Raising limits for our RPC messages

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

Re: [libvirt] Raising limits for our RPC messages

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

Re: [libvirt] Raising limits for our RPC messages

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

Re: [libvirt] Raising limits for our RPC messages

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 >

Re: [libvirt] Availability of Candidate Release 2 of libvirt-3.3.0

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

Re: [libvirt] Raising limits for our RPC messages

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. >

Re: [libvirt] [PATCH] mdev: Fix mingw build by adding a check for non-NULL pointer

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 >

[libvirt] Raising limits for our RPC messages

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

[libvirt] [PATCH] mdev: Fix mingw build by adding a check for non-NULL pointer

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 =

Re: [libvirt] [PATCH 3/2] news: Add even more v3.3.0 entries

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

Re: [libvirt] 答复: Re: [PATCH] qemu: change the name of tap device for a tapand bridge network

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.

Re: [libvirt] [PATCH v2 08/38] util: Introduce virFileInData

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

Re: [libvirt] [PATCH 2/2] mdev: Fix daemon crash on domain shutdown after reconnect

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