Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary
On 26/11/12 16:59, Adam Litke wrote: On Mon, Nov 26, 2012 at 02:57:19PM +0200, Livnat Peer wrote: On 26/11/12 03:15, Shu Ming wrote: Livnat, Thanks for your summary. I got comments below. 2012-11-25 18:53, Livnat Peer: Hi All, We have been discussing $subject for a while and I'd like to summarized what we agreed and disagreed on thus far. The way I see it there are two related discussions: 1. Getting VDSM networking stack to be distribution agnostic. - We are all in agreement that VDSM API should be generic enough to incorporate multiple implementation. (discussed on this thread: Alon's suggestion, Mark's patch for adding support for netcf etc.) - We would like to maintain at least one implementation as the working/up-to-date implementation for our users, this implementation should be distribution agnostic (as we all acknowledge this is an important goal for VDSM). I also think that with the agreement of this community we can choose to change our focus, from time to time, from one implementation to another as we see fit (today it can be OVS+netcf and in a few months we'll use the quantum based implementation if we agree it is better) 2. The second discussion is about persisting the network configuration on the host vs. dynamically retrieving it from a centralized location like the engine. Danken raised a concern that even if going with the dynamic approach the host should persist the management network configuration. About dynamical retrieving from a centralized location, when will the retrieving start? Just in the very early stage of host booting before network functions? Or after the host startup and in the normal running state of the host? Before retrieving the configuration, how does the host network connecting to the engine? I think we need a basic well known network between hosts and the engine first. Then after the retrieving, hosts should reconfigure the network for later management. However, the timing to retrieve and reconfigure are challenging. We did not discuss the dynamic approach in details on the list so far and I think this is a good opportunity to start this discussion... From what was discussed previously I can say that the need for a well known network was raised by danken, it was referred to as the management network, this network would be used for pulling the full host network configuration from the centralized location, at this point the engine. About the timing for retrieving the configuration, there are several approaches. One of them was described by Alon, and I think he'll join this discussion and maybe put it in his own words, but the idea was to 'keep' the network synchronized at all times. When the host have communication channel to the engine and the engine detects there is a mismatch in the host configuration, the engine initiates 'apply network configuration' action on the host. Using this approach we'll have a single path of code to maintain and that would reduce code complexity and bugs - That's quoting Alon Bar Lev (Alon I hope I did not twisted your words/idea). On the other hand the above approach makes local tweaks on the host (done manually by the administrator) much harder. I worry a lot about the above if we take the dynamic approach. It seems we'd need to introduce before/after 'apply network configuration' hooks where the admin could add custom config commands that aren't yet modeled by engine. yes, and I'm not sure the administrators would like the fact that we are 'forcing' them to write everything in a script and getting familiar with VDSM hooking mechanism (which in some cases require the use of custom properties on the engine level) instead of running a simple command line. Any other approaches ? Static configuration has the advantage of allowing a host to bring itself back online independent of the engine. This is also useful for anyone who may want to deploy a vdsm node in standalone mode. I think it would be possible to easily support a quasi-static configuration mode simply by extending the design of the dynamic approach slightly. In dynamic mode, the network configuration is passed down as a well-defined data structure. When a particular configuration has been committed, vdsm could write a copy of that configuration data structure to /var/run/vdsm/network-config.json. During a subsequent boot, if the engine cannot be contacted after activating the management network, the cached configuration can be applied using the same code as for dynamic mode. We'd have to flesh out the circumstances under which this would happen. I like this approach a lot but we need to consider that network configuration is an accumulated state, for example - 1. The engine sends a setup-network command with the full host network configuration 2. The user configures new network on the host, the engine sends a new setup-network request to VDSM which includes only the
Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary
- Original Message - From: Livnat Peer lp...@redhat.com To: Adam Litke a...@us.ibm.com Cc: Alon Bar-Lev abar...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, November 27, 2012 10:42:00 AM Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary On 26/11/12 16:59, Adam Litke wrote: On Mon, Nov 26, 2012 at 02:57:19PM +0200, Livnat Peer wrote: On 26/11/12 03:15, Shu Ming wrote: Livnat, Thanks for your summary. I got comments below. 2012-11-25 18:53, Livnat Peer: Hi All, We have been discussing $subject for a while and I'd like to summarized what we agreed and disagreed on thus far. The way I see it there are two related discussions: 1. Getting VDSM networking stack to be distribution agnostic. - We are all in agreement that VDSM API should be generic enough to incorporate multiple implementation. (discussed on this thread: Alon's suggestion, Mark's patch for adding support for netcf etc.) - We would like to maintain at least one implementation as the working/up-to-date implementation for our users, this implementation should be distribution agnostic (as we all acknowledge this is an important goal for VDSM). I also think that with the agreement of this community we can choose to change our focus, from time to time, from one implementation to another as we see fit (today it can be OVS+netcf and in a few months we'll use the quantum based implementation if we agree it is better) 2. The second discussion is about persisting the network configuration on the host vs. dynamically retrieving it from a centralized location like the engine. Danken raised a concern that even if going with the dynamic approach the host should persist the management network configuration. About dynamical retrieving from a centralized location, when will the retrieving start? Just in the very early stage of host booting before network functions? Or after the host startup and in the normal running state of the host? Before retrieving the configuration, how does the host network connecting to the engine? I think we need a basic well known network between hosts and the engine first. Then after the retrieving, hosts should reconfigure the network for later management. However, the timing to retrieve and reconfigure are challenging. We did not discuss the dynamic approach in details on the list so far and I think this is a good opportunity to start this discussion... From what was discussed previously I can say that the need for a well known network was raised by danken, it was referred to as the management network, this network would be used for pulling the full host network configuration from the centralized location, at this point the engine. About the timing for retrieving the configuration, there are several approaches. One of them was described by Alon, and I think he'll join this discussion and maybe put it in his own words, but the idea was to 'keep' the network synchronized at all times. When the host have communication channel to the engine and the engine detects there is a mismatch in the host configuration, the engine initiates 'apply network configuration' action on the host. Using this approach we'll have a single path of code to maintain and that would reduce code complexity and bugs - That's quoting Alon Bar Lev (Alon I hope I did not twisted your words/idea). On the other hand the above approach makes local tweaks on the host (done manually by the administrator) much harder. I worry a lot about the above if we take the dynamic approach. It seems we'd need to introduce before/after 'apply network configuration' hooks where the admin could add custom config commands that aren't yet modeled by engine. yes, and I'm not sure the administrators would like the fact that we are 'forcing' them to write everything in a script and getting familiar with VDSM hooking mechanism (which in some cases require the use of custom properties on the engine level) instead of running a simple command line. In which case will we force? Please be more specific. If we can pass most of the iproute2, brctl, bond parameters via key/value pairs via the API, what in your view that is common or even seldom should be used? This hook mechanism is only as fallback, provided to calm people down. Any other approaches ? Static configuration has the advantage of allowing a host to bring itself back online independent of the engine. This is also useful for anyone who may want to deploy a vdsm node in standalone mode. I think it would be possible to easily support a quasi-static configuration mode simply by extending the design of the dynamic approach slightly. In dynamic mode, the network configuration is passed down as a
Re: [vdsm] [RFC]about the implement of text-based console
Hi all, For now in there is no agreement on the remote guest console solution, so I decide to do some investigation continue the discussion. Our goal VM serial console remote access in CLI mode. That means the client runs without X environment. There are several proposals. 1. Sandboxed sshd VDSM runs a new host sshd instance in virtual machine/sandbox and redirects the virtio console to it. 2. Third-party sshd VDSM runs third-party sshd library/implementation and redirects virtio console to it. 3. Spice Extend spice to support console and implement a client to be run without GUI environment 4. oVirt shell - Engine - libvirt The user connects to Engine via oVirt CLI, then issues a serial-console command, then Engine locates the host and connect to the guest console. Currently there is a workaround, it invokes virsh -c qemu+tls://host/qemu console vmid from Engine side. 5. VDSM console streaming API VDSM exposes getConsoleReadStream() and getConsoleWriteStream() via XMLRPC binding. Then implement the related client in vdsClient and Engine Detailed discussion 1. Sandboxes Solution 1 and 2 allow users connect to console using their favorite ssh client. The login name is vmid, the password is set by setVmTicket() call of VDSM. The connection will be lost during migration. This is similar to VNC in oVirt. I take a look at several sandbox technologies, including libvirt-sandbox, lxc and selinux. a) libvirt-sandbox boots a VM using host kernel and initramfs, then passthru the host file system to the VM in read only mode. We can also add extra binding to the guest file system. It's very easy to use. To run shell in a VM, one can just issues virt-sandbox -c qemu:///session /bin/sh Then the VM will be ready in several seconds. However it will trigger some selinux violations. Currently there is no official support for selinux policy configuration from this project. In the project page this is put in the todo list. b) lxc utilize Linux container to run a process in sandbox. It needs to be configured properly. I find in the package lxc-templates there is an example configuration file for running sshd in lxc. c) sandbox command in the package policycoreutils-python makes use of selinux to run a process in sandbox, but there is no official or example policy files for sshd. In a word, for sandbox technologies, we have to configure the policies/file system binding/network carefully and test the compatibility with popular sshd implementations (openssh-server). When those sshd upgrade, the policy must be upgraded by us at the same time. Since the policies are not maintained by who implements sshd, this is a burden for us. Work to do Write and maintain the policies. Find ways for auth callback and redirecting data to openssh-server. pros Re-use existing pieces and technologies (host sshd, sandbox). User friendly, they can use existing ssh clients. cons Connection is lost in migration, this is not a big problem because 1) VNC connection share the same problem, 2) the user can reconnect manually. It's not easy to maintain the sandbox policies/file system binding/network for compatibility with sshd. 2. Third-party sshd implementations Almost the same as solution 1 but with better flexibility. VDSM can import a third-party sshd library and let that library deal with auth and transport. VDSM just have to implement the data forwarding. Many people consider this is insecure but I think the ticket solution for VNC is even not as secure as this. Currently most of us only trust openssh-server and think the quality of third-party sshd is low. I searched for a while and found twisted.conch from the popular twisted project. I'm not familiar with twisted.conch, but I still put it in this mail to collect opinions from potential twisted.conch experts. In a word, I prefer sandbox technologies to third-party sshd implementations unless there is a implementation as good as openssh-server. Work to do Integrate twisted.conch into VDSM pros Very flexible. If library provide auth callback to VDSM, then VDSM can just compares the login password to the VM ticket without knowing SSH detials. cons Third party implementations are not as secure and carefully maintained as sshd in the host (probably openssh-server). 3. Extend Spice to support console Is it possible to implement a spice client can be run in pure text mode without GUI environment? If we extend the protocol to support console stream but the client must be run in GUI, it will be less useful. pros No new VMs and server process, easy for maintenance. cons Must wait for Spice developers to commit the support. Need special client program in CLI, the user may prefer existing client program like ssh. It not a big problem because this feature can be put in to oVirt shell. 4. oVirt shell - Engine - libvirtd This is the current workaround described in
Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary
On 27/11/12 10:53, Alon Bar-Lev wrote: - Original Message - From: Livnat Peer lp...@redhat.com To: Adam Litke a...@us.ibm.com Cc: Alon Bar-Lev abar...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, November 27, 2012 10:42:00 AM Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary On 26/11/12 16:59, Adam Litke wrote: On Mon, Nov 26, 2012 at 02:57:19PM +0200, Livnat Peer wrote: On 26/11/12 03:15, Shu Ming wrote: Livnat, Thanks for your summary. I got comments below. 2012-11-25 18:53, Livnat Peer: Hi All, We have been discussing $subject for a while and I'd like to summarized what we agreed and disagreed on thus far. The way I see it there are two related discussions: 1. Getting VDSM networking stack to be distribution agnostic. - We are all in agreement that VDSM API should be generic enough to incorporate multiple implementation. (discussed on this thread: Alon's suggestion, Mark's patch for adding support for netcf etc.) - We would like to maintain at least one implementation as the working/up-to-date implementation for our users, this implementation should be distribution agnostic (as we all acknowledge this is an important goal for VDSM). I also think that with the agreement of this community we can choose to change our focus, from time to time, from one implementation to another as we see fit (today it can be OVS+netcf and in a few months we'll use the quantum based implementation if we agree it is better) 2. The second discussion is about persisting the network configuration on the host vs. dynamically retrieving it from a centralized location like the engine. Danken raised a concern that even if going with the dynamic approach the host should persist the management network configuration. About dynamical retrieving from a centralized location, when will the retrieving start? Just in the very early stage of host booting before network functions? Or after the host startup and in the normal running state of the host? Before retrieving the configuration, how does the host network connecting to the engine? I think we need a basic well known network between hosts and the engine first. Then after the retrieving, hosts should reconfigure the network for later management. However, the timing to retrieve and reconfigure are challenging. We did not discuss the dynamic approach in details on the list so far and I think this is a good opportunity to start this discussion... From what was discussed previously I can say that the need for a well known network was raised by danken, it was referred to as the management network, this network would be used for pulling the full host network configuration from the centralized location, at this point the engine. About the timing for retrieving the configuration, there are several approaches. One of them was described by Alon, and I think he'll join this discussion and maybe put it in his own words, but the idea was to 'keep' the network synchronized at all times. When the host have communication channel to the engine and the engine detects there is a mismatch in the host configuration, the engine initiates 'apply network configuration' action on the host. Using this approach we'll have a single path of code to maintain and that would reduce code complexity and bugs - That's quoting Alon Bar Lev (Alon I hope I did not twisted your words/idea). On the other hand the above approach makes local tweaks on the host (done manually by the administrator) much harder. I worry a lot about the above if we take the dynamic approach. It seems we'd need to introduce before/after 'apply network configuration' hooks where the admin could add custom config commands that aren't yet modeled by engine. yes, and I'm not sure the administrators would like the fact that we are 'forcing' them to write everything in a script and getting familiar with VDSM hooking mechanism (which in some cases require the use of custom properties on the engine level) instead of running a simple command line. In which case will we force? Please be more specific. If we can pass most of the iproute2, brctl, bond parameters via key/value pairs via the API, what in your view that is common or even seldom should be used? This hook mechanism is only as fallback, provided to calm people down. I understand, I'm saying it can irritate the administrators that needs to use it, it does not help that we are calmed down ;) Just to make it clear I'm not against the stateless approach, I'm trying to understand it better and make sure we are all aware of the drawbacks this approach has. Complicating local tweaks to the admin is one of them. I'll reply on your original mail with the questions I have on your proposal. Any other approaches ? Static configuration has the advantage of allowing a host to bring itself
Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary
- Original Message - From: Livnat Peer lp...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org, Shu Ming shum...@linux.vnet.ibm.com, Saggi Mizrahi smizr...@redhat.com, Dan Kenigsberg dan...@redhat.com Sent: Tuesday, November 27, 2012 12:18:31 PM Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary On 26/11/12 22:18, Alon Bar-Lev wrote: - Original Message - From: Livnat Peer lp...@redhat.com To: Shu Ming shum...@linux.vnet.ibm.com Cc: Alon Bar-Lev abar...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Monday, November 26, 2012 2:57:19 PM Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary On 26/11/12 03:15, Shu Ming wrote: Livnat, Thanks for your summary. I got comments below. 2012-11-25 18:53, Livnat Peer: Hi All, We have been discussing $subject for a while and I'd like to summarized what we agreed and disagreed on thus far. The way I see it there are two related discussions: 1. Getting VDSM networking stack to be distribution agnostic. - We are all in agreement that VDSM API should be generic enough to incorporate multiple implementation. (discussed on this thread: Alon's suggestion, Mark's patch for adding support for netcf etc.) - We would like to maintain at least one implementation as the working/up-to-date implementation for our users, this implementation should be distribution agnostic (as we all acknowledge this is an important goal for VDSM). I also think that with the agreement of this community we can choose to change our focus, from time to time, from one implementation to another as we see fit (today it can be OVS+netcf and in a few months we'll use the quantum based implementation if we agree it is better) 2. The second discussion is about persisting the network configuration on the host vs. dynamically retrieving it from a centralized location like the engine. Danken raised a concern that even if going with the dynamic approach the host should persist the management network configuration. About dynamical retrieving from a centralized location, when will the retrieving start? Just in the very early stage of host booting before network functions? Or after the host startup and in the normal running state of the host? Before retrieving the configuration, how does the host network connecting to the engine? I think we need a basic well known network between hosts and the engine first. Then after the retrieving, hosts should reconfigure the network for later management. However, the timing to retrieve and reconfigure are challenging. We did not discuss the dynamic approach in details on the list so far and I think this is a good opportunity to start this discussion... From what was discussed previously I can say that the need for a well known network was raised by danken, it was referred to as the management network, this network would be used for pulling the full host network configuration from the centralized location, at this point the engine. About the timing for retrieving the configuration, there are several approaches. One of them was described by Alon, and I think he'll join this discussion and maybe put it in his own words, but the idea was to 'keep' the network synchronized at all times. When the host have communication channel to the engine and the engine detects there is a mismatch in the host configuration, the engine initiates 'apply network configuration' action on the host. Using this approach we'll have a single path of code to maintain and that would reduce code complexity and bugs - That's quoting Alon Bar Lev (Alon I hope I did not twisted your words/idea). On the other hand the above approach makes local tweaks on the host (done manually by the administrator) much harder. Any other approaches ? I'd like to add a more general question to the discussion what are the advantages of taking the dynamic approach? So far I collected two reasons: -It is a 'cleaner' design, removes complexity on VDSM code, easier to maintain going forward, and less bug prone (I agree with that one, as long as we keep the retrieving configuration mechanism/algorithm simple). -It adheres to the idea of having a stateless hypervisor - some more input on this point would be appreciated Any other advantages? discussing the benefits of having the persisted Livnat Sorry for the delay. Some more expansion. ASSUMPTION After boot a host running vdsm is able to receive communication from engine. This means that host has legitimate layer 2 configuration and layer 3 configuration for the interface used to communicate to engine. MISSION Reduce
Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary
On Tue, Nov 27, 2012 at 05:38:25AM -0500, Alon Bar-Lev wrote: snip ASSUMPTION After boot a host running vdsm is able to receive communication from engine. This means that host has legitimate layer 2 configuration and layer 3 configuration for the interface used to communicate to engine. MISSION Reduce complexity of implementation, so that only one algorithm is used in order to reach to operative state as far as networking is concerned. (Storage is extremely similar I can s/network/storage/ and still be relevant). For reaching the mission above we can also use the approach suggested by Adam. start from a clean configuration and execute setup network to set the host networking configuration. In Adam's proposal VDSM itself is issuing the setupNetwork and in your approach the engine does. Right. we can do this 100+ ways, question is which implementation will be the simplest. My problem with Adam's idea is http://xkcd.com/927/ : it amounts to an (n+1)th way of persisting network configuration on disk. We may have to take that way, but as with VM definitions and storage connections, I would like to keep it in a smaller service on top of vdsm. DESIGN FOCAL POINT Host running vdsm is a complete slave of its master, will it be ovirt-engine or other engine. Having a complete slave ease implementation: 1. Master always apply the setting as-is. 2. No need to consider slave state. 3. No need to implement AI to reach from unknown state X to known state Y + delta. 4. After reboot (or fence) host is always in known state. ALGORITHM A. Given communication to vdsm, I think we should not brush this permise aside. Current Vdsm API lets Engine tweak the means of communication for next boot. We had customers that wanted to add a bond, or change the vlan, or fix the IP address of the management interface. They could have used Engine for this, and declare the new configuration as safe (setSafeNetConfig). In many cases, the latter step has to be done out of band. But there are cases where this can be done completely remotely. It seems that you suggest to take this crucial configuration completely out-of-band. construct required vlan, bonding, bridge setup on machine. B. Reboot/Fence - host is reset, apply A. C. Network configuration is changed at engine: (1) Drop all resources that are not used by active VMs. I'm not sure what you mean by the above, drop all resources *not* used by VMs? Let's say we have running VM using bridge bridge1. We cannot modify this bridge1 as long as VM is operative. So we drop all network configuration except of bridge1 to allow VM to survive the upgrade. I was tempted to write something else but I did not want to alarm people But... when network configuration is changed on a host with running VMs, first move the VMs to a different host, then recycle configuration (simplest: reboot). We've been doing that until v3.1... (2) Apply A. D. Host in maintenance - network configuration can be changed, will be applied when host go into active, apply C (no resources are used by VMs, all resources are dropped). E. Critical network is down (Host not operative) - network configuration is not changed. F. Host unreachable (None responsive) - network configuration cannot be changed. What happens if we have a host that is added to the engine (or used to be non-operational and now returns to up) and reports a network configuration different than what is configured in the engine? This is a sign of totally malicious node! A trigger to fencing, active rebooting. Can you please describe a valid sequence in which it can happen? I'm not sure this example flies all, but how about a sysadmin that wants to replace our bonding definition with teaming. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary
On Tue, Nov 27, 2012 at 11:56:54AM +0200, Livnat Peer wrote: On 27/11/12 10:53, Alon Bar-Lev wrote: - Original Message - From: Livnat Peer lp...@redhat.com To: Adam Litke a...@us.ibm.com Cc: Alon Bar-Lev abar...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, November 27, 2012 10:42:00 AM Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary On 26/11/12 16:59, Adam Litke wrote: On Mon, Nov 26, 2012 at 02:57:19PM +0200, Livnat Peer wrote: On 26/11/12 03:15, Shu Ming wrote: Livnat, Thanks for your summary. I got comments below. 2012-11-25 18:53, Livnat Peer: Hi All, We have been discussing $subject for a while and I'd like to summarized what we agreed and disagreed on thus far. The way I see it there are two related discussions: 1. Getting VDSM networking stack to be distribution agnostic. - We are all in agreement that VDSM API should be generic enough to incorporate multiple implementation. (discussed on this thread: Alon's suggestion, Mark's patch for adding support for netcf etc.) - We would like to maintain at least one implementation as the working/up-to-date implementation for our users, this implementation should be distribution agnostic (as we all acknowledge this is an important goal for VDSM). I also think that with the agreement of this community we can choose to change our focus, from time to time, from one implementation to another as we see fit (today it can be OVS+netcf and in a few months we'll use the quantum based implementation if we agree it is better) 2. The second discussion is about persisting the network configuration on the host vs. dynamically retrieving it from a centralized location like the engine. Danken raised a concern that even if going with the dynamic approach the host should persist the management network configuration. About dynamical retrieving from a centralized location, when will the retrieving start? Just in the very early stage of host booting before network functions? Or after the host startup and in the normal running state of the host? Before retrieving the configuration, how does the host network connecting to the engine? I think we need a basic well known network between hosts and the engine first. Then after the retrieving, hosts should reconfigure the network for later management. However, the timing to retrieve and reconfigure are challenging. We did not discuss the dynamic approach in details on the list so far and I think this is a good opportunity to start this discussion... From what was discussed previously I can say that the need for a well known network was raised by danken, it was referred to as the management network, this network would be used for pulling the full host network configuration from the centralized location, at this point the engine. About the timing for retrieving the configuration, there are several approaches. One of them was described by Alon, and I think he'll join this discussion and maybe put it in his own words, but the idea was to 'keep' the network synchronized at all times. When the host have communication channel to the engine and the engine detects there is a mismatch in the host configuration, the engine initiates 'apply network configuration' action on the host. Using this approach we'll have a single path of code to maintain and that would reduce code complexity and bugs - That's quoting Alon Bar Lev (Alon I hope I did not twisted your words/idea). On the other hand the above approach makes local tweaks on the host (done manually by the administrator) much harder. I worry a lot about the above if we take the dynamic approach. It seems we'd need to introduce before/after 'apply network configuration' hooks where the admin could add custom config commands that aren't yet modeled by engine. yes, and I'm not sure the administrators would like the fact that we are 'forcing' them to write everything in a script and getting familiar with VDSM hooking mechanism (which in some cases require the use of custom properties on the engine level) instead of running a simple command line. In which case will we force? Please be more specific. If we can pass most of the iproute2, brctl, bond parameters via key/value pairs via the API, what in your view that is common or even seldom should be used? This hook mechanism is only as fallback, provided to calm people down. I understand, I'm saying it can irritate the administrators that needs to use it, it does not help that we are calmed down ;) Just to make it clear I'm not against the stateless approach, I'm trying to understand it better and make sure we are all aware of the drawbacks this approach has. Complicating local tweaks to the
Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary
- Original Message - From: Dan Kenigsberg dan...@redhat.com To: Livnat Peer lp...@redhat.com Cc: Alon Bar-Lev alo...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, November 27, 2012 4:22:19 PM Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary snip Livnat, I don't see any argument of persistence vs non persistence as the above is common to any approach taken. Only this manual configuration argument keeps poping, which as I wrote is irrelevant in large scale and we do want to go into large scale. Well, we call it manual configuration, but it applies just as well to puppet-based configuration. Dan. There can by only one (manager to each host). Alon. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary
On Tue, Nov 27, 2012 at 10:42:00AM +0200, Livnat Peer wrote: On 26/11/12 16:59, Adam Litke wrote: On Mon, Nov 26, 2012 at 02:57:19PM +0200, Livnat Peer wrote: On 26/11/12 03:15, Shu Ming wrote: Livnat, Thanks for your summary. I got comments below. 2012-11-25 18:53, Livnat Peer: Hi All, We have been discussing $subject for a while and I'd like to summarized what we agreed and disagreed on thus far. The way I see it there are two related discussions: 1. Getting VDSM networking stack to be distribution agnostic. - We are all in agreement that VDSM API should be generic enough to incorporate multiple implementation. (discussed on this thread: Alon's suggestion, Mark's patch for adding support for netcf etc.) - We would like to maintain at least one implementation as the working/up-to-date implementation for our users, this implementation should be distribution agnostic (as we all acknowledge this is an important goal for VDSM). I also think that with the agreement of this community we can choose to change our focus, from time to time, from one implementation to another as we see fit (today it can be OVS+netcf and in a few months we'll use the quantum based implementation if we agree it is better) 2. The second discussion is about persisting the network configuration on the host vs. dynamically retrieving it from a centralized location like the engine. Danken raised a concern that even if going with the dynamic approach the host should persist the management network configuration. About dynamical retrieving from a centralized location, when will the retrieving start? Just in the very early stage of host booting before network functions? Or after the host startup and in the normal running state of the host? Before retrieving the configuration, how does the host network connecting to the engine? I think we need a basic well known network between hosts and the engine first. Then after the retrieving, hosts should reconfigure the network for later management. However, the timing to retrieve and reconfigure are challenging. We did not discuss the dynamic approach in details on the list so far and I think this is a good opportunity to start this discussion... From what was discussed previously I can say that the need for a well known network was raised by danken, it was referred to as the management network, this network would be used for pulling the full host network configuration from the centralized location, at this point the engine. About the timing for retrieving the configuration, there are several approaches. One of them was described by Alon, and I think he'll join this discussion and maybe put it in his own words, but the idea was to 'keep' the network synchronized at all times. When the host have communication channel to the engine and the engine detects there is a mismatch in the host configuration, the engine initiates 'apply network configuration' action on the host. Using this approach we'll have a single path of code to maintain and that would reduce code complexity and bugs - That's quoting Alon Bar Lev (Alon I hope I did not twisted your words/idea). On the other hand the above approach makes local tweaks on the host (done manually by the administrator) much harder. I worry a lot about the above if we take the dynamic approach. It seems we'd need to introduce before/after 'apply network configuration' hooks where the admin could add custom config commands that aren't yet modeled by engine. yes, and I'm not sure the administrators would like the fact that we are 'forcing' them to write everything in a script and getting familiar with VDSM hooking mechanism (which in some cases require the use of custom properties on the engine level) instead of running a simple command line. Any other approaches ? Static configuration has the advantage of allowing a host to bring itself back online independent of the engine. This is also useful for anyone who may want to deploy a vdsm node in standalone mode. I think it would be possible to easily support a quasi-static configuration mode simply by extending the design of the dynamic approach slightly. In dynamic mode, the network configuration is passed down as a well-defined data structure. When a particular configuration has been committed, vdsm could write a copy of that configuration data structure to /var/run/vdsm/network-config.json. During a subsequent boot, if the engine cannot be contacted after activating the management network, the cached configuration can be applied using the same code as for dynamic mode. We'd have to flesh out the circumstances under which this would happen. I like this approach a lot but we need to consider that network configuration is an accumulated state, for example - 1. The engine sends a
Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary
On Mon, Nov 26, 2012 at 06:13:01PM -0500, Alon Bar-Lev wrote: Hello, - Original Message - From: Adam Litke a...@us.ibm.com To: Alon Bar-Lev alo...@redhat.com Cc: Livnat Peer lp...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, November 27, 2012 12:51:36 AM Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary Nice writeup! I like where this is going but see my comments inline below. On Mon, Nov 26, 2012 at 03:18:22PM -0500, Alon Bar-Lev wrote: - Original Message - From: Livnat Peer lp...@redhat.com To: Shu Ming shum...@linux.vnet.ibm.com Cc: Alon Bar-Lev abar...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Monday, November 26, 2012 2:57:19 PM Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary On 26/11/12 03:15, Shu Ming wrote: Livnat, Thanks for your summary. I got comments below. 2012-11-25 18:53, Livnat Peer: Hi All, We have been discussing $subject for a while and I'd like to summarized what we agreed and disagreed on thus far. The way I see it there are two related discussions: 1. Getting VDSM networking stack to be distribution agnostic. - We are all in agreement that VDSM API should be generic enough to incorporate multiple implementation. (discussed on this thread: Alon's suggestion, Mark's patch for adding support for netcf etc.) - We would like to maintain at least one implementation as the working/up-to-date implementation for our users, this implementation should be distribution agnostic (as we all acknowledge this is an important goal for VDSM). I also think that with the agreement of this community we can choose to change our focus, from time to time, from one implementation to another as we see fit (today it can be OVS+netcf and in a few months we'll use the quantum based implementation if we agree it is better) 2. The second discussion is about persisting the network configuration on the host vs. dynamically retrieving it from a centralized location like the engine. Danken raised a concern that even if going with the dynamic approach the host should persist the management network configuration. About dynamical retrieving from a centralized location, when will the retrieving start? Just in the very early stage of host booting before network functions? Or after the host startup and in the normal running state of the host? Before retrieving the configuration, how does the host network connecting to the engine? I think we need a basic well known network between hosts and the engine first. Then after the retrieving, hosts should reconfigure the network for later management. However, the timing to retrieve and reconfigure are challenging. We did not discuss the dynamic approach in details on the list so far and I think this is a good opportunity to start this discussion... From what was discussed previously I can say that the need for a well known network was raised by danken, it was referred to as the management network, this network would be used for pulling the full host network configuration from the centralized location, at this point the engine. About the timing for retrieving the configuration, there are several approaches. One of them was described by Alon, and I think he'll join this discussion and maybe put it in his own words, but the idea was to 'keep' the network synchronized at all times. When the host have communication channel to the engine and the engine detects there is a mismatch in the host configuration, the engine initiates 'apply network configuration' action on the host. Using this approach we'll have a single path of code to maintain and that would reduce code complexity and bugs - That's quoting Alon Bar Lev (Alon I hope I did not twisted your words/idea). On the other hand the above approach makes local tweaks on the host (done manually by the administrator) much harder. Any other approaches ? I'd like to add a more general question to the discussion what are the advantages of taking the dynamic approach? So far I collected two reasons: -It is a 'cleaner' design, removes complexity on VDSM code, easier to maintain going forward, and less bug prone (I agree with that one, as long as we keep the retrieving configuration mechanism/algorithm simple). -It adheres to the idea of having a stateless hypervisor - some more input on this point would be appreciated Any other advantages? discussing the benefits of having the persisted Livnat Sorry for the delay. Some more
Re: [vdsm] [RFC]about the implement of text-based console
Thanks for the writeup Zhou Zheng! This is a very nice explanation of the possible approaches that are on the table. I would like to add my thoughts on each approach inline below. On Tue, Nov 27, 2012 at 05:22:20PM +0800, Zhou Zheng Sheng wrote: Hi all, For now in there is no agreement on the remote guest console solution, so I decide to do some investigation continue the discussion. Our goal VM serial console remote access in CLI mode. That means the client runs without X environment. There are several proposals. 1. Sandboxed sshd VDSM runs a new host sshd instance in virtual machine/sandbox and redirects the virtio console to it. 2. Third-party sshd VDSM runs third-party sshd library/implementation and redirects virtio console to it. 3. Spice Extend spice to support console and implement a client to be run without GUI environment 4. oVirt shell - Engine - libvirt The user connects to Engine via oVirt CLI, then issues a serial-console command, then Engine locates the host and connect to the guest console. Currently there is a workaround, it invokes virsh -c qemu+tls://host/qemu console vmid from Engine side. 5. VDSM console streaming API VDSM exposes getConsoleReadStream() and getConsoleWriteStream() via XMLRPC binding. Then implement the related client in vdsClient and Engine Detailed discussion 1. Sandboxes Solution 1 and 2 allow users connect to console using their favorite ssh client. The login name is vmid, the password is set by setVmTicket() call of VDSM. The connection will be lost during migration. This is similar to VNC in oVirt. I take a look at several sandbox technologies, including libvirt-sandbox, lxc and selinux. a) libvirt-sandbox boots a VM using host kernel and initramfs, then passthru the host file system to the VM in read only mode. We can also add extra binding to the guest file system. It's very easy to use. To run shell in a VM, one can just issues virt-sandbox -c qemu:///session /bin/sh Then the VM will be ready in several seconds. However it will trigger some selinux violations. Currently there is no official support for selinux policy configuration from this project. In the project page this is put in the todo list. b) lxc utilize Linux container to run a process in sandbox. It needs to be configured properly. I find in the package lxc-templates there is an example configuration file for running sshd in lxc. c) sandbox command in the package policycoreutils-python makes use of selinux to run a process in sandbox, but there is no official or example policy files for sshd. In a word, for sandbox technologies, we have to configure the policies/file system binding/network carefully and test the compatibility with popular sshd implementations (openssh-server). When those sshd upgrade, the policy must be upgraded by us at the same time. Since the policies are not maintained by who implements sshd, this is a burden for us. Work to do Write and maintain the policies. Find ways for auth callback and redirecting data to openssh-server. pros Re-use existing pieces and technologies (host sshd, sandbox). User friendly, they can use existing ssh clients. cons Connection is lost in migration, this is not a big problem because 1) VNC connection share the same problem, 2) the user can reconnect manually. It's not easy to maintain the sandbox policies/file system binding/network for compatibility with sshd. I find all of these sandbox techniques to be far too cumbersome to be useful. In each case, the dependencies on the base operating system (selinux, etc.) are too great to make this a maintainable option going forward. 2. Third-party sshd implementations Almost the same as solution 1 but with better flexibility. VDSM can import a third-party sshd library and let that library deal with auth and transport. VDSM just have to implement the data forwarding. Many people consider this is insecure but I think the ticket solution for VNC is even not as secure as this. Currently most of us only trust openssh-server and think the quality of third-party sshd is low. I searched for a while and found twisted.conch from the popular twisted project. I'm not familiar with twisted.conch, but I still put it in this mail to collect opinions from potential twisted.conch experts. In a word, I prefer sandbox technologies to third-party sshd implementations unless there is a implementation as good as openssh-server. Work to do Integrate twisted.conch into VDSM pros Very flexible. If library provide auth callback to VDSM, then VDSM can just compares the login password to the VM ticket without knowing SSH detials. cons Third party implementations are not as secure and carefully maintained as sshd in the host (probably openssh-server). As others have said previously, the security implications of relying on a third-party ssh implementation makes this idea a
Re: [vdsm] [RFC]about the implement of text-based console
The best solution would of course be 3 (Or something similar that keeps the terminal state inside the VM memory so that migration works). Tunelling screen can do that but it requires having screen (or something similar) installed on the guest which is hard to do. But I think the more practical solution is 2 as it has semantics similar to VNC. Running a real ssh (ie. 1) is problematic because we have less control over the daemon and there are more vectors the user can try and use to break out of the sandbox. Further more, setting up sandboxes is a bit problematic ATM. I don't really understand 5. What does those methods return the virtio dev path? - Original Message - From: Zhou Zheng Sheng zhshz...@linux.vnet.ibm.com To: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, November 27, 2012 4:22:20 AM Subject: Re: [vdsm] [RFC]about the implement of text-based console Hi all, For now in there is no agreement on the remote guest console solution, so I decide to do some investigation continue the discussion. Our goal VM serial console remote access in CLI mode. That means the client runs without X environment. Do you mean like running qemu with -curses? There are several proposals. 1. Sandboxed sshd VDSM runs a new host sshd instance in virtual machine/sandbox and redirects the virtio console to it. 2. Third-party sshd VDSM runs third-party sshd library/implementation and redirects virtio console to it. 3. Spice Extend spice to support console and implement a client to be run without GUI environment 4. oVirt shell - Engine - libvirt The user connects to Engine via oVirt CLI, then issues a serial-console command, then Engine locates the host and connect to the guest console. Currently there is a workaround, it invokes virsh -c qemu+tls://host/qemu console vmid from Engine side. 5. VDSM console streaming API VDSM exposes getConsoleReadStream() and getConsoleWriteStream() via XMLRPC binding. Then implement the related client in vdsClient and Engine Detailed discussion 1. Sandboxes Solution 1 and 2 allow users connect to console using their favorite ssh client. The login name is vmid, the password is set by setVmTicket() call of VDSM. The connection will be lost during migration. This is similar to VNC in oVirt. I take a look at several sandbox technologies, including libvirt-sandbox, lxc and selinux. a) libvirt-sandbox boots a VM using host kernel and initramfs, then passthru the host file system to the VM in read only mode. We can also add extra binding to the guest file system. It's very easy to use. To run shell in a VM, one can just issues virt-sandbox -c qemu:///session /bin/sh Then the VM will be ready in several seconds. However it will trigger some selinux violations. Currently there is no official support for selinux policy configuration from this project. In the project page this is put in the todo list. b) lxc utilize Linux container to run a process in sandbox. It needs to be configured properly. I find in the package lxc-templates there is an example configuration file for running sshd in lxc. c) sandbox command in the package policycoreutils-python makes use of selinux to run a process in sandbox, but there is no official or example policy files for sshd. In a word, for sandbox technologies, we have to configure the policies/file system binding/network carefully and test the compatibility with popular sshd implementations (openssh-server). When those sshd upgrade, the policy must be upgraded by us at the same time. Since the policies are not maintained by who implements sshd, this is a burden for us. Work to do Write and maintain the policies. Find ways for auth callback and redirecting data to openssh-server. pros Re-use existing pieces and technologies (host sshd, sandbox). User friendly, they can use existing ssh clients. cons Connection is lost in migration, this is not a big problem because 1) VNC connection share the same problem, 2) the user can reconnect manually. It's not easy to maintain the sandbox policies/file system binding/network for compatibility with sshd. 2. Third-party sshd implementations Almost the same as solution 1 but with better flexibility. VDSM can import a third-party sshd library and let that library deal with auth and transport. VDSM just have to implement the data forwarding. Many people consider this is insecure but I think the ticket solution for VNC is even not as secure as this. Currently most of us only trust openssh-server and think the quality of third-party sshd is low. I searched for a while and found twisted.conch from the popular twisted project. I'm not familiar with twisted.conch, but I still put it in this mail to collect opinions from potential twisted.conch experts. In a word, I prefer sandbox technologies to third-party sshd
Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary
On 11/26/2012 03:18 PM, Alon Bar-Lev wrote: - Original Message - From: Livnat Peer lp...@redhat.com To: Shu Ming shum...@linux.vnet.ibm.com Cc: Alon Bar-Lev abar...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Monday, November 26, 2012 2:57:19 PM Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary On 26/11/12 03:15, Shu Ming wrote: Livnat, Thanks for your summary. I got comments below. 2012-11-25 18:53, Livnat Peer: Hi All, We have been discussing $subject for a while and I'd like to summarized what we agreed and disagreed on thus far. The way I see it there are two related discussions: 1. Getting VDSM networking stack to be distribution agnostic. - We are all in agreement that VDSM API should be generic enough to incorporate multiple implementation. (discussed on this thread: Alon's suggestion, Mark's patch for adding support for netcf etc.) - We would like to maintain at least one implementation as the working/up-to-date implementation for our users, this implementation should be distribution agnostic (as we all acknowledge this is an important goal for VDSM). I also think that with the agreement of this community we can choose to change our focus, from time to time, from one implementation to another as we see fit (today it can be OVS+netcf and in a few months we'll use the quantum based implementation if we agree it is better) 2. The second discussion is about persisting the network configuration on the host vs. dynamically retrieving it from a centralized location like the engine. Danken raised a concern that even if going with the dynamic approach the host should persist the management network configuration. About dynamical retrieving from a centralized location, when will the retrieving start? Just in the very early stage of host booting before network functions? Or after the host startup and in the normal running state of the host? Before retrieving the configuration, how does the host network connecting to the engine? I think we need a basic well known network between hosts and the engine first. Then after the retrieving, hosts should reconfigure the network for later management. However, the timing to retrieve and reconfigure are challenging. We did not discuss the dynamic approach in details on the list so far and I think this is a good opportunity to start this discussion... From what was discussed previously I can say that the need for a well known network was raised by danken, it was referred to as the management network, this network would be used for pulling the full host network configuration from the centralized location, at this point the engine. About the timing for retrieving the configuration, there are several approaches. One of them was described by Alon, and I think he'll join this discussion and maybe put it in his own words, but the idea was to 'keep' the network synchronized at all times. When the host have communication channel to the engine and the engine detects there is a mismatch in the host configuration, the engine initiates 'apply network configuration' action on the host. Using this approach we'll have a single path of code to maintain and that would reduce code complexity and bugs - That's quoting Alon Bar Lev (Alon I hope I did not twisted your words/idea). On the other hand the above approach makes local tweaks on the host (done manually by the administrator) much harder. Any other approaches ? I'd like to add a more general question to the discussion what are the advantages of taking the dynamic approach? So far I collected two reasons: -It is a 'cleaner' design, removes complexity on VDSM code, easier to maintain going forward, and less bug prone (I agree with that one, as long as we keep the retrieving configuration mechanism/algorithm simple). -It adheres to the idea of having a stateless hypervisor - some more input on this point would be appreciated Any other advantages? discussing the benefits of having the persisted Livnat Sorry for the delay. Some more expansion. ASSUMPTION After boot a host running vdsm is able to receive communication from engine. This means that host has legitimate layer 2 configuration and layer 3 configuration for the interface used to communicate to engine. MISSION Reduce complexity of implementation, so that only one algorithm is used in order to reach to operative state as far as networking is concerned. (Storage is extremely similar I can s/network/storage/ and still be relevant). DESIGN FOCAL POINT Host running vdsm is a complete slave of its master, will it be ovirt-engine or other engine. Having a complete slave ease implementation: 1. Master always apply the setting as-is. 2. No need to consider slave state. 3. No need to implement AI to reach from unknown state X to known state Y + delta. 4. After reboot (or fence) host is always in known state. ALGORITHM A. Given communication to vdsm, construct
Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary
- Original Message - From: Itamar Heim ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Livnat Peer lp...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, November 27, 2012 10:08:34 PM Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary On 11/26/2012 03:18 PM, Alon Bar-Lev wrote: - Original Message - From: Livnat Peer lp...@redhat.com To: Shu Ming shum...@linux.vnet.ibm.com Cc: Alon Bar-Lev abar...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Monday, November 26, 2012 2:57:19 PM Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary On 26/11/12 03:15, Shu Ming wrote: Livnat, Thanks for your summary. I got comments below. 2012-11-25 18:53, Livnat Peer: Hi All, We have been discussing $subject for a while and I'd like to summarized what we agreed and disagreed on thus far. The way I see it there are two related discussions: 1. Getting VDSM networking stack to be distribution agnostic. - We are all in agreement that VDSM API should be generic enough to incorporate multiple implementation. (discussed on this thread: Alon's suggestion, Mark's patch for adding support for netcf etc.) - We would like to maintain at least one implementation as the working/up-to-date implementation for our users, this implementation should be distribution agnostic (as we all acknowledge this is an important goal for VDSM). I also think that with the agreement of this community we can choose to change our focus, from time to time, from one implementation to another as we see fit (today it can be OVS+netcf and in a few months we'll use the quantum based implementation if we agree it is better) 2. The second discussion is about persisting the network configuration on the host vs. dynamically retrieving it from a centralized location like the engine. Danken raised a concern that even if going with the dynamic approach the host should persist the management network configuration. About dynamical retrieving from a centralized location, when will the retrieving start? Just in the very early stage of host booting before network functions? Or after the host startup and in the normal running state of the host? Before retrieving the configuration, how does the host network connecting to the engine? I think we need a basic well known network between hosts and the engine first. Then after the retrieving, hosts should reconfigure the network for later management. However, the timing to retrieve and reconfigure are challenging. We did not discuss the dynamic approach in details on the list so far and I think this is a good opportunity to start this discussion... From what was discussed previously I can say that the need for a well known network was raised by danken, it was referred to as the management network, this network would be used for pulling the full host network configuration from the centralized location, at this point the engine. About the timing for retrieving the configuration, there are several approaches. One of them was described by Alon, and I think he'll join this discussion and maybe put it in his own words, but the idea was to 'keep' the network synchronized at all times. When the host have communication channel to the engine and the engine detects there is a mismatch in the host configuration, the engine initiates 'apply network configuration' action on the host. Using this approach we'll have a single path of code to maintain and that would reduce code complexity and bugs - That's quoting Alon Bar Lev (Alon I hope I did not twisted your words/idea). On the other hand the above approach makes local tweaks on the host (done manually by the administrator) much harder. Any other approaches ? I'd like to add a more general question to the discussion what are the advantages of taking the dynamic approach? So far I collected two reasons: -It is a 'cleaner' design, removes complexity on VDSM code, easier to maintain going forward, and less bug prone (I agree with that one, as long as we keep the retrieving configuration mechanism/algorithm simple). -It adheres to the idea of having a stateless hypervisor - some more input on this point would be appreciated Any other advantages? discussing the benefits of having the persisted Livnat Sorry for the delay. Some more expansion. ASSUMPTION After boot a host running vdsm is able to receive communication from engine. This means that host has legitimate layer 2 configuration and layer 3 configuration for the interface used to communicate to engine. MISSION Reduce complexity of implementation, so that only one algorithm is used in order to
Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary
- Original Message - From: Itamar Heim ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Livnat Peer lp...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, November 27, 2012 10:19:51 PM Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary On 11/27/2012 03:17 PM, Alon Bar-Lev wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Livnat Peer lp...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, November 27, 2012 10:08:34 PM Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary On 11/26/2012 03:18 PM, Alon Bar-Lev wrote: - Original Message - From: Livnat Peer lp...@redhat.com To: Shu Ming shum...@linux.vnet.ibm.com Cc: Alon Bar-Lev abar...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Monday, November 26, 2012 2:57:19 PM Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary On 26/11/12 03:15, Shu Ming wrote: Livnat, Thanks for your summary. I got comments below. 2012-11-25 18:53, Livnat Peer: Hi All, We have been discussing $subject for a while and I'd like to summarized what we agreed and disagreed on thus far. The way I see it there are two related discussions: 1. Getting VDSM networking stack to be distribution agnostic. - We are all in agreement that VDSM API should be generic enough to incorporate multiple implementation. (discussed on this thread: Alon's suggestion, Mark's patch for adding support for netcf etc.) - We would like to maintain at least one implementation as the working/up-to-date implementation for our users, this implementation should be distribution agnostic (as we all acknowledge this is an important goal for VDSM). I also think that with the agreement of this community we can choose to change our focus, from time to time, from one implementation to another as we see fit (today it can be OVS+netcf and in a few months we'll use the quantum based implementation if we agree it is better) 2. The second discussion is about persisting the network configuration on the host vs. dynamically retrieving it from a centralized location like the engine. Danken raised a concern that even if going with the dynamic approach the host should persist the management network configuration. About dynamical retrieving from a centralized location, when will the retrieving start? Just in the very early stage of host booting before network functions? Or after the host startup and in the normal running state of the host? Before retrieving the configuration, how does the host network connecting to the engine? I think we need a basic well known network between hosts and the engine first. Then after the retrieving, hosts should reconfigure the network for later management. However, the timing to retrieve and reconfigure are challenging. We did not discuss the dynamic approach in details on the list so far and I think this is a good opportunity to start this discussion... From what was discussed previously I can say that the need for a well known network was raised by danken, it was referred to as the management network, this network would be used for pulling the full host network configuration from the centralized location, at this point the engine. About the timing for retrieving the configuration, there are several approaches. One of them was described by Alon, and I think he'll join this discussion and maybe put it in his own words, but the idea was to 'keep' the network synchronized at all times. When the host have communication channel to the engine and the engine detects there is a mismatch in the host configuration, the engine initiates 'apply network configuration' action on the host. Using this approach we'll have a single path of code to maintain and that would reduce code complexity and bugs - That's quoting Alon Bar Lev (Alon I hope I did not twisted your words/idea). On the other hand the above approach makes local tweaks on the host (done manually by the administrator) much harder. Any other approaches ? I'd like to add a more general question to the discussion what are the advantages of taking the dynamic approach? So far I collected two reasons: -It is a 'cleaner' design, removes complexity on VDSM code, easier to maintain going forward, and less bug prone (I agree with that one, as long as we keep the retrieving configuration mechanism/algorithm simple). -It adheres to the idea of having a stateless hypervisor - some more input on this point would be appreciated Any other advantages? discussing the benefits of
[vdsm] ovirt network monthly sync meeting - Agenda
Hi All, We have a scheduled sync meeting on oVirt network today. We did not set an agenda for this meeting yet so I'll postpone it for next week. Please respond to this note with agenda items. If there are no agenda items by December 5th, I'll cancel the call. Thanks, Livnat ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] ovirt network
BEGIN:VCALENDAR PRODID:Zimbra-Calendar-Provider VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:Asia/Jerusalem BEGIN:STANDARD DTSTART:19710101T02 TZOFFSETTO:+0200 TZOFFSETFROM:+0300 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=9;BYDAY=4SU TZNAME:IST END:STANDARD BEGIN:DAYLIGHT DTSTART:19710101T02 TZOFFSETTO:+0300 TZOFFSETFROM:+0200 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1FR TZNAME:IDT END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT UID:cfd70d5d-b663-41f3-b72a-15b532782b23 SUMMARY:ovirt network ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailto:engine- de...@ovirt.org ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailto:vdsm-de v...@lists.fedorahosted.org ATTENDEE;CN=Tony Gargya/Germany/IBM;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTI ON;RSVP=TRUE:mailto:gar...@de.ibm.com ATTENDEE;CN=Dan Yasny;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:m ailto:dya...@redhat.com ATTENDEE;CN=Simon Grinberg;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=T RUE:mailto:si...@redhat.com ATTENDEE;CN=Mike Kolesnik;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TR UE:mailto:mkole...@redhat.com ATTENDEE;CN=Avi Tal;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mai lto:a...@redhat.com ATTENDEE;CN=Igor Lvovsky;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRU E:mailto:ilvov...@redhat.com ATTENDEE;CN=Doron Fediuck;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TR UE:mailto:dfedi...@redhat.com ATTENDEE;CN=Pradipta Kumar Banerjee;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTI ON;RSVP=TRUE:mailto:pradipta.baner...@gmail.com ATTENDEE;CN=Gary Kotton;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE :mailto:gkot...@redhat.com ATTENDEE;CN=Keith Robertson;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE:mailto:krobe...@redhat.com ATTENDEE;CN=Antoni Segura Puimedon;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTIO N;RSVP=TRUE:mailto:asegu...@redhat.com ATTENDEE;CN=Thang Pham/Poughkeepsie/IBM;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS- ACTION;RSVP=TRUE:mailto:thang.p...@us.ibm.com ATTENDEE;CN=Yaniv Kaul;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE: mailto:yk...@redhat.com ORGANIZER;CN=Livnat Peer:mailto:lp...@redhat.com DTSTART;TZID=Asia/Jerusalem:20121205T16 DTEND;TZID=Asia/Jerusalem:20121205T17 STATUS:CONFIRMED CLASS:PUBLIC X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY TRANSP:OPAQUE RECURRENCE-ID;TZID=Asia/Jerusalem:20121128T16 LAST-MODIFIED:20121128T071446Z DTSTAMP:20121128T071446Z SEQUENCE:2 DESCRIPTION:A single instance of the following meeting has been modified:\n\ nSubject: ovirt network \nOrganiser: Livnat Peer lp...@redhat.com \n\nT ime: Wednesday\, 5 December\, 2012\, 4:00:00 PM - 5:00:00 PM GMT +02:00 Jeru salem [MODIFIED]\n \nInvitees: engine-de...@ovirt.org\; vdsm-de...@lists.fed orahosted.org\; gar...@de.ibm.com\; dya...@redhat.com\; si...@redhat.com\; m kole...@redhat.com\; a...@redhat.com\; ilvov...@redhat.com\; dfediuck@redhat .com\; pradipta.baner...@gmail.com\; gkot...@redhat.com ... \n\n\n*~*~*~*~*~ *~*~*~*~*\n\nHi All\, \nAs discussed previously on the list\, I am adding a monthly discussion on Networking in oVirt. \nIn this meeting we'll discuss g eneral status of networking and features that we're missing. \n\nThanks\, Li vnat \n\n\nBridge ID: 972506565679 \nDial-in information: \nReservationless- Plus Toll Free Dial-In Number (US Canada): (800) 451-8679 \nReservationles s-Plus International Dial-In Number: (212) 729-5016 \nConference code: 84259 73915 \n\nGlobal Access Numbers Local: \nAustralia\, Sydney Dial-In #: 02898 52326 \nAustria\, Vienna Dial-In #: 012534978196 \nBelgium\, Brussels Dial-I n #: 027920405 \nChina Dial-In #: 4006205013 \nDenmark\, Copenhagen Dial-In #: 32729215 \nFinland\, Helsinki Dial-In #: 0923194436 \nFrance\, Paris Dial -In #: 0170377140 \nGermany\, Berlin Dial-In #: 030300190579 \nIreland\, Dub lin Dial-In #: 014367793 \nItaly\, Milan Dial-In #: 0236269529 \nNetherlands \, Amsterdam Dial-In #: 0207975872 \nNorway\, Oslo Dial-In #: 21033188 \nSin gapore Dial-In #: 64840858 \nSpain\, Barcelona Dial-In #: 935452328 \nSweden \, Stockholm Dial-In #: 0850513770 \nSwitzerland\, Geneva Dial-In #: 0225927 881 \nUnited Kingdom Dial-In #: 02078970515 \nUnited Kingdom Dial-In #: 0844 5790676 \nUnited Kingdom\, LocalCall Dial-In #: 08445790678 \nUnited States Dial-In #: 2127295016 \n\n\nGlobal Access Numbers Tollfree: \nArgentina Dial -In #: 8004441016 \nAustralia Dial-In #: 1800337169 \nAustria Dial-In #: 080 0005898 \nBahamas Dial-In #: 18002054776 \nBahrain Dial-In #: 80004377 \nBel gium Dial-In #: 080048325 \nBrazil Dial-In #: 08008921002 \nBulgaria Dial-In #: 008001100236 \nChile Dial-In #: 800370228 \nColombia Dial-In #: 01800913 4033 \nCosta Rica Dial-In #: 08000131048 \nCyprus Dial-In #: 80095297 \nCzec h Republic Dial-In #: 800700318 \nDenmark Dial-In #: 80887114 \nDominican Re public Dial-In #: 18887512313 \nEstonia Dial-In #: 8000100232 \nFinland Dial -In #: 0800117116 \nFrance
Re: [vdsm] Proposal to add Adam Litke as maintainer to vdsm
On 11/26/2012 03:39 AM, Federico Simoncelli wrote: +1 - Original Message - From: Itamar Heim ih...@redhat.com To: Ayal Baron aba...@redhat.com, Dan Kenigsberg dan...@redhat.com, Saggi Mizrahi smizr...@redhat.com, Federico Simoncelli fsimo...@redhat.com, Eduardo Warszawski ewars...@redhat.com, Igor Lvovsky ilvov...@redhat.com Cc: vdsm-devel@lists.fedorahosted.org Sent: Friday, November 16, 2012 5:50:27 PM Subject: Proposal to add Adam Litke as maintainer to vdsm Adam has been submitting numerous patches for VDSM for more than a year, most noticeably on improving VDSM API into, well, an API... I'd like to propose Adam as a maintainer for vdsm. Thanks, Itamar added adam as a vdsm maintainer. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
