Vdsm sync call May 13, 2014 =========================== (Join us every other week, 14:30 GMT, on https://bluejeans.com/35386075901 or https://www.intercallonline.com/listNumbersByCode.action?confCode=3538607... ) =========================== - We had a long descussion about multiple graphic devices http://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:... - fromani to figure out whether libvirt intends to provide an "alias" for graphics devices. Without it, it would be next-to-impossible to support multiple spice devices. It's already cumbersome to tell spice from vnc devices. - On input, Vdsm must accept both legacy display definitions (in vm.conf) and new-style ones (in vm.conf['devices']). If both exist, legacy ones are to be ignored. - writeable floppies. We believe that they were never used. Currently, vdsm makes floppies writable based on the writability of their filesystem imagea, and checks it in an unsafe manner. So we intend to make all floppies read-only. Actually, it would be nicer to expose a "readonly" flag, so that the client can use in case it really needs to write on the floppy (such as for saving Doom I game state). - live merge Saggi to review Adam's patches, and see if their use of task id is acceptable to him, and would follow the devel(a)ovirt.org thread on the matter. I'm still worried about Engine trusting the vdsm mapping of taskid to (vmid,volumeid), as Vdsm can crash and disappear. - unified network persistence. recently, unified persistence has become the default on the master branch http://gerrit.ovirt.org/25784 this may cause breakage to post-boot network connectivity, in case vdsm fails to start. - To avoid this fragility, we plan to have a leaner standalone service to configure networking on boot. - As a stopgap measure, the management network would be set as ONBOOT=yes, so that most setup would keep their connectivity. please report other problems! - ioprocess integration There's a worry regarding the path of replacing remote-file-handler with ioprocess. Currently, ioprocess is mimicking rfh semantics, while it is more reasonable to align with the future, and make the current rfh implementation mimick ioprocess. When network decided to move away from ifcfg to iproute2, we refactor the code to support both (with configurators), implemented iproute2, and only recently - moved to use it by default. This path ensures that we're not stuck with a convoluted code that matches no implementation. Have I forgotten anything? Dan.