This commit implements the function qemuAgentGetHostname() that uses the
QEMU command 'guest-get-host-name' to retrieve the guest hostname of
Virtual Machine. It is a possibility where QEMU-GA is running.
Signed-off-by: Julio Faracco
---
src/qemu/qemu_agent.c | 39
This commit add the support to use the function qemuAgentGetHostname() for
obtain the domain hostname using QEMU-GA command.
Signed-off-by: Julio Faracco
---
src/qemu/qemu_driver.c | 41 +
1 file changed, 41 insertions(+)
diff --git
This serie adds a new function into QEMU Guest Agent handlers to use
the QEMU command 'guest-get-host-name' to retrieve the domain hostname.
This approach requires QEMU-GA running inside the guest, but it is the
fastest and easiest way to get this info.
Julio Faracco (2):
qemu: implementing
https://bugzilla.redhat.com/show_bug.cgi?id=1613746
When shrinking the capacity of a qcow2 or luks volume using
the qemu-img program, the --shrink qualifier must be added.
Signed-off-by: John Ferlan
---
src/storage/storage_util.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
On 08/14/2018 07:19 AM, Michal Privoznik wrote:
> Fortunately, we have qemu wrappers so it's sufficient to put
> lock/unlock call only there.
>
Kind of sparse... Maybe a few words related to what benefit locking the
metadata provides. There is a danger in all this too if the unlock does
fail
On Fri, Aug 17, 2018 at 07:59:40PM +0200, Paolo Bonzini wrote:
> On 17/08/2018 19:48, Eduardo Habkost wrote:
> > So let's do what's necessary to remove it. But I don't think the
> > removal of "feature-words" should block the inclusion of this
> > series.
> >
> > Now, should QOM properties
On 17/08/2018 19:48, Eduardo Habkost wrote:
> So let's do what's necessary to remove it. But I don't think the
> removal of "feature-words" should block the inclusion of this
> series.
>
> Now, should QOM properties follow our feature deprecation policy,
> or they were never a supported external
On 08/14/2018 07:19 AM, Michal Privoznik wrote:
> In order for our drivers to lock resources for metadata change we
> need set of new APIs. Fortunately, we don't have to care about
> every possible device a domain can have. We care only about those
> which can live on a network filesystem and
On Fri, Aug 17, 2018 at 07:34:13PM +0200, Paolo Bonzini wrote:
> On 17/08/2018 17:55, Eduardo Habkost wrote:
> >> The names will be X86_CPU_FEATURE_WORD_TYPE_CPUID and
> >> X86_CPU_FEATURE_WORD_TYPE_MSR.
> > I wouldn't like to make this an external API unless really
> > necessary. I would rather
On Tue, 2018-08-07 at 17:10 +0800, Yi Min Zhao wrote:
> Abstract
>
> The PCI representation in QEMU has recently been extended for S390
> allowing configuration of zPCI attributes like uid (user-defined
> identifier) and fid (PCI function identifier).
> The details can be found here:
>
On Tue, 2018-08-07 at 17:10 +0800, Yi Min Zhao wrote:
[...]
> +
> +
> + qemu: Added support for PCI device passthrough on S390
> +
> +
> + The new zPCI attributes uid (user-defined identifier)
> + and fid (PCI function identifier) of the
On Tue, 2018-08-07 at 17:10 +0800, Yi Min Zhao wrote:
[...]
> +have multiple functions used. (Since 4.7.0
> +), PCI address extensions depending on the architecture
> +are supported. E.g. for S390 guests, PCI addresses have
> +additional attributes: uid (a hex value
Quoting Jiri Denemark (2018-07-13 10:14:22)
> On Mon, Jul 09, 2018 at 22:56:53 -0500, Chris Venteicher wrote:
> > Commit makes starting a single persistent QEMU instance possible for use
> > over multiple independent QMP commands without starting and stopping
> > QEMU for each QMP command or
On Tue, 2018-08-07 at 17:10 +0800, Yi Min Zhao wrote:
> This commit adds hotplug support for PCI devices on S390 guests.
> There's no need to implement hot unplug for zPCI as QEMU implements
> an unplug callback which will unplug both PCI and zPCI device in a
> cascaded way.
It looks like you
On 08/14/2018 07:19 AM, Michal Privoznik wrote:
> No real support implemented here. But hey, at least we will not
> fail.
>
> Signed-off-by: Michal Privoznik
> ---
> src/locking/lock_driver_sanlock.c | 25 ++---
> 1 file changed, 18 insertions(+), 7 deletions(-)
>
> diff
On Thu, Aug 16, 2018 at 12:35:17 +0200, Erik Skultety wrote:
> So the procedure to detect SEV support works like this:
> 1) we detect that sev-guest is among the QOM types and set the cap flag
> 2) we probe the monitor for SEV support
> - this is tricky, because QEMU with compiled SEV support
Provide some examples and scenarios.
Signed-off-by: Andrea Bolognani
---
guests/README.markdown | 19 +++
1 file changed, 19 insertions(+)
diff --git a/guests/README.markdown b/guests/README.markdown
index ddf0149..870619e 100644
--- a/guests/README.markdown
+++
Signed-off-by: Andrea Bolognani
---
guests/lcitool | 4
1 file changed, 4 insertions(+)
diff --git a/guests/lcitool b/guests/lcitool
index e0410f3..2901a92 100755
--- a/guests/lcitool
+++ b/guests/lcitool
@@ -323,6 +323,7 @@ class Application:
common actions:
Signed-off-by: Andrea Bolognani
---
guests/lcitool | 87 ++
1 file changed, 45 insertions(+), 42 deletions(-)
diff --git a/guests/lcitool b/guests/lcitool
index f28199d..e0410f3 100755
--- a/guests/lcitool
+++ b/guests/lcitool
@@ -351,6 +351,50 @@
These tasks mirror the Jenkins jobs contained in the
top-level jobs/ directory.
Signed-off-by: Andrea Bolognani
---
.../build/jobs/autotools-build-job.yml| 15
.../build/jobs/autotools-check-job.yml| 16 +
.../build/jobs/autotools-rpm-job.yml | 17
These tasks mirror the Jenkins projects contained in the
top-level projects/ directory.
Signed-off-by: Andrea Bolognani
---
guests/playbooks/build/projects/libosinfo.yml | 36 +
.../playbooks/build/projects/libvirt-cim.yml | 10
.../playbooks/build/projects/libvirt-dbus.yml |
Instead of defining a default and overriding it on a
case-by-case basis, always define archive_format at the
project level.
This adds a bit of duplication, but it's consistent with
how we define other metadata for projects and it will
help us out later.
Signed-off-by: Andrea Bolognani
---
Changes from [v1]:
* rebase on top of master (985ab833be9b) and integrate recent
changes to build rules on the Jenkins side;
* build on more targets.
[v1] https://www.redhat.com/archives/libvir-list/2018-August/msg00393.html
Andrea Bolognani (13):
projects: Add default machines for
The pipe syntax is intended for multi-line preformatted
text, and is abused here. Use a saner syntax instead.
Signed-off-by: Andrea Bolognani
---
jobs/defaults.yaml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/jobs/defaults.yaml b/jobs/defaults.yaml
index
This doesn't change the results but brings it more in line
with how other projects are defined and will help us out
later.
Signed-off-by: Andrea Bolognani
---
projects/libvirt-dbus.yaml | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git
This playbook represent the entry point for automated
builds, and follows the same calling conventions as the
existing update playbook.
Signed-off-by: Andrea Bolognani
---
guests/playbooks/build/main.yml | 16
1 file changed, 16 insertions(+)
create mode 100644
The Jenkins build jobs can only run on the subset of
guests that are available on CentOS CI, but when we're
running build jobs through lcitool we don't have that
limitation and we can build on more targets.
Signed-off-by: Andrea Bolognani
---
guests/playbooks/build/jobs/defaults.yml
Building master is useful for CI purposes and to debug CI
failures locally, but when developing we want to be able
to build a personal branch to validate in-progress changes.
Signed-off-by: Andrea Bolognani
---
guests/lcitool | 30
The affected parameters are autogen_args, command and
command_pre_build.
Moving their default value next to the other overridable
defaults makes sense, and it will help us out later.
Signed-off-by: Andrea Bolognani
---
jobs/autotools.yaml| 1 -
jobs/defaults.yaml | 3 +++
Other user-defined variables use underscores as
separator instead of dashes; this change will also
help us out later.
Signed-off-by: Andrea Bolognani
---
jobs/autotools.yaml | 2 +-
jobs/generic.yaml | 2 +-
jobs/go.yaml | 2 +-
jobs/perl-modulebuild.yaml
On Fri, 2018-08-17 at 11:43 +0100, Daniel P. Berrangé wrote:
> On Fri, Aug 17, 2018 at 12:35:11PM +0200, Andrea Bolognani wrote:
> > If we decide we want to explicitly spell out the options instead
> > of relying on QEMU changing behavior based on the slot type, which
> > is probably a good idea
Andrea Bolognani (2):
conf: Rename some device_conf predicates
conf: Move some device_conf predicates
src/bhyve/bhyve_device.c | 6 ++--
src/conf/device_conf.c | 22 ++
src/conf/device_conf.h | 23 ++-
src/conf/domain_addr.c | 2 +-
The affected functions are
virDeviceInfoPCIAddressWanted()
virDeviceInfoPCIAddressPresent()
which get renamed to
virDeviceInfoPCIAddressIsWanted()
virDeviceInfoPCIAddressIsPresent()
to comply with the naming convention used for other
predicates.
Signed-off-by: Andrea Bolognani
---
Turn
virPCIDeviceAddressIsEmpty()
virDeviceInfoPCIAddressIsWanted()
virDeviceInfoPCIAddressIsPresent()
from inline functions to regular functions.
Signed-off-by: Andrea Bolognani
---
src/conf/device_conf.c | 22 ++
src/conf/device_conf.h | 23
On Fri, Aug 17, 2018 at 03:13:22PM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé writes:
>
> > On Fri, Aug 17, 2018 at 12:35:11PM +0200, Andrea Bolognani wrote:
> >> On Fri, 2018-08-17 at 10:29 +0100, Daniel P. Berrangé wrote:
> >> > On Thu, Aug 16, 2018 at 06:20:29PM -0400, Laine Stump
Daniel P. Berrangé writes:
> On Fri, Aug 17, 2018 at 12:35:11PM +0200, Andrea Bolognani wrote:
>> On Fri, 2018-08-17 at 10:29 +0100, Daniel P. Berrangé wrote:
>> > On Thu, Aug 16, 2018 at 06:20:29PM -0400, Laine Stump wrote:
>> > > 5) Some guest OSes that we still want to support (and which
On 08/17/2018 05:40 AM, Michal Privoznik wrote:
> On 08/16/2018 05:22 PM, John Ferlan wrote:
>>
>>
>> On 08/13/2018 06:49 AM, Michal Privoznik wrote:
>>> Currently the way virStorageVolWipe() works is it looks up
>>> pool containing given volume and hold it locked throughout while
>>> API
On Mon, Aug 13, 2018 at 06:00:35PM +0200, Peter Krempa wrote:
Add code paths which call into the new functions to gather the data on a
per-node-name basis and tweak the aliases used for extracting the data.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_driver.c | 54
On Mon, Aug 13, 2018 at 06:00:34PM +0200, Peter Krempa wrote:
Use the 'qdev' instead of the disk alias to lookup the stats and
transfer the capacity from the appropriate node name so that the
function works with -blockdev.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_driver.c | 48
On Mon, Aug 13, 2018 at 06:00:36PM +0200, Peter Krempa wrote:
'query-blockstats' did not report the 'qdev' field prior to fixing it so
that it works with our setup. Use that as a witness to enable -blockdev
Note that the blockjobs were NOT adapted yet so any blockjob will desync
the state of
On Mon, Aug 13, 2018 at 06:00:33PM +0200, Peter Krempa wrote:
Switch to using the QOM/qdev handles in all calls to
qemuMonitorGetBlockInfo when using -blockdev. The callers also need to
make sure to use the correct handle afterwards to extract the data.
Signed-off-by: Peter Krempa
---
On Mon, Aug 13, 2018 at 06:00:32PM +0200, Peter Krempa wrote:
With -blockdev qemu will not report any useful "device" for the data
returned by 'query-block'. We need to start using the 'qdev' field to do
so in cases when "device" is empty or it does not match the entry name.
This patch adds
On Mon, Aug 13, 2018 at 06:00:31PM +0200, Peter Krempa wrote:
Data relevant for the storage of a backing chain member will need to be
reported separately when switching to blockdev. Prepare a function that
extracts the appropriate data.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_driver.c |
On Mon, Aug 13, 2018 at 06:00:30PM +0200, Peter Krempa wrote:
When reporting stats for the backing chain some of them make sense only
for the topmost entry as they are actually tied to the frontend device.
We unfortunately can't change that fact, but we can stop reporting all
zero stats for the
On Mon, Aug 13, 2018 at 06:00:29PM +0200, Peter Krempa wrote:
Signed-off-by: Peter Krempa
---
src/qemu/qemu_driver.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
Reviewed-by: Ján Tomko
Jano
signature.asc
Description: Digital signature
--
libvir-list mailing
On Mon, Aug 13, 2018 at 06:00:28PM +0200, Peter Krempa wrote:
While we report the read and written byte stats for every single layer
of the backing chain, qemu in fact reports them only for the frontend.
Split out the relevant stats into a separate function so that we can
later fix this bug and
On Mon, Aug 13, 2018 at 06:00:27PM +0200, Peter Krempa wrote:
Split out the header so that the loop can be refactored later.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_driver.c | 38 --
1 file changed, 28 insertions(+), 10 deletions(-)
diff --git
On Mon, Aug 13, 2018 at 06:00:27PM +0200, Peter Krempa wrote:
Split out the header so that the loop can be refactored later.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_driver.c | 38 --
1 file changed, 28 insertions(+), 10 deletions(-)
Reviewed-by: Ján
On Mon, Aug 13, 2018 at 06:00:26PM +0200, Peter Krempa wrote:
Split out the code which converts the stats gathered in
qemuDomainGetStatsBlock into typed parameters so that it will look
less ugly when extending it.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_driver.c | 73
On Mon, Aug 13, 2018 at 06:00:25PM +0200, Peter Krempa wrote:
In cases when -blockdev is used we need to use 'query-named-block-nodes'
instead of 'query-block'. This means that we can extract the
write-threshold variable right away.
To keep compatibility with old VMs modify the code which was
On Fri, Aug 17, 2018 at 12:35:11PM +0200, Andrea Bolognani wrote:
> On Fri, 2018-08-17 at 10:29 +0100, Daniel P. Berrangé wrote:
> > On Thu, Aug 16, 2018 at 06:20:29PM -0400, Laine Stump wrote:
> > > 5) Some guest OSes that we still want to support (and which would
> > > otherwise work okay on a
On Fri, 2018-08-17 at 10:29 +0100, Daniel P. Berrangé wrote:
> On Thu, Aug 16, 2018 at 06:20:29PM -0400, Laine Stump wrote:
> > 5) Some guest OSes that we still want to support (and which would
> > otherwise work okay on a Q35 virtual machine) have virtio drivers too
> > old to support virtio-1.0
On 08/16/2018 05:22 PM, John Ferlan wrote:
>
>
> On 08/13/2018 06:49 AM, Michal Privoznik wrote:
>> Currently the way virStorageVolWipe() works is it looks up
>> pool containing given volume and hold it locked throughout while
>> API execution. This is suboptimal because wiping a volume means
>>
On Thu, Aug 16, 2018 at 06:20:29PM -0400, Laine Stump wrote:
> Summary of the problem:
>
> 1) We want to persuade libvirt+QEMU users to move away from the i440fx
> machinetype in favor of Q35. (NB: Someday this *might* lead to the
> ability to deprecate and even remove the 440fx machinetype, but
On Thu, Aug 16, 2018 at 23:03:40 +0300, Povilas Kanapickas wrote:
> On 16/08/2018 10:38, Peter Krempa wrote:
> > To fix this you should record the backing format [1] into your overlay
> > image. If we'd relax the code we'd face the regression in the security
> > fix we've done.
> >
> > [1]
On Thu, 2018-08-16 at 17:01 +0200, Cornelia Huck wrote:
> On Thu, 16 Aug 2018 16:52:18 +0200 Andrea Bolognani
> wrote:
> > On Tue, 2018-08-07 at 17:10 +0800, Yi Min Zhao wrote:
> > > @@ -3227,6 +3227,7 @@ qemuDomainDefAddDefaultDevices(virDomainDefPtr def,
> > > case VIR_ARCH_S390X:
> > >
On Fri, 2018-08-17 at 08:35 +0200, Boris Fiuczynski wrote:
> On 08/16/2018 06:31 PM, Andrea Bolognani wrote:
> > Another thing that I forgot to ask earlier and this is as good a
> > time as any: once zPCI support has been merged, will users have
> > to opt-in to it using
> >
> >
> >
> > or
On Fri, 2018-08-17 at 06:41 +0200, Bjoern Walk wrote:
> Andrea Bolognani [2018-08-16, 04:44PM +0200]:
> > On Tue, 2018-08-07 at 17:10 +0800, Yi Min Zhao wrote:
> > > +case VIR_DOMAIN_DEVICE_NONE:
> > > +case VIR_DOMAIN_DEVICE_LAST:
> >
> > Missing 'default' case.
>
> I thought we
On 08/17/2018 09:14 AM, Peter Krempa wrote:
> commit 5c81c342a7 forgot to skip the detaching of the shmem backend
> when async unplug is requested which meant that we've tried to unplug
> the backend prior to delivery of the DEVICE_DELETED event.
>
> Resolves:
commit 5c81c342a7 forgot to skip the detaching of the shmem backend
when async unplug is requested which meant that we've tried to unplug
the backend prior to delivery of the DEVICE_DELETED event.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1618622
Signed-off-by: Peter Krempa
---
Hi,
> b) Rather than a "legacy-only" model for virtio-0.9, it would be more
> useful to have "transitional". This way the config would work for older
> OSes that don't support virtio-1.0, and when/if the OS was upgraded such
> that it supported virtio-1.0, that would be automatically used
On 08/16/2018 06:31 PM, Andrea Bolognani wrote:
Another thing that I forgot to ask earlier and this is as good a
time as any: once zPCI support has been merged, will users have
to opt-in to it using
or will they get zPCI devices by default? And if so, will it still
be possible for them to
62 matches
Mail list logo
