Created attachment 989565 [details] engine and vdsm logs Description of problem: Failed to run vm with NUMA under RHEL7.1 Version-Release number of selected component (if applicable): vdsm-4.16.8.1-6.el7ev.x86_64 rhevm-3.5.0-0.31.el6ev.noarch How reproducible: Always Steps to Reproduce: 1. Create vm and pinned it to host with NUMA architecture 2. Create numa nodes on vm 3. Run vm Actual results: Vm failed to run with error under vdsm log: Traceback (most recent call last): File "/usr/share/vdsm/virt/vm.py", line 2264, in _startUnderlyingVm self._run() File "/usr/share/vdsm/virt/vm.py", line 3323, in _run self._connection.createXML(domxml, flags), File "/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py", line 111, in wrapper ret = f(*args, **kwargs) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3424, in createXML if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self) libvirtError: internal error: early end of file from monitor: possible problem: 2015-02-09T08:17:58.028331Z qemu-kvm: -numa memdev is not supported by machine rhel6.5.0 Expected results: Vm success to run Additional info:
Additional information about versions: 3.10.0-227.el7.x86_64 Red Hat Enterprise Linux Server release 7.1 (Maipo) libvirt-1.2.8-16.el7.x86_64
how is this relevant to 3.5 GA on an unsupported RHEL release of 7.1? Results on libvirt&qemu from the latest 7.0.z?
Gil ask from me to check feature on RHEL 7.1, I checked it and open bug for version where I checked it. About reasons you can ask Gil
it's cool to test against 7.1 as it's going out soon and we should be ready. But first and foremost you should test on 7.0 please doublecheck the libvirt version as there was a recent 7.0.z libvirt fix
can you please attach the corresponding qemu.log?
Created attachment 989764 [details] qemu log I wrote libvirt version above, so you can say me if fix already in.
it may be a regression in libvirt behavior, memdev devices are not supported in rhel_6.5.0 machine type
1. Removing blocker flag since there's no regression here in functionality. NUMA pinning (strict mode) is not a common use case in RHEL 7.x (unlike 6.x where we have numad). 2. Functionality wise, interleaved mode should be used if pinning (strict) does not work, and no need for special settings since autonuma is being used. 3. Agree with Michal 7.0.z should be verified first. Please use 1.1.1-29+ as you did with cpu qos. 4. Looking into vdsm logs show we're using rhel6.5.0: Thread-150::DEBUG::2015-02-09 10:10:36,931::__init__::469::jsonrpc.JsonRpcServer::(_serveRequest) Calling 'VM.create' in bridge with {u'vmParams': {u'acpiEnable': u'true', u'emulatedMachine': u'rhel6.5.0', and we should check if we should change it or indeed a libvirt regression which will require a libvirt fix.
removing 3.5.0 flag to allow to move to async release. still needs 3.5.z flag.
Can you please check if still relevant in RHEV 3.5.5?
Checked on rhevm-3.5.5-0.1.el6ev.noarch. Vm with numa succeed to run, also I see difference in qemu command: -numa node,nodeid=0,cpus=0-1,mem=1024 instead of -numa node,nodeid=0,cpus=0-1,memdev=ram-node0 So I believe we can close this bug.
Host version: Red Hat Enterprise Linux Server release 7.1 (Maipo) 3.10.0-229.20.1.el7.x86_64 vdsm-4.16.27-1.el7ev.x86_64 libvirt-1.2.8-16.el7_1.5.x86_64
Closing based on comment 11.