- Users - libvirt List Archives

[libvirt-users] How to connect to console of domain on PowerPC?
by Yin Olivia-R63875 04 Feb '13

04 Feb '13

Hi, I tried to use libvirt to run KVM/QEMU on Freescale PowerPC platforms. So far there's only one serial device (spapr-vty) defined in QEMU to work as console for IBM PSeries platform. There's no serial device support in QEMU for Freescale PowerPC (ePAPR). libvirt/src/qemu/qemu_command.c /* This function generates the correct '-device' string for character * devices of each architecture. */ char * qemuBuildChrDeviceStr(virDomainChrDefPtr serial, virBitmapPtr qemuCaps, char *os_arch, char *machine) { virBuffer cmd = VIR_BUFFER_INITIALIZER; if (STREQ(os_arch, "ppc64") && STREQ(machine, "pseries")) { if (serial->deviceType == VIR_DOMAIN_CHR_DEVICE_TYPE_SERIAL && serial->source.type == VIR_DOMAIN_CHR_TYPE_PTY && serial->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_SPAPRVIO) { virBufferAsprintf(&cmd, "spapr-vty,chardev=char%s", serial->info.alias); if (qemuBuildDeviceAddressStr(&cmd, &serial->info, qemuCaps) < 0) goto error; } } else virBufferAsprintf(&cmd, "isa-serial,chardev=char%s,id=%s", serial->info.alias, serial->info.alias); if (virBufferError(&cmd)) { virReportOOMError(); goto error; } return virBufferContentAndReset(&cmd); error: virBufferFreeAndReset(&cmd); return NULL; } We usually connect guest with telnet. For instance, /usr/bin/qemu-system-ppc -name demo -M ppce500v2 -enable-kvm -m 256 -nographic -kernel /media/ram/uImage -initrd /media/ram/ramdisk -append "root=/dev/ram rw console=ttyS0,115200" -serial tcp::4445,server Then to run 'telnet 10.193.20.xxx 4445' could connect the guest. The temporary workaround is not add '-device' string after '-serial' option. diff -Nur libvirt-0.10.1.orig/src/qemu/qemu_command.c libvirt-0.10.1/src/qemu/qemu_command.c --- libvirt-0.10.1.orig/src/qemu/qemu_command.c 2012-08-30 15:35:18.000000000 +0530 +++ libvirt-0.10.1/src/qemu/qemu_command.c 2012-10-05 17:19:32.060368755 +0530 @@ -5501,13 +5501,15 @@ virCommandAddArg(cmd, devstr); VIR_FREE(devstr); - virCommandAddArg(cmd, "-device"); - if (!(devstr = qemuBuildChrDeviceStr(serial, qemuCaps, + if (!STREQ(def->os.arch, "ppc")) { + virCommandAddArg(cmd, "-device"); + if (!(devstr = qemuBuildChrDeviceStr(serial, + qemuCaps, def->os.arch, def->os.machine))) - goto error; - virCommandAddArg(cmd, devstr); - VIR_FREE(devstr); + goto error; + virCommandAddArg(cmd, devstr); + VIR_FREE(devstr); + } } else { virCommandAddArg(cmd, "-serial"); if (!(devstr = qemuBuildChrArgStr(&serial->source, NULL))) Applying the above patch to libvirt, all the other domain control commands could work except 'virsh console domain'. # cat >demo.args <<EOF > /usr/bin/qemu-system-ppc -name demo -M ppce500v2 -enable-kvm -m 256 > -nographic -kernel /media/ram/uImage -initrd /media/ram/ramdisk > -append "root=/dev/ram rw console=ttyS0,115200" -serial > tcp::4445,server -net nic EOF # vi demo.args /usr/bin/qemu-system-ppc -name demo -M ppce500v2 -enable-kvm -m 256 -nographic -kernel /media/ram/uImage -initrd /media/ram/ramdisk -append "root=/dev/ram rw console=ttyS0,115200" -serial tcp::4445,server -net nic # virsh domxml-from-native qemu-argv demo.args >demo.xml # vi demo.xml <domain type='kvm'> <name>demo</name> <uuid>985d7154-83c8-0763-cbac-ecd159eee8a6</uuid> <memory unit='KiB'>262144</memory> <currentMemory unit='KiB'>262144</currentMemory> <vcpu placement='static'>1</vcpu> <os> <type arch='ppc' machine='ppce500v2'>hvm</type> <kernel>/media/ram/uImage</kernel> <initrd>/media/ram/ramdisk</initrd> <cmdline>root=/dev/ram rw console=ttyS0,115200</cmdline> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/bin/qemu-system-ppc</emulator> <serial type='tcp'> <source mode='bind' host='' service='4445'/> <protocol type='raw'/> <target port='0'/> </serial> <console type='tcp'> <source mode='bind' host='' service='4445'/> <protocol type='raw'/> <target type='serial' port='0'/> </console> <memballoon model='virtio'/> </devices> </domain> # virsh -c qemu:///system define demo.xml # virsh -c qemu:///system start demo But it seemed that can't connect to the console. # virsh -c qemu:///system console demo Connected to domain test Escape character is ^] error: internal error character device (null) is not using a PTY I tried also use '-serial pty' option, /usr/bin/qemu-system-ppc -name test -M ppce500v2 -enable-kvm -m 256 -nographic -kernel /media/ram/uImage -initrd /media/ram/ramdisk -append "root=/dev/ram rw console=ttyS0,115200" -serial pty Then there's no other output after the below message: # virsh -c qemu:///system console demo Connected to domain test Escape character is ^] It seemed not libvirt group issue. I also tried the LXC. It could connect to the console if <init>/bin/sh/</init> instead of <init>/sbin/init</init> Best Regards, Olivia

1 0

[libvirt-users] Networking problem - multiple guests using MacVTap in bridge mode
by Filip Korzeniowski 03 Feb '13

03 Feb '13

Dear list, I am getting strange problems using a setup outlined in the subject. I want to run three guests on a single kvm host. The guests are connected through macvtap directly to the network device 'eth0' of the host using this configuration: <interface type='direct'> <mac address='52:54:00:86:3f:24'/> <source dev='eth0' mode='bridge'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> Each guest is assigned a static ip address, no DHCP is involved. When I start the guests the macvtap links are generated automatically, ifconfig outputs this: macvtap2 Link encap:Ethernet HWaddr 52:54:00:86:3f:24 inet6 addr: fe80::5054:ff:fe86:3f24/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:98 errors:0 dropped:0 overruns:0 frame:0 TX packets:31 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:10946 (10.6 KiB) TX bytes:2184 (2.1 KiB) However, depending on the startup order, only the first two guests are able to reach the network! I can't access the third one. After the initial startup, the last host won't connect to the network even if I restart all the guests in a differnt order. I can only reset this by restarting the host. As far as I have tested this, it really depends on the initial startup order of the guests after a host restart. This seems very strange to me. As I am quite new to all of this, I have no clue how to start searching for the problem here. Can anyone provide me with some hints?

2 1

[libvirt-users] control ip address of VM
by zorg 03 Feb '13

03 Feb '13

HI I have 15 vm (libvirt + kvm) with a network brigde and ip address like 192.168.0.1 VM1 192.168.0.2 VM2 192.168.0.3 VM3 ..... The vm are use by other people and I want to be sure that if someone change the ip of VM3 to 192.168.0.1 it will filter it network traffic for him and can't flood the VM1 What the best way to achieve this Hope I m clear enough

2 1

[libvirt-users] Sanlock gives up lock when VM is paused
by Michael Rodrigues 01 Feb '13

01 Feb '13

Hello, I'm using libvirt and sanlock on qemu-kvm guests. Each guest has it's own Logical Volume for it's root filesystem. Sanlock is configured and working and prevents me from starting the same VM twice on multiple nodes and corrupting it's root filesystem. Each VM's domain XML resides on 2 servers that share the LVM volume group over fiber channel. In testing, I noticed that if I pause a VM on node 1, the sanlock lock is relinquished, and I am able to start the same VM, using the same root filesystem, on node 2. I get a lock error when unpausing node 1's VM if node 2's copy is still running, but by this point, the disk may already be corrupted. Is it necessary that paused VMs don't get to keep their locks? Is there a way to configure sanlock to lock when a VM is paused? Versions: sanlock(-devel, -lib) 2.3-1.el6 libvirt(-lock-sanlock, -client) 0.9.10-21.el6_3.8 I'm using NFS for the lockspace. Thanks, Michael -- Michael Rodrigues Interim Help Desk Manager Gevirtz Graduate School of Education Education Building 4203 (805) 893-8031 help(a)education.ucsb.edu

2 7

[libvirt-users] Live Migration and KSM merging
by James 01 Feb '13

01 Feb '13

Hi, Could anyone provide (or point me to) information on how KSM merging behaves when performing live migrations? Does libvirt perform any special work to trigger KSM scanning of the migrated pages? Any guidance is appreciated. James

2 1

[libvirt-users] How to copy snapshots of a VM to the other computer.
by Jonghee Youn 01 Feb '13

01 Feb '13

Currently, I've tried to move qemu VM image to a new computer. So, I copied VM image files in /var/lib/libvirt/images, VM xml files in /etc/libvirt/qemu, VM snapshot files in /var/lib/libvirt/qemu/snapshot to the same places at the new computer. Everything is OK except snapshot!! When I use "qemu-img info" for the copied VM image, I can see the snapshot list in the result as shown below: root@doc-scheduler:/var/lib/libvirt/images# qemu-img info VM22.img image: VM22.img file format: qcow2 virtual size: 10G (10737418240 bytes) disk size: 1.7G cluster_size: 65536 Snapshot list: ID TAG VM SIZE DATE VM CLOCK 1 VM22_A 228M 2013-01-31 10:06:45 00:06:38.110 But, when I use "virsh snapshot-list " for the copied VM, the result is empty as follows: root@doc-scheduler:~# virsh snapshot-list VM22 Name Creation Time State ------------------------------------------------------------ and of course, I can't revert to the snapshot. Please let me know how I can copy my snapshots to the new machine. Thanks.

2 1

[libvirt-users] migrate vm images to new storage pool
by Jamie Fargen 01 Feb '13

01 Feb '13

I am searching for directions for using live block migration to copy running vm's to a different storage pool. Example: VM1 running on HOST1, the image(s) for VM1 are stored in /var/lib/libvirt/images. I'd like to copy the disk image(s) that VM1 is using to /nfs/images. Without stopping/pausing/powering down the VM. Regards, Jamie Ian Fargen

1 0

Re: [libvirt-users] windows 2008 guest causing rcu_shed to emit NMI
by Andrey Korolyov 31 Jan '13

31 Jan '13

On Thu, Jan 31, 2013 at 12:11 AM, Marcelo Tosatti <mtosatti(a)redhat.com> wrote: > On Wed, Jan 30, 2013 at 11:21:08AM +0300, Andrey Korolyov wrote: >> On Wed, Jan 30, 2013 at 3:15 AM, Marcelo Tosatti <mtosatti(a)redhat.com> wrote: >> > On Tue, Jan 29, 2013 at 02:35:02AM +0300, Andrey Korolyov wrote: >> >> On Mon, Jan 28, 2013 at 5:56 PM, Andrey Korolyov <andrey(a)xdel.ru> wrote: >> >> > On Mon, Jan 28, 2013 at 3:14 AM, Marcelo Tosatti <mtosatti(a)redhat.com> wrote: >> >> >> On Mon, Jan 28, 2013 at 12:04:50AM +0300, Andrey Korolyov wrote: >> >> >>> On Sat, Jan 26, 2013 at 12:49 AM, Marcelo Tosatti <mtosatti(a)redhat.com> wrote: >> >> >>> > On Fri, Jan 25, 2013 at 10:45:02AM +0300, Andrey Korolyov wrote: >> >> >>> >> On Thu, Jan 24, 2013 at 4:20 PM, Marcelo Tosatti <mtosatti(a)redhat.com> wrote: >> >> >>> >> > On Thu, Jan 24, 2013 at 01:54:03PM +0300, Andrey Korolyov wrote: >> >> >>> >> >> Thank you Marcelo, >> >> >>> >> >> >> >> >>> >> >> Host node locking up sometimes later than yesterday, bur problem still >> >> >>> >> >> here, please see attached dmesg. Stuck process looks like >> >> >>> >> >> root 19251 0.0 0.0 228476 12488 ? D 14:42 0:00 >> >> >>> >> >> /usr/bin/kvm -no-user-config -device ? -device pci-assign,? -device >> >> >>> >> >> virtio-blk-pci,? -device >> >> >>> >> >> >> >> >>> >> >> on fourth vm by count. >> >> >>> >> >> >> >> >>> >> >> Should I try upstream kernel instead of applying patch to the latest >> >> >>> >> >> 3.4 or it is useless? >> >> >>> >> > >> >> >>> >> > If you can upgrade to an upstream kernel, please do that. >> >> >>> >> > >> >> >>> >> >> >> >>> >> With vanilla 3.7.4 there is almost no changes, and NMI started firing >> >> >>> >> again. External symptoms looks like following: starting from some >> >> >>> >> count, may be third or sixth vm, qemu-kvm process allocating its >> >> >>> >> memory very slowly and by jumps, 20M-200M-700M-1.6G in minutes. Patch >> >> >>> >> helps, of course - on both patched 3.4 and vanilla 3.7 I`m able to >> >> >>> >> kill stuck kvm processes and node returned back to the normal, when on >> >> >>> >> 3.2 sending SIGKILL to the process causing zombies and hanged ``ps'' >> >> >>> >> output (problem and workaround when no scheduler involved described >> >> >>> >> here http://www.spinics.net/lists/kvm/msg84799.html) >> >> >>> > >> >> >>> > Try disabling pause loop exiting with ple_gap=0 kvm-intel.ko module parameter. >> >> >>> > >> >> >>> >> >> >>> Hi Marcelo, >> >> >>> >> >> >>> thanks, this parameter helped to increase number of working VMs in a >> >> >>> half of order of magnitude, from 3-4 to 10-15. Very high SY load, 10 >> >> >>> to 15 percents, persists on such numbers for a long time, where linux >> >> >>> guests in same configuration do not jump over one percent even under >> >> >>> stress bench. After I disabled HT, crash happens only in long runs and >> >> >>> now it is kernel panic :) >> >> >>> Stair-like memory allocation behaviour disappeared, but other symptom >> >> >>> leading to the crash which I have not counted previously, persists: if >> >> >>> VM count is ``enough'' for crash, some qemu processes starting to eat >> >> >>> one core, and they`ll panic system after run in tens of minutes in >> >> >>> such state or if I try to attach debugger to one of them. If needed, I >> >> >>> can log entire crash output via netconsole, now I have some tail, >> >> >>> almost the same every time: >> >> >>> http://xdel.ru/downloads/btwin.png >> >> >> >> >> >> Yes, please log entire crash output, thanks. >> >> >> >> >> > >> >> > Here please, 3.7.4-vanilla, 16 vms, ple_gap=0: >> >> > >> >> > http://xdel.ru/downloads/oops-default-kvmintel.txt >> >> >> >> Just an update: I was able to reproduce that on pure linux VMs using >> >> qemu-1.3.0 and ``stress'' benchmark running on them - panic occurs at >> >> start of vm(with count ten working machines at the moment). Qemu-1.1.2 >> >> generally is not able to reproduce that, but host node with older >> >> version crashing on less amount of Windows VMs(three to six instead >> >> ten to fifteen) than with 1.3, please see trace below: >> >> >> >> http://xdel.ru/downloads/oops-old-qemu.txt >> > >> > Single bit memory error, apparently. Try: >> > >> > 1. memtest86. >> > 2. Boot with slub_debug=ZFPU kernel parameter. >> > 3. Reproduce on different machine >> > >> > >> >> Hi Marcelo, >> >> I always follow the rule - if some weird bug exists, check it on >> ECC-enabled machine and check IPMI logs too before start complaining >> :) I have finally managed to ``fix'' the problem, but my solution >> seems a bit strange: >> - I have noticed that if virtual machines started without any cgroup >> setting they will not cause this bug under any conditions, >> - I have thought, very wrong in my mind, that the >> CONFIG_SCHED_AUTOGROUP should regroup the tasks without any cgroup and >> should not touch tasks already inside any existing cpu cgroup. First >> sight on the 200-line patch shows that the autogrouping always applies >> to all tasks, so I tried to disable it, >> - wild magic appears - VMs didn`t crashed host any more, even in count >> 30+ they work fine. >> I still don`t know what exactly triggered that and will I face it >> again under different conditions, so my solution more likely to be a >> patch of mud in wall of the dam, instead of proper fixing. >> >> There seems to be two possible origins of such error - a very very >> hideous race condition involving cgroups and processes like qemu-kvm >> causing frequent context switches and simple incompatibility between >> NUMA, logic of CONFIG_SCHED_AUTOGROUP and qemu VMs already doing work >> in the cgroup, since I have not observed this errors on single numa >> node(mean, desktop) on relatively heavier condition. > > Yes, it would be important to track it down though. Enabling > slub_debug=ZFPU kernel parameter should help. > > Hi Marcelo, I have finally beat that one. As I have mentioned before in the off-list message, nested cgroups for vcpu/emulator threads created by libvirt was a root cause of this problem. Today we`ve disabled creation of cgroup deeper than qemu/vm/ level and trace didn`t showed up under different workloads. So for libvirt itself, it may be a feature request to create thread-based cgroups iff any element of the VM` config requires that. As for cgroups, seems it is fatal to have very large amount of nested elements inside cpu on qemu-kvm, or on very large amount of threads - since I have limited core amount on each node, I can`t prove what exactly, complicated cgroup hierarchy or some side effects putting threads on the dedicated cgroup, caused all this pain. And, of course, without Windows(tm) bug is very hard to observe in the wild, since almost no synthetic test I have put on the linux VMs is able to show it.

1 0

[libvirt-users] There's no output when connecting to console of domain on PowerPC
by Yin Olivia-R63875 31 Jan '13

31 Jan '13

Hi, I tried to use libvirt to run KVM/QEMU on Freescale PowerPC platforms. So far there's only one serial device (spapr-vty) defined in QEMU to work as console for IBM PSeries platform. There's no serial device support in QEMU for Freescale PowerPC (ePAPR). libvirt/src/qemu/qemu_command.c /* This function generates the correct '-device' string for character * devices of each architecture. */ char * qemuBuildChrDeviceStr(virDomainChrDefPtr serial, virBitmapPtr qemuCaps, char *os_arch, char *machine) { virBuffer cmd = VIR_BUFFER_INITIALIZER; if (STREQ(os_arch, "ppc64") && STREQ(machine, "pseries")) { if (serial->deviceType == VIR_DOMAIN_CHR_DEVICE_TYPE_SERIAL && serial->source.type == VIR_DOMAIN_CHR_TYPE_PTY && serial->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_SPAPRVIO) { virBufferAsprintf(&cmd, "spapr-vty,chardev=char%s", serial->info.alias); if (qemuBuildDeviceAddressStr(&cmd, &serial->info, qemuCaps) < 0) goto error; } } else virBufferAsprintf(&cmd, "isa-serial,chardev=char%s,id=%s", serial->info.alias, serial->info.alias); if (virBufferError(&cmd)) { virReportOOMError(); goto error; } return virBufferContentAndReset(&cmd); error: virBufferFreeAndReset(&cmd); return NULL; } We usually connect guest with telnet. For instance, /usr/bin/qemu-system-ppc -name demo -M ppce500v2 -enable-kvm -m 256 -nographic -kernel /media/ram/uImage -initrd /media/ram/ramdisk -append "root=/dev/ram rw console=ttyS0,115200" -serial tcp::4445,server Then to run 'telnet 10.193.20.xxx 4445' could connect the guest. The temporary workaround is not add '-device' string after '-serial' option. diff -Nur libvirt-0.10.1.orig/src/qemu/qemu_command.c libvirt-0.10.1/src/qemu/qemu_command.c --- libvirt-0.10.1.orig/src/qemu/qemu_command.c 2012-08-30 15:35:18.000000000 +0530 +++ libvirt-0.10.1/src/qemu/qemu_command.c 2012-10-05 17:19:32.060368755 +0530 @@ -5501,13 +5501,15 @@ virCommandAddArg(cmd, devstr); VIR_FREE(devstr); - virCommandAddArg(cmd, "-device"); - if (!(devstr = qemuBuildChrDeviceStr(serial, qemuCaps, + if (!STREQ(def->os.arch, "ppc")) { + virCommandAddArg(cmd, "-device"); + if (!(devstr = qemuBuildChrDeviceStr(serial, qemuCaps, def->os.arch, def->os.machine))) - goto error; - virCommandAddArg(cmd, devstr); - VIR_FREE(devstr); + goto error; + virCommandAddArg(cmd, devstr); + VIR_FREE(devstr); + } } else { virCommandAddArg(cmd, "-serial"); if (!(devstr = qemuBuildChrArgStr(&serial->source, NULL))) Applying the above patch to libvirt, all the other domain control commands could work except 'virsh console domain'. # cat >demo.args <<EOF > /usr/bin/qemu-system-ppc -name demo -M ppce500v2 -enable-kvm -m 256 -nographic -kernel /media/ram/uImage -initrd /media/ram/ramdisk -append "root=/dev/ram rw console=ttyS0,115200" -serial tcp::4445,server -net nic > EOF # vi demo.args /usr/bin/qemu-system-ppc -name demo -M ppce500v2 -enable-kvm -m 256 -nographic -kernel /media/ram/uImage -initrd /media/ram/ramdisk -append "root=/dev/ram rw console=ttyS0,115200" -serial tcp::4445,server -net nic # virsh domxml-from-native qemu-argv demo.args >demo.xml # vi demo.xml <domain type='kvm'> <name>demo</name> <uuid>985d7154-83c8-0763-cbac-ecd159eee8a6</uuid> <memory unit='KiB'>262144</memory> <currentMemory unit='KiB'>262144</currentMemory> <vcpu placement='static'>1</vcpu> <os> <type arch='ppc' machine='ppce500v2'>hvm</type> <kernel>/media/ram/uImage</kernel> <initrd>/media/ram/ramdisk</initrd> <cmdline>root=/dev/ram rw console=ttyS0,115200</cmdline> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/bin/qemu-system-ppc</emulator> <serial type='tcp'> <source mode='bind' host='' service='4445'/> <protocol type='raw'/> <target port='0'/> </serial> <console type='tcp'> <source mode='bind' host='' service='4445'/> <protocol type='raw'/> <target type='serial' port='0'/> </console> <memballoon model='virtio'/> </devices> </domain> # virsh -c qemu:///system define demo.xml # virsh -c qemu:///system start demo But it seemed that can't connect to the console. # virsh -c qemu:///system console demo Connected to domain test Escape character is ^] error: internal error character device (null) is not using a PTY I tried also use '-serial pty' option, /usr/bin/qemu-system-ppc -name test -M ppce500v2 -enable-kvm -m 256 -nographic -kernel /media/ram/uImage -initrd /media/ram/ramdisk -append "root=/dev/ram rw console=ttyS0,115200" -serial pty Then there's no other output after the below message: # virsh -c qemu:///system console demo Connected to domain test Escape character is ^] It seemed not libvirt group issue. I also tried the LXC. It could connect to the console if <init>/bin/sh/</init> instead of <init>/sbin/init</init> Best Regards, Olivia

1 0

[libvirt-users] VMs fail to start with NUMA configuration
by Doug Goldstein 31 Jan '13

31 Jan '13

I am using libvirt 0.10.2.2 and qemu-kvm 1.2.2 (qemu-kvm 1.2.0 + qemu 1.2.2 applied on top plus a number of stability patches). Having issue where my VMs fail to start with the following message: kvm_init_vcpu failed: Cannot allocate memory Following the instructions at http://libvirt.org/formatdomain.html#elementsNUMATuning I've added the following to my VCPU configuration: <vcpu placement='auto'>2</vcpu> Which libvirt expands out as I'd expect per the documentation to: <vcpu placement='auto'>2</vcpu> <numatune> <memory tune='strict' placement='auto'/> </numatune> However, the VMs won't start and the system is no low on memory. # numactl --hardware available: 8 nodes (0-7) node 0 cpus: 0 4 8 12 16 20 24 28 node 0 size: 16374 MB node 0 free: 11899 MB node 1 cpus: 32 36 40 44 48 52 56 60 node 1 size: 16384 MB node 1 free: 15318 MB node 2 cpus: 2 6 10 14 18 22 26 30 node 2 size: 16384 MB node 2 free: 15766 MB node 3 cpus: 34 38 42 46 50 54 58 62 node 3 size: 16384 MB node 3 free: 15347 MB node 4 cpus: 3 7 11 15 19 23 27 31 node 4 size: 16384 MB node 4 free: 15041 MB node 5 cpus: 35 39 43 47 51 55 59 63 node 5 size: 16384 MB node 5 free: 15202 MB node 6 cpus: 1 5 9 13 17 21 25 29 node 6 size: 16384 MB node 6 free: 15197 MB node 7 cpus: 33 37 41 45 49 53 57 61 node 7 size: 16368 MB node 7 free: 15669 MB The system has 4 Opteron 6272 which add up to a total of 64 cores, 16 cores per socket. These are the CPUs that Dan B noticed issues with in the past regarding topology but I thought this was resolved. But the capabilities are posted below, you'll notice the topology is incorrect. # virsh capabilities <capabilities> <host> <uuid>44454c4c-5300-1038-8031-c4c04f545331</uuid> <cpu> <arch>x86_64</arch> <model>Opteron_G4</model> <vendor>AMD</vendor> <topology sockets='1' cores='8' threads='2'/> <feature name='nodeid_msr'/> <feature name='wdt'/> <feature name='skinit'/> <feature name='ibs'/> <feature name='osvw'/> <feature name='cr8legacy'/> <feature name='extapic'/> <feature name='cmp_legacy'/> <feature name='fxsr_opt'/> <feature name='mmxext'/> <feature name='osxsave'/> <feature name='monitor'/> <feature name='ht'/> <feature name='vme'/> </cpu> <power_management> <suspend_disk/> </power_management> <migration_features> <live/> <uri_transports> <uri_transport>tcp</uri_transport> </uri_transports> </migration_features> <topology> <cells num='8'> <cell id='0'> <cpus num='8'> <cpu id='0'/> <cpu id='4'/> <cpu id='8'/> <cpu id='12'/> <cpu id='16'/> <cpu id='20'/> <cpu id='24'/> <cpu id='28'/> </cpus> </cell> <cell id='1'> <cpus num='8'> <cpu id='32'/> <cpu id='36'/> <cpu id='40'/> <cpu id='44'/> <cpu id='48'/> <cpu id='52'/> <cpu id='56'/> <cpu id='60'/> </cpus> </cell> <cell id='2'> <cpus num='8'> <cpu id='2'/> <cpu id='6'/> <cpu id='10'/> <cpu id='14'/> <cpu id='18'/> <cpu id='22'/> <cpu id='26'/> <cpu id='30'/> </cpus> </cell> <cell id='3'> <cpus num='8'> <cpu id='34'/> <cpu id='38'/> <cpu id='42'/> <cpu id='46'/> <cpu id='50'/> <cpu id='54'/> <cpu id='58'/> <cpu id='62'/> </cpus> </cell> <cell id='4'> <cpus num='8'> <cpu id='3'/> <cpu id='7'/> <cpu id='11'/> <cpu id='15'/> <cpu id='19'/> <cpu id='23'/> <cpu id='27'/> <cpu id='31'/> </cpus> </cell> <cell id='5'> <cpus num='8'> <cpu id='35'/> <cpu id='39'/> <cpu id='43'/> <cpu id='47'/> <cpu id='51'/> <cpu id='55'/> <cpu id='59'/> <cpu id='63'/> </cpus> </cell> <cell id='6'> <cpus num='8'> <cpu id='1'/> <cpu id='5'/> <cpu id='9'/> <cpu id='13'/> <cpu id='17'/> <cpu id='21'/> <cpu id='25'/> <cpu id='29'/> </cpus> </cell> <cell id='7'> <cpus num='8'> <cpu id='33'/> <cpu id='37'/> <cpu id='41'/> <cpu id='45'/> <cpu id='49'/> <cpu id='53'/> <cpu id='57'/> <cpu id='61'/> </cpus> </cell> </cells> </topology> <secmodel> <model>none</model> <doi>0</doi> </secmodel> <secmodel> <model>dac</model> <doi>0</doi> </secmodel> </host> <guest> <os_type>hvm</os_type> <arch name='i686'> <wordsize>32</wordsize> <emulator>/usr/bin/qemu-system-x86_64</emulator> <machine>pc-1.2</machine> <machine canonical='pc-1.2'>pc</machine> <machine>pc-1.1</machine> <machine>pc-1.0</machine> <machine>pc-0.15</machine> <machine>pc-0.14</machine> <machine>pc-0.13</machine> <machine>pc-0.12</machine> <machine>pc-0.11</machine> <machine>pc-0.10</machine> <machine>isapc</machine> <machine>none</machine> <domain type='qemu'> </domain> <domain type='kvm'> <emulator>/usr/bin/qemu-kvm</emulator> <machine>pc-1.2</machine> <machine canonical='pc-1.2'>pc</machine> <machine>pc-1.1</machine> <machine>pc-1.0</machine> <machine>pc-0.15</machine> <machine>pc-0.14</machine> <machine>pc-0.13</machine> <machine>pc-0.12</machine> <machine>pc-0.11</machine> <machine>pc-0.10</machine> <machine>isapc</machine> <machine>none</machine> </domain> </arch> <features> <cpuselection/> <deviceboot/> <pae/> <nonpae/> <acpi default='on' toggle='yes'/> <apic default='on' toggle='no'/> </features> </guest> <guest> <os_type>hvm</os_type> <arch name='x86_64'> <wordsize>64</wordsize> <emulator>/usr/bin/qemu-system-x86_64</emulator> <machine>pc-1.2</machine> <machine canonical='pc-1.2'>pc</machine> <machine>pc-1.1</machine> <machine>pc-1.0</machine> <machine>pc-0.15</machine> <machine>pc-0.14</machine> <machine>pc-0.13</machine> <machine>pc-0.12</machine> <machine>pc-0.11</machine> <machine>pc-0.10</machine> <machine>isapc</machine> <machine>none</machine> <domain type='qemu'> </domain> <domain type='kvm'> <emulator>/usr/bin/qemu-kvm</emulator> <machine>pc-1.2</machine> <machine canonical='pc-1.2'>pc</machine> <machine>pc-1.1</machine> <machine>pc-1.0</machine> <machine>pc-0.15</machine> <machine>pc-0.14</machine> <machine>pc-0.13</machine> <machine>pc-0.12</machine> <machine>pc-0.11</machine> <machine>pc-0.10</machine> <machine>isapc</machine> <machine>none</machine> </domain> </arch> <features> <cpuselection/> <deviceboot/> <acpi default='on' toggle='yes'/> <apic default='on' toggle='no'/> </features> </guest> </capabilities> Any suggestions are appreciated. -- Doug Goldstein

3 14