[libvirt] Why "integratorcp" as the default machine type for ARM / AArch64?
by Kashyap Chamarthy
Hi
I see in the following change, Dan added the default machine types for
all architectures:
https://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=26cfb1a3
("qemu: ensure default machine types don't change if QEMU changes")
What caught my eye was the default machine type chosen ("integratorcp")
for ARM / AAarch64:
+ [VIR_ARCH_ARMV7L] = "integratorcp",
+ [VIR_ARCH_ARMV7B] = "integratorcp",
+
+ [VIR_ARCH_AARCH64] = "integratorcp",
I thought the default for AArch64 / ARM would be 'virt'---as I learnt
that upstream QEMU explicitly designed the 'virt' board for ARM /
AArch64-based machine machines (because it supports PCI, 'virtio', has
decent RAM limits, etc.)
So, shouldn't the default for the above be changed from "integratorcp"
to "virt"?
PS: I thought "integratorcp" board was picked as it was probably the
first entry when you run `qemu-system-aarch64 -machine help`, but
that wasn't the case on my Fedora-28 machine---it was the 12th
entry.
--
/kashyap
6 years, 4 months
[libvirt] [PATCH] util: netdevbridge: fall back to ioctl from sysfs
by Christian Ehrhardt
There are certain cases e.g. containers where the sysfs path might
exists, but might fail. Unfortunately the exact restrictions are only
known to libvirt when trying to write to it so we need to try it.
But in case it fails there is no need to fully abort, in those cases try
to fall back to the older ioctl interface which can still work.
That makes setting up a bridge in unprivileged LXD containers work.
Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1802906
Signed-off-by: Christian Ehrhardt <christian.ehrhardt(a)canonical.com>
---
src/util/virnetdevbridge.c | 48 +++++++++++++++++++++-----------------
1 file changed, 26 insertions(+), 22 deletions(-)
diff --git a/src/util/virnetdevbridge.c b/src/util/virnetdevbridge.c
index 071ebb7b35..cbba3c9652 100644
--- a/src/util/virnetdevbridge.c
+++ b/src/util/virnetdevbridge.c
@@ -113,6 +113,8 @@ static int virNetDevBridgeCmd(const char *brname,
* or by ioctl on older kernels. Perhaps we could just use
* ioctl for every kernel, but its not clear what the long
* term lifespan of the ioctl interface is...
+ * Fall back to ioctl if sysfs interface is not available or
+ * failing (e.g. due to container isolation).
*/
static int virNetDevBridgeSet(const char *brname,
const char *paramname, /* sysfs param name */
@@ -128,29 +130,31 @@ static int virNetDevBridgeSet(const char *brname,
if (virFileExists(path)) {
char valuestr[INT_BUFSIZE_BOUND(value)];
snprintf(valuestr, sizeof(valuestr), "%lu", value);
- if (virFileWriteStr(path, valuestr, 0) < 0) {
- virReportSystemError(errno,
- _("Unable to set bridge %s %s"), brname, paramname);
- return -1;
- }
+ if (virFileWriteStr(path, valuestr, 0) >= 0)
+ return 0;
+ virReportSystemError(errno,
+ _("Unable to set bridge %s %s via sysfs"),
+ brname, paramname);
+ }
+
+ unsigned long paramid;
+ if (STREQ(paramname, "stp_state")) {
+ paramid = BRCTL_SET_BRIDGE_STP_STATE;
+ } else if (STREQ(paramname, "forward_delay")) {
+ paramid = BRCTL_SET_BRIDGE_FORWARD_DELAY;
} else {
- unsigned long paramid;
- if (STREQ(paramname, "stp_state")) {
- paramid = BRCTL_SET_BRIDGE_STP_STATE;
- } else if (STREQ(paramname, "forward_delay")) {
- paramid = BRCTL_SET_BRIDGE_FORWARD_DELAY;
- } else {
- virReportSystemError(EINVAL,
- _("Unable to set bridge %s %s"), brname, paramname);
- return -1;
- }
- unsigned long args[] = { paramid, value, 0, 0 };
- ifr->ifr_data = (char*)&args;
- if (ioctl(fd, SIOCDEVPRIVATE, ifr) < 0) {
- virReportSystemError(errno,
- _("Unable to set bridge %s %s"), brname, paramname);
- return -1;
- }
+ virReportSystemError(EINVAL,
+ _("Unable to set bridge %s %s via ioctl"),
+ brname, paramname);
+ return -1;
+ }
+ unsigned long args[] = { paramid, value, 0, 0 };
+ ifr->ifr_data = (char*)&args;
+ if (ioctl(fd, SIOCDEVPRIVATE, ifr) < 0) {
+ virReportSystemError(errno,
+ _("Failed to set bridge %s %s via ioctl"),
+ brname, paramname);
+ return -1;
}
return 0;
--
2.17.1
6 years, 4 months
[libvirt] [PATCH v2 0/4] rpc: fixing compilation error due to deprecated functions.
by Julio Faracco
After 0.8.0 release, libssh deprecated some functions like:
ssh_is_server_known() and ssh_write_knownhost(). They were replaced by
ssh_session_is_known_server() and ssh_session_update_known_hosts()
respectively. This serie creates the alias to keep the compatibility and
create an auxiliar enum to help it because
ssh_session_update_known_hosts() introduced new state returns.
Julio Faracco (4):
m4: checking if ssh_session_is_known_server() exists.
rpc: replacing ssh_is_server_known() by ssh_session_is_known_server().
m4: checking if ssh_session_update_known_hosts() exists.
rpc: replacing ssh_write_knownhost() by
ssh_session_update_known_hosts().
m4/virt-libssh.m4 | 12 ++++++++++++
src/rpc/virnetlibsshsession.c | 31 +++++++++++++++++++++++--------
2 files changed, 35 insertions(+), 8 deletions(-)
--
2.19.1
6 years, 4 months
[libvirt] [PATCH v2 0/4] qemu: Fix offline migration onto the same host
by Michal Privoznik
v2 of:
https://www.redhat.com/archives/libvir-list/2018-November/msg00832.html
diff to v1:
- in 2/4 I'm passing @priv whenever possible
- only doing s/priv/NULL/ in 3/4 as suggested in review
Patches 1/4 and 4/4 are reviewed already (not pushed yet though).
Michal Prívozník (4):
qemuMigrationDstPrepareAny: Don't overwrite error in cleanup path
qemuMigrationEatCookie: Pass virDomainDef instead of virDomainObj
qemuMigrationDstPrepareAny: Parse cookie before adding domain onto
list
qemuMigrationSrcConfirm: Don't remove domain config if confirm phase
fails
src/qemu/qemu_migration.c | 42 ++++++++++++++++++++------------
src/qemu/qemu_migration_cookie.c | 23 ++++++++---------
src/qemu/qemu_migration_cookie.h | 4 ++-
3 files changed, 41 insertions(+), 28 deletions(-)
--
2.18.1
6 years, 4 months
[libvirt] [PATCH 0/4] qemu: Fix offline migration onto the same host
by Michal Privoznik
This started as a report on #virt that the following command makes
libvirt lose domain and which is worse - remove its XML!
virsh migrate --offline --undefinesource --persistent $dom qemu+tcp://localhost/system
Turns out, there are two problems. The first one is that we try to add
incoming domain definition onto virDomainObjList before parsing
migration cookie; the second one being VIR_MIGRATE_UNDEFINE_SOURCE takes
effect regardless of migration success or failure.
Michal Prívozník (4):
qemuMigrationDstPrepareAny: Don't overwrite error in cleanup path
qemuMigrationEatCookie: Pass virDomainDef instead of virDomainObj
qemuMigrationDstPrepareAny: Parse cookie before adding domain onto
list
qemuMigrationSrcConfirm: Don't remove domain config if confirm phase
fails
src/qemu/qemu_migration.c | 42 ++++++++++++++++++++------------
src/qemu/qemu_migration_cookie.c | 23 ++++++++---------
src/qemu/qemu_migration_cookie.h | 4 ++-
3 files changed, 41 insertions(+), 28 deletions(-)
--
2.18.1
6 years, 4 months
[libvirt] [jenkins-ci PATCH] Revert "Enable {media, tree}uri tests for libosinfo"
by Andrea Bolognani
While a very good idea in theory, it turns out that running
these tests on CI results in a lot of false positives due to
issues on the remote side, which are of course entirely out
of our control.
This reverts commit ad8cdcf7a1e0e293e3cea19f36187b943bb881dd.
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
guests/playbooks/build/projects/libosinfo.yml | 4 ----
projects/libosinfo.yaml | 3 ---
2 files changed, 7 deletions(-)
diff --git a/guests/playbooks/build/projects/libosinfo.yml b/guests/playbooks/build/projects/libosinfo.yml
index dce1333..311a52b 100644
--- a/guests/playbooks/build/projects/libosinfo.yml
+++ b/guests/playbooks/build/projects/libosinfo.yml
@@ -9,10 +9,6 @@
- include: '{{ playbook_base }}/jobs/autotools-build-job.yml'
- include: '{{ playbook_base }}/jobs/autotools-syntax-check-job.yml'
- include: '{{ playbook_base }}/jobs/autotools-check-job.yml'
- vars:
- local_env: |
- # Run tests that require network connectivity
- export LIBOSINFO_NETWORK_TESTS=1
- include: '{{ playbook_base }}/jobs/autotools-rpm-job.yml'
vars:
machines: '{{ rpm_machines }}'
diff --git a/projects/libosinfo.yaml b/projects/libosinfo.yaml
index bf9ea6b..0376d0c 100644
--- a/projects/libosinfo.yaml
+++ b/projects/libosinfo.yaml
@@ -12,9 +12,6 @@
parent_jobs: 'libosinfo-build'
- autotools-check-job:
parent_jobs: 'libosinfo-syntax-check'
- local_env: |
- # Run tests that require network connectivity
- export LIBOSINFO_NETWORK_TESTS=1
- autotools-rpm-job:
parent_jobs: 'libosinfo-check'
machines: '{rpm_machines}'
--
2.19.1
6 years, 4 months
[libvirt] [PATCH 00/12] Autoselect a DRM node for egl-headless and add it to cmdline
by Erik Skultety
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1628892.
The problem is that we didn't put the DRI device into the namespace for QEMU to
access, but that was only a part of the issue. The other part of the issue is
that QEMU doesn't support specifying 'rendernode' for egl-headless yet (some
patches to solve this are already upstream for 3.1, some are still waiting to
be merged). Instead, QEMU's been autoselecting the DRI device on its own.
There's no compelling reason for libvirt not doing that instead and thus
prevent any permission-related issues.
Unlike for SPICE though, I deliberately didn't add an XML attribute for users
to select the rendernode for egl-headless, because:
a) most of the time, users really don't care about which DRM node will be used
and libvirt will most probably do a good decision
b) egl-headless is only useful until we have a remote OpenGL acceleration
support within SPICE
c) for SPICE (or for SDL for that matter at some point), the rendernode is
specified as part of the <gl> subelement which says "if enabled, use OpenGL
acceleration", but egl-headless graphics type essentially serves the same
purpose, it's like having <gl enabled='yes'/> for SPICE, thus having a <gl>
subelement for egl-headless type is rather confusing
Erik Skultety (12):
util: Introduce virHostGetDRMRenderNode helper
qemu: command: spice: Pick the first available DRM render node
qemu: caps: Start probing for egl-headless display type
qemu: caps: Introduce QEMU_EGL_HEADLESS_RENDERNODE capability
qemu: command: Introduce qemuBuildGraphicsEGLHeadlessCommandLine
helper
conf: Add egl-headless to virDomainGraphicsDef union
qemu: domain: Put the egl-headless' rendernode device into the
namespace
qemu: cgroup: Add the DRI device to the cgroup list for egl-headless
too
command: Put the 'rendernode' option onto egl-headless graphics
cmdline
security: dac: Relabel the DRI render device for egl-headless too
tests: Add a test case for the egl-headless' rendernode option
docs: Provide a news update for libvirt being able to pick a DRI
device
docs/news.xml | 13 ++++
src/conf/domain_conf.h | 3 +
src/libvirt_private.syms | 1 +
src/qemu/qemu_capabilities.c | 17 +++--
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_cgroup.c | 15 ++--
src/qemu/qemu_command.c | 72 +++++++++++++++----
src/qemu/qemu_domain.c | 15 ++--
src/security/security_dac.c | 21 +++---
src/util/virutil.c | 53 ++++++++++++++
src/util/virutil.h | 2 +
...cs-egl-headless-rendernode-autoselect.args | 26 +++++++
...ics-egl-headless-rendernode-autoselect.xml | 1 +
tests/qemuxml2argvmock.c | 9 +++
tests/qemuxml2argvtest.c | 4 ++
15 files changed, 220 insertions(+), 33 deletions(-)
create mode 100644 tests/qemuxml2argvdata/graphics-egl-headless-rendernode-autoselect.args
create mode 120000 tests/qemuxml2argvdata/graphics-egl-headless-rendernode-autoselect.xml
--
2.19.1
6 years, 4 months
[libvirt] [PATCH v2] security: aa-helper: fix static defined vfio MDEVs
by Christian Ehrhardt
virt-aa-helper needs to grant QEMU access to VFIO MDEV devices.
This extends commit 74e86b6b which only covered PCI hostdevs for VFIO-PCI
assignment by now also covering vfio MDEVs.
It has still the same limitations regarding the device lifecycle, IOW we're
unable to predict the actual VFIO device being created, thus we need
wildcards.
Also note that the hotplug case, where apparmor is able to detect the actual
VFIO device during runtime, is already covered by commit 606afafb.
Signed-off-by: Christian Ehrhardt <christian.ehrhardt(a)canonical.com>
Reviewed-by: Erik Skultety <eskultet(a)redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com>
---
src/security/virt-aa-helper.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/src/security/virt-aa-helper.c b/src/security/virt-aa-helper.c
index 03cc15c9d3..c7488432d6 100644
--- a/src/security/virt-aa-helper.c
+++ b/src/security/virt-aa-helper.c
@@ -1105,6 +1105,23 @@ get_files(vahControl * ctl)
break;
}
+ case VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_MDEV: {
+ virDomainHostdevSubsysMediatedDevPtr mdevsrc = &dev->source.subsys.u.mdev;
+ switch ((virMediatedDeviceModelType) mdevsrc->model) {
+ case VIR_MDEV_MODEL_TYPE_VFIO_PCI:
+ case VIR_MDEV_MODEL_TYPE_VFIO_AP:
+ case VIR_MDEV_MODEL_TYPE_VFIO_CCW:
+ needsVfio = true;
+ break;
+ case VIR_MDEV_MODEL_TYPE_LAST:
+ default:
+ virReportEnumRangeError(virMediatedDeviceModelType,
+ mdevsrc->model);
+ break;
+ }
+ break;
+ }
+
case VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI: {
virPCIDevicePtr pci = virPCIDeviceNew(
dev->source.subsys.u.pci.addr.domain,
--
2.17.1
6 years, 4 months
[libvirt] [PATCH] security: aa-helper: fix static defined vfio MDEVs
by Christian Ehrhardt
For vfio MDEVs we need to allow qemu the vfio access in apparmor.
This is extending the older fix 74e86b6b: "Fix apparmor profile
to make vfio pci passthrough work" which was for VFIO PCI
passthrough on static hostdevs to now also cover vfio MDEVs.
It is having the same limitations of the lifecycle at that time
being unable to detect the actual vfio device and therefore
adds a wildcars.
Please also note that hotplug - which in can detect the right
device at runtime - is covered by labeling callbacks in
606afafb: "security: Enable labeling of vfio mediated devices"
Signed-off-by: Christian Ehrhardt <christian.ehrhardt(a)canonical.com>
---
src/security/virt-aa-helper.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/src/security/virt-aa-helper.c b/src/security/virt-aa-helper.c
index 03cc15c9d3..c7488432d6 100644
--- a/src/security/virt-aa-helper.c
+++ b/src/security/virt-aa-helper.c
@@ -1105,6 +1105,23 @@ get_files(vahControl * ctl)
break;
}
+ case VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_MDEV: {
+ virDomainHostdevSubsysMediatedDevPtr mdevsrc = &dev->source.subsys.u.mdev;
+ switch ((virMediatedDeviceModelType) mdevsrc->model) {
+ case VIR_MDEV_MODEL_TYPE_VFIO_PCI:
+ case VIR_MDEV_MODEL_TYPE_VFIO_AP:
+ case VIR_MDEV_MODEL_TYPE_VFIO_CCW:
+ needsVfio = true;
+ break;
+ case VIR_MDEV_MODEL_TYPE_LAST:
+ default:
+ virReportEnumRangeError(virMediatedDeviceModelType,
+ mdevsrc->model);
+ break;
+ }
+ break;
+ }
+
case VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI: {
virPCIDevicePtr pci = virPCIDeviceNew(
dev->source.subsys.u.pci.addr.domain,
--
2.17.1
6 years, 4 months
Re: [libvirt] Overview of libvirt incremental backup API, part 2 (incremental/differential pull mode)
by Michael Ablassmeier
hi,
after watching Johns slides from the kvm forum (thanks for that) i had
some quick look at the backup-v3 branch. Just to provide some feebdack
for you guys, and some questions.
My main question is about the part of the NBD backup. By default what
you get from reading all the NDB data is a thick provisioned image of
the domains disk. One can use the `qemu-img map' function to get a
detailed information about the used blocks in the image, in case one
wants to create a thin provisioned backup.
As a third party backup vendor you cannot allways depend on qemu tools,
because you might not even install any software on the host you are
taking a backup from. So is, or will there be any way to get an output
that represents the same information from the map function in the backup
XML description via the libvirt API? Would it make sense to provide
this information in the `backup-dumpxml' output?
>From what i know in the Citrix XEN implementation, they provide a way to read
this information via the API, because they do not want the backup vendor to
install any component on the host systems.
Another thing i came across is that libvirt currently seems to forget about the
running backup job if a domain is destroyed and started after a backup job was
created:
[root@x ~]# virsh backup-begin centos backup-pull.xml
Backup id 1 started
backup used description from 'backup-pull.xml'
[root@x ~]# virsh destroy centos && virsh start centos
[root@x ~]# virsh backup-end --id 1 centos
error: Requested operation is not valid: No active block job 'tmp-hda'
[root@x ~]# virsh backup-dumpxml --id 1 centos
<domainbackup mode='pull' id='1'>
<server transport='tcp' name='localhost' port='10809'/>
<disks>
<disk name='hda' type='file'>
<driver type='qcow2'/>
<scratch file='/vm/base.img.1542876138'/>
</disk>
</disks>
</domainbackup>
thanks for your hard work on this!
bye,
- michael
6 years, 4 months
