On 03/08/2017 06:16 PM, Cedric Bosdonnat wrote:
> Hi all,
>
> I've worked on making the containers rootfs creation easy.
> Here is a wrap-up of my work:
>
> http://bosdonnat.fr/system-container-images.html
>
> Any opinion on that? Anything to do to move it forward?
Awesome. I always felt like p
This series introduce flag VIR_DOMAIN_SAVE_DIRECT
to enable command 'save' to write to PIPE.
This will write QEMU_SAVE_MAGIC directly.
Base upon patches from Roy Keene
with some fixes.
Change from original patch:
1) Check whether the specified path is a PIPE.
2) Rebase on upstream.
3) Add doc fo
From: Chen Hanxiao
Base upon patches from Roy Keene
Currently qemuDomainSaveMemory can save vm's config
and memory to fd.
It write a magic QEMU_SAVE_PARTIAL firstly,
then re-open it to change QEMU_SAVE_PARTIAL as QEMU_SAVE_MAGIC.
For pipes this is not possible, attempting to re-open the pipe
w
From: Chen Hanxiao
Base upon patches from Roy Keene
This patch introduces --direct flag for save command.
We could use this flag to save vm to a PIPE.
We could saving a VM state directly to Ceph RBD images
without having an intermediate file.
How to test:
fifo="$(mktemp -u)"; mkfifo "${fifo}
I'm happy to announce the release of virt-manager 1.4.1!
virt-manager is a desktop application for managing KVM, Xen, and LXC
virtualization via libvirt.
The release can be downloaded from:
http://virt-manager.org/download/
This release includes:
- storage/nodedev event API support (Jovanka Gu
Hi All,
Encountering a qemu monitor timeout when starting a VM has been discussed here
before, e.g.
https://www.redhat.com/archives/libvir-list/2014-January/msg00060.html
https://www.redhat.com/archives/libvir-list/2014-January/msg00408.html
Recently I've received reports of the same when starti
Hello,
Am 08.03.2017 um 17:28 schrieb Martin Kletzander:
> On Wed, Mar 01, 2017 at 08:44:54PM +0100, Philipp Hahn wrote:
>> The documentation is plain wrong about the default write_error policy,
>> as its only implemented by QEMU (src/vz/vz_utils.c is the only other
>> case, which simply explodes,
Rename 'secretUsageType' to 'usageType' since it's superfluous in an
API qemu*Secret*
Signed-off-by: John Ferlan
---
Pushed as trivial - based upon Jirka's review comment from patch 1 of
the "Alter TLS/UUID algorithms to be a bit more generic" series.
src/qemu/qemu_domain.c | 32
On 08.03.2017 18:19, Michal Privoznik wrote:
> ACK, but we really need a better way to detect capabilites. For instance
> now, bhyve binary is executed 4 times just to find out whether it
> supports 4 capabilities. That's just madness. Maybe we can get in touch
> with bhyve developers and ask them?
On Tue, Mar 07, 2017 at 10:59:42AM -0500, Cole Robinson wrote:
> Demonstrates the bug fix in commit 0e5db762627
> ---
> tests/storagevolxml2argvdata/iso-input.argv | 1 +
> tests/storagevolxml2argvdata/iso.argv | 1 +
> tests/storagevolxml2argvtest.c | 7 +++
> tests/stor
On Fri, Dec 16, Daniel P. Berrange wrote:
> The PERF_COUNT_HW_REF_CPU_CYCLES constant is not available
> on all Linux distros libvirt targets, so its use must be
> made conditional. Other constant have existed long enough
> that we can assume they exist, as we don't support very
> old distros like
On 03/08/17 18:12, Daniel P. Berrange wrote:
> On Wed, Mar 08, 2017 at 06:05:02PM +0100, Andrea Bolognani wrote:
>> On Wed, 2017-03-08 at 16:00 +, Daniel P. Berrange wrote:
So far, libvirt has assumed that only x86 supports ACPI,
but that's inaccurate since aarch64 supports it too.
>>
On 03/08/17 18:05, Andrea Bolognani wrote:
> On Wed, 2017-03-08 at 16:00 +, Daniel P. Berrange wrote:
>>> So far, libvirt has assumed that only x86 supports ACPI,
>>> but that's inaccurate since aarch64 supports it too.
>>
>> IIUC, it only supports ACPI if using the AAVMF firmware, right ?
>
On 02/25/2017 02:30 PM, Roman Bogorodskiy wrote:
> Add bhyve support to virt-host-validate(1). It checks for the
> essential kernel modules to be available so that user can actually
> start VMs, have networking and console access.
>
> It uses the kldnext(2)/kldstat(2) routines to retrieve modules
Hi all,
I've worked on making the containers rootfs creation easy.
Here is a wrap-up of my work:
http://bosdonnat.fr/system-container-images.html
Any opinion on that? Anything to do to move it forward?
--
Cedric
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/
On 02/12/2017 04:12 PM, Roman Bogorodskiy wrote:
> From: Fabian Freyer
>
> Allow to boot using UEFI rather than using an external boot loader
> such as bhyveload or grub-bhyve.
>
> Also, make LPC PCI-ISA bridge handling more flexible as now it's
> needed not only for serial ports, but for bootro
On 02/12/2017 04:12 PM, Roman Bogorodskiy wrote:
> Signed-off-by: Roman Bogorodskiy
> ---
> tests/bhyvexml2argvdata/bhyvexml2argv-vnc.args | 12 +++
> tests/bhyvexml2argvdata/bhyvexml2argv-vnc.ldargs | 1 +
> tests/bhyvexml2argvdata/bhyvexml2argv-vnc.xml| 26
>
On 02/12/2017 04:12 PM, Roman Bogorodskiy wrote:
> From: Fabian Freyer
>
> Signed-off-by: Roman Bogorodskiy
> ---
> src/bhyve/bhyve_capabilities.c | 28
> 1 file changed, 28 insertions(+)
>
ACK
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://ww
On 02/12/2017 04:12 PM, Roman Bogorodskiy wrote:
> From: Fabian Freyer
>
> bhyve supports 'gop' video device that allows clients to connect
> to VMs using VNC clients. This commit adds support for that to
> the bhyve driver:
>
> - Introducr 'gop' video device type
> - Add capabilities probing
On 02/12/2017 04:12 PM, Roman Bogorodskiy wrote:
> From: Fabian Freyer
>
> Implement the BHACE_CAP_LPC_BOOTROM capability by checking the stderr
> output of 'bhyve -l bootrom'. If the bootrom option is unsupported, this
> will contain the following output:
>
> bhyve: invalid lpc device confi
On 02/12/2017 04:12 PM, Roman Bogorodskiy wrote:
> From: Fabian Freyer
>
> Signed-off-by: Roman Bogorodskiy
> ---
> tests/bhyvexml2argvdata/bhyvexml2argv-uefi.args | 11 +++
> tests/bhyvexml2argvdata/bhyvexml2argv-uefi.ldargs | 1 +
> tests/bhyvexml2argvdata/bhyvexml2argv-uefi.xml
On Wed, Mar 08, 2017 at 06:05:02PM +0100, Andrea Bolognani wrote:
> On Wed, 2017-03-08 at 16:00 +, Daniel P. Berrange wrote:
> > > So far, libvirt has assumed that only x86 supports ACPI,
> > > but that's inaccurate since aarch64 supports it too.
> >
> > IIUC, it only supports ACPI if using th
On Wed, 2017-03-08 at 16:00 +, Daniel P. Berrange wrote:
> > So far, libvirt has assumed that only x86 supports ACPI,
> > but that's inaccurate since aarch64 supports it too.
>
> IIUC, it only supports ACPI if using the AAVMF firmware, right ?
My current understanding is that ACPI on aarch64
This partially reverts commit c96bd78e4e.
If an API virDomainAttachDevice(Flags) is used the device address
is assigned after the validation and the address type may not be set.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1430275
Signed-off-by: Pavel Hrdina
---
src/conf/domain_conf.c
On 03/05/2017 03:20 PM, Roman Bogorodskiy wrote:
> Even though scsi storage driver builds fine on non-Linux, it
> will not work properly because it relies on Linux procfs, so
> disable that in configure if we're not building for Linux.
> ---
> configure.ac | 1 +
> 1 file changed, 1 insertion(+)
>
On Wed, Mar 01, 2017 at 08:44:54PM +0100, Philipp Hahn wrote:
The documentation is plain wrong about the default write_error policy,
as its only implemented by QEMU (src/vz/vz_utils.c is the only other
case, which simply explodes, is anything except other then
VIR_DOMAIN_DISK_ERROR_POLICY_DEFAULT
On Tue, Mar 07, 2017 at 06:09:58PM +0100, Philipp Hahn wrote:
QEMU should be written all upper or all lower case.
---
v2: Drop docs/news-* as they are historic.
Drop po/*.po files as they are from extern.
ChangeLog-old | 4 ++--
I also dropped this as it's even marked 'old'
On Wed, Mar 08, 2017 at 04:56:30PM +0100, Andrea Bolognani wrote:
> So far, libvirt has assumed that only x86 supports ACPI,
> but that's inaccurate since aarch64 supports it too.
>
> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1429509
> ---
> Advertising ACPI support in capabilities mea
On Wed, Mar 08, 2017 at 04:56:30PM +0100, Andrea Bolognani wrote:
> So far, libvirt has assumed that only x86 supports ACPI,
> but that's inaccurate since aarch64 supports it too.
IIUC, it only supports ACPI if using the AAVMF firmware, right ?
I know that is the preferred firmware for aarch64, b
The capabilities used in test cases should match those used
during normal operation for the tests to make any sense.
---
src/qemu/qemu_capabilities.c | 2 ++
.../qemuxml2argv-balloon-ccw-deflate.args| 1 -
tests/qemuxml2argvdata/qemuxml2argv-console-sc
Posted as RFC due to the concerns outlined in patch 1.
Andrea Bolognani (2):
qemu: Advertise ACPI support for aarch64 guests
tests: Initialize basic capabilities properly
src/qemu/qemu_capabilities.c | 30 +-
.../caps_2.6.0-gicv2.aarch64.xml
So far, libvirt has assumed that only x86 supports ACPI,
but that's inaccurate since aarch64 supports it too.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1429509
---
Advertising ACPI support in capabilities means that tools
such as virt-manager will start automatically adding the
elemen
On Wed, Mar 01, 2017 at 18:30:26 -0500, John Ferlan wrote:
> Split apart and rename qemuDomainGetChardevTLSObjects in order to make a
> more generic API that can create the TLS JSON prop objects (secret and
> tls-creds-x509) to be used to create the objects
>
> Signed-off-by: John Ferlan
> ---
>
On Wed, Mar 01, 2017 at 18:30:25 -0500, John Ferlan wrote:
> Move the call to inside the qemuDomainAddChardevTLSObjects in order to
> further converge the code.
>
> Signed-off-by: John Ferlan
> ---
> src/qemu/qemu_hotplug.c | 31 ---
> 1 file changed, 12 insertions(+)
On Wed, Mar 01, 2017 at 18:30:24 -0500, John Ferlan wrote:
> Move the call to inside the qemuDomainAddChardevTLSObjects in order to
> further converge the code.
>
> Signed-off-by: John Ferlan
> ---
> src/qemu/qemu_hotplug.c | 33 +++--
> 1 file changed, 15 insertions(
On Wed, Mar 01, 2017 at 18:30:23 -0500, John Ferlan wrote:
> Create a qemuDomainAddChardevTLSObjects which will encapsulate the
> qemuDomainGetChardevTLSObjects and qemuDomainAddTLSObjects so that
> the callers don't need to worry about the props.
>
> Move the dev->type and haveTLS checks in to th
On 03/08/2017 03:07 PM, Daniel P. Berrange wrote:
> On Wed, Mar 08, 2017 at 03:09:11PM +, Joao Martins wrote:
>> On 03/08/2017 02:13 PM, Daniel P. Berrange wrote:
>>> On Wed, Mar 08, 2017 at 03:07:12PM +0100, Wim Ten Have wrote:
From: Wim ten Have
This patch enhances host-passth
On Wed, Mar 08, 2017 at 03:09:11PM +, Joao Martins wrote:
> On 03/08/2017 02:13 PM, Daniel P. Berrange wrote:
> > On Wed, Mar 08, 2017 at 03:07:12PM +0100, Wim Ten Have wrote:
> >> From: Wim ten Have
> >>
> >> This patch enhances host-passthrough capability to advertise the
> >> required vendo
On 03/08/2017 02:13 PM, Daniel P. Berrange wrote:
> On Wed, Mar 08, 2017 at 03:07:12PM +0100, Wim Ten Have wrote:
>> From: Wim ten Have
>>
>> This patch enhances host-passthrough capability to advertise the
>> required vendor CPU virtualization feature which will be used to
>> enable 'nestedhvm' i
On Wed, Mar 01, 2017 at 18:30:22 -0500, John Ferlan wrote:
> Refactor the TLS object adding code to make two separate API's that will
> handle the add/remove of the "secret" and "tls-creds-x509" objects including
> the Enter/Exit monitor commands.
>
> Signed-off-by: John Ferlan
> ---
> src/qemu/
On Wed, Mar 08, 2017 at 10:48:15AM +0100, Michal Privoznik wrote:
On 03/08/2017 10:15 AM, Martin Kletzander wrote:
On Mon, Mar 06, 2017 at 08:38:00AM +0100, Michal Privoznik wrote:
Some of our tests (e.g. qemuhotplugtest) call
virDomainSaveConfig(). Now the problem is, qemuTestDriverInit()
crea
On Wed, Mar 01, 2017 at 18:30:21 -0500, John Ferlan wrote:
> Since qemuDomainObjExitMonitor can also generate error messages,
> let's move it inside any error message saving code on error paths
> for various hotplug add activities.
>
> Signed-off-by: John Ferlan
> ---
> src/qemu/qemu_hotplug.c |
On Wed, Mar 01, 2017 at 18:30:20 -0500, John Ferlan wrote:
> Building upon the qemuDomainSecretInfoNew, create a helper which will
> build the secret used for TLS.
>
> Signed-off-by: John Ferlan
> ---
> src/qemu/qemu_domain.c | 59
> ++
> 1 file c
On Wed, Mar 01, 2017 at 18:30:19 -0500, John Ferlan wrote:
> Create a helper which will create the secinfo used for disks, hostdevs,
> and chardevs.
>
> Signed-off-by: John Ferlan
> ---
> src/qemu/qemu_domain.c | 137
> +
> 1 file changed, 71 inse
On Wed, Mar 08, 2017 at 03:07:12PM +0100, Wim Ten Have wrote:
> From: Wim ten Have
>
> This patch enhances host-passthrough capability to advertise the
> required vendor CPU virtualization feature which will be used to
> enable 'nestedhvm' in the libxl driver.
>
> For Intel virtualization (VT-x)
From: Wim ten Have
This patch enhances host-passthrough capability to advertise the
required vendor CPU virtualization feature which will be used to
enable 'nestedhvm' in the libxl driver.
For Intel virtualization (VT-x)
..
For AMD virtualization (AMD-V)
..
Joao M
From: Joao Martins
In other words, on configurations containing (within its
CPU element) one of the following for a host-passthrough
mode:
It will then generate (or parse) for nestedhvm=1 in/from xl format.
Signed-off-by: Joao Martins
Signed-off-by: Wim ten Have
---
src/xenconfig/xen_xl.c
From: Joao Martins
nestedhvm is the option on Xen 4.4+ which enables nested
virtualization on Xen. We set this field when one of the
following features is included in a host-passthrough CPU
element:
or:
Signed-off-by: Joao Martins
Signed-off-by: Wim ten Have
---
src/libxl/libxl_conf.c |
From: Wim ten Have
Configurations containing (within its CPU element) following:
Intel virtualization (VT-x):
AMD virtualization (AMD-V):
generate nestedhvm=1 in/from xl format.
Signed-off-by: Wim ten Have
---
tests/xlconfigdata/test-fullvirt-nestedhvm.cfg | 26 +++
tests/xlconfig
One of the main reasons for introducing host-model CPU definition in a
domain capabilities XML was the inability to express disabled features
in a host capabilities XML. That is, when a host CPU is, e.g., Haswell
without x2apic support, host capabilities XML will have to report it as
Westmere + a b
Signed-off-by: Jiri Denemark
---
Notes:
This is the host CPU which allowed me to find the missing functionality,
but I haven't quite figured out how to test this stuff all the way up
to domain capabilities XML. Let's just add it to the low level tests
for now.
tests/cputest.c
The function is now called virQEMUCapsProbeHostCPU. Both the refactoring
and the change of the name is done for consistency with a new function
which will be introduced in the following commit.
Signed-off-by: Jiri Denemark
---
src/qemu/qemu_capabilities.c | 16 ++--
1 file changed, 6
One of the main reasons for introducing host-model CPU definition in a
domain capabilities XML was the inability to express disabled features
in a host capabilities XML. That is, when a host CPU is, e.g., Haswell
without x2apic support, host capabilities XML will have to report it as
Westmere + a b
The parameter can be used to request either VIR_CPU_TYPE_HOST (which has
been assumed so far) or VIR_CPU_TYPE_GUEST definition.
Signed-off-by: Jiri Denemark
---
src/bhyve/bhyve_capabilities.c | 2 +-
src/cpu/cpu.c | 41 -
src/cpu/cpu.h
When creating host CPU definition usable with a given emulator, the CPU
should not be defined using an unsupported CPU model. The new @models
and @nmodels parameters can be used to limit CPU models which can be
used in the result.
Signed-off-by: Jiri Denemark
---
src/bhyve/bhyve_capabilities.c |
This element is only allowed for host CPUs.
Signed-off-by: Jiri Denemark
---
src/conf/cpu_conf.c | 2 +-
tests/cputestdata/x86_64-cpuid-A10-5800K-guest.xml | 1 -
tests/cputestdata/x86_64-cpuid-A10-5800K-json.xml | 1 -
tests/cputestdata/x86_64-cpui
cpuNodeData has always been followed by cpuDecode as no hypervisor
driver is really interested in raw CPUID data for a host CPU. Let's
create a new CPU driver API which returns virCPUDefPtr directly.
Signed-off-by: Jiri Denemark
---
src/bhyve/bhyve_capabilities.c | 34 -
On Wed, Mar 08, 2017 at 12:11:57 +0100, Pavel Hrdina wrote:
> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1430258
>
> Signed-off-by: Pavel Hrdina
> ---
> src/qemu/qemu_process.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_proce
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1430258
Signed-off-by: Pavel Hrdina
---
src/qemu/qemu_process.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 78d10099af..fcba7d3097 100644
--- a/src/qemu/qemu_process.c
+++ b
On Wed, 2017-03-08 at 09:22 +0100, Peter Krempa wrote:
> On Tue, Mar 07, 2017 at 18:45:23 +0100, Pavel Hrdina wrote:
> >
> > So far there is probably no change that is allowed to be done
> > by the VIR_DOMAIN_DEF_PARSE_ABI_UPDATE flag that would break
> > guest ABI but this may change in the futur
On 03/08/2017 10:15 AM, Martin Kletzander wrote:
> On Mon, Mar 06, 2017 at 08:38:00AM +0100, Michal Privoznik wrote:
>> Some of our tests (e.g. qemuhotplugtest) call
>> virDomainSaveConfig(). Now the problem is, qemuTestDriverInit()
>> creates a fake qemu driver and fills it with some fake
>> confi
On Wed, Mar 08, 2017 at 10:32:32AM +0100, Marc Hartmayer wrote:
> On Mon, Feb 27, 2017 at 11:20 AM +0100, "Daniel P. Berrange"
> wrote:
> > On Mon, Feb 27, 2017 at 10:59:39AM +0100, Marc Hartmayer wrote:
> >> On Thu, Feb 23, 2017 at 05:36 PM +0100, "Daniel P. Berrange"
> >> wrote:
> >> > On Thu
On Mon, Mar 06, 2017 at 08:38:00AM +0100, Michal Privoznik wrote:
Some of our tests (e.g. qemuhotplugtest) call
virDomainSaveConfig(). Now the problem is, qemuTestDriverInit()
creates a fake qemu driver and fills it with some fake
configuration. At least so we hoped. The truth is, it calls
regula
On 03/07/2017 09:22 PM, D L wrote:
> Hi Michal,
>
> Thank you so much for the detailed description. I will get back to you for
> each point in detail next week.
Sure, not problem.
>
> By the way, so nice to see the power of vi in a real project.
http://vim.wikia.com/wiki/Browsing_programs_with
#0 0x7fda223d66d8 in virClassIsDerivedFrom (klass=0xdeadbeef,
parent=0x7fda24c81b40) at util/virobject.c:169
#1 0x7fda223d6a1e in virObjectIsClass
(anyobj=anyobj@entry=0x7fd9e575b400, klass=) at
util/virobject.c:365
#2 0x7fda223d6a44 in virObjectLock (anyobj=0x7fd9e575
On Tue, Mar 07, 2017 at 18:45:23 +0100, Pavel Hrdina wrote:
> So far there is probably no change that is allowed to be done
> by the VIR_DOMAIN_DEF_PARSE_ABI_UPDATE flag that would break
> guest ABI but this may change in the future.
>
> The other cases where this flag is used is only when we are
66 matches
Mail list logo
