[ovirt-users] numa error after upgrading from 3.5rc2 to 3.5rc3

[Gianluca Cecchi]

Hello,
my suspect was correct.
I found some reference here about possible values:
http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA

so I made this
[root at ovirtmgr ~]# cat numa_tune.xml
<vm><numa_tune_mode>interleave</numa_tune_mode></vm>


[root at ovirtmgr ~]# curl --insecure -u "admin at internal:my_password" -H
"Content-type: application/xml" -T numa_tune.xml '
https://ovirtmgr/api/vms/168470b1-b7eb-4dab-8fa4-6b744e2ad738'

and now start of VM succeeds with
[root at ovirtmgr ~]# curl --insecure   --request POST -H "Content-type:
application/xml" -u "admin at internal:my_password"  --header "Accept:
application/xml" --data '<action> </action>' "
https://ovirtmgr/ovirt-engine/api/vms/168470b1-b7eb-4dab-8fa4-6b744e2ad738/start
"


In qemu log file for the VM

2014-09-25 13:55:38.111+0000: starting up
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin
QEMU_AUDIO_DRV=spice /usr/libexec/qemu-kvm -name ubuntutrusty -S -M
rhel6.5.0 -cpu Nehalem -enable-kvm -m 4096 -realtime mlock=off -smp
1,maxcpus=16,sockets=16,cores=1,threads=1 -uuid
168470b1-b7eb-4dab-8fa4-6b744e2ad738 -smbios
type=1,manufacturer=oVirt,product=oVirt
Node,version=6-5.el6.centos.11.2,serial=9B1B2F84-3CB9-11DE-B5A1-001517B493E8,uuid=168470b1-b7eb-4dab-8fa4-6b744e2ad738
-nodefconfig -nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/ubuntutrusty.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc
base=2014-09-25T15:55:37,driftfix=slew -no-kvm-pit-reinjection -no-shutdown
-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device
virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x5 -device
virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x6 -drive
if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw,serial=
-device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive
file=/rhev/data-center/4512e567-f94e-476a-a050-6cd0a15e260a/346732c8-e1e9-49de-9ca4-63f4477ef6dd/images/d690177e-eca6-4dd2-9380-9d2d49c35b68/cc46a780-ea50-4a71-8acc-963f703e7321,if=none,id=drive-virtio-disk0,format=qcow2,serial=d690177e-eca6-4dd2-9380-9d2d49c35b68,cache=none,werror=stop,rerror=stop,aio=native
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
-netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=26 -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=00:01:a4:a3:42:02,bus=pci.0,addr=0x3
-chardev
socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/168470b1-b7eb-4dab-8fa4-6b744e2ad738.com.redhat.rhevm.vdsm,server,nowait
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm
-chardev
socket,id=charchannel1,path=/var/lib/libvirt/qemu/channels/168470b1-b7eb-4dab-8fa4-6b744e2ad738.org.qemu.guest_agent.0,server,nowait
-device
virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0
-chardev spicevmc,id=charchannel2,name=vdagent -device
virtserialport,bus=virtio-serial0.0,nr=3,chardev=charchannel2,id=channel2,name=com.redhat.spice.0
-spice
port=5900,tls-port=5901,addr=192.168.1.74,x509-dir=/etc/pki/vdsm/libvirt-spice,tls-channel=main,tls-channel=display,tls-channel=inputs,tls-channel=cursor,tls-channel=playback,tls-channel=record,tls-channel=smartcard,tls-channel=usbredir,seamless-migration=on
-k en-us -vga qxl -global qxl-vga.ram_size=67108864 -global
qxl-vga.vram_size=33554432 -device intel-hda,id=sound0,bus=pci.0,addr=0x4
-device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8

The question now is how can I influence configuration from the GUI so that
all my VMs are by default created as interleave.

I will also try to create VM from scratch in 3.5rc3 to find if the problem
could arise only for pre-existing VMs or not...

Comments welcome on my findings....

Gianluca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20140925/32dd0e91/attachment-0001.html>