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 makes
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:
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
++
From: Nikolay Shirokovskiy nshirokovs...@virtuozzo.com
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
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.spec.in
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(+)
diff
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'.
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 boot order='2'/
which, in my opinion, is a valid thing
From: Nikolay Shirokovskiy nshirokovs...@virtuozzo.com
Signed-off-by: Nikolay Shirokovskiy nshirokovs...@virtuozzo.com
---
src/vz/vz_driver.c | 58 ---
1 files changed, 54 insertions(+), 4 deletions(-)
diff --git a/src/vz/vz_driver.c
From: Nikolay Shirokovskiy nshirokovs...@virtuozzo.com
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 nshirokovs...@virtuozzo.com
From: Nikolay Shirokovskiy nshirokovs...@virtuozzo.com
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.
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'.
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/virStoragePoolBuild
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 we
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
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 this
From: Nikolay Shirokovskiy nshirokovs...@virtuozzo.com
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 nshirokovs...@virtuozzo.com
---
src/vz/vz_sdk.c | 12 ++--
src/vz/vz_utils.h |
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 nshirokovs...@virtuozzo.com
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
From: Nikolay Shirokovskiy nshirokovs...@virtuozzo.com
Signed-off-by: Nikolay Shirokovskiy nshirokovs...@virtuozzo.com
---
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
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 boot
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
Like s/authoriation/authorization/ and s/requries/requires/
Signed-off-by: Michal Privoznik mpriv...@redhat.com
---
Pushed under trivial rule.
src/access/viraccessperm.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/access/viraccessperm.h
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
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 fzig...@redhat.com
---
src/qemu/qemu_capabilities.c | 2 ++
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.
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
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
From: Shivaprasad G Bhat sb...@linux.vnet.ibm.com
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:
From: Shivaprasad G Bhat sb...@linux.vnet.ibm.com
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
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
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
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
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,
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
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 problem as
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
---
---
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
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
+++
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
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
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
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 fzig...@redhat.com
---
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
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
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
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 p.fe...@samsung.com
---
src/qemu/qemu_capabilities.c | 2 ++
src/qemu/qemu_capabilities.h | 1 +
2 files changed, 3 insertions(+)
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 p.fe...@samsung.com
---
src/qemu/qemu_command.c | 8
1 file changed, 8 insertions(+)
diff --git
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 p.fe...@samsung.com
---
src/qemu/qemu_command.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
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
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 is valid
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 |
---
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;
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
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 +
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
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
This patch provides qemu support for the contents of model in
controller 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 model type attribute default as
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:
*
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
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
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
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
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
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:
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
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 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 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 ioh3420.
chassis and port from the model 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
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,
75 matches
Mail list logo
