December 2016 - Devel - libvirt List Archives

[libvirt] memory-ballooning side-channel attack
by bancfc＠openmailbox.org 09 Jan '17

09 Jan '17

Hello and Happy Holidays, In the past few years many serious attacks against the memory deduplication (KSM) feature of all hypervisors have been shown. [1] Even allowing attackers to modify/steal APT keys and source lists on the host. [2] Since its not enabled by default the fall out is relatively low and easily mitigated. New side-channel attacks against memory-ballon enabled VMs are beginning to surface. Please consider documenting this and disabling this feature for newly created VMs to have safe defaults. [1] https://staff.aist.go.jp/c.artho/papers/EuroSec2011-suzaki.pdf [2] https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper… [3] http://ieeexplore.ieee.org/document/7562068/ *Hint: If you can't see the IEEE paper use sci-hub.

1 1

[libvirt] [PATCH 0/9] Qemu: s390: Cpu Model Support
by Jason J. Herne 06 Jan '17

06 Jan '17

This patch set enables cpu model support for s390. The user can now set exact cpu models, query supported models via virsh domcapabilities, and use host-model and host-passthrough modes. The end result is that migration is safer because Qemu will perform runnability checking on the destination host and quit with an error if the guest's cpu model is not supported. Note: Some test data has been separated from corresponding test case updates for ease of review. Changelog --------- [v3] s390: Cpu driver support for update and compare - Fixed indentation of error message in virCPUs390Update test-data: Qemu caps replies and xml for s390x qemu 2.7 and 2.8 - Moved this patch before introduction of query-cpu-model-expansion - Regenerated all test data tests: domain capabilities: qemu 2.7 and 2.8 on s390x - Added Qemu 2.7 test - Removed fake host model name - Moved this patch before introduction of query-cpu-model-expansion tests: qemu capabilites: qemu 2.7 and 2.8 on s390x - Moved this patch before introduction of query-cpu-model-expansion - Stop using fake host cpu qemu: qmp query-cpu-model-expansion command - Moved query-cpu-model-expansion capability to this patch - changed label "cleanup" to "error" in qemuMonitorCPUModelInfoCopy - qemuMonitorJSONParseCPUModelProperty is now static, and also made appropriate changes when passing a boolean to virJSONValueGetBoolean - removed unnecessary error checking when assigning "data" variable in qemuMonitorJSONGetCPUModelExpansion - Fix up capabilities test data to reflect changes from this commit - fixed query-cpu-model-expansion's enumeration formatting qemu-caps: Get host model directly from Qemu when available - Moved query-cpu-model-expansion capability from this patch - virQEMUCapsCopyCPUModelFromQEMU is now static and type void - check for native guest is done before attempting to set host CPU - s390x no longer falls back to getting host CPU model from the host if it cannot be retrieved from QEMU - fixed unnecessary intialization of some variables that were introduced in v2 of these patches - virQEMUCapsLoadHostCPUModelInfo now first allocates data into a qemuMonitorCPUModelInfoPtr before assigning it to appropriate qemuCaps field - if we do not have QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION available, skip trying to read the hostCPU portion of the qemu cache file - all hostCPU element parsing is handled in its entirety within function virQEMUCapsLoadHostCPUModelInfo - Fix up capabilities test data to reflect changes from this commit qemu: command: Support new cpu feature argument syntax - Add error message for case where s390 guest attempts to use cpu features on older qemu. - Combined the tests into this commit - Now tests s390 cpu features both with and without query-cpu-model-expansion [v2] * Added s390x cpu and capabilities tests * Added cpu feature syntax tests * Dropped patch: Warn when migrating host-passthrough * Added patch: Document migrating host-passthrough is dangerous s390: Cpu driver support for update and compare - Compare: Added comment explaining why s390 bypasses the cpuCompare operation - Update: Added error message explaining minimum match mode is not supported - Update: Ensure user is not using unsupported optional feature policy - Update: Use virCPUDefUpdateFeature to update/create user requested features - Other minor fixes s390-cpu: Remove nodeData and decode - Completely remove nodeData and decode functions qemu: qmp query-cpu-model-expansion command - Cleaned up debug print - Restructured qemuMonitorJSONGetCPUModelExpansion - Added more JSON parsing error handling - CPU model features now parsed via an iterator - qemuMonitorJSONGetCPUModelExpansion: Fixed double free of model ptr - Restructure qemuMonitorCPUModelInfoFree - Other minor fixes qemu-caps: Get host model directly from Qemu when available - virQEMUCapsProbeQMPHostCPU: indentation fix - Fixed rebase error involving a missing 'goto cleanup;'. - Fix indentation in virQEMUCapsProbeQMPHostCPU - virQEMUCapsInitHostCPUModel now routes to virQEMUCapsCopyModelFromQEMU or virQEMUCapsCopyModelFromHost, depending on architecture. - Restructure hostCpu data in qemu caps cache xml - Other minor fixes Collin L. Walling (5): test-data: Qemu caps replies and xml for s390x qemu 2.7 and 2.8 tests: domain capabilities: qemu 2.7 and 2.8 on s390x tests: qemu capabilites: qemu 2.7 and 2.8 on s390x qemu: qmp query-cpu-model-expansion command qemu: command: Support new cpu feature argument syntax Jason J. Herne (4): s390: Cpu driver support for update and compare s390-cpu: Remove nodeData and decode qemu-caps: Get host model directly from Qemu when available tests: qemuxml2argv s390x cpu model po/POTFILES.in | 1 + src/cpu/cpu_s390.c | 103 +- src/qemu/qemu_capabilities.c | 190 +- src/qemu/qemu_capabilities.h | 3 + src/qemu/qemu_command.c | 18 +- src/qemu/qemu_monitor.c | 62 + src/qemu/qemu_monitor.h | 22 + src/qemu/qemu_monitor_json.c | 117 + src/qemu/qemu_monitor_json.h | 6 + tests/domaincapsschemadata/qemu_2.7.0.s390x.xml | 78 + tests/domaincapsschemadata/qemu_2.8.0.s390x.xml | 159 + tests/domaincapstest.c | 18 + .../qemucapabilitiesdata/caps_2.7.0.s390x.replies | 11999 +++++++++++++++++ tests/qemucapabilitiesdata/caps_2.7.0.s390x.xml | 140 + .../qemucapabilitiesdata/caps_2.8.0.s390x.replies | 13380 +++++++++++++++++++ tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml | 286 + tests/qemucapabilitiestest.c | 2 + .../qemuxml2argv-cpu-s390-features.args | 19 + .../qemuxml2argv-cpu-s390-features.xml | 23 + .../qemuxml2argv-cpu-s390-zEC12.args | 19 + .../qemuxml2argv-cpu-s390-zEC12.xml | 21 + tests/qemuxml2argvtest.c | 14 + 22 files changed, 26638 insertions(+), 42 deletions(-) create mode 100644 tests/domaincapsschemadata/qemu_2.7.0.s390x.xml create mode 100644 tests/domaincapsschemadata/qemu_2.8.0.s390x.xml create mode 100644 tests/qemucapabilitiesdata/caps_2.7.0.s390x.replies create mode 100644 tests/qemucapabilitiesdata/caps_2.7.0.s390x.xml create mode 100644 tests/qemucapabilitiesdata/caps_2.8.0.s390x.replies create mode 100644 tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-features.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-features.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-zEC12.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-zEC12.xml -- 2.7.4

