Jim Fehlig wrote:
> Jim Fehlig wrote:
> > Markus Groà wrote:
> >> 2. The driver supports libvirtxml <-> xen-xm conversion, thanks to the
> >> unified xen driver which already offered this functionality. But since
> >> this driver is not part of xen unified, I had to copy this
> >> functionality, rather than reusing it.
> >
> > Yep, same with some of the capabilities code. But I haven't done much
> > in the way of libvirtXML <-> xen-xm conversion since I'm not convinced
> > the libvirt libxenlight driver should even manage vms it has not created
> > (similar to qemu driver). If a vm is started with xl tool, it has a
> > daemon spawned to listen for domain death, CD eject, etc. events. I'm
> > not sure of libvirt libxenlight driver should get involved with that.
>
> Just to clarify, we do need to convert xl/libxl config syntax (which is
> same as legacy xen python config files except that arbitrary embedded
> python is not supported) to libvirtXML. At a minimum, it will be needed
> to support virConnectDomain{From,To}Native(). My point above is that
> this functionality, and the other missing driver table functions, can be
> added incrementally. But we do need to solve the code duplication with
> existing xen driver, at which point we have the conversion anyhow.
> Speaking of code duplication, I think we can solve it as Matthias did
> for esx and vmware/player drivers - see src/vmx. What do you think?
That sounds like a good idea.
The necessary functions could be split into new source files and moved to
src/xen-xm or src/xm.
Cheers,
Markus
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list