Ronen,
Can you please look into it and re-assign as needed (qemu/kvm)?

It looks OK to me, since the virtual size is derived from the address space max address, and not from the actually allocated memory, so it is not swapped or anything that can cause performance degradation.
QE, can you look into it.

I think that /proc/<processid>/status can tell, but I am not an expert.

I understand VSZ is not the actual RSS, but a 1GB overhead is something we may want to be able to explain.?
Additionally, what would happen during migration? will this extra 1GB be migrated?

If you cat /proc/<pid>/maps you will see where the extra address space is being used. You will see a stack for every qemu-kvm thread, a zillion shared libraries, the qemu-kvm heap, the guest memory map, and a few other things.

Only guest memory should be migrated over in a live migration, everything else is initialized from scratch on the destination side. The vast majority of the virtual memory is shared (libraries), or never used (the qemu IO threads use far less stack space than the allocated virtual space for each thread stack).

Whether 1GB is reasonable is for the qemu-kvm developers to decide.

I can reproduce this issue on rhel6.5 host with the following version:

kernel-2.6.32-410.el6.x86_64
qemu-kvm-0.12.1.2-2.393.el6.x86_64
seabios-0.6.1.2-26.el6.x86_64

(1) Boot up a guest with 2G mem.

#  /usr/libexec/qemu-kvm -cpu SandyBridge -M rhel6.5.0 -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 -name rhel6.4-64 -uuid 9a0e67ec-f286-d8e7-0548-0c1c9ec93009 -nodefconfig -nodefaults -monitor stdio -rtc base=utc,clock=host,driftfix=slew -no-kvm-pit-reinjection -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/home/RHEL-Server-6.4-64-virtio.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,id=hostnet0,vhost=on -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:d5:51:8a,bus=pci.0,addr=0x3 -chardev socket,id=charserial0,path=/tmp/isa-serial,server,nowait -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc :10 -vga std -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=0x6 -qmp tcp:0:5555,server,nowait -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7


(2) Check the VSZ size.
#ps -aux | grep qemu

Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.8/FAQ
root      4752 32.0  5.7 3296196 457056 pts/1  Dl+  15:54   0:15 /usr/libexec/qemu-kvm -cpu SandyBridge -M rhel6.5.0 -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 ....

It shows 3296196KB VSZ size, about 3.14G.

We're going to investigate it upstream and for that we'll track the progress via Bug 1193966 (RHEL7). We don't have plans to fix it in RHEL6 though, so I'm closing this bug.

Alex, if this issue is critical or in any way time sensitive, please raise a ticket through your regular Red Hat support channels to make certain it receives the proper attention and prioritization that will result in a timely resolution.

For information on how to contact the Red Hat production support team, please visit: https://www.redhat.com/support/process/production/#howto

Thanks!