[libvirt] [PATCH] libxl config file convertion: correct `type=netfront' to 'type=vif'
According to current xl.cfg docs and xl codes, it uses type=vif instead of type=netfront. Currently after domxml-to-native, libvirt xml model=netfront will be converted to xl type=netfront. This has no problem before, xen codes for a long time just check type=ioemu, if not, set type to _VIF. Since libxl uses parse_nic_config to avoid duplicate codes, it compares 'type=vif' and 'type=ioemu' for valid parameters, others are considered as invalid, thus we have problem with type=netfront in xl config file. #xl create sles12gm-hvm.orig Parsing config from sles12gm-hvm.orig Invalid parameter `type'. Correct the convertion in libvirt, so that it matchs libxl codes and also xl.cfg. Signed-off-by: Chunyan Liu <cyliu@suse.com> --- Since type=netfront config has been used for a very long time, at lease for xm/xend, it has no problem. I'm not sure if we need to split into xenParseXLVif vs xenParseXMVif, and xenFormatXLVif vs xenFormatXMVif for this change? src/xenconfig/xen_common.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/xenconfig/xen_common.c b/src/xenconfig/xen_common.c index 4dcd484..ae81635 100644 --- a/src/xenconfig/xen_common.c +++ b/src/xenconfig/xen_common.c @@ -944,7 +944,8 @@ xenParseVif(virConfPtr conf, virDomainDefPtr def) VIR_STRDUP(net->model, model) < 0) goto cleanup; - if (!model[0] && type[0] && STREQ(type, "netfront") && + if (!model[0] && type[0] && + (STREQ(type, "netfront") || STREQ(type, "vif")) && VIR_STRDUP(net->model, "netfront") < 0) goto cleanup; @@ -1201,7 +1202,7 @@ xenFormatNet(virConnectPtr conn, virBufferAsprintf(&buf, ",model=%s", net->model); } else { if (net->model != NULL && STREQ(net->model, "netfront")) { - virBufferAddLit(&buf, ",type=netfront"); + virBufferAddLit(&buf, ",type=vif"); } else { if (net->model != NULL) virBufferAsprintf(&buf, ",model=%s", net->model); -- 2.1.4
On 04/08/2016 08:26 AM, Chunyan Liu wrote:
According to current xl.cfg docs and xl codes, it uses type=vif instead of type=netfront.
Currently after domxml-to-native, libvirt xml model=netfront will be converted to xl type=netfront. This has no problem before, xen codes for a long time just check type=ioemu, if not, set type to _VIF.
Since libxl uses parse_nic_config to avoid duplicate codes, it compares 'type=vif' and 'type=ioemu' for valid parameters, others are considered as invalid, thus we have problem with type=netfront in xl config file. #xl create sles12gm-hvm.orig Parsing config from sles12gm-hvm.orig Invalid parameter `type'.
Correct the convertion in libvirt, so that it matchs libxl codes and also xl.cfg.
Signed-off-by: Chunyan Liu <cyliu@suse.com> --- Since type=netfront config has been used for a very long time, at lease for xm/xend, it has no problem. I'm not sure if we need to split into xenParseXLVif vs xenParseXMVif, and xenFormatXLVif vs xenFormatXMVif for this change?
Hm, although looking at xend code (xen 4.4, 4.3) it seems that only type=ioemu is tested against too, which means the patch as is looks good and XM would accept "vif" same as the previous netfront". Though splitting that into two functions as you suggest would perhaps be "safer" as the behavior is no longer kept the same across XM and XL - but may be that isn't a concern. Joao
On 04/08/2016 01:26 AM, Chunyan Liu wrote:
According to current xl.cfg docs and xl codes, it uses type=vif instead of type=netfront.
Currently after domxml-to-native, libvirt xml model=netfront will be converted to xl type=netfront. This has no problem before, xen codes for a long time just check type=ioemu, if not, set type to _VIF.
Since libxl uses parse_nic_config to avoid duplicate codes, it compares 'type=vif' and 'type=ioemu' for valid parameters, others are considered as invalid, thus we have problem with type=netfront in xl config file. #xl create sles12gm-hvm.orig Parsing config from sles12gm-hvm.orig Invalid parameter `type'.
Correct the convertion in libvirt, so that it matchs libxl codes and also xl.cfg.
Signed-off-by: Chunyan Liu <cyliu@suse.com> --- Since type=netfront config has been used for a very long time, at lease for xm/xend, it has no problem. I'm not sure if we need to split into xenParseXLVif vs xenParseXMVif, and xenFormatXLVif vs xenFormatXMVif for this change?
I think separate parsers/formatters for xm and xl is the safest approach. To ease the burden, you could make the existing functions in xen_common take a 'const char *' parameter for the preferred name, and provide it in the xm and xl specific functions.
src/xenconfig/xen_common.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/xenconfig/xen_common.c b/src/xenconfig/xen_common.c index 4dcd484..ae81635 100644 --- a/src/xenconfig/xen_common.c +++ b/src/xenconfig/xen_common.c @@ -944,7 +944,8 @@ xenParseVif(virConfPtr conf, virDomainDefPtr def) VIR_STRDUP(net->model, model) < 0) goto cleanup;
- if (!model[0] && type[0] && STREQ(type, "netfront") && + if (!model[0] && type[0] && + (STREQ(type, "netfront") || STREQ(type, "vif")) && VIR_STRDUP(net->model, "netfront") < 0) goto cleanup;
@@ -1201,7 +1202,7 @@ xenFormatNet(virConnectPtr conn, virBufferAsprintf(&buf, ",model=%s", net->model); } else { if (net->model != NULL && STREQ(net->model, "netfront")) { - virBufferAddLit(&buf, ",type=netfront"); + virBufferAddLit(&buf, ",type=vif");
This causes a 'make check' failure, which can be avoided with the xm and xl specific approach. Can you also add a xlconfigtest for type=vif? Regards, Jim
participants (3)
-
Chunyan Liu -
Jim Fehlig -
Joao Martins