2 20

Re: [libvirt] [RFC] phi support in libvirt
by He Chen 06 Jan '17

06 Jan '17

> On Mon, Dec 05, 2016 at 04:12:22PM +0000, Feng, Shaohe wrote: > > Hi all: > > > > As we are know Intel® Xeon phi targets high-performance computing and > > other parallel workloads. > > Now qemu has supported phi virtualization，it is time for libvirt to > > support phi. > > Can you provide pointer to the relevant QEMU changes. > Xeon Phi Knights Landing (KNL) contains 2 primary hardware features, one is up to 288 CPUs which needs patches to support and we are pushing it, the other is Multi-Channel DRAM (MCDRAM) which does not need any changes currently. Let me introduce more about MCDRAM, MCDRAM is on-package high-bandwidth memory (~500GB/s). On KNL platform, hardware expose MCDRAM as a seperate, CPUless and remote NUMA node to OS so that MCDRAM will not be allocated by default (since MCDRAM node has no CPU, every CPU regards MCDRAM node as remote node). In this way, MCDRAM can be reserved for certain specific applications. > > Different from the traditional X86 server, There is a special numa > > node with Multi-Channel DRAM (MCDRAM) on Phi, but without any CPU . > > > > Now libvirt requires nonempty cpus argument for NUMA node, such as. > > <numa> > > <cell id='0' cpus='0-239' memory='80' unit='GiB'/> > > <cell id='1' cpus='240-243' memory='16' unit='GiB'/> </numa> > > > > In order to support phi virtualization, libvirt needs to allow a numa > > cell definition without 'cpu' attribution. > > > > Such as: > > <numa> > > <cell id='0' cpus='0-239' memory='80' unit='GiB'/> > > <cell id='1' memory='16' unit='GiB'/> </numa> > > > > When a cell without 'cpu', qemu will allocate memory by default MCDRAM instead of DDR. > > There's separate concepts at play which your description here is mixing up. > > First is the question of whether the guest NUMA node can be created with only RAM or CPUs, or a mix of both. > > Second is the question of what kind of host RAM (MCDRAM vs DDR) is used as the backing store for the guest > Guest NUMA node shoulde be created with memory only (keep the same as host's) and the more important things is the memory should bind to (come from) host MCDRAM node. > These are separate configuration items which don't need to be conflated in libvirt. ie we should be able to create a guest with a node containing only memory, and back that by DDR on the host. Conversely we should be able to create a guest with a node containing memory + cpus and back that by MCDRAM on the host (even if that means the vCPUs will end up on a different host node from its RAM) > > On the first point, there still appears to be some brokness in either QEMU or Linux wrt configuration of virtual NUMA where either cpus or memory are absent from nodes. > > eg if I launch QEMU with > > -numa node,nodeid=0,cpus=0-3,mem=512 > -numa node,nodeid=1,mem=512 > -numa node,nodeid=2,cpus=4-7 > -numa node,nodeid=3,mem=512 > -numa node,nodeid=4,mem=512 > -numa node,nodeid=5,cpus=8-11 > -numa node,nodeid=6,mem=1024 > -numa node,nodeid=7,cpus=12-15,mem=1024 > > then the guest reports > > # numactl --hardware > available: 6 nodes (0,3-7) > node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 > node 0 size: 487 MB > node 0 free: 230 MB > node 3 cpus: 12 13 14 15 > node 3 size: 1006 MB > node 3 free: 764 MB > node 4 cpus: > node 4 size: 503 MB > node 4 free: 498 MB > node 5 cpus: > node 5 size: 503 MB > node 5 free: 499 MB > node 6 cpus: > node 6 size: 503 MB > node 6 free: 498 MB > node 7 cpus: > node 7 size: 943 MB > node 7 free: 939 MB > > so its pushed all the CPUs from nodes without RAM into the first node, and moved CPUs from the 7th node into the 3rd node. > I am not sure why this happens, but basically, I lauch QEMU like: -object memory-backend-ram,size=20G,prealloc=yes,host-nodes=0,policy=bind,id=node0 \ -numa node,nodeid=0,cpus=0-14,cpus=60-74,cpus=120-134,cpus=180-194,memdev=node0 \ -object memory-backend-ram,size=20G,prealloc=yes,host-nodes=1,policy=bind,id=node1 \ -numa node,nodeid=1,cpus=15-29,cpus=75-89,cpus=135-149,cpus=195-209,memdev=node1 \ -object memory-backend-ram,size=20G,prealloc=yes,host-nodes=2,policy=bind,id=node2 \ -numa node,nodeid=2,cpus=30-44,cpus=90-104,cpus=150-164,cpus=210-224,memdev=node2 \ -object memory-backend-ram,size=20G,prealloc=yes,host-nodes=3,policy=bind,id=node3 \ -numa node,nodeid=3,cpus=45-59,cpus=105-119,cpus=165-179,cpus=225-239,memdev=node3 \ -object memory-backend-ram,size=3G,prealloc=yes,host-nodes=4,policy=bind,id=node4 \ -numa node,nodeid=4,memdev=node4 \ -object memory-backend-ram,size=3G,prealloc=yes,host-nodes=5,policy=bind,id=node5 \ -numa node,nodeid=5,memdev=node5 \ -object memory-backend-ram,size=3G,prealloc=yes,host-nodes=6,policy=bind,id=node6 \ -numa node,nodeid=6,memdev=node6 \ -object memory-backend-ram,size=3G,prealloc=yes,host-nodes=7,policy=bind,id=node7 \ -numa node,nodeid=7,memdev=node7 \ (Please ignore the complex cpus parameters...) As you can see, the pair of `-object memory-backend-ram` and `-numa` is used to specify where the memory of the guest NUMA node is allocated from. It works well for me :-) > So before considering MCDRAM / Phi, we need to fix this more basic NUMA topology setup. > > > Now here I'd like to discuss these questions: > > 1. This feature is only for Phi at present, but we > > will check Phi platform for CPU-less NUMA node. > > The NUMA node without CPU indicates MCDRAM node. > > We should not assume such semantics - it is a concept that is specific to particular Intel x86_64 CPUs. We need to consider that other architectures may have nodes without CPUs that are backed by normal DDR. > IOW, we shoud be explicit about presence of MCDRAM in the host. > Agreed, but for KNL, that is how we detect MCDRAM on host: 1. detect CPU family is Xeon Phi X200 (means KNL) 2. enumerate all NUMA nodes and regard the nodes that contain memory only as MCDRAM nodes. ... Thanks, -He

