Michal Privoznik wrote:
On 11.06.2013 16:12, Jim Fehlig wrote:
Michal Privoznik wrote:
On 10.06.2013 22:21, Jim Fehlig wrote:
Currently, the libxl driver reports a connection type of "xenlight". To be compatible with the legacy Xen driver, it should return "Xen".
Note: I noticed this while testing the libxl driver on OpenStack. After switching my Xen compute nodes to use the libxl stack, I could no longer launch instances on those nodes since hypervisor_type was reported as "xenlight" instead of "xen". --- src/libxl/libxl_driver.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c index 3990354..935919b 100644 --- a/src/libxl/libxl_driver.c +++ b/src/libxl/libxl_driver.c @@ -1405,7 +1405,7 @@ libxlConnectClose(virConnectPtr conn ATTRIBUTE_UNUSED) static const char * libxlConnectGetType(virConnectPtr conn ATTRIBUTE_UNUSED) { - return "xenlight"; + return "Xen"; }
static int
I am not so convinced about this one. I think there exist some applications which want to distinguish between "Xen" and "xenlight".
If that was the case, we would have went with a libxl:// URI. In fact, the original libxl driver patch introduced a libxl:// URI, but Daniel V. pointed out that approach conflicted with libvirt's goal of minimizing the impact on application stacks as the lower layers churn
https://www.redhat.com/archives/libvir-list/2011-March/msg00449.html
Right, you certainly got a point there. But I'd like to see DV's input in here then.
If a application (like Openstack) doesn't want, nothing is easier than:
type = virConnectGetType(conn); if (!strcmp(type, "Xen") || !strcmp(type, "xenlight")) { DoTheMagic(); } else { ReportError("XEN not supported); }
Yes, but every app would have to do that, all because some lower layer tool was reworked.
It wasn't reworked. It's here from initial introduction of libxl :)
I meant the reworking of xen tools, e.g. the replacement of xm/xend with xl/libxl. libvirt apps should be insulated from these types of infrastructure changes at the lower levels. I'd expect my libvirt apps to continue working after a Xen upgrade, similar to how they continue to work after installing a new qemu. Regards, Jim