The downstream ports of an x3130-upstream switch can each have one of
these plugged into them (and that is the only place they can be
connected). Each xio3130-downstream provides a single PCIe port that
can have PCI or PCIe devices hotplugged into it. Apparently an entire
set of x3130-upstream + se
This is backed by the qemu device xio3130-downstream. It can only be
connected to a pcie-switch-upstream-port (x3130-upstream) on the
upstream side.
---
V2:
* change test case to reflect additional pcie-root-port between
pcie-root and pcie-switch-upstream-port and add a 2nd switch that is
conn
This controller can be connected only to a port on a
pcie-switch-upstream-port. It provides a single hotpluggable port that
will accept any PCI or PCIe device, as well as any device requiring a
pcie-*-port (the only current example of such a device is the
pcie-switch-upstream-port).
---
V2:
* chan
This is the upstream part of a PCIe switch. It connects to a PCIe port
(but not PCI) on the upstream side, and can have up to 31
xio3130-downstream controllers (but no other types of devices)
connected to its downstream side.
This device will be used to implement the "pcie-switch" model of pci
con
This controller can be connected only to a pcie-root-port or a
pcie-switch-downstream-port (which will be added in a later patch),
which is the reason for the new connect type
VIR_PCI_CONNECT_TYPE_PCIE_PORT. A pcie-switch-upstream-port provides
32 ports (slot=0 to slot=31) on the downstream side, w
This is backed by the qemu device ioh3420.
chassis and port from the subelement are used to store/set the
respective qemu device options for the ioh3420. Currently, chassis is
set to be the index of the controller, and port is set to
"(slot << 3) + function" (per suggestion from Alex Williamson).
This is a PCIE "root port". It connects only to a port of the
integrated pcie.0 bus of a Q35 machine (can't be hotplugged), and
provides a single PCIe port that can have PCI or PCIe devices
hotplugged into it.
This device will be used to implement the "pcie-root-port" model of
pci controller.
---
this is backed by the qemu device x3130-upstream. It can only plug
into a pcie-root-port or pcie-switch-downstream-port.
---
V2: change test case to reflect additional pcie-root-port between
pcie-root and pcie-switch-upstream-port
src/qemu/qemu_command.c| 37 ++
This controller can be connected (at domain startup time only - not
hotpluggable) only to a port on the pcie root complex ("pcie-root" in
libvirt config), hence the new connect type
VIR_PCI_CONNECT_TYPE_PCIE_ROOT. It provides a hotpluggable port that
will accept any PCI or PCIe device.
New attribu
There are some non-0 default values in virDomainControllerDef (and
will soon be more) that are easier to not forget if the remembering is
done by a single initializer function (rather than inline code after
allocating the obejct with generic VIR_ALLOC().
---
new in V2
src/conf/domain_conf.c | 64
This uses the new subelement/attribute in two ways:
1) If a "pci-bridge" pci controller has no chassisNr attribute, it
will automatically be set to the controller's index during
qemuDomainAssignPCIAddresses()
2) when creating the commandline for a pci-bridge device, chassisNr
will be used to set
This new subelement is used in PCI controllers: the toplevel
*attribute* "model" of a controller denotes what kind of PCI
controller is being described, e.g. a "dmi-to-pci-bridge",
"pci-bridge", or "pci-root". But in the future there will be different
implementations of some of those types of PCI c
This loop occurs just after we've assured that all devices that
require a PCI device have been assigned and all necessary PCI
controllers have been added. It is the perfect place to add other
potentially auto-generated PCI controller attributes that are
dependent on the controller's PCI address (up
This patch provides qemu support for the contents of in
for the two existing PCI controller types that need it
(i.e. the two controller types that are backed by a device that must
be specified on the qemu commandline):
1) pci-bridge - sets type attribute default as "pci-bridge"
2) dmi-to-pci-b
There are some configuration options to some types of pci
controllers that are currently automatically derived from other parts
of the controller's configuration. For example, a pci-bridge
controller has an option that is called "chassis_nr" in qemu; libvirt
always sets chassis_nr to the index of t
I had previously sent patches adding these new controller types:
pcie-root-port
pcie-switch-upstream-port
pcie-switch-downstream-port
but there were issues with where the device name and guest-visible
attributes should be stored in the XML:
https://www.redhat.com/archives/libvir-list/201
The function that auto-assigns PCI addresses was written with the
hardcoded assumptions that any PCI bus would have slots available
starting at 1 and ending at 31. This isn't true for many types of
controller (some have a single slot/port at 0, some have slots/ports
from 0 to 31). This patch update
This makes the range and static host array management in
virNetworkDHCPDefParseXML() more similar to what is done in
virNetworkDefUpdateIPDHCPRange() and virNetworkDefUpdateIPDHCPHost() -
they use VIR_APPEND_ELEMENT rather than a combination of
VIR_REALLOC_N() and separate incrementing of the array
Currently, build fails on FreeBSD with:
CC libvirt_driver_la-nodeinfo.lo
nodeinfo.c:1941:56: error: use of undeclared identifier 'SYSFS_SYSTEM_PATH'
const char *prefix = sysfs_prefix ? sysfs_prefix : SYSFS_SYSTEM_PATH;
^
1 error ge
Michal,
Please see my comments intermixed below.
>
> > 1. `Pipe`s used to interconnect to the QEMU on the both sides are obviously
> > to be replaced by the UNIX sockets since the pipes cannot support
> > bidirectional output due to the design. This is to be made *one for each*
> > block device,
On 07/17/2015 10:14 AM, Andrea Bolognani wrote:
> Note: this series is to be applied on top of the
>
> [PATCH 00/10] nodeinfo: Various cleanups
>
> series I've posted at the same time.
>
> Changes since v4:
>
> * streamlined the logic used to decide whether the subcore
> configuration i
Hello. I'm testing sheepdog storage pool under libvirt 1.2.16 and when
i'm try to create 20 vm in the same time i lost libvirt (daemon
shutdown without error in logs)
2015-07-17 16:13:42.959+: 27679: error : virExec:491 : Cannot find
'pm-is-supported' in path: No such file or directory
2015-07
On Tue, 2015-07-14 at 11:47 +0200, Andrea Bolognani wrote:
>
> FWIW, now that John's series has been merged I'm going to
> rebase my version of the patch on top of it and post if for
> review. Shouldn't take long.
Well, it took way more than I hoped it would, but that's
what happens when you dive
Note: this series is to be applied on top of the
[PATCH 00/03] nodeinfo: Various fixes
series I've posted at the same time.
A bunch of improvements and cleanups that make the nodeinfo
code a bit nicer, more streamlined and less redundant, hopefully
not just to my eyes.
Andrea Bolognani (10):
When cleaning up the data (taken from a running system) for inclusion
I went a little too far and deleted a bunch of links that should have
been left alone. The test worked despite this because it was going
through a fallback code path.
A few other files are affected as well: again, the data is ta
From: Shivaprasad G Bhat
The nodeinfo is reporting incorrect number of cpus and incorrect host
topology on PPC64 KVM hosts. The KVM hypervisor on PPC64 needs only
the primary thread in a core to be online, and the secondaries offlined.
While scheduling a guest in, the kvm scheduler wakes up the s
From: Shivaprasad G Bhat
The nodeGetThreadsPerSubcore() function is mocked to return 8 for
ppc64 tests, which corresponds to the default subcore mode.
Update the expected output for the deconfigured-cpus nodeinfo
test to account for this change.
Signed-off-by: Shivaprasad G Bhat
Signed-off-by:
If the cpu/present file is not available, we assume that the kernel
is too old to support non-consecutive CPU ids and return a bitmap
with all the bits set to represent this fact. This assumption is
already exploited in nodeGetCPUCount().
This means users of this API can expect the information to
Keep track of what CPUs belong to the current node while walking
through the sysfs node entry, so we don't need to do it a second
time immediately afterwards.
This also allows us to loop through all CPUs that are part of a
node in guaranteed ascending order, which is something that is
required for
The new name makes it clear that the returned bitmap contains the
information about which CPUs are online, not eg. which CPUs are
present.
Change the name of the out parameter from max_id, which didn't
reflect the actual value returned, to size. Update the error
message as well.
No functional cha
Swap out all instances of cpu_set_t and replace them with virBitmap,
which some of the code was already using anyway.
The changes are pretty mechanical, with one notable exception: an
assumption has been added on the max value we can run into while
reading either socket_it or core_id.
While this
This aligns it with nodeGetCPUBitmap(), which already has a
similar out parameters, and relieves users of this API from the
need to call virBitmapSize() on the returned bitmap.
---
src/nodeinfo.c | 8 ++--
src/nodeinfo.h | 6 --
src/util/vircgroup.c | 4 +---
3 files changed, 1
The original name was confusing because the function returns the number
of CPUs, not the maximum CPU id. The comment above the function has
been updated to reflect this.
No functional changes.
---
src/nodeinfo.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/nodein
No need to look up the online status of each CPU separately when we
can get all the information in one go.
---
src/nodeinfo.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/src/nodeinfo.c b/src/nodeinfo.c
index 61a3b33..eceecc6 100644
--- a/src/nodeinfo.c
+++
---
src/nodeinfo.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/nodeinfo.c b/src/nodeinfo.c
index 64b12e6..7a12d54 100644
--- a/src/nodeinfo.c
+++ b/src/nodeinfo.c
@@ -973,6 +973,9 @@ linuxGetCPUGlobalPath(const char *sysfs_prefix,
# define linuxGetCPUPresentPath(sy
This is just a more generic version of linuxGetCPUPresentPath(),
which is now implemented by calling the new function appropriately.
---
src/nodeinfo.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/nodeinfo.c b/src/nodeinfo.c
index 105d7ab..64b12e6 100644
--- a/s
---
src/libvirt_private.syms | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index eb7ec76..b6347de 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -1008,6 +1008,7 @@ nodeGetInfo;
nodeGetMemory;
nodeGetMemoryParamete
During the recent refactoring/cleanups, a bug has been introduced
that caused all CPUs to be reported as online unless the sysfs
cpu/present file was available.
This commit fixes the fallback code path by building the directory
path passed to virNodeGetCpuValue() correctly.
---
src/nodeinfo.c | 8
This series fixes a bunch of issues currently affecting nodeinfo
and related tests.
Andrea Bolognani (3):
tests: Restore links in deconfigured-cpus nodeinfo test
nodeinfo: Add nodeGetPresentCPUBitmap() to libvirt_private.syms
nodeinfo: Fix nodeGetCPUBitmap()'s fallback code path
src/libvir
On Fri, Jul 17, 2015 at 03:42:36PM +0200, Martin Kletzander wrote:
> On Fri, Jul 17, 2015 at 12:11:55PM +0200, Peter Krempa wrote:
> >On Fri, Jul 17, 2015 at 09:29:44 +0100, Frediano Ziglio wrote:
> >>Allows to specify maximum number of head to QXL driver.
> >>
> >>Actually can be a compatiblity pr
On 17.07.2015 16:21, Michal Privoznik wrote:
> On 10.07.2015 08:20, Martin Kletzander wrote:
>> If one calls update-device with information that is not updatable,
>> libvirt reports success even though no data were updated. The example
>> used in the bug linked below uses updating device with
>>
On Thu, Jul 16, 2015 at 04:18:08PM +0200, Peter Krempa wrote:
> The scope name, even according to our docs is
> "machine-$DRIVER\x2d$VMNAME.scope" virSystemdMakeScopeName would use the
> resource partition name instead of "machine-" if it was specified thus
> creating invalid scope paths.
>
> This
On 10.07.2015 08:20, Martin Kletzander wrote:
> If one calls update-device with information that is not updatable,
> libvirt reports success even though no data were updated. The example
> used in the bug linked below uses updating device with
> which, in my opinion, is a valid thing to request f
>
> On Fri, Jul 17, 2015 at 12:11:55PM +0200, Peter Krempa wrote:
> >On Fri, Jul 17, 2015 at 09:29:44 +0100, Frediano Ziglio wrote:
> >> Allows to specify maximum number of head to QXL driver.
> >>
> >> Actually can be a compatiblity problem as heads in the XML configuration
> >> was set by defau
On Tue, Jul 14, 2015 at 02:44:59PM -0400, Cole Robinson wrote:
> As of fedora polkit-0.113-2, polkit-devel only pulls in polkit-libs, not
> full polkit, but we need the latter for pkcheck otherwise our configure
> test fails.
> ---
> libvirt.spec.in | 2 ++
> 1 file changed, 2 insertions(+)
>
> d
On 14.07.2015 20:44, Cole Robinson wrote:
> As of fedora polkit-0.113-2, polkit-devel only pulls in polkit-libs, not
> full polkit, but we need the latter for pkcheck otherwise our configure
> test fails.
> ---
> libvirt.spec.in | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libvirt.s
On Fri, Jul 10, 2015 at 11:26:17AM +0200, Jiri Denemark wrote:
> virDomainMigrateFinish* APIs were unfortunately designed to return the
> pointer to the domain on destination and NULL on error. This looks OK in
> normal cases but the same API is also called when we know migration
> failed and thus
On Fri, Jul 17, 2015 at 10:31:11AM +0200, Martin Kletzander wrote:
> On Fri, Jul 17, 2015 at 10:12:44AM +0200, Christophe Fergeau wrote:
> >Currently, when trying to virsh pool-define/virsh pool-build a new
> >'dir' pool, if the target directory already exists, virsh
> >pool-build/virStoragePoolBui
On Fri, Jul 17, 2015 at 12:11:55PM +0200, Peter Krempa wrote:
On Fri, Jul 17, 2015 at 09:29:44 +0100, Frediano Ziglio wrote:
Allows to specify maximum number of head to QXL driver.
Actually can be a compatiblity problem as heads in the XML configuration
was set by default to '1'.
Signed-off-by
From: Nikolay Shirokovskiy
Migration API has a lot of options. This patch intention is to provide
support for those options that can be trivially supported and give
estimation for other options support in this commit message.
I. Supported.
1. VIR_MIGRATE_COMPRESSED. Means 'use compression when
From: Nikolay Shirokovskiy
Signed-off-by: Nikolay Shirokovskiy
---
src/vz/vz_driver.c | 58 ---
1 files changed, 54 insertions(+), 4 deletions(-)
diff --git a/src/vz/vz_driver.c b/src/vz/vz_driver.c
index 8087165..c6086a7 100644
--- a/src/vz/vz
From: Nikolay Shirokovskiy
We need the session uuid of a connection to destination host on source host to
perform migration. This patch do all the job to pass this uuid from destination
node to source.
Signed-off-by: Nikolay Shirokovskiy
---
daemon/remote.c | 30
From: Nikolay Shirokovskiy
Signed-off-by: Nikolay Shirokovskiy
---
src/vz/vz_driver.c | 12 ++--
src/vz/vz_sdk.c| 16 +---
src/vz/vz_sdk.h|5 -
3 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/src/vz/vz_driver.c b/src/vz/vz_driver.c
index
From: Nikolay Shirokovskiy
This session uuid acts as authN token for different multihost vz operations one
of which is migration. Unfortunately we can't get it from server at any time
thus we need to save it at login.
Signed-off-by: Nikolay Shirokovskiy
---
src/vz/vz_sdk.c | 39 +++
> Actually, I found out this is easier to review as a one patch with
> various diff options used for various parts of the patch. Some
> questions and suggestions below.
>
> Why vshClientHooks and vshCmdGrp aren't in the vshControl struct? If
> we move the client helpers into a library (I think t
Hello,
I passed yesturday on the #virt IRC channel to ask there my question but
without receiving any answer. So I write you here to know if it is planned, on
the libvirt roadmap, to support external snapshot for revert/delete ?
I know there is a workaround in the meantime, but in this roadmap
From: Nikolay Shirokovskiy
vz puts uuids into curly braces. Simply introduce new contstant to reflect this
and get rid of magic +2 in code.
Signed-off-by: Nikolay Shirokovskiy
---
src/vz/vz_sdk.c | 12 ++--
src/vz/vz_utils.h |2 ++
2 files changed, 8 insertions(+), 6 deletions(
NOTE that minimal command to migrate vz domain is like next:
virsh -c vz:///system migrate 200 vz+ssh://shiny0/system -p2p --live
--persistent
--compressed
Difference from v1:
1. Patch is quite different. First patchset implements migration thru managed
migration scheme. This one goes thru p2p
From: Nikolay Shirokovskiy
This patch makes basic vz migration possible. For example by virsh:
virsh -c vz:///system migrate $NAME vz+ssh://$DST/system
Vz migration is implemented as peer2peer migration. The reason
is that vz sdk do all the job. The question may arise then
why don't implement it
ACK series and pushed.
Christophe
On Thu, Jul 09, 2015 at 03:13:46PM +0530, T A Mahadevan wrote:
> This is needed to be able to add UNIX channels
> ---
> libvirt-gconfig/Makefile.am| 2 +
> .../libvirt-gconfig-domain-chardev-source-unix.c | 84
> ++
On 14.07.2015 14:36, Martin Kletzander wrote:
> After upgrade to perl-5.22.0, it started complaining about one of our
> scripts. The thing is that even though it works, it wants all curly
> brackets escaped properly. The change is not functional, it merely gets
> rid of the following error:
>
>
virtio-net-pci adapter is capable to use irqfd with vhost-net only in MSI-X
mode, which appears to be available only on PCIe bus, at least on ARM
Signed-off-by: Pavel Fedin
---
src/qemu/qemu_command.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/qemu/qemu_command.c b/src/qemu/
Legacy -net option works correctly only with embedded device models, which
do not require any bus specification. Therefore, we should use -device for
PCI hardware
Signed-off-by: Pavel Fedin
---
src/qemu/qemu_command.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/qemu
Virt machine in qemu since v2.3.0 has PCI generic host controller, and
can use PCI devices. This provides performance improvement as well as
vhost-net with irqfd support for virtio-net. However libvirt currently
does not allow ARM virt machine to have PCI devices. This patchset adds
the necessary s
Here we assume that if qemu supports generic PCI host controller,
it is a part of virt machine and can be used for adding PCI devices.
In qemu this is actually a PCIe bus, so we also declare multibus
capability so that 0'th bus is specified to qemu correctly as 'pcie.0'
Signed-off-by: Pavel Fedin
This capability specifies that qemu can implement generic PCI host
controller. It is often used for virtual environments, including ARM.
Signed-off-by: Pavel Fedin
---
src/qemu/qemu_capabilities.c | 2 ++
src/qemu/qemu_capabilities.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/src/qemu
On Fri, Jul 17, 2015 at 09:29:44 +0100, Frediano Ziglio wrote:
> Allows to specify maximum number of head to QXL driver.
>
> Actually can be a compatiblity problem as heads in the XML configuration
> was set by default to '1'.
>
> Signed-off-by: Frediano Ziglio
> ---
> src/qemu/qemu_capabilitie
Our domain_conf.* files are big enough. Not only they contain XML
parsing code, but they served as a storage of all functions whose
name is virDomain prefixed. This is just wrong as it gathers not
related functions (and modules) into one big file which is then
harder to maintain. Split virDomainObj
https://bugzilla.redhat.com/show_bug.cgi?id=1226234#c3
After hot-plug a memory device success, the audit log show
that memory update failed:
type=VIRT_RESOURCE ... old-mem=1024000 new-mem=1548288 \
exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=pts/2 res=failed
This is because the ret is st
Allows to specify maximum number of head to QXL driver.
Actually can be a compatiblity problem as heads in the XML configuration
was set by default to '1'.
Signed-off-by: Frediano Ziglio
---
src/qemu/qemu_capabilities.c | 2 ++
src/qemu/qemu_capabilities.h
On Fri, Jul 17, 2015 at 10:12:44AM +0200, Christophe Fergeau wrote:
Currently, when trying to virsh pool-define/virsh pool-build a new
'dir' pool, if the target directory already exists, virsh
pool-build/virStoragePoolBuild will error out. This is a change of
behaviour compared to eg libvirt 1.2.
Currently, when trying to virsh pool-define/virsh pool-build a new
'dir' pool, if the target directory already exists, virsh
pool-build/virStoragePoolBuild will error out. This is a change of
behaviour compared to eg libvirt 1.2.13
This is caused by the wrong type being used for the dir_create_fla
Like s/authoriation/authorization/ and s/requries/requires/
Signed-off-by: Michal Privoznik
---
Pushed under trivial rule.
src/access/viraccessperm.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/access/viraccessperm.h b/src/access/viraccessperm.h
index 0acd156.
On Mon, 2015-06-01 at 09:26 +0100, Daniel P. Berrange wrote:
>
> Thanks, I've successfully push to gitlab & github mirrors now
Both gitlab and github mirrors seem to have stopped working
on July 6, at least for the libvirt repository; Other
repositories such as libvirt-glib seem to be okay.
Chee
On Thu, Jul 09, 2015 at 10:13:16AM +0200, Christophe Fergeau wrote:
> Hey,
>
> This patch series makes tests/test-gconfig valgrind-clean, and refactors two
> setters in GVirConfigDomainVideo to make them use the helpers provided by
> GVirConfigObject.
Ping?
Christophe
pgpcnLMuTzo94.pgp
Descrip
75 matches
Mail list logo