4 6

[libvirt] [PATCH 0/3] qemu: fix pit timer tick policy
by Maxim Nestratov 06 Jan '17

06 Jan '17

Maxim Nestratov (3): qemu: fix pit timer tick policy=delay qemu: allow to specify pit timer tick policy=discard qemu: tests: add "no-kvm-pit-device" testcase src/qemu/qemu_command.c | 10 ++++++-- .../qemuxml2argv-kvm-pit-delay.args | 2 +- .../qemuxml2argv-kvm-pit-device.xml | 2 +- .../qemuxml2argv-no-kvm-pit-device.args | 23 +++++++++++++++++ .../qemuxml2argv-no-kvm-pit-device.xml | 29 ++++++++++++++++++++++ tests/qemuxml2argvtest.c | 5 ++-- 6 files changed, 64 insertions(+), 7 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-no-kvm-pit-device.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-no-kvm-pit-device.xml -- 2.4.11

2 9

[libvirt] [libivrt] storage: Two iSCSI node records may cause refreshing iscsi pool failed
by Shichangkuo 06 Jan '17

06 Jan '17

Hi, John When starting an iscsi storage pool, libvirt will execute “iscsiadm --mode node --portal 192.168.0.42 --targetname iqn.2003-10.com.xxxx --op new”, which is called by virISCSINodeNew. This will add an iSCSI node record. The record file is /etc/iscsi/nodes/iqn.2003-10.com.xxxx/192.168.0.42,3260. When we already executed "iscsiadm --mode discovery --type sendtargets --portal 192.168.0.42 --op new", another iSCSI node record will be produced in /etc/iscsi/nodes/iqn.2003-10.com.xxxx/192.168.0.42,3260,1/default. Then two iscsi sessions, as [2] and [3], will be logged in when we start the pool. Device of session [2] is /dev/sde, and device of session [3] is /dev/sdf. But there is only one path in /dev/disk/by-path, let's assume it is /dev/sdf. Refreshing storage pool will choose first session, like [2], and libvirt will find sde NOT sdf in /dev/disk/by-path. We will not find sde, then no volumes is found in the pool. I think the root reason is we have two iSCSI node records. Can we use "iscsiadm --mode discovery --type sendtargets --portal 192.168.0.42 --op new" in virISCSINodeNew? diff --git a/src/util/viriscsi.c b/src/util/viriscsi.c index 504ffbd..a8a8644 100644 --- a/src/util/viriscsi.c +++ b/src/util/viriscsi.c @@ -469,9 +469,9 @@ virISCSINodeNew(const char *portal, int ret = -1; cmd = virCommandNewArgList(ISCSIADM, - "--mode", "node", + "--mode", "discovery", + "--type", "sendtargets", "--portal", portal, - "--targetname", target, "--op", "new", NULL); Thanks, Changkuo. ------------------------------------------------------------------------------------------------------------------------------------- 本邮件及其附件含有杭州华三通信技术有限公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

