12:09 p.m.
v6: https://www.redhat.com/archives/libvir-list/2017-August/msg00993.html
Changes/notes since v6:
Patch1 - Used the "right" process to create the files. There's also a
separate patch on list which I used mainly to "extract" the
details/needs from being associated specifically with the
addition of VxHS support
Patch2 - Altered the commit message slightly to note that lack of
ability to actually check that even though something is
introspectible, there's no "non-hacky" way to determine if
the QEMU image being used was built "--enable=vxhs" *unless*
(as Jeff Cody points out) we scan --help output for vxhs within
the "Supported formats:" line. We're avoiding that path for
many different reasons.
Patch3 -> Patch5
- No change, patches ACKed.
Patch6 - Removed qemuCaps from qemuBlockStorageSourceGetVxHSProps and
created a qemuProcessStartValidateDisks which will run the
disk list looking for NETWORK and VXHS to ensure the
QEMU_CAPS_VXHS bit is set. Also added a note here similar
to patch2 describing the "gotcha" with the processing.
Patch7 - Altered the text of the vxhs_tls description a bit, not much
Patch8 - Altered the formatdomain.html.in description a bit in order to
remove the previous restriction surrounding when vxhs_tls = 0,
but src->haveTLS = YES.
Added a tlsFromConfig boolean to virStorageSource to match the
same logic as chardev's use. Documented it's use though as every
time I've read that for chardev, I've first said tlsFromConfig
must mean domain config, when in fact it's meant to be qemu.conf.
Make code adjustments to handle tlsFromConfig
Patch9 - Altered the order here - used to be flip-flopped with subsequent
patch. Create the qemuDomainPrepareDiskSource[TLS] API's in order
manage the src->haveTLS setting just as we've done for chardev.
Also, introduce and manage a virStorageSource "tlsAlias" field.
This is where we'll "set" the alias to be used.
Patch10- Fixed up the virStorageSourceParseBackingJSONVxHS and
TEST_BACKING_PARSE to manage the new src->tlsAlias field.
Patch11- Make this all work for qemu_command *and* qemu_hotplug - well
theoretically at least.
The hotplug code is new in this patch - it has essentially
copied what was needed from qemuDomainAddChardevTLSObjects
and applied it to the needs for disks in general, but mainly
for VxHS in particular.
The qemuDomainAddDiskTLSObjects also doesn't set a 'tlscreds'
boolean like Chardev does since JSON object generation doesn't
occur in the depths of qemu_monitor_json, but rather it occurs
in qemu_block and we have everything we need there. Probably
could have done the chardev code differently to keep the TLS
alias around...
Although I don't believe VxHS has support/need for MassUSB
and SCSI Disk operations, adding the infrastructure there
should be usable for future needs. I also left a note about
future needs that may arise if some network disk type requires
a secret to decrypt a server key (although I cannot imagine
the need, someone else may have a better imagination than me).
The rest of the qemu_command changes remove the qemuCaps and
diskAlias parameters from the qemuBlockStorageSourceGetBackendProps
API and use what's been (hopefully) properly set up during
qemuDomainPrepareDiskSourceTLS.
Finally former patch12 has been removed since there is no
restriction regarding vxhs_tls = 0 and "tls = 'yes'"... Also
former patch13 has been merged into patch11.
Still to be done:
Patch12 - A news.xml article for 3.8.0, but 3.7.0 isn't closed yet
so I'm waiting...
Testing, testing, testing, testing, testing, and more testing. Hopefully
even some hotplug testing as I have absolutely no way to know if the
changes I've made actually work since I don't have a Veritas enviroment
set up. I leave the testing/debugging to Ashish.
I do believe that patches 1-5 (e.g. everything not TLS related are
reasonable and ready once 3.8.0 opens for business).
Ashish Mittal (8):
storage: Introduce VIR_STORAGE_NET_PROTOCOL_VXHS
docs: Add schema and docs for Veritas HyperScale (VxHS)
util: storage: Add JSON backing volume parse for VxHS
qemu: Add qemu command line generation for a VxHS block device
conf: Introduce TLS options for VxHS block device clients
util: Add TLS attributes to virStorageSource
util: Add virstoragetest to parse/format a tls='yes'
qemu: Add TLS support for Veritas HyperScale (VxHS)
John Ferlan (3):
qemu: Add QEMU 2.10 x86_64 the generated capabilities
qemu: Detect support for vxhs
qemu: Introduce qemuDomainPrepareDiskSource
docs/formatdomain.html.in | 45 +-
docs/schemas/domaincommon.rng | 18 +
src/conf/domain_conf.c | 28 +-
src/libxl/libxl_conf.c | 1 +
src/qemu/libvirtd_qemu.aug | 4 +
src/qemu/qemu.conf | 34 +
src/qemu/qemu_block.c | 44 +
src/qemu/qemu_capabilities.c | 4 +
src/qemu/qemu_capabilities.h | 3 +
src/qemu/qemu_command.c | 38 +
src/qemu/qemu_conf.c | 16 +
src/qemu/qemu_conf.h | 3 +
src/qemu/qemu_domain.c | 71 +
src/qemu/qemu_domain.h | 11 +
src/qemu/qemu_driver.c | 3 +
src/qemu/qemu_hotplug.c | 73 +
src/qemu/qemu_parse_command.c | 15 +
src/qemu/qemu_process.c | 33 +
src/qemu/test_libvirtd_qemu.aug.in | 2 +
src/util/virstoragefile.c | 58 +-
src/util/virstoragefile.h | 14 +
src/xenconfig/xen_xl.c | 1 +
.../caps_2.10.0.x86_64.replies | 18144 +++++++++++++++++++
tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml | 799 +
tests/qemucapabilitiestest.c | 1 +
...-disk-drive-network-tlsx509-multidisk-vxhs.args | 43 +
...v-disk-drive-network-tlsx509-multidisk-vxhs.xml | 50 +
...muxml2argv-disk-drive-network-tlsx509-vxhs.args | 30 +
...emuxml2argv-disk-drive-network-tlsx509-vxhs.xml | 32 +
.../qemuxml2argv-disk-drive-network-vxhs.args | 27 +
.../qemuxml2argv-disk-drive-network-vxhs.xml | 32 +
tests/qemuxml2argvtest.c | 8 +
...uxml2xmlout-disk-drive-network-tlsx509-vxhs.xml | 34 +
.../qemuxml2xmlout-disk-drive-network-vxhs.xml | 34 +
tests/qemuxml2xmltest.c | 2 +
tests/virstoragetest.c | 23 +
36 files changed, 19766 insertions(+), 12 deletions(-)
create mode 100644 tests/qemucapabilitiesdata/caps_2.10.0.x86_64.replies
create mode 100644 tests/qemucapabilitiesdata/caps_2.10.0.x86_64.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.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
create mode 100644
tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-drive-network-tlsx509-vxhs.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-drive-network-vxhs.xml
--
2.9.5