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?
Thanks,
Jim
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list