2 1

[libvirt] [PATCH] internal: Simplify STREQ_NULLABLE
by Michal Privoznik 05 Jan '17

05 Jan '17

Our STREQ_NULLABLE and STRNEQ_NULLABLE macros are too complicated. This was a result of some broken version of gcc. However, that is long gone and therefore we can simplify the macros. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/internal.h | 4 ++-- tests/virstringtest.c | 61 +++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 63 insertions(+), 2 deletions(-) diff --git a/src/internal.h b/src/internal.h index d8cc5adc3..334659d32 100644 --- a/src/internal.h +++ b/src/internal.h @@ -92,9 +92,9 @@ # define STRSKIP(a, b) (STRPREFIX(a, b) ? (a) + strlen(b) : NULL) # define STREQ_NULLABLE(a, b) \ - ((a) ? (b) && STREQ((a) ? (a) : "", (b) ? (b) : "") : !(b)) + ((a) ? (b) && STREQ((a), (b)) : !(b)) # define STRNEQ_NULLABLE(a, b) \ - ((a) ? !(b) || STRNEQ((a) ? (a) : "", (b) ? (b) : "") : !!(b)) + ((a) ? !(b) || STRNEQ((a), (b)) : !!(b)) # define NUL_TERMINATE(buf) do { (buf)[sizeof(buf)-1] = '\0'; } while (0) # define ARRAY_CARDINALITY(Array) (sizeof(Array) / sizeof(*(Array))) diff --git a/tests/virstringtest.c b/tests/virstringtest.c index 1d660b798..db1731f96 100644 --- a/tests/virstringtest.c +++ b/tests/virstringtest.c @@ -34,6 +34,53 @@ VIR_LOG_INIT("tests.stringtest"); +struct testStreqData { + const char *a; + const char *b; +}; + +static int testStreq(const void *args) +{ + const struct testStreqData *data = args; + int ret = -1; + bool equal = true; + bool streq_rv, strneq_rv; + size_t i; + + if ((size_t) data->a ^ (size_t) data->b) + equal = false; + if (data->a && data->b) { + for (i = 0; data->a[i] != '\0'; i++) { + if (data->b[i] == '\0' || + data->a[i] != data->b[i]) { + equal = false; + break; + } + } + } + + streq_rv = STREQ_NULLABLE(data->a, data->b); + strneq_rv = STRNEQ_NULLABLE(data->a, data->b); + + if (streq_rv != equal) { + virFilePrintf(stderr, + "STREQ not working correctly. Expected %d got %d", + (int) equal, (int) streq_rv); + goto cleanup; + } + + if (strneq_rv == equal) { + virFilePrintf(stderr, + "STRNEQ not working correctly. Expected %d got %d", + (int) equal, (int) strneq_rv); + goto cleanup; + } + + ret = 0; + cleanup: + return ret; +} + struct testSplitData { const char *string; const char *delim; @@ -651,6 +698,20 @@ mymain(void) { int ret = 0; +#define TEST_STREQ(aa, bb) \ + do { \ + struct testStreqData streqData = {.a = aa, .b = bb}; \ + if (virTestRun("Streq", testStreq, &streqData) < 0) \ + ret = -1; \ + } while (0) + + TEST_STREQ("hello", "world"); + TEST_STREQ(NULL, NULL); + TEST_STREQ(NULL, ""); + TEST_STREQ("", NULL); + TEST_STREQ("", ""); + TEST_STREQ("hello", "hello"); + #define TEST_SPLIT(str, del, max, toks) \ do { \ struct testSplitData splitData = { \ -- 2.11.0

