4:33 a.m.
This patch removes what appears to be an unnecessary check in the VMX
driver which is preventing us from importing guests that have an odd
number of vCPUs with virt-v2v.
Unfortunately to test this it seems you need a real VMware server
somewhere (substitute for ‘example.com’ below).
Download the VMX file attached to
https://bugzilla.redhat.com/show_bug.cgi?id=1584091
$ virsh -c 'esx://example.com' domxml-from-native vmware-vmx window2016.vmx
Enter root's password for example.com:
error: internal error: Expecting VMX entry 'numvcpus' to be an unsigned integer (1
or a multiple of 2) but found 7
After applying the patch:
$ ~/d/libvirt/run ~/d/libvirt/tools/virsh -c 'esx://example.com'
domxml-from-native vmware-vmx window2016.vmx
Enter root's password for example.com:
<domain type='vmware'>
...
<cpu>
<topology sockets='1' cores='7' threads='1'/>
...
Rich.
4:33 a.m.
https://bugzilla.redhat.com/show_bug.cgi?id=1584091
It is possible to create a VMware guest with an odd number of vCPUs,
but such guests cannot be accessed by libvirt because of this
unnecessary check.
I retained the sanity-check that numvcpus must be >= 1.
Signed-off-by: Richard W.M. Jones <rjones(a)redhat.com>
---
src/vmx/vmx.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/vmx/vmx.c b/src/vmx/vmx.c
index bdc27b15b0..456bbaf190 100644
--- a/src/vmx/vmx.c
+++ b/src/vmx/vmx.c
@@ -1506,10 +1506,10 @@ virVMXParseConfig(virVMXContext *ctx,
if (virVMXGetConfigLong(conf, "numvcpus", &numvcpus, 1, true) < 0)
goto cleanup;
- if (numvcpus <= 0 || (numvcpus % 2 != 0 && numvcpus != 1)) {
+ if (numvcpus <= 0) {
virReportError(VIR_ERR_INTERNAL_ERROR,
- _("Expecting VMX entry 'numvcpus' to be an unsigned
"
- "integer (1 or a multiple of 2) but found %lld"),
numvcpus);
+ _("Expecting VMX entry 'numvcpus' to be a positive
"
+ "integer >= 1, but found %lld"), numvcpus);
goto cleanup;
}
--
2.16.2
4:52 a.m.
On Wed, May 30, 2018 at 10:33:45 +0100, Richard W.M. Jones wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1584091
It is possible to create a VMware guest with an odd number of vCPUs,
but such guests cannot be accessed by libvirt because of this
unnecessary check.
I retained the sanity-check that numvcpus must be >= 1.
Signed-off-by: Richard W.M. Jones <rjones(a)redhat.com>
---
src/vmx/vmx.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/vmx/vmx.c b/src/vmx/vmx.c
index bdc27b15b0..456bbaf190 100644
--- a/src/vmx/vmx.c
+++ b/src/vmx/vmx.c
@@ -1506,10 +1506,10 @@ virVMXParseConfig(virVMXContext *ctx,
if (virVMXGetConfigLong(conf, "numvcpus", &numvcpus, 1, true) < 0)
goto cleanup;
- if (numvcpus <= 0 || (numvcpus % 2 != 0 && numvcpus != 1)) {
+ if (numvcpus <= 0) {
virReportError(VIR_ERR_INTERNAL_ERROR,
- _("Expecting VMX entry 'numvcpus' to be an unsigned
"
- "integer (1 or a multiple of 2) but found %lld"),
numvcpus);
+ _("Expecting VMX entry 'numvcpus' to be a positive
"
+ "integer >= 1, but found %lld"), numvcpus);
goto cleanup;
}
The same check is in virVMXFormatConfig:
maxvcpus = virDomainDefGetVcpusMax(def);
if (maxvcpus == 0 || (maxvcpus % 2 != 0 && maxvcpus != 1)) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("Expecting domain XML entry 'vcpu' to be 1 or a "
"multiple of 2 but found %d"),
maxvcpus);
goto cleanup;
}
4:55 a.m.
On Wednesday, 30 May 2018 11:33:45 CEST Richard W.M. Jones wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1584091
It is possible to create a VMware guest with an odd number of vCPUs,
but such guests cannot be accessed by libvirt because of this
unnecessary check.
I retained the sanity-check that numvcpus must be >= 1.
Signed-off-by: Richard W.M. Jones <rjones(a)redhat.com>
---
NACK until there is a reply to
https://www.redhat.com/archives/libvir-list/2018-May/msg02159.html
Also, this patch is incomplete, since:
- there giant "documentation" comment at the beginning was not updated
- virVMXFormatConfig has the very same check
That is why I did not send this patch yet: the check was added on
purpose (documented, and implemented), so there must be a reason, even
if trivial. I can take care of this, but after knowing a bit more.
--
Pino Toscano
2404
days inactive
2404
days old
3 comments
3 participants
participants (3)
-
Peter Krempa -
Pino Toscano -
Richard W.M. Jones