Re: [libvirt] [PATCH 1/2] libxl: Report connect type as Xen

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

> 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.

Regards, Jim -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list