[libvirt] [PATCH] Fix compile error for stable 1.2.9
by Yang hongyang
Seems a backport miss. An extra member is passed to struct
virLXCBasicMountInfo.
Signed-off-by: Yang hongyang <hongyang.yang(a)easystack.cn>
---
src/lxc/lxc_container.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c
index 28dabec..1c65fa9 100644
--- a/src/lxc/lxc_container.c
+++ b/src/lxc/lxc_container.c
@@ -760,7 +760,7 @@ typedef struct {
static const virLXCBasicMountInfo lxcBasicMounts[] = {
{ "proc", "/proc", "proc", MS_NOSUID|MS_NOEXEC|MS_NODEV, false, false },
- { "/proc/sys", "/proc/sys", NULL, MS_BIND|MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_RDONLY, false, false, false },
+ { "/proc/sys", "/proc/sys", NULL, MS_BIND|MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_RDONLY, false, false },
{ "sysfs", "/sys", "sysfs", MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_RDONLY, false, false },
{ "securityfs", "/sys/kernel/security", "securityfs", MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_RDONLY, true, true },
#if WITH_SELINUX
--
1.7.1
1 year
[libvirt] Supporting vhost-net and macvtap in libvirt for QEMU
by Anthony Liguori
Disclaimer: I am neither an SR-IOV nor a vhost-net expert, but I've CC'd
people that are who can throw tomatoes at me for getting bits wrong :-)
I wanted to start a discussion about supporting vhost-net in libvirt.
vhost-net has not yet been merged into qemu but I expect it will be soon
so it's a good time to start this discussion.
There are two modes worth supporting for vhost-net in libvirt. The
first mode is where vhost-net backs to a tun/tap device. This is
behaves in very much the same way that -net tap behaves in qemu today.
Basically, the difference is that the virtio backend is in the kernel
instead of in qemu so there should be some performance improvement.
Current, libvirt invokes qemu with -net tap,fd=X where X is an already
open fd to a tun/tap device. I suspect that after we merge vhost-net,
libvirt could support vhost-net in this mode by just doing -net
vhost,fd=X. I think the only real question for libvirt is whether to
provide a user visible switch to use vhost or to just always use vhost
when it's available and it makes sense. Personally, I think the later
makes sense.
The more interesting invocation of vhost-net though is one where the
vhost-net device backs directly to a physical network card. In this
mode, vhost should get considerably better performance than the current
implementation. I don't know the syntax yet, but I think it's
reasonable to assume that it will look something like -net
tap,dev=eth0. The effect will be that eth0 is dedicated to the guest.
On most modern systems, there is a small number of network devices so
this model is not all that useful except when dealing with SR-IOV
adapters. In that case, each physical device can be exposed as many
virtual devices (VFs). There are a few restrictions here though. The
biggest is that currently, you can only change the number of VFs by
reloading a kernel module so it's really a parameter that must be set at
startup time.
I think there are a few ways libvirt could support vhost-net in this
second mode. The simplest would be to introduce a new tag similar to
<source network='br0'>. In fact, if you probed the device type for the
network parameter, you could probably do something like <source
network='eth0'> and have it Just Work.
Another model would be to have libvirt see an SR-IOV adapter as a
network pool whereas it handled all of the VF management. Considering
how inflexible SR-IOV is today, I'm not sure whether this is the best model.
Has anyone put any more thought into this problem or how this should be
modeled in libvirt? Michael, could you share your current thinking for
-net syntax?
--
Regards,
Anthony Liguori
1 year
[libvirt] [libvirt-sandbox PATCH 0/2] virt-sandbox-image: unbreak start from library
by Guido Günther
This is basically a V2 of "Drop library/ from template name and image path"
with Dan's comment implemented.
Guido Günther (2):
Drop library/ from image path
Sanitize domain name
libvirt-sandbox/image/cli.py | 8 ++++++--
libvirt-sandbox/image/sources/docker.py | 2 +-
2 files changed, 7 insertions(+), 3 deletions(-)
--
2.11.0
7 years, 2 months
[libvirt] [PATCH] tpm: Use /dev/null for cancel path if none was found
by Stefan Berger
TPM 2 does not implement sysfs files for cancellation of commands.
We therefore use /dev/null for the cancel path passed to QEMU.
Signed-off-by: Stefan Berger <stefanb(a)linux.vnet.ibm.com>
---
src/util/virtpm.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/util/virtpm.c b/src/util/virtpm.c
index 6d9b065..d5c10da 100644
--- a/src/util/virtpm.c
+++ b/src/util/virtpm.c
@@ -61,9 +61,7 @@ virTPMCreateCancelPath(const char *devpath)
VIR_FREE(path);
}
if (!path)
- virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
- _("No usable sysfs TPM cancel file could be "
- "found"));
+ ignore_value(VIR_STRDUP(path, "/dev/null"));
} else {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("TPM device path %s is invalid"), devpath);
--
2.5.5
7 years, 2 months
[libvirt] [PATCH v4 0/3] Add support for Veritas HyperScale (VxHS) block device protocol
by Ashish Mittal
From: Ashish Mittal <ashish.mittal(a)veritas.com>
QEMU changes for VxHS (including TLS support) are already upstream.
This series of patches adds support for VxHS block devices in libvirt.
Patch 1 adds the base functionality for supporting VxHS protocol.
Patch 2 adds two new configuration options in qemu.conf to enable TLS
for VxHS devices.
Patch 3 implements the main TLS functionality.
Ashish Mittal (3):
Add support for Veritas HyperScale (VxHS) block device protocol
conf: Introduce TLS options for VxHS block device clients
Add TLS support for Veritas HyperScale (VxHS) block device protocol
docs/formatdomain.html.in | 31 ++++-
docs/schemas/domaincommon.rng | 18 +++
src/conf/domain_conf.c | 19 +++
src/libxl/libxl_conf.c | 1 +
src/qemu/libvirtd_qemu.aug | 4 +
src/qemu/qemu.conf | 23 +++
src/qemu/qemu_command.c | 155 +++++++++++++++++++++
src/qemu/qemu_conf.c | 7 +
src/qemu/qemu_conf.h | 3 +
src/qemu/qemu_driver.c | 3 +
src/qemu/qemu_parse_command.c | 25 ++++
src/qemu/test_libvirtd_qemu.aug.in | 2 +
src/util/virstoragefile.c | 77 +++++++++-
src/util/virstoragefile.h | 10 ++
src/xenconfig/xen_xl.c | 1 +
.../qemuargv2xml-disk-drive-network-vxhs-fail.args | 24 ++++
tests/qemuargv2xmltest.c | 17 ++-
...ml2argv-disk-drive-network-tlsx509-err-vxhs.xml | 34 +++++
...-disk-drive-network-tlsx509-multidisk-vxhs.args | 41 ++++++
...k-drive-network-tlsx509-multidisk-vxhs.args.new | 41 ++++++
...v-disk-drive-network-tlsx509-multidisk-vxhs.xml | 56 ++++++++
...muxml2argv-disk-drive-network-tlsx509-vxhs.args | 28 ++++
...emuxml2argv-disk-drive-network-tlsx509-vxhs.xml | 34 +++++
.../qemuxml2argv-disk-drive-network-vxhs.args | 25 ++++
.../qemuxml2argv-disk-drive-network-vxhs.xml | 34 +++++
tests/qemuxml2argvtest.c | 10 ++
tests/virstoragetest.c | 30 ++++
27 files changed, 748 insertions(+), 5 deletions(-)
create mode 100644 tests/qemuargv2xmldata/qemuargv2xml-disk-drive-network-vxhs-fail.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-tlsx509-err-vxhs.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-tlsx509-multidisk-vxhs.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-tlsx509-multidisk-vxhs.args.new
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-tlsx509-multidisk-vxhs.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-tlsx509-vxhs.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-tlsx509-vxhs.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-vxhs.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-vxhs.xml
--
2.5.5
7 years, 2 months
[libvirt] [PATCH 0/8] qemu: Default to video type=virtio for machvirt
by Cole Robinson
This series aim is to change the qemu machvirt video type default to
virtio, but rather than continue to hack things into place in
domain_conf.c, this rearranges things to allow drivers to set a
video type default.
Patches 1-4 are small cleanups/improvements in this area
Patches 5-7 are the plumbing to allow drivers to set their own default
Patch 8 is the actual default change
https://bugzilla.redhat.com/show_bug.cgi?id=1404112
Cole Robinson (8):
qemu: parse: drop redundant video config
qemu: domain: Move some validation out of DeviceDefPostParse
qemu: annotate some VIDEO_TYPE enum switch
conf: add virDomainVideoDefNew
conf: domain: add VIDEO_TYPE_DEFAULT
conf: domain: move video type validation to DeviceDefValidate
qemu: Set default video type in qemu PostParse
qemu: Default to video type=virtio for machvirt
src/conf/domain_conf.c | 54 +++++++++++-------
src/conf/domain_conf.h | 2 +
src/libvirt_private.syms | 1 +
src/qemu/qemu_command.c | 7 +--
src/qemu/qemu_domain.c | 66 ++++++++++++++--------
src/qemu/qemu_domain_address.c | 1 +
src/qemu/qemu_monitor_json.c | 16 ++----
src/qemu/qemu_parse_command.c | 14 +----
src/qemu/qemu_process.c | 7 +--
src/vz/vz_sdk.c | 3 +-
tests/domaincapsschemadata/full.xml | 1 +
.../qemuxml2argv-aarch64-video-default.args | 24 ++++++++
.../qemuxml2argv-aarch64-video-default.xml | 17 ++++++
tests/qemuxml2argvtest.c | 6 ++
.../qemuxml2xmlout-aarch64-video-default.xml | 46 +++++++++++++++
tests/qemuxml2xmltest.c | 6 ++
16 files changed, 191 insertions(+), 80 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-video-default.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-video-default.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-aarch64-video-default.xml
--
2.13.0
7 years, 2 months
[libvirt] [PATCH v2] vz: support disabled items in vz boot order
by Nikolay Shirokovskiy
At the time the check was written virtuozzo did not use disabled items in boot
order configuration. Boot items were always enabled. Now they can be disabled
as well. Supporting such items is easy - they just should be ignored.
---
src/vz/vz_sdk.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/src/vz/vz_sdk.c b/src/vz/vz_sdk.c
index 8ccd7ea..a6eb0dd 100644
--- a/src/vz/vz_sdk.c
+++ b/src/vz/vz_sdk.c
@@ -1736,11 +1736,8 @@ prlsdkConvertBootOrderVm(PRL_HANDLE sdkdom, virDomainDefPtr def)
pret = PrlBootDev_IsInUse(bootDev, &inUse);
prlsdkCheckRetGoto(pret, cleanup);
- if (!inUse) {
- virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
- _("Boot ordering with disabled items is not supported"));
- goto cleanup;
- }
+ if (!inUse)
+ continue;
pret = PrlBootDev_GetSequenceIndex(bootDev, &bootIndex);
prlsdkCheckRetGoto(pret, cleanup);
--
1.8.3.1
7 years, 3 months
[libvirt] [PATCH v2] qemu: command: align disk serial check to schema
by Nikolay Shirokovskiy
Disk serial schema has extra '.+' allowed characters in comparison
with check in code. Looks like there is no reason for that as qemu
allows any character AFAIK for serial. This discrepancy is originated
in 85d15b51 where ability to add serial was added.
---
Diff from v1:
* fix xml2argv disk serial test to use all valid chars
Looks like there is no existing infrastructure to test every invalid character.
src/qemu/qemu_command.c | 2 +-
tests/qemuxml2argvdata/qemuxml2argv-disk-serial.args | 2 +-
tests/qemuxml2argvdata/qemuxml2argv-disk-serial.xml | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index c76f923..c5369b0 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -432,7 +432,7 @@ qemuBuildIoEventFdStr(virBufferPtr buf,
}
#define QEMU_SERIAL_PARAM_ACCEPTED_CHARS \
- "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_ "
+ "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_ .+"
static int
qemuSafeSerialParamValue(const char *value)
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-serial.args b/tests/qemuxml2argvdata/qemuxml2argv-disk-serial.args
index 2cefdca..fa0fc93 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-disk-serial.args
+++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-serial.args
@@ -18,6 +18,6 @@ QEMU_AUDIO_DRV=none \
-boot c \
-usb \
-drive 'file=/dev/HostVG/QEMUGuest1,format=raw,if=none,id=drive-ide0-0-1,\
-serial=\ \ WD-WMAP9A966149' \
+serial=abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_\ .+' \
-device ide-drive,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-serial.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-serial.xml
index 565462e..d54d73b 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-disk-serial.xml
+++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-serial.xml
@@ -17,7 +17,7 @@
<disk type='block' device='disk'>
<source dev='/dev/HostVG/QEMUGuest1'/>
<target dev='hda' bus='ide'/>
- <serial> WD-WMAP9A966149</serial>
+ <serial>abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_ .+</serial>
<address type='drive' controller='0' bus='0' target='0' unit='1'/>
</disk>
<controller type='usb' index='0'/>
--
1.8.3.1
7 years, 3 months