2 2

[libvirt] Loosing lxc guests when restarting libvirt
by Christian Ehrhardt 05 Jan '17

05 Jan '17

Hi, I found an issue in libvirt related to libvirt-lxc, but fail to find the root cause. The TL;DR is: libvirt-lxc guests get killed on libvirt restart due to "internal error: No valid cgroup for machine" It was able to reproduce libvirt 1.3.1, 2.4 and 2.5 as packages in Ubuntu and Debian. I wanted to ask for two things: - wider coverage where this does reproduce - your expertise on the case itself. Steps to reproduce: 1. Spawn new KVM Guest of your choice 2. install test dependencies $ apt-get install libvirt-daemon-system libvirt-clients libxml2-utils # or package managers / package names of your chosen os 3. run the following sequence as root export LIBVIRT_DEFAULT_URI=lxc:/// cat << EOF > /tmp/smoke-lxc.xml <domain type='lxc'> <name>sl</name> <memory unit='KiB'>256000</memory> <currentMemory unit='KiB'>256000</currentMemory> <vcpu placement='static'>1</vcpu> <os> <type>exe</type> <init>/bin/bash</init> </os> <features> <privnet/> </features> <clock offset='utc'/> <devices> <emulator>/usr/lib/libvirt/libvirt_lxc</emulator> <filesystem type='mount' accessmode='passthrough'> <source dir='/'/> <target dir='/'/> </filesystem> <console type='pty'> <target type='lxc' port='0'/> </console> </devices> </domain> EOF virsh define /tmp/smoke-lxc.xml virsh start sl virsh list --all # is running now /etc/init.d/libvirtd restart virsh list --all # is no more running, but it should Way more background and detail can be found at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848317 -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd

