Alessandro, I agree with you. I created a Blueprint. Let us collaborate and achieve this on all types of hypervisors.
All, Here is the link for the BP as discussed. https://blueprints.launchpad.net/nova/+spec/appliance-communication-channel Thanks, -Ravi. On Mon, Sep 30, 2013 at 12:56 PM, Alessandro Pilotti < apilo...@cloudbasesolutions.com> wrote: > Hi all, > > A host / guest communication channel can be useful in a lot of > scenarios. What about thinking on a common interface to be implemented on > other hypervisors as well and not only on KVM? > We're planning to start working on something similar for Hyper-V and there > were some chats about ideas related to XenServer as well (John?). > > Each hypervisor provides different ways of achieving this goal, but IMO > it'd be fairly easy to define a common adapter interface. > > > Alessandro > > > On Sep 30, 2013, at 20:21 , Daniel P. Berrange <berra...@redhat.com> > wrote: > > On Mon, Sep 30, 2013 at 09:46:02AM -0700, Ravi Chunduru wrote: > > Let me present an use case. > Today Nova enables to launch guests of different types. For real > deployments we would need appliances from various vendors to run as > instances. Appliances can be Loadbalancer, Firewall, IPsec, Routers or > UTM etc., > > These appliances can be tied up with Neutron Services and would need > configuration from various services like FWaaS, LBaaS, VPNaaS etc., > One way to configure these appliances from Neutron Agents is by opening up > the so needed virtio unix channel socket and reach the configuration daemon > in the appliance. > Other approach is by having a separate network for management activities > and having agent to communicate to a daemon in netns to reach out to > appliance. > > > Thanks, this is the kind of usage information I was asking for, wrt > host integration. This shows the use case for virtio-serial is as a > mechanism for integration between infrastructure pieces controlled by > the cloud admin, not as something that is targetted towards end users > of the cloud. > > I think we need to have a detailed blueprint for this, describing the > use case(s) to be addressed and proposing some possible design(s). > > > Daniel > -- > |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/:| > |: http://libvirt.org -o- http://virt-manager.org:| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/:| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc:| > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Ravi
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
