> Hi! Thanks for explaining how TLS could work for block devices
in
> general, and specifically for VxHS. I agree that the plan should be to
> first have the base VxHS patch ready (sans TLS support), and then
> build the TLS support in a series of patches on top of the base patch.
> To that end, I have made changes to v3 to fix the problems pointed out
> in this series and plan to submit the new patch soon. I do have some
> confusion regarding your comment above - I thought I have already
> implemented the new syntax similar to gluster's "-drive
> 'file.driver=gluster,file.volume=..." in this v3 patch series.
>
>>>> v3 changelog:
>>>> (1) Implemented the modern syntax for VxHS disk specification.
>>>> (2) Changed qemuxml2argvdata VxHS test case to verify the new syntax.
>
> Please see the newly added xml2argv test +++
> b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-vxhs.args
>
> +-drive file.driver=vxhs,file.vdisk-id=eb90327c-8302-4725-9e1b-4e85ed4dc251,\
> +file.server.host=192.168.0.1,file.server.port=9999,format=raw,if=none,\
>
> Let me know if I'm still missing something on the new syntax. Thanks!
>
I've made some changes over v3 -
(1) Review comments incorporated
(2) Changed code to error out with proper error message on URI syntax.
Added new test cases to check this.
Changes can be reviewed here before I email the new patch -
https://github.com/libvirt/libvirt/compare/master...MittalAshish:basechan...
I will send out the new patch if nothing else is missing in the base
functionality.
Thanks!
Sorry - been focused on my own work lately, but will try to spend a few
cycles on this today. I don't have the context fully "paged in" from the
previous series and the recent responses. Heck I've almost forgotten the
recent ones. I can guarantee though that you won't make 3.3 on any of
these changes. Also I'm not a fan of github diff sets.
John
[...]