4 5

[libvirt] [PATCH] Changes to support Veritas HyperScale (VxHS) block device protocol with qemu-kvm
by Ashish Mittal 05 Jan '17

05 Jan '17

Sample XML for a vxhs vdisk is as follows: <disk type='network' device='disk'> <driver name='qemu' type='raw' cache='none'/> <source protocol='vxhs' name='eb90327c-8302-4725-9e1b-4e85ed4dc251'> <host name='192.168.0.1' port='9999'/> </source> <backingStore/> <target dev='vda' bus='virtio'/> <serial>eb90327c-8302-4725-9e1b-4e85ed4dc251</serial> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> Signed-off-by: Ashish Mittal <Ashish.Mittal(a)veritas.com> --- docs/formatdomain.html.in | 12 ++++++-- docs/schemas/domaincommon.rng | 1 + src/qemu/qemu_command.c | 4 +++ src/qemu/qemu_driver.c | 3 ++ src/qemu/qemu_parse_command.c | 25 ++++++++++++++++ src/util/virstoragefile.c | 4 ++- src/util/virstoragefile.h | 1 + .../qemuxml2argv-disk-drive-network-vxhs.args | 23 +++++++++++++++ .../qemuxml2argv-disk-drive-network-vxhs.xml | 34 ++++++++++++++++++++++ tests/qemuxml2argvtest.c | 1 + 10 files changed, 104 insertions(+), 4 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-vxhs.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-vxhs.xml diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 11b3330..ade35a3 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -2276,9 +2276,9 @@ <dd> The <code>protocol</code> attribute specifies the protocol to access to the requested image. Possible values are "nbd", - "iscsi", "rbd", "sheepdog" or "gluster". If the - <code>protocol</code> attribute is "rbd", "sheepdog" or - "gluster", an additional attribute <code>name</code> is + "iscsi", "rbd", "sheepdog", "gluster" or "vxhs". If the + <code>protocol</code> attribute is "rbd", "sheepdog", "gluster" + or "vxhs", an additional attribute <code>name</code> is mandatory to specify which volume/image will be used. For "nbd", the <code>name</code> attribute is optional. For "iscsi" (<span class="since">since 1.0.4</span>), the <code>name</code> @@ -2388,6 +2388,12 @@ <td> one or more (<span class="since">Since 2.1.0</span>), just one prior to that </td> <td> 24007 </td> </tr> + <tr> + <td> vxhs </td> + <td> a server running Veritas HyperScale daemon </td> + <td> only one </td> + <td> 9999 </td> + </tr> </table> <p> gluster supports "tcp", "rdma", "unix" as valid values for the diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng index 19d45fd..e569e0a 100644 --- a/docs/schemas/domaincommon.rng +++ b/docs/schemas/domaincommon.rng @@ -1464,6 +1464,7 @@ <value>ftp</value> <value>ftps</value> <value>tftp</value> + <value>vxhs</value> </choice> </attribute> <optional> diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 4a5fce3..c7b95aa 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -491,6 +491,9 @@ qemuNetworkDriveGetPort(int protocol, /* no default port specified */ return 0; + case VIR_STORAGE_NET_PROTOCOL_VXHS: + return 9999; + case VIR_STORAGE_NET_PROTOCOL_RBD: case VIR_STORAGE_NET_PROTOCOL_LAST: case VIR_STORAGE_NET_PROTOCOL_NONE: @@ -1034,6 +1037,7 @@ qemuBuildNetworkDriveStr(virStorageSourcePtr src, case VIR_STORAGE_NET_PROTOCOL_TFTP: case VIR_STORAGE_NET_PROTOCOL_ISCSI: case VIR_STORAGE_NET_PROTOCOL_GLUSTER: + case VIR_STORAGE_NET_PROTOCOL_VXHS: ret = qemuBuildNetworkDriveURI(src, secinfo); break; diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index a82e58b..4910004 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -13724,6 +13724,7 @@ qemuDomainSnapshotPrepareDiskExternalBackingInactive(virDomainDiskDefPtr disk) case VIR_STORAGE_NET_PROTOCOL_FTPS: case VIR_STORAGE_NET_PROTOCOL_TFTP: case VIR_STORAGE_NET_PROTOCOL_SSH: + case VIR_STORAGE_NET_PROTOCOL_VXHS: case VIR_STORAGE_NET_PROTOCOL_LAST: virReportError(VIR_ERR_INTERNAL_ERROR, _("external inactive snapshots are not supported on " @@ -13787,6 +13788,7 @@ qemuDomainSnapshotPrepareDiskExternalOverlayActive(virDomainSnapshotDiskDefPtr d case VIR_STORAGE_NET_PROTOCOL_FTPS: case VIR_STORAGE_NET_PROTOCOL_TFTP: case VIR_STORAGE_NET_PROTOCOL_SSH: + case VIR_STORAGE_NET_PROTOCOL_VXHS: case VIR_STORAGE_NET_PROTOCOL_LAST: virReportError(VIR_ERR_INTERNAL_ERROR, _("external active snapshots are not supported on " @@ -13932,6 +13934,7 @@ qemuDomainSnapshotPrepareDiskInternal(virConnectPtr conn, case VIR_STORAGE_NET_PROTOCOL_FTPS: case VIR_STORAGE_NET_PROTOCOL_TFTP: case VIR_STORAGE_NET_PROTOCOL_SSH: + case VIR_STORAGE_NET_PROTOCOL_VXHS: case VIR_STORAGE_NET_PROTOCOL_LAST: virReportError(VIR_ERR_INTERNAL_ERROR, _("internal inactive snapshots are not supported on " diff --git a/src/qemu/qemu_parse_command.c b/src/qemu/qemu_parse_command.c index c3b27aa..f2edc28 100644 --- a/src/qemu/qemu_parse_command.c +++ b/src/qemu/qemu_parse_command.c @@ -263,6 +263,16 @@ qemuParseNBDString(virDomainDiskDefPtr disk) return -1; } +static int +qemuParseVxHSString(virDomainDiskDefPtr def) +{ + virURIPtr uri = NULL; + + if (!(uri = virURIParse(def->src->path))) + return -1; + + return qemuParseDriveURIString(def, uri, "vxhs"); +} /* * This method takes a string representing a QEMU command line ARGV set @@ -737,6 +747,12 @@ qemuParseCommandLineDisk(virDomainXMLOptionPtr xmlopt, if (VIR_STRDUP(def->src->path, vdi) < 0) goto error; } + } else if (STRPREFIX(def->src->path, "vxhs:")) { + def->src->type = VIR_STORAGE_TYPE_NETWORK; + def->src->protocol = VIR_STORAGE_NET_PROTOCOL_VXHS; + + if (qemuParseVxHSString(def) < 0) + goto error; } else { def->src->type = VIR_STORAGE_TYPE_FILE; } @@ -1933,6 +1949,10 @@ qemuParseCommandLine(virCapsPtr caps, disk->src->type = VIR_STORAGE_TYPE_NETWORK; disk->src->protocol = VIR_STORAGE_NET_PROTOCOL_SHEEPDOG; val += strlen("sheepdog:"); + } else if (STRPREFIX(val, "vxhs:")) { + disk->src->type = VIR_STORAGE_TYPE_NETWORK; + disk->src->protocol = VIR_STORAGE_NET_PROTOCOL_VXHS; + val += strlen("vxhs:"); } else { disk->src->type = VIR_STORAGE_TYPE_FILE; } @@ -2009,6 +2029,11 @@ qemuParseCommandLine(virCapsPtr caps, goto error; break; + case VIR_STORAGE_NET_PROTOCOL_VXHS: + if (qemuParseVxHSString(disk) < 0) + goto error; + + break; case VIR_STORAGE_NET_PROTOCOL_HTTP: case VIR_STORAGE_NET_PROTOCOL_HTTPS: case VIR_STORAGE_NET_PROTOCOL_FTP: diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c index 272db67..a730a01 100644 --- a/src/util/virstoragefile.c +++ b/src/util/virstoragefile.c @@ -86,7 +86,8 @@ VIR_ENUM_IMPL(virStorageNetProtocol, VIR_STORAGE_NET_PROTOCOL_LAST, "ftp", "ftps", "tftp", - "ssh") + "ssh", + "vxhs") VIR_ENUM_IMPL(virStorageNetHostTransport, VIR_STORAGE_NET_HOST_TRANS_LAST, "tcp", @@ -2634,6 +2635,7 @@ virStorageSourceParseBackingColon(virStorageSourcePtr src, case VIR_STORAGE_NET_PROTOCOL_ISCSI: case VIR_STORAGE_NET_PROTOCOL_GLUSTER: case VIR_STORAGE_NET_PROTOCOL_SSH: + case VIR_STORAGE_NET_PROTOCOL_VXHS: virReportError(VIR_ERR_INTERNAL_ERROR, _("malformed backing store path for protocol %s"), protocol); diff --git a/src/util/virstoragefile.h b/src/util/virstoragefile.h index 3d09468..88dff36 100644 --- a/src/util/virstoragefile.h +++ b/src/util/virstoragefile.h @@ -132,6 +132,7 @@ typedef enum { VIR_STORAGE_NET_PROTOCOL_FTPS, VIR_STORAGE_NET_PROTOCOL_TFTP, VIR_STORAGE_NET_PROTOCOL_SSH, + VIR_STORAGE_NET_PROTOCOL_VXHS, VIR_STORAGE_NET_PROTOCOL_LAST } virStorageNetProtocol; diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-vxhs.args b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-vxhs.args new file mode 100644 index 0000000..3d37b00 --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-vxhs.args @@ -0,0 +1,23 @@ +LC_ALL=C \ +PATH=/bin \ +HOME=/home/test \ +USER=test \ +LOGNAME=test \ +QEMU_AUDIO_DRV=none \ +/usr/libexec/qemu-kvm \ +-name QEMUGuest1 \ +-S \ +-M pc \ +-cpu qemu32 \ +-m 214 \ +-smp 1,sockets=1,cores=1,threads=1 \ +-uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \ +-nographic \ +-nodefaults \ +-monitor unix:/tmp/lib/domain--1-QEMUGuest1/monitor.sock,server,nowait \ +-no-acpi \ +-boot c \ +-usb \ +-drive file=vxhs://192.168.0.1:9999/eb90327c-8302-4725-9e1b-4e85ed4dc251,\ +format=raw,if=none,id=drive-virtio-disk0,cache=none \ +-device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-vxhs.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-vxhs.xml new file mode 100644 index 0000000..45c807f --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-vxhs.xml @@ -0,0 +1,34 @@ +<domain type='qemu'> + <name>QEMUGuest1</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>219136</memory> + <currentMemory unit='KiB'>219136</currentMemory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='i686' machine='pc'>hvm</type> + <boot dev='hd'/> + </os> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/libexec/qemu-kvm</emulator> + <disk type='network' device='disk'> + <driver name='qemu' type='raw' cache='none'/> + <source protocol='vxhs' name='eb90327c-8302-4725-9e1b-4e85ed4dc251'> + <host name='192.168.0.1' port='9999'/> + </source> + <backingStore/> + <target dev='vda' bus='virtio'/> + <serial>eb90327c-8302-4725-9e1b-4e85ed4dc251</serial> + <alias name='virtio-disk0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </disk> + <controller type='usb' index='0'/> + <controller type='pci' index='0' model='pci-root'/> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <memballoon model='none'/> + </devices> +</domain> diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index 1ee8402..d94e3f2 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -869,6 +869,7 @@ mymain(void) # endif DO_TEST("disk-drive-network-rbd-ipv6", NONE); DO_TEST_FAILURE("disk-drive-network-rbd-no-colon", NONE); + DO_TEST("disk-drive-network-vxhs", NONE); DO_TEST("disk-drive-no-boot", QEMU_CAPS_BOOTINDEX); DO_TEST_PARSE_ERROR("disk-device-lun-type-invalid", -- 2.5.5

4 8

[libvirt] [PATCH] NEWS: Update after qemu namespace fix
by Michal Privoznik 05 Jan '17

05 Jan '17

Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Pushed under my-christmas-gift-to-libvirt rule. docs/news.html.in | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/news.html.in b/docs/news.html.in index 36c7d3d66..e544cfa38 100644 --- a/docs/news.html.in +++ b/docs/news.html.in @@ -67,6 +67,10 @@ The chardev detection code has been improved and can now handle this configuration properly </li> + <li>qemu: Enable mount namespace<br/> + To avoid funny races with udev relabelling devices under our hands and + to enhance security, libvirt now spawns each qemu process with its own + <code>/dev</code>.</li> </ul> </li> </ul> -- 2.11.0

4 3

[libvirt] Issue with libvirtd
by Faysal Ali 05 Jan '17

05 Jan '17

Hi I have a CentOS 7.3 server where I am running KVM with few virtual machines. I noticed this being repeated regularly in /var/log/messages *libvirtd[1956]: End of file while reading data: Input/output error* Anyone have seen that happening ?? Any idea where should I dig more ?? Br. Umar

2 1