[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] Next features and target for development

On Tue, Jul 10, 2007 at 05:23:01PM +0100, Daniel P. Berrange wrote:
> > (2) Are the hosts compatible?  (eg. microarchitecture, hypervisor, ... 
> > other sources of incompatibility?)  Should we care at the API level or 
> > just report errors from the hypervisors?
> The app can validate to some degree by looking at the capabilities
> XML to see what's supported on both ends & what the guest is using.
> So I'd let the app do high level validation with that, and just then
> propagate errors from the underlying system - keeping poliucy out of
> the libvirt API.

  that was my take too. We can check a few things but as Dan said I would
rather rely on propagating errors back.

> > (3) Should the data be encrypted when it travels?
> Implementation defined, so not something for libvirt to worry about. Its
> a separate task to make XenD use SSL/TLS for communcating with other XenDs

  It's sure a concern, the APIs should have a flag, and requirement about
secure migration could be one of the bits.

> > Xen uses a particular port & protocol for migration.  Is this protocol 
> > one-way or two-way?

  initiated by the current host for the domain from what I could find some
time ago, then once the TCP connection is open it's used until the migration
has finished IIRC.

> > >  - Support for Xen-API new entry points at least for localhost access
> > >    since we have remote support now
> > 
> > Is there stuff we can do with Xen-API which we can't do with the sexpr 
> > API?  Are upstream going to continue offering both APIs?
> Upstream would like to kill the SEXPR api. So far we've prevented them
> doing this. SEXPR is limited in so much as its all, or nothing & this
> has horrific performance issues, because pulling out all the device info
> hits xenstored alot - hence a single SEXPR request can take as much as
> 1 second to complete :-(

  yeah and I'm afraid sexpr may get removed in the future, the earlier
we allow both the smoother it should be for the user base. The call I'm
really afraid of is the creation once, there is (was) a lot of structures
to encode in XML :-\


Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]