Ping..
Pulling the questions at the top.
>> Will libvirt report 'description' RO attribute, its output would be
>> string, so that user could be able to see the configuration of that
>> profile?
>>
>
> Daniel,
> Waiting for your input on this.
>
>> We can have 'class' as optional attribute. So In
https://bugzilla.redhat.com/show_bug.cgi?id=1349898
Add the duration parameters to the virsh input/output for blkdeviotune
command and describe them in the pod file.
Signed-off-by: John Ferlan
---
tools/virsh-domain.c | 55
tools/virsh.pod
Rework the repetitive lines to add iotune values into easier to read macro
Signed-off-by: John Ferlan
---
tools/virsh-domain.c | 141 +--
1 file changed, 25 insertions(+), 116 deletions(-)
diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
i
Since persistent_def is the only place that uses it, let's just keep
it closer to where it's used.
Signed-off-by: John Ferlan
---
src/qemu/qemu_driver.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 3ce3f
Modify _virDomainBlockIoTuneInfo and rng schema to support the _length
options for bps/iops throttling values. Document the new values.
Signed-off-by: John Ferlan
---
docs/formatdomain.html.in | 40 -
docs/schemas/domaincommon.rng | 38 ++
Add the capability to detect if the qemu binary can support the feature
to use bps-max-length and friends.
Signed-off-by: John Ferlan
---
src/qemu/qemu_capabilities.c| 2 ++
src/qemu/qemu_capabilities.h| 1 +
tests/qemucapabilitiesdata/caps
This patch will also adjust the qemuMonitorJSONSetBlockIoThrottle error
procession so that rather than returning/displaying:
"error: internal error: Unexpected error"
Fetch the actual error message from qemu and display that
Signed-off-by: John Ferlan
---
src/qemu/qemu_monitor_json.c | 14
Add support for a duration/length for the bps/iops and friends.
Modify the API in order to add the "blkdeviotune." specific definitions
for the iotune throttling duration/length options
total_bytes_sec_max_length
write_bytes_sec_max_length
read_bytes_sec_max_length
total_iops_sec_
Create a helper to set the bytes/iops iotune default values based on
the current qemu setting
Signed-off-by: John Ferlan
---
src/qemu/qemu_driver.c | 66 ++
1 file changed, 40 insertions(+), 26 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/sr
Add new options to allow proving a duration/length in seconds to allow the
bps/iops (and friends) to occur:
total_bytes_sec_max_length
write_bytes_sec_max_length
read_bytes_sec_max_length
total_iops_sec_max_length
write_iops_sec_max_length
read_iops_sec_max_length
Add cont
Add in the block I/O throttling length/duration parameter to the command
line if supported. If not supported, fail command creation.
Add the xml2argvtest for testing.
Signed-off-by: John Ferlan
---
src/qemu/qemu_command.c| 21 +
.../qemuxml2argv-blkdeviot
Rather than repeat the lines in the persistent def, use the same helper
to set config values.
This also fixes a bug where config values for *_max and size_iops_sec would
be set back to 0 if a config value was set.
Signed-off-by: John Ferlan
---
src/qemu/qemu_driver.c | 15 +++
1 fil
Create a macros to hide all the comparisons for each of the fields.
Add a 'continue;' for a compiler hint that we only need to find one
this should be similar enough to the if - elseif - elseif logic.
Signed-off-by: John Ferlan
---
src/qemu/qemu_driver.c | 153 +++---
v1: http://www.redhat.com/archives/libvir-list/2016-September/msg01090.html
Differences since v1:
Patches 1-5 are new...
Patch 1 is essentially the former patch 8.5 added after initial review
based on a review comment. Erik Skultety and I went back and forth
on this one a few times
On 10/06/2016 10:06 AM, Kashyap Chamarthy wrote:
> On Thu, Oct 06, 2016 at 09:25:26AM -0500, Eric Blake wrote:
>> On 10/06/2016 06:34 AM, Peter Krempa wrote:
>
> [...]
>
>>> We expose the state of the copy job in the XML and forward the READY
>>> event from qemu to the users.
>>
>> I was not awar
On Tue, 2016-09-20 at 15:14 -0400, Laine Stump wrote:
> The nec-usb-xhci device (which is a USB3 controller) has always
> presented itself as a PCI device when plugged into a legacy PCI slot,
> and a PCIe device when plugged into a PCIe slot, but libvirt has
> always auto-assigned it to a PCI slot.
Commit 660468b1 forgot to add it, so let's add it now to prevent future linker
issues.
Signed-off-by: Erik Skultety
---
Pushed under trivial rule
src/libvirt_private.syms | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index c4af57d..923af
On 10/06/2016 10:25 AM, Eric Blake wrote:
On 10/06/2016 06:34 AM, Peter Krempa wrote:
Currently libvirt block APIs (& consequently higher-level applications
like Nova which use these APIs) rely on polling for job completion via
libvirt is _not_ polling the data. Libvirt relies on the events
Martin Kletzander writes ("Re: [OSSTEST PATCH 2/2] libvirt: Do not attempt
save/restore when migration not advertised"):
> Well then, unfortunately you do.
>
> Also, looking at how the code is structured, if you have live migration
> but don't have save/restore, you won't have there
> at all.
R
On 10/06/2016 11:20 AM, Richard W.M. Jones wrote:
On Thu, Oct 06, 2016 at 10:00:39AM -0400, Laine Stump wrote:
* x 4 - a set of USB2
controllers. This will turn into a single USB3 controller on a
root-port after my patches. Alternately, since it seems you don't
use it, you could eliminate it wi
On Thu, 2016-10-06 at 12:04 -0400, Laine Stump wrote:
> > Since now you're using info exclusively inside this block,
> > you can move its declaration here as well.
>
> Except that patch 19/18 uses it too (it was that patch that led to me
> re-doing this one and posting a v3.5)
Nevermind then :)
On Thu, 2016-10-06 at 11:57 -0400, Laine Stump wrote:
> (BTW, isn't there something wrt aarch64 about "no pci controllers in
> config means use mmio for devices", or something like that? (Or maybe we
> were just *thinking* about that and didn't actually do it, I don't
> remember). Using the lack
On Thu, Oct 06, 2016 at 11:57:17AM -0400, Laine Stump wrote:
> On 10/06/2016 11:31 AM, Daniel P. Berrange wrote:
> > On Thu, Oct 06, 2016 at 12:58:51PM +0200, Andrea Bolognani wrote:
> > > On Wed, 2016-10-05 at 18:36 +0100, Richard W.M. Jones wrote:
> > > > > > (b) It would be nice to turn the whol
On 10/06/2016 11:39 AM, Andrea Bolognani wrote:
On Thu, 2016-09-29 at 10:14 -0400, Laine Stump wrote:
Andrea had the right idea when he disabled the "reserve an extra
unused slot" bit for aarch64/virt. For *any* PCI Express-based
machine, it is pointless since 1) an extra legacy-PCI slot can't b
On 10/06/2016 11:31 AM, Daniel P. Berrange wrote:
On Thu, Oct 06, 2016 at 12:58:51PM +0200, Andrea Bolognani wrote:
On Wed, 2016-10-05 at 18:36 +0100, Richard W.M. Jones wrote:
(b) It would be nice to turn the whole thing off for people who don't
care about / need hotplugging.
I had contempl
On Thu, Oct 06, 2016 at 05:18:11PM +0200, Pavel Hrdina wrote:
> On Thu, Oct 06, 2016 at 04:58:40PM +0200, Michal Privoznik wrote:
> > Pids are signed, report them as such.
> >
> > Before:
> > Detected mount/mapping 2:cpuset at /sys/fs/cgroup/cpuset in
> > /machine/qemu-4-fedora.libvirt-qemu/vcpu0
On Thu, 2016-09-29 at 10:14 -0400, Laine Stump wrote:
> Andrea had the right idea when he disabled the "reserve an extra
> unused slot" bit for aarch64/virt. For *any* PCI Express-based
> machine, it is pointless since 1) an extra legacy-PCI slot can't be
> used for hotplug, since hotplug into lega
On Thu, Oct 06, 2016 at 12:58:51PM +0200, Andrea Bolognani wrote:
> On Wed, 2016-10-05 at 18:36 +0100, Richard W.M. Jones wrote:
> > > > (b) It would be nice to turn the whole thing off for people who don't
> > > > care about / need hotplugging.
> > >
> > > I had contemplated having an "availableP
On Thu, Oct 06, 2016 at 10:00:39AM -0400, Laine Stump wrote:
> * x 4 - a set of USB2
> controllers. This will turn into a single USB3 controller on a
> root-port after my patches. Alternately, since it seems you don't
> use it, you could eliminate it with:
Yup, this is auto-added, and a mistake.
On Thu, Oct 06, 2016 at 04:58:40PM +0200, Michal Privoznik wrote:
> Pids are signed, report them as such.
>
> Before:
> Detected mount/mapping 2:cpuset at /sys/fs/cgroup/cpuset in
> /machine/qemu-4-fedora.libvirt-qemu/vcpu0 for pid 18446744073709551615
>
> After:
> Detected mount/mapping 2:cpuse
On Thu, Oct 06, 2016 at 09:25:26AM -0500, Eric Blake wrote:
> On 10/06/2016 06:34 AM, Peter Krempa wrote:
[...]
> > We expose the state of the copy job in the XML and forward the READY
> > event from qemu to the users.
>
> I was not aware of that when I was chatting on IRC yesterday; that's
> us
Pids are signed, report them as such.
Before:
Detected mount/mapping 2:cpuset at /sys/fs/cgroup/cpuset in
/machine/qemu-4-fedora.libvirt-qemu/vcpu0 for pid 18446744073709551615
After:
Detected mount/mapping 2:cpuset at /sys/fs/cgroup/cpuset in
/machine/qemu-4-fedora.libvirt-qemu/vcpu0 for pid -
On 10/06/2016 06:34 AM, Peter Krempa wrote:
>> Currently libvirt block APIs (& consequently higher-level applications
>> like Nova which use these APIs) rely on polling for job completion via
>
> libvirt is _not_ polling the data. Libvirt relies on the events from
> qemu which are also exposed as
On Tue, 2016-09-20 at 15:14 -0400, Laine Stump wrote:
> The e1000e is an emulated network device based on the Intel 82574,
> present in qemu 2.7.0 and later. Among other differences from the
> e1000, it presents itself as a PCIe device rather than legacy PCI. In
> order to get it assigned to a PCIe
On 28.09.2016 13:43, Chen Hanxiao wrote:
> From: Chen Hanxiao
>
> Add pid of VM in domain log.
> We used to show this info in debug log.
>
> For example:
> If a process send SIGKILL to a qemu process,
> we could find something in audit logs.
> Then the pid of VM in domain log will be helpful.
>
On Thu, Oct 06, 2016 at 04:29:46PM +0200, Michal Privoznik wrote:
> On 28.09.2016 13:43, Chen Hanxiao wrote:
> > From: Chen Hanxiao
> >
> > Add pid of VM in domain log.
> > We used to show this info in debug log.
> >
> > For example:
> > If a process send SIGKILL to a qemu process,
> > we could
On 10/06/2016 10:13 AM, Andrea Bolognani wrote:
On Tue, 2016-09-20 at 15:14 -0400, Laine Stump wrote:
libvirt previously assigned nearly all devices to a "hotpluggable"
legacy PCI slot even on machines with a PCIe root bus (and even though
most such machines don't even support hotplug on legacy
On Tue, 2016-09-20 at 15:14 -0400, Laine Stump wrote:
> libvirt previously assigned nearly all devices to a "hotpluggable"
> legacy PCI slot even on machines with a PCIe root bus (and even though
> most such machines don't even support hotplug on legacy PCI slots!)
> Forcing all devices onto legacy
On 06.10.2016 13:30, Andrea Bolognani wrote:
> This was needed for RHEL 4 vintage distributions, which we
> haven't supported for a long time now.
> ---
> m4/virt-pkgconfig-back-compat.m4 | 23 ---
> 1 file changed, 23 deletions(-)
> delete mode 100644 m4/virt-pkgconfig-back-c
On 10/06/2016 06:58 AM, Andrea Bolognani wrote:
On Wed, 2016-10-05 at 18:36 +0100, Richard W.M. Jones wrote:
(b) It would be nice to turn the whole thing off for people who don't
care about / need hotplugging.
I had contemplated having an "availablePCIeSlots" (or something like
that) that wa
There's no need to reinvent the wheel here. We already have a
function to format virDomainChrSourceDefPtr. It's called
qemuBuildChrChardevStr(). Use that instead of some dummy
virBufferAsprintf().
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_command.c | 16 +---
1 file changed,
https://bugzilla.redhat.com/show_bug.cgi?id=1366505
So far, this function lacked support for
VIR_DOMAIN_NET_TYPE_VHOSTUSER leaving callers to hack around the
problem by constructing the command line on their own. This is
not ideal as it blocks hot plug support.
Signed-off-by: Michal Privoznik
--
Currently, what we do for vhost-user network is generate the
following part of command line:
-netdev type=vhost-user,id=hostnet0,chardev=charnet0
There's no need for 'type=' it is the default. Drop it.
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_command.c
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_command.c | 34 +++---
1 file changed, 27 insertions(+), 7 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 5ca82ec..cc3b24f 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_com
The idea is to have function that does some checking of the
arguments at its beginning and then have one big switch for all
the interface types it supports. Each one of them generating the
corresponding part of the command line.
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_command.c
The idea is to have function that does some checking of the
arguments at its beginning and then have one big switch for all
the interface types it supports. Each one of them generating the
corresponding part of the command line.
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_command.c
Instead of blindly claim support for hot-plugging of every
interface type out there we should copy approach we have for
device types: white listing supported types and explicitly error
out on unsupported ones.
For instance, trying to hotplug vhostuser interface results in
nothing usable from guest
This alone makes not much sense. But the aim is to reuse this
function in qemuBuildVhostuserCommandLine() where 'nowait' is not
supported for vhost-user devices.
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_command.c | 35 +++
1 file changed, 19 insertions(+)
https://bugzilla.redhat.com/show_bug.cgi?id=1366108
There are couple of things that needs to be done in order to
allow vhost-user hotplug. Firstly, vhost-user requires a chardev
which is connected to vhost-user bridge and through which qemu
communicates with the bridge (no acutal guest traffic is
Instead of various NULL arguments, we can pass proper qemu driver
config, log manager, and virCommand.
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_command.c | 31 ++-
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/q
The idea is to have function that does some checking at its
beginning and then have one big switch for all the interface
types it supports.
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_hotplug.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a
v2 of:
https://www.redhat.com/archives/libvir-list/2016-August/msg00806.html
The first patches are mostly code movement and cleanups.
diff to v1:
- Hopefully all John's review suggestions are worked in now
Michal Privoznik (14):
virDomainNetDefParseXML: Realign
virDomainNetGetActualType: Re
We tend to prevent using 'default' in switches. And it is for a
good reason - control may end up in paths we wouldn't want for
new values. In this specific case, if qemuBuildHostNetStr is
called over VIR_DOMAIN_NET_TYPE_VHOSTUSER it would produce
meaningless output. Fortunately, there no such call
There are couple of formatting issues. No functional change
though.
Signed-off-by: Michal Privoznik
---
src/conf/domain_conf.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index f562323..8f04e6f 100644
--- a/src/conf/
This function for some weird reason returns integer instead of
virDomainNetType type. It is important to return the correct type
so that we know what values we can expect.
Signed-off-by: Michal Privoznik
---
src/bhyve/bhyve_command.c | 2 +-
src/bhyve/bhyve_process.c | 2 +-
src/conf/domain_co
On Tue, 2016-09-20 at 15:14 -0400, Laine Stump wrote:
> Before now, all the qemu hotplug functions assumed that all devices to
> be hotplugged were legacy PCI endpoint devices
> (VIR_PCI_CONNECT_TYPE_PCI_DEVICE). This worked out "okay", because all
> devices *are* legacy PCI endpoint devices on x86
On Thu, Oct 06, 2016 at 01:34:59PM +0200, Peter Krempa wrote:
> On Thu, Oct 06, 2016 at 12:26:50 +0200, Kashyap Chamarthy wrote:
[...]
> > And, libvirt was fixed to use the above field in this commit (available
> > in libvirt v1.2.18 or above):
> >
> > http://libvirt.org/git/?p=libvirt.git;a
On Wed, Oct 05, 2016 at 07:28:00PM +0300, Marko Myllynen wrote:
Hi,
FYI, I've written a PCP plugin (PMDA in PCP parlance) to support most
hypervisor / domain information and metrics available over the libvirt
Python API, it's up to date as of libvirt 2.3 (so it already supports
the recently adde
On Thu, Oct 06, 2016 at 12:26:50 +0200, Kashyap Chamarthy wrote:
> Backround
> -
>
> For QEMU block device jobs, the "ready" boolean field (part of QMP
> `query-block-jobs`) was introduced in commit ef6dbf1 (available in QEMU
> v2.2.0 or above):
>
> http://git.qemu.org/?p=qemu.git;a=c
This was needed for RHEL 4 vintage distributions, which we
haven't supported for a long time now.
---
m4/virt-pkgconfig-back-compat.m4 | 23 ---
1 file changed, 23 deletions(-)
delete mode 100644 m4/virt-pkgconfig-back-compat.m4
diff --git a/m4/virt-pkgconfig-back-compat.m4 b
On Thu, Oct 06, 2016 at 03:58:54PM +1100, Sam Bobroff wrote:
On Tue, Oct 04, 2016 at 11:28:15AM +0200, Martin Kletzander wrote:
On Tue, Oct 04, 2016 at 02:34:57PM +1100, Sam Bobroff wrote:
>On Mon, Oct 03, 2016 at 04:27:25PM +0200, Martin Kletzander wrote:
>>On Mon, Aug 01, 2016 at 02:01:22PM +1
On Thu, 2016-10-06 at 11:32 +0200, Martin Kletzander wrote:
> Running the output of qemu -help doesn't make any sense. We should be
> looking for libvirt being mentioned in the output. This worked by
> accident, let's make it work as expected it to.
>
> Signed-off-by: Martin Kletzander
> ---
>
On Wed, 2016-10-05 at 18:36 +0100, Richard W.M. Jones wrote:
> > > (b) It would be nice to turn the whole thing off for people who don't
> > > care about / need hotplugging.
> >
> > I had contemplated having an "availablePCIeSlots" (or something like
> > that) that was either an attribute of the c
On 10/06/2016 06:42 AM, Erik Skultety wrote:
> On 21/09/16 21:14, John Ferlan wrote:
>>
>>
>> On 08/18/2016 07:47 AM, Erik Skultety wrote:
>>> Since virLogParseAndDefineOutputs is going to be stripped from 'output
>>> defining'
>>> logic, replace all relevant occurrences with virLogSetOutputs ca
On 21/09/16 21:39, John Ferlan wrote:
>
>
> On 08/18/2016 07:47 AM, Erik Skultety wrote:
>> This is mainly virLogAddOutputTo* which were replaced by virLogNewOutputTo*
>> and
>> the previously poorly named ones virLogParseAndDefine* functions. All of
>> these
>> are unnecessary now, since all t
On 21/09/16 21:14, John Ferlan wrote:
>
>
> On 08/18/2016 07:47 AM, Erik Skultety wrote:
>> Since virLogParseAndDefineOutputs is going to be stripped from 'output
>> defining'
>> logic, replace all relevant occurrences with virLogSetOutputs call to make
>> the
>> change transparent to all origi
On Thu, Oct 06, 2016 at 10:59:06AM +0100, Ian Jackson wrote:
Martin Kletzander writes ("Re: [OSSTEST PATCH 2/2] libvirt: Do not attempt
save/restore when migration not advertised"):
Since offline migration (as in migrating a domain between hosts without
being running) is not that used in the co
>> +
>> +VIR_DEBUG("outputs=%s", src);
>> +
>> +if (!(strings = virStringSplit(src, " ", 0)))
>
> You could use the Count version and then...
>
>> +goto cleanup;
>> +
>> +for (i = 0; strings[i]; i++) {
>
> ...rather than strings[i], it's < count
Well, this way we spared one
Backround
-
For QEMU block device jobs, the "ready" boolean field (part of QMP
`query-block-jobs`) was introduced in commit ef6dbf1 (available in QEMU
v2.2.0 or above):
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=ef6dbf1e4 --
blockjob: Add "ready" field
"When a block job s
Julien Grall writes ("Re: [OSSTEST PATCH 1/2] libvirt: Check migration
capabilities using proper XML parser"):
> On 04/10/2016 10:05, Ian Jackson wrote:
> > Missing _. I didn't test this again before sending it. I'd still
> > like a review from libvirt (and Xen/ARM) folks.
>
> I am not sure wha
Martin Kletzander writes ("Re: [OSSTEST PATCH 2/2] libvirt: Do not attempt
save/restore when migration not advertised"):
> Since offline migration (as in migrating a domain between hosts without
> being running) is not that used in the code and talked about, I'm
> guessing offline means save resto
On Wed, Oct 05, 2016 at 06:06:29PM -0600, Jim Fehlig wrote:
On 10/04/2016 11:02 AM, Ian Jackson wrote:
Currently, osstest wrongly thinks that ARM can do save/restore,
because `virsh help' does mention the save command (on all
architectures).
Additionally, check the virth capabilities xpath
/
Running the output of qemu -help doesn't make any sense. We should be
looking for libvirt being mentioned in the output. This worked by
accident, let's make it work as expected it to.
Signed-off-by: Martin Kletzander
---
m4/virt-yajl.m4 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
di
On 06/10/16 09:57, Michal Privoznik wrote:
> On 05.10.2016 09:26, Jiri Denemark wrote:
>> GCC complained that
>>
>> vsh.c: In function 'vshReadlineOptionsGenerator':
>> vsh.c:2622:29: warning: unused variable 'opt' [-Wunused-variable]
>> const vshCmdOptDef *opt = &cmd->opts[list_index];
>>
On 21/09/16 22:01, John Ferlan wrote:
>
>
> On 08/18/2016 07:47 AM, Erik Skultety wrote:
>> Handling of outputs and filters has been changed in a way that splits
>> parsing and defining. Do the same thing for logging priority as well, this
>> however, doesn't need much of a preparation.
>> ---
>>
On 06.10.2016 11:01, Jiri Denemark wrote:
> On Wed, Oct 05, 2016 at 16:52:10 +0300, Nikolay Shirokovskiy wrote:
>> ---
>> src/qemu/qemu_blockjob.c | 13 +++--
>> src/qemu/qemu_blockjob.h | 3 ++-
>> src/qemu/qemu_domain.h | 1 +
>> src/qemu/qemu_driver.c | 4 ++--
>
On Wed, Oct 05, 2016 at 09:37:52AM +0200, Christophe Fergeau wrote:
> hey,
>
> On Tue, Oct 04, 2016 at 04:30:14PM +0100, Daniel P. Berrange wrote:
> > > +
> > > +/**
> > > + * gvir_config_domain_graphics_listen_address_get_inet_address:
> > > + *
> > > + * Returns the #GInetAddress associated with
On 06.10.2016 11:02, Peter Krempa wrote:
> On Wed, Oct 05, 2016 at 16:52:09 +0300, Nikolay Shirokovskiy wrote:
>> BLOCK_JOB_COMPLETED has error field set on error from day one (12bd451f)
>> thus there is no need to guess for error. Is it true that when
>> len == offset then can be no error?
>
>
On Wed, Oct 05, 2016 at 16:52:09 +0300, Nikolay Shirokovskiy wrote:
> BLOCK_JOB_COMPLETED has error field set on error from day one (12bd451f)
> thus there is no need to guess for error. Is it true that when
> len == offset then can be no error?
That is the question you should be able to answer wh
On Wed, Oct 05, 2016 at 16:52:10 +0300, Nikolay Shirokovskiy wrote:
> ---
> src/qemu/qemu_blockjob.c | 13 +++--
> src/qemu/qemu_blockjob.h | 3 ++-
> src/qemu/qemu_domain.h | 1 +
> src/qemu/qemu_driver.c | 4 ++--
> src/qemu/qemu_migration.c| 34 +++
On 05.10.2016 09:26, Jiri Denemark wrote:
> GCC complained that
>
> vsh.c: In function 'vshReadlineOptionsGenerator':
> vsh.c:2622:29: warning: unused variable 'opt' [-Wunused-variable]
> const vshCmdOptDef *opt = &cmd->opts[list_index];
> ^
> vsh.c: In functi
On 06.10.2016 10:29, Peter Krempa wrote:
> On Thu, Oct 06, 2016 at 10:23:05 +0300, Nikolay Shirokovskiy wrote:
>>
>>
>> On 05.10.2016 18:13, Peter Krempa wrote:
>>> On Mon, Sep 12, 2016 at 17:34:39 +0300, Nikolay Shirokovskiy wrote:
Hi, all.
In case migration fails due to destina
On Thu, Oct 06, 2016 at 10:23:05 +0300, Nikolay Shirokovskiy wrote:
>
>
> On 05.10.2016 18:13, Peter Krempa wrote:
> > On Mon, Sep 12, 2016 at 17:34:39 +0300, Nikolay Shirokovskiy wrote:
> >> Hi, all.
> >>
> >> In case migration fails due to destination qemu exits unexpectedly user
> >> recevie
On Thu, Oct 06, 2016 at 10:23:05 +0300, Nikolay Shirokovskiy wrote:
>
>
> On 05.10.2016 18:13, Peter Krempa wrote:
> > On Mon, Sep 12, 2016 at 17:34:39 +0300, Nikolay Shirokovskiy wrote:
> >> Hi, all.
> >>
> >> In case migration fails due to destination qemu exits unexpectedly user
> >> recevie
On 05.10.2016 17:36, Jiri Denemark wrote:
> On Wed, Oct 05, 2016 at 16:52:08 +0300, Nikolay Shirokovskiy wrote:
>> ---
>> src/qemu/qemu_monitor_json.c | 6 ++
>> 1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c
>>
On 05.10.2016 18:13, Peter Krempa wrote:
> On Mon, Sep 12, 2016 at 17:34:39 +0300, Nikolay Shirokovskiy wrote:
>> Hi, all.
>>
>> In case migration fails due to destination qemu exits unexpectedly user
>> recevies the qemu log in the error message. Unfortunately log is truncated
>> and
>> the m
On 05.10.2016 18:08, Peter Krempa wrote:
> On Mon, Sep 12, 2016 at 17:34:42 +0300, Nikolay Shirokovskiy wrote:
>
> This is a pretty big change but you did not write anything to describe
> or justify it.
>
>> ---
>> src/logging/log_handler.c | 38 --
>> src/
On 29.09.2016 16:35, John Ferlan wrote:
[...]
>> --- a/src/qemu/qemu_driver.c
>> +++ b/src/qemu/qemu_driver.c
>> @@ -1478,13 +1478,17 @@ qemuDomainHelperGetVcpus(virDomainObjPtr vm,
>> virDomainVcpuDefPtr vcpu = virDomainDefGetVcpu(vm->def, i);
>> pid_t vcpupid = qemuDomainGetVcpu
On Wed, Oct 05, 2016 at 09:38:16 -0400, John Ferlan wrote:
> On 09/27/2016 12:39 PM, Peter Krempa wrote:
> > Until now the test was rather useless since it didn't check the
> > arguments formatted and didn't use properly configured chardev objects.
> >
> > Add the expected arguments and instrument
On 29.09.2016 16:34, John Ferlan wrote:
[...]
>> --- a/src/qemu/qemu_domain.c
>> +++ b/src/qemu/qemu_domain.c
>> @@ -5956,6 +5956,75 @@ qemuDomainRefreshVcpuInfo(virQEMUDriverPtr driver,
>> return ret;
>> }
>>
>> +/**
>> + * qemuDomainGetVcpuHalted:
>> + * @vm: domain object
>> + * @vcpu: c
90 matches
Mail list logo
