Signed-off-by: Jim Fehlig
---
Pushing under the trivial rule.
configure.ac | 2 +-
docs/news.xml | 8
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index ef521e370c..d0ef7de750 100644
--- a/configure.ac
+++ b/configure.ac
@@ -16,7 +16,7 @@
The news schema requires two digits for both month and day in the date
attribute. s/2/02/ in the day value of date to fix the following
'make check' failure
2165) Checking ../docs/news.xml against ../news.rng ...
libvirt: XML Util error : XML document failed to validate
On Tue, Dec 3, 2019 at 1:40 AM Boris Fiuczynski
wrote:
> On 12/2/19 9:41 AM, Han Han wrote:
> > In the last commit, we allowed unit number of virtio scsi disk to use
> > range 0..16383. Extend the range in rng file to match that.
> >
> > Signed-off-by: Han Han
> > ---
> >
On Mon, Dec 2, 2019 at 8:33 PM Andrea Bolognani wrote:
>
> On Mon, 2019-12-02 at 16:41 +0100, Fabiano Fidêncio wrote:
> > Jim,
> >
> > Firstly, sorry it took so long for me to give it a try in your patch.
> >
> > Now, comments inline ...
> >
> > On Tue, Nov 26, 2019 at 1:52 AM Jim Fehlig wrote:
This is landing more or less on time :-)
I just tagged it in git, and pushed signed tarball and source rpm to the usual
place:
https://libvirt.org/sources/
I also made a release for the Python bindings you can find at
https://libvirt.org/sources/python/
I had to do a bit of workaround
On Mon, 2019-12-02 at 20:01 +0100, Fabiano Fidêncio wrote:
> On Mon, Dec 2, 2019 at 7:32 PM Andrea Bolognani wrote:
> > A couple of changes that we need to have in before openSUSE can be
> > added, as already mentioned on the mailing list.
> >
> > Andrea Bolognani (2):
> > lcitool: Search /etc
On Mon, 2019-12-02 at 16:41 +0100, Fabiano Fidêncio wrote:
> Jim,
>
> Firstly, sorry it took so long for me to give it a try in your patch.
>
> Now, comments inline ...
>
> On Tue, Nov 26, 2019 at 1:52 AM Jim Fehlig wrote:
> > This change adds support for the latest openSUSE Leap and
> >
On Mon, Dec 2, 2019 at 7:32 PM Andrea Bolognani wrote:
>
> A couple of changes that we need to have in before openSUSE can be
> added, as already mentioned on the mailing list.
>
> Andrea Bolognani (2):
> lcitool: Search /etc and /usr/local/etc separately
> lcitool: Create group and user
Some operating systems (notably openSUSE) don't create a group
with the same name when a user is created: create it explicitly
so that we can later rely on it being present.
Signed-off-by: Andrea Bolognani
---
guests/playbooks/update/tasks/users.yml | 6 ++
1 file changed, 6 insertions(+)
A couple of changes that we need to have in before openSUSE can be
added, as already mentioned on the mailing list.
Andrea Bolognani (2):
lcitool: Search /etc and /usr/local/etc separately
lcitool: Create group and user separately
guests/playbooks/update/tasks/paths.yml | 2 +-
Some operating systems (notably openSUSE) have the former but not
the latter, which results in the single call to find(1) we've used
so far to fail.
Signed-off-by: Andrea Bolognani
---
I tried implementing my original suggestion and it turned out to
be much worse than what Jim and Fabiano
With the commit message spelling corrected
Reviewed-by: Boris Fiuczynski
On 12/2/19 9:41 AM, Han Han wrote:
Introduced in c8007fdc5d2, it should use 'greater than max' instread of
'equal or greater than max' for the condition of checking invalid scsi
unit.
Signed-off-by: Han Han
---
On 12/2/19 9:41 AM, Han Han wrote:
In the last commit, we allowed unit number of virtio scsi disk to use
range 0..16383. Extend the range in rng file to match that.
Signed-off-by: Han Han
---
docs/schemas/domaincommon.rng | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Mon, Dec 2, 2019 at 4:41 PM Fabiano Fidêncio wrote:
>
> Jim,
>
> Firstly, sorry it took so long for me to give it a try in your patch.
>
> Now, comments inline ...
>
> On Tue, Nov 26, 2019 at 1:52 AM Jim Fehlig wrote:
> >
> > This change adds support for the latest openSUSE Leap and
> >
On Mon, Dec 02, 2019 at 04:35:36PM +0100, Peter Krempa wrote:
The redetection was originally added in 43c01d3838 as a way to recover
from libvirtd upgrade from the time when we didn't persist the qemu
capabilities in the status XML. Also this the oldest supported qemu by
more than two years.
Jim,
Firstly, sorry it took so long for me to give it a try in your patch.
Now, comments inline ...
On Tue, Nov 26, 2019 at 1:52 AM Jim Fehlig wrote:
>
> This change adds support for the latest openSUSE Leap and
> openSUSE Tumbleweed guests.
>
> Signed-off-by: Jim Fehlig
> ---
>
> This
On Tue, Nov 26, 2019 at 14:57:25 -0500, Cole Robinson wrote:
> On 11/25/19 7:53 AM, Peter Krempa wrote:
> > Blockdev is required to do incremental backups properly. Add a helper
> > function for locking out capabilities and export it to allow re-doing
> > the processing if a different code path
The redetection was originally added in 43c01d3838 as a way to recover
from libvirtd upgrade from the time when we didn't persist the qemu
capabilities in the status XML. Also this the oldest supported qemu by
more than two years.
Even if somebody would have a running VM running at least qemu 1.5
The code calling this method expects it to have reported an error on
failure.
Signed-off-by: Daniel P. Berrangé
---
src/access/viraccessmanager.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/access/viraccessmanager.c b/src/access/viraccessmanager.c
index 31e1787919..f4120c6139
Signed-off-by: Daniel P. Berrangé
---
po/POTFILES.in | 1 +
src/util/virevent.c | 25 +
src/util/virevent.h | 2 ++
3 files changed, 28 insertions(+)
diff --git a/po/POTFILES.in b/po/POTFILES.in
index debb51cd70..b396797ff2 100644
--- a/po/POTFILES.in
+++
The intent here is to allow the virt drivers to be run directly embedded
in an arbitrary process without interfering with libvirtd. To achieve
this they need to store all their configuration & state in a separate
directory tree from the main system or session libvirtd instances.
This can be
This enables support for running the secret driver embedded to the
calling application process using a URI:
secret:///embed?root=/some/path
When using the embedded mode with a root=/var/tmp/embed, the
driver will use the following paths:
configDir: /var/tmp/embed/etc/secrets
The previous "QEMU shim" proof of concept was taking an approach of only
caring about initial spawning of the QEMU process. It was then
registered with the libvirtd daemon who took over management of it. The
intent was that later libvirtd would be refactored so that the shim
retained control over
The driver URI scheme:
"$drivername:///embed?root=/some/path"
enables a new way to use the drivers by embedding them directly in the
calling process. To use this the process must have a thread running the
libvirt event loop. This URI will then cause libvirt to dynamically load
the driver
This enables support for running QEMU embedded to the calling
application process using a URI:
qemu:///embed?root=/some/path
Note that it is important to keep the path reasonably short to
avoid risk of hitting the limit on UNIX socket path names
which is 108 characters.
When using the
This is a followup to:
https://www.redhat.com/archives/libvir-list/2019-May/msg00467.html
This series implements support for an embedded driver mode for libvirt,
with initial support in the QEMU and secrets drivers.
In this mode of operation, the driver stores all its config and state
under a
Now, that we have everything prepared, we can generate command
line for NVMe disks.
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_block.c | 25 +++-
src/qemu/qemu_command.c | 3 +
src/qemu/qemu_process.c | 7 +++
If a domain has an NVMe disk configured, then we need to create
/dev/vfio/* paths in domain's namespace so that qemu can open
them.
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_domain.c | 67 --
1 file changed, 51 insertions(+), 16 deletions(-)
diff
If a domain has an NVMe disk configured, then we need to allow it
on devices CGroup so that qemu can access it. There is one caveat
though - if an NVMe disk is read only we need CGroup to allow
write too. This is because when opening the device, qemu does
couple of ioctl()-s which are considered
We have this beautiful function that does crystal ball
divination. The function is named
qemuDomainGetMemLockLimitBytes() and it calculates the upper
limit of how much locked memory is given guest going to need. The
function bases its guess on devices defined for a domain. For
instance, if there
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_domain.c | 58 +
src/qemu/qemu_hostdev.c | 22
src/qemu/qemu_hostdev.h | 6 +
3 files changed, 86 insertions(+)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index
There are couple of places where a domain with a VFIO device gets
special treatment: in CGroups when enabling/disabling access to
/dev/vfio/vfio, and when creating/removing nodes in domain mount
namespace. Well, a NVMe disk is a VFIO device too. Fortunately,
we have this qemuDomainNeedsVFIO()
This function is currently not called for any type of storage
source that is not considered 'local' (as defined by
virStorageSourceIsLocalStorage()). Well, NVMe disks are not
'local' from that point of view and therefore we will need to
call this function more frequently.
Signed-off-by: Michal
This is slightly more complicated because NVMe disk source is not
a simple attribute to element. The format in which the
PCI address and namespace ID are printed is the same as QEMU
accepts them:
nvme://:XX:XX.X/X
Signed-off-by: Michal Privoznik
---
tools/virsh-domain-monitor.c | 31
With NVMe disks, one can start a blockjob with a NVMe disk
that is not visible in domain XML (at least right away). Usually,
it's fairly easy to override this limitation of
qemuDomainGetMemLockLimitBytes() - for instance for hostdevs we
temporarily add the device to domain def, let the function
Sometimes, we have a PCI address and not fully allocated
virPCIDevice and yet we still want to know its /dev/vfio/N path.
Introduce virPCIDeviceAddressGetIOMMUGroupDev() function exactly
for that.
Signed-off-by: Michal Privoznik
---
src/libvirt_private.syms | 1 +
src/qemu/qemu_domain.c | 11
This helper is cleaner than plain memcpy() because one doesn't
have to look into virPCIDeviceAddress struct to see if it
contains any strings / pointers.
Signed-off-by: Michal Privoznik
ACKed-by: Peter Krempa
---
src/libvirt_private.syms | 1 +
src/util/virpci.c| 14 ++
At the very beginning of the attach function the
qemuDomainStorageSourceChainAccessAllow() is called which
modifies CGroups, locks and seclabels for new disk and its
backing chain. This must be followed by a counterpart which
reverts back all the changes if something goes wrong. This boils
down to
There are several variables which could be automatically freed
upon return from the function. I'm not changing @tmpPaths (which
is a string list) because it is going to be removed in next
commit.
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_domain.c | 18 ++
1 file changed,
Now that all callers of qemuDomainGetHostdevPath() handle
/dev/vfio/vfio on their own, we can safely drop handling in this
function. In near future the decision whether domain needs VFIO
file is going to include more device types than just
virDomainHostdev.
Signed-off-by: Michal Privoznik
---
This capability tracks if qemu is capable of:
-drive file.driver=nvme
The feature was added in QEMU's commit of v2.12.0-rc0~104^2~2.
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_capabilities.c | 2 ++
src/qemu/qemu_capabilities.h | 1 +
This module will be used by virHostdevManager and it's inspired
by virPCIDevice module. They are very similar except instead of
what makes a NVMe device: PCI address AND namespace ID. This
means that a NVMe device can appear in a domain multiple times,
each time with a different namespace.
Now that we have virNVMeDevice module (introduced in previous
commit), let's use it int virHostdev to track which NVMe devices
are free to be used by a domain and which are taken.
Signed-off-by: Michal Privoznik
---
src/libvirt_private.syms | 5 +
src/util/virhostdev.c| 331
Because this is a HMP we're dealing with, there is nothing like
class of reply message, so we have to do some string comparison
to guess if the command fails. Well, with NVMe disks whole new
class of errors comes to play because qemu needs to initialize
IOMMU and VFIO for them. You can see all the
This function will return true if any of disks (or their backing
chain) for given domain contains an NVMe disk.
Signed-off-by: Michal Privoznik
ACKed-by: Peter Krempa
---
src/conf/domain_conf.c | 14 ++
src/conf/domain_conf.h | 3 +++
src/libvirt_private.syms | 1 +
3 files
To simplify implementation, some restrictions are added. For
instance, an NVMe disk can't go to any bus but virtio and has to
be type of 'disk' and can't have startupPolicy set.
Signed-off-by: Michal Privoznik
---
src/conf/domain_conf.c | 95 ++
The qemu driver has its own wrappers around virHostdev module (so
that some arguments are filled in automatically). Extend these to
include NVMe devices too.
Signed-off-by: Michal Privoznik
ACKed-by: Peter Krempa
---
src/qemu/qemu_hostdev.c | 49 ++---
In near future we will have a list of PCI devices we want to
re-attach to the host (held in virPCIDeviceListPtr) but we don't
have virDomainHostdevDefPtr. That's okay because
virHostdevReAttachPCIDevices() works with virPCIDeviceListPtr
mostly anyway. And in very few places where it needs
The device configs (which are actually the same one config)
come from a NVMe disk of mine.
Signed-off-by: Michal Privoznik
ACKed-by: Peter Krempa
---
tests/virpcimock.c | 3 +++
tests/virpcitestdata/-01-00.0.config | Bin 0 -> 4096 bytes
This function will return true if there's a storage source of
type VIR_STORAGE_TYPE_NVME, or false otherwise.
Signed-off-by: Michal Privoznik
ACKed-by: Peter Krempa
---
src/libvirt_private.syms | 1 +
src/util/virstoragefile.c | 14 ++
src/util/virstoragefile.h | 2 ++
3 files
There are going to be more disk types that are considered unsafe
with respect to migration. Therefore, move the error reporting
call outside of if() body and rework if-else combo to switch().
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_migration.c | 25 -
1 file
Signed-off-by: Michal Privoznik
ACKed-by: Peter Krempa
---
tests/virhostdevtest.c | 97 ++
1 file changed, 97 insertions(+)
diff --git a/tests/virhostdevtest.c b/tests/virhostdevtest.c
index ed8e7e8fc1..39216edc67 100644
--- a/tests/virhostdevtest.c
+++
There is this class of PCI devices that act like disks: NVMe.
Therefore, they are both PCI devices and disks. While we already
have (and can assign a NVMe device to a domain
successfully) we don't have disk representation. There are three
problems with PCI assignment in case of a NVMe device:
1)
In near future we will have a list of PCI devices we want to
detach (held in virPCIDeviceListPtr) but we don't have
virDomainHostdevDefPtr. That's okay because
virHostdevPreparePCIDevices() works with virPCIDeviceListPtr
mostly anyway. And in very few places where it needs
virDomainHostdevDefPtr
In near future, the decision what to do with /dev/vfio/vfio with
respect to domain namespace and CGroup is going to be moved out
of qemuDomainGetHostdevPath() because there will be some other
types of devices than hostdevs that need access to VFIO.
All functions that I'm changing (except
Previous patches rendered some of 'cleanup' labels needless.
Drop them.
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_cgroup.c | 25 +
src/qemu/qemu_domain.c | 50 --
2 files changed, 29 insertions(+), 46 deletions(-)
diff --git
v3 of:
https://www.redhat.com/archives/libvir-list/2019-September/msg01209.html
Builds just fine ;-)
https://travis-ci.org/zippy2/libvirt/builds/619622349
diff to v2:
- Fixed bug reported by Cole - unability to plug regular -s
caused by v2.
Michal Prívozník (30):
qemu: Explicitly
On Mon, Dec 02, 2019 at 01:18:44PM +, Daniel P. Berrangé wrote:
> The API XML files are generated files, so live in the build dir not the
> source dir.
>
> Signed-off-by: Daniel P. Berrangé
> ---
> src/libvirt-lxc.pc.in | 2 +-
> src/libvirt-qemu.pc.in | 2 +-
> src/libvirt.pc.in | 2
On Mon, Dec 02, 2019 at 13:18:44 +, Daniel Berrange wrote:
> The API XML files are generated files, so live in the build dir not the
> source dir.
>
> Signed-off-by: Daniel P. Berrangé
> ---
> src/libvirt-lxc.pc.in | 2 +-
> src/libvirt-qemu.pc.in | 2 +-
> src/libvirt.pc.in | 2 +-
>
The API XML files are generated files, so live in the build dir not the
source dir.
Signed-off-by: Daniel P. Berrangé
---
src/libvirt-lxc.pc.in | 2 +-
src/libvirt-qemu.pc.in | 2 +-
src/libvirt.pc.in | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git
On 12/2/19 5:41 AM, Han Han wrote:
In the last commit, we allowed unit number of virtio scsi disk to use
range 0..16383. Extend the range in rng file to match that.
Signed-off-by: Han Han
---
Reviewed-by: Daniel Henrique Barboza
--
libvir-list mailing list
libvir-list@redhat.com
On 12/2/19 5:41 AM, Han Han wrote:
Introduced in c8007fdc5d2, it should use 'greater than max' instread of
s/instread/instead
'equal or greater than max' for the condition of checking invalid scsi
unit.
Signed-off-by: Han Han
---
Reviewed-by: Daniel Henrique Barboza
--
libvir-list
On Fri, Nov 15, 2019 at 01:40:42PM +0100, Pino Toscano wrote:
Move the creation of a virStoragePtr object from the
esxVI_HostInternetScsiHbaStaticTarget object of a target out of
esxStoragePoolLookupByName in an own helper. This way it can be used
also in other functions.
Signed-off-by: Pino
On Fri, Nov 15, 2019 at 01:40:41PM +0100, Pino Toscano wrote:
Move the detection of the type of a vmfs pool out of
esxLookupVMFSStoragePoolType in an own helper. This way it can be used
also in other functions.
Signed-off-by: Pino Toscano
---
src/esx/esx_storage_backend_vmfs.c | 49
On Fri, Nov 15, 2019 at 01:40:40PM +0100, Pino Toscano wrote:
Move the creation of a virStoragePtr object from the esxVI_ObjectContent
object of a datastore out of esxStoragePoolLookupByName in an own
helper. This way it can be used also in other functions.
Signed-off-by: Pino Toscano
---
On Wed, Nov 27, 2019 at 11:10:21AM +, Ani Sinha wrote:
> Hi :
>
> I see a commit in qemu that adds support for CLZERO but in CPUIDs. :
>
> commit e900135dcfb676a4019dc206395e02db5d1de0d6
> Author: Sebastian Andrzej Siewior
> Date: Wed Sep 25 23:49:48 2019 +0200
>
> i386: Add CPUID bit for
On Fri, Nov 29, 2019 at 02:44:00PM +0100, Peter Krempa wrote:
Commit 4b58fdf280a which enabled block copy also for network
destinations needed to limit when the 'mirror' storage source is
initialized in cases when we e.g. don't have an appropriate backend.
Limiting it just to
On Fri, Nov 29, 2019 at 02:43:59PM +0100, Peter Krempa wrote:
We tolerate image format detection during block copy in very specific
circumstances, but the code didn't error out on failure of the format
detection.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_driver.c | 17 -
1
On 11/29/19 11:18 AM, Han Han wrote:
In the last commit, we allowed unit number of virtio scsi disk to use
range 0..16383. Extend the range in rng file to match that.
Signed-off-by: Han Han
---
docs/schemas/domaincommon.rng | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
In the last commit, we allowed unit number of virtio scsi disk to use
range 0..16383. Extend the range in rng file to match that.
Signed-off-by: Han Han
---
docs/schemas/domaincommon.rng | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/schemas/domaincommon.rng
Introduced in c8007fdc5d2, it should use 'greater than max' instread of
'equal or greater than max' for the condition of checking invalid scsi
unit.
Signed-off-by: Han Han
---
src/conf/domain_conf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/conf/domain_conf.c
v1: https://www.redhat.com/archives/libvir-list/2019-November/msg01451.html
Han Han (2):
conf: fix logic error for scsi units
rng: Extend the valid range of drive unit
docs/schemas/domaincommon.rng | 2 +-
src/conf/domain_conf.c| 2 +-
2 files changed, 2 insertions(+), 2
On Mon, Dec 2, 2019 at 4:17 PM Boris Fiuczynski
wrote:
> On 11/29/19 11:18 AM, Han Han wrote:
> > In qemu, 16383 is the top valid value for virtio scsi unit number:
> >
> > $ /usr/libexec/qemu-kvm \
> > -device \
> > virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x6 \
> > -drive \
> >
On 11/29/19 11:18 AM, Han Han wrote:
In qemu, 16383 is the top valid value for virtio scsi unit number:
$ /usr/libexec/qemu-kvm \
-device \
virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x6 \
-drive \
file=A.qcow2,format=qcow2,if=none,id=drive
-device \
74 matches
Mail list logo
