On Sun, Mar 9, 2014 at 8:09 AM, Gene Cumm <gene.cumm at gmail.com> wrote:> On Sat, Mar 8, 2014 at 12:39 PM, Gene Cumm <gene.cumm at gmail.com> wrote: >> On Mar 8, 2014 10:08 AM, "Gene Cumm" <gene.cumm at gmail.com> wrote: >>> >>> vNIC not VMNet. AMD PCNet32 vlance, Intel e1000, Intel e1000e, VMware >>> VMXNet3? Feel free to directly email me your .vmx file if you don't know. >> >> So that should be vlance or flexible (which can be PCNet32 or e1000). Could >> you verify with a real OS? > > I finally got the opportunity to test your VMX and I can see the same > issue. Interestingly, I also see issues with booting from the second > NIC (null IP) > >> I see it has two cores per socket. Is it one socket? What exact make/model >> is the CPU in the host? You might be choking the VM. Have you considered >> just 1 socket and 1 core per socket?1) My assumption would be that the VMware virtualized AMD 79C970A (PCNet32 driver; vlance virtualDev) lacks proper EFI64 support. 2) I have 0 speed issues using your VMX. If you only have two real cores for this 2vCPU VM, you're choking it as the host needs time to run. If you choke it, you mess with timers. If you mess with timers, interface polling and a HUGE slew of items (including a guest OS's clock) will be slowed to a crawl. In my experience (both on ESXi and VMware Workstation), gGeneral sizing guidelines are that the first core on the first socket and 1-2GiB RAM should be considered dedicated to the host and arbitrary VMs should not have a vCPU count greater than the number of cores of an available socket and the vRAM should not exceed the RAM directly available to the NUMA node of the socket. 2 Intel Xeon x54xx constitute 1 NUMA node so you can have (1) 4vCPU VM with most of the RAM of the entire server. 2 Intel Xeon x55xx constitute 2 NUMA nodes so you can up to the vCPU count of the number of available cores in a socket and up to the available RAM directly controlled by that socket. If we had 2 Intel Xeon E5530 with (6) 8GiB DIMMs, the best we could do for a single VM on this otherwise idle host is 4vCPUs and 22-24 GiB RAM. -- -Gene
On 2014/3/10 ?? 05:48, Gene Cumm wrote:> 1) My assumption would be that the VMware virtualized AMD 79C970A > (PCNet32 driver; vlance virtualDev) lacks proper EFI64 support. > > 2) I have 0 speed issues using your VMX. If you only have two real > cores for this 2vCPU VM, you're choking it as the host needs time to > run. If you choke it, you mess with timers. If you mess with timers, > interface polling and a HUGE slew of items (including a guest OS's > clock) will be slowed to a crawl. > > In my experience (both on ESXi and VMware Workstation), gGeneral > sizing guidelines are that the first core on the first socket and > 1-2GiB RAM should be considered dedicated to the host and arbitrary > VMs should not have a vCPU count greater than the number of cores of > an available socket and the vRAM should not exceed the RAM directly > available to the NUMA node of the socket. 2 Intel Xeon x54xx > constitute 1 NUMA node so you can have (1) 4vCPU VM with most of the > RAM of the entire server. 2 Intel Xeon x55xx constitute 2 NUMA nodes > so you can up to the vCPU count of the number of available cores in a > socket and up to the available RAM directly controlled by that socket. > If we had 2 Intel Xeon E5530 with (6) 8GiB DIMMs, the best we could > do for a single VM on this otherwise idle host is 4vCPUs and 22-24 GiB > RAM. > > -- -GeneHi Gene, Thanks for your explanation. Today I did two more tests here. All were done with Syslinux 6.03-pre6. First one is for the real machine (Lenovo X230, Intel CPU core i5, NIC is Intel Corporation 82579LM Gigabit Network Connection (rev 04). The 2nd one is for VMWare WS 10 with 1 core client. The host machine uses Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz with hyper-thread on, so 8 cores shown in /proc/cpuinfo. I describe the results in the following: (1) For the Lenovo X230, I have the issue to EFI network booting. The client machine stopped at: ================Getting cached packet My IP is 192.168.1.1 ================The system log on the server shows: ================Mar 10 08:09:32 drbldbn dhcpd: Client 3c:97:e:9b:75:46 requests 1:2:3:4:5:6:c:d:f:11:12:16:17:1c:28:29:2a:2b:32:33:36:3a:3b:3c:42:43:61:80:81:82:83:84:85:86:87 - PXEClient:Arch:00007:UNDI:003016 - no dhcp-client-id Mar 10 08:09:32 drbldbn dhcpd: DHCPREQUEST for 192.168.1.1 (192.168.1.182) from 3c:97:0e:9b:75:46 via eth1 Mar 10 08:09:32 drbldbn dhcpd: DHCPACK on 192.168.1.1 to 3c:97:0e:9b:75:46 via eth1 Mar 10 08:09:32 drbldbn atftpd[4821]: Serving bootx64.efi to 192.168.1.1:1549 Mar 10 08:09:32 drbldbn atftpd[4821]: Serving bootx64.efi to 192.168.1.1:1550 Mar 10 08:12:02 drbldbn dhcpd: DHCPREQUEST for 192.168.1.1 from 3c:97:0e:9b:75:46 via eth1 Mar 10 08:12:02 drbldbn dhcpd: DHCPACK on 192.168.1.1 to 3c:97:0e:9b:75:46 via eth1 ================As you can tell, the client did not request ldlinux.e64. (2) For the VM with one core, The system log on the server shows: ================Mar 10 08:13:10 drbldbn dhcpd: Client 0:c:29:68:f3:23 requests 1:2:3:4:5:6:c:d:f:11:12:16:17:1c:28:29:2a:2b:32:33:36:3a:3b:3c:42:43:61:80:81:82:83:84:85:86:87 - PXEClient:Arch:00007:UNDI:003016 - no dhcp-client-id Mar 10 08:13:10 drbldbn dhcpd: DHCPREQUEST for 192.168.120.3 (192.168.120.254) from 00:0c:29:68:f3:23 via vmnet1 Mar 10 08:13:10 drbldbn dhcpd: DHCPACK on 192.168.120.3 to 00:0c:29:68:f3:23 via vmnet1 Mar 10 08:13:10 drbldbn atftpd[4821]: Serving bootx64.efi to 192.168.120.3:1540 Mar 10 08:13:10 drbldbn atftpd[4821]: Serving bootx64.efi to 192.168.120.3:1541 Mar 10 08:13:10 drbldbn atftpd[4821]: Serving ldlinux.e64 to 192.168.120.3:1542 Mar 10 08:13:10 drbldbn atftpd[4821]: Serving pxelinux.cfg/564d880a-57b6-3c13-26d5-a2af8968f323 to 192.168.120.3:1543 Mar 10 08:13:10 drbldbn atftpd[4821]: Serving pxelinux.cfg/01-00-0c-29-68-f3-23to 192.168.120.3:1544 Mar 10 08:13:10 drbldbn atftpd[4821]: Serving vesamenu.c32 to 192.168.120.3:1545 Mar 10 08:13:10 drbldbn atftpd[4821]: Serving efi64/vesamenu.c32 to 192.168.120.3:1546 Mar 10 08:13:11 drbldbn atftpd[4821]: Serving libcom32.c32 to 192.168.120.3:1547 Mar 10 08:13:11 drbldbn atftpd[4821]: Serving efi64/libcom32.c32 to 192.168.120.3:1548 Mar 10 08:13:11 drbldbn atftpd[4821]: Serving libutil.c32 to 192.168.120.3:1549 Mar 10 08:13:11 drbldbn atftpd[4821]: Serving efi64/libutil.c32 to 192.168.120.3:1550 Mar 10 08:13:11 drbldbn atftpd[4821]: Serving pxelinux.cfg/01-00-0c-29-68-f3-23 to 192.168.120.3:1551 Mar 10 08:13:11 drbldbn atftpd[4821]: Serving drblwp.png to 192.168.120.3:1552 Mar 10 08:13:14 drbldbn atftpd[4821]: Serving vmlinuz-pxe to 192.168.120.3:1553 Mar 10 08:13:17 drbldbn atftpd[4821]: Serving initrd-pxe.img to 192.168.120.3:1554 Mar 10 08:14:25 drbldbn dhcpd: Client 0:c:29:68:f3:23 requests 1:3:6:c:f:1c:2a - DRBLClient - no dhcp-client-id ================As you can see, with one core this time it took longer to download initrd-pxe.img. For the Lenovo client, any test I could do? Thanks in advance. Steven. -- Steven Shiau <steven _at_ nchc org tw> <steven _at_ stevenshiau org> National Center for High-performance Computing, Taiwan. http://www.nchc.org.tw Public Key Server PGP Key ID: 4096R/47CF935C Fingerprint: 0240 1FEB 695D 7112 62F0 8796 11C1 12DA 47CF 935C
On Sun, Mar 9, 2014 at 8:48 PM, Steven Shiau <steven at nchc.org.tw> wrote:> On 2014/3/10 ?? 05:48, Gene Cumm wrote: >> >> 1) My assumption would be that the VMware virtualized AMD 79C970A >> (PCNet32 driver; vlance virtualDev) lacks proper EFI64 support. >> >> 2) I have 0 speed issues using your VMX. If you only have two real >> cores for this 2vCPU VM, you're choking it as the host needs time to >> run. If you choke it, you mess with timers. If you mess with timers, >> interface polling and a HUGE slew of items (including a guest OS's >> clock) will be slowed to a crawl. >> >> In my experience (both on ESXi and VMware Workstation), gGeneral >> sizing guidelines are that the first core on the first socket and >> 1-2GiB RAM should be considered dedicated to the host and arbitrary >> VMs should not have a vCPU count greater than the number of cores of >> an available socket and the vRAM should not exceed the RAM directly >> available to the NUMA node of the socket. 2 Intel Xeon x54xx >> constitute 1 NUMA node so you can have (1) 4vCPU VM with most of the >> RAM of the entire server. 2 Intel Xeon x55xx constitute 2 NUMA nodes >> so you can up to the vCPU count of the number of available cores in a >> socket and up to the available RAM directly controlled by that socket. >> If we had 2 Intel Xeon E5530 with (6) 8GiB DIMMs, the best we could >> do for a single VM on this otherwise idle host is 4vCPUs and 22-24 GiB >> RAM. >> >> -- -Gene > > Hi Gene, > Thanks for your explanation. Today I did two more tests here. All were done > with Syslinux 6.03-pre6. > First one is for the real machine (Lenovo X230, Intel CPU core i5, NIC is > Intel Corporation 82579LM Gigabit Network Connection (rev 04). > The 2nd one is for VMWare WS 10 with 1 core client. The host machine uses > Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz with hyper-thread on, so 8 coresNo, this is 8 execution contexts (CPU threads) on 4 execution cores. Thanks for trying 1vCPU.> shown in /proc/cpuinfo. > I describe the results in the following: > (1) For the Lenovo X230, I have the issue to EFI network booting. The client > machine stopped at: > ================> Getting cached packet > My IP is 192.168.1.1 > ================> The system log on the server shows: > ================> Mar 10 08:09:32 drbldbn dhcpd: Client 3c:97:e:9b:75:46 requests > 1:2:3:4:5:6:c:d:f:11:12:16:17:1c:28:29:2a:2b:32:33:36:3a:3b:3c:42:43:61:80:81:82:83:84:85:86:87 > - PXEClient:Arch:00007:UNDI:003016 - no dhcp-client-id > Mar 10 08:09:32 drbldbn dhcpd: DHCPREQUEST for 192.168.1.1 (192.168.1.182) > from 3c:97:0e:9b:75:46 via eth1 > Mar 10 08:09:32 drbldbn dhcpd: DHCPACK on 192.168.1.1 to 3c:97:0e:9b:75:46 > via eth1 > Mar 10 08:09:32 drbldbn atftpd[4821]: Serving bootx64.efi to > 192.168.1.1:1549 > Mar 10 08:09:32 drbldbn atftpd[4821]: Serving bootx64.efi to > 192.168.1.1:1550 > Mar 10 08:12:02 drbldbn dhcpd: DHCPREQUEST for 192.168.1.1 from > 3c:97:0e:9b:75:46 via eth1 > Mar 10 08:12:02 drbldbn dhcpd: DHCPACK on 192.168.1.1 to 3c:97:0e:9b:75:46 > via eth1 > ================> As you can tell, the client did not request ldlinux.e64.The best way to verify is a port mirror packet capture.> (2) For the VM with one core, > The system log on the server shows: > ================ > Mar 10 08:13:14 drbldbn atftpd[4821]: Serving vmlinuz-pxe to > 192.168.120.3:1553 > Mar 10 08:13:17 drbldbn atftpd[4821]: Serving initrd-pxe.img to > 192.168.120.3:1554 > Mar 10 08:14:25 drbldbn dhcpd: Client 0:c:29:68:f3:23 requests > 1:3:6:c:f:1c:2a - DRBLClient - no dhcp-client-id > ================> As you can see, with one core this time it took longer to download > initrd-pxe.img.There's no indication how long it takes to fetch the file. The only indication is the time between when the client begins to fetch the initrd and when the booted OS does its DHCP (1m8s if I'm reading correctly while 3s between vmlinuz-pxe and initrd-pxe.img).> For the Lenovo client, any test I could do? > Thanks in advance.On Sat, Mar 8, 2014 at 10:20 PM, Steven Shiau <steven at nchc.org.tw> wrote:> Mar 9 10:36:25 drbldbn atftpd[10590]: Serving vmlinuz-pxe to > 192.168.120.3:1830 > Mar 9 10:36:28 drbldbn atftpd[10590]: Serving initrd-pxe.img to > 192.168.120.3:1831 > Mar 9 10:37:32 drbldbn dhcpd: Client 0:c:29:68:f3:23 requests > 1:3:6:c:f:1c:2a - DRBLClient - no dhcp-client-id3s between vmlinuz-pxe and initrd-pxe.img while 1m4s between initrd-pxe.img and DHCP.> Mar 9 11:04:08 drbldbn atftpd[10590]: Serving vmlinuz-pxe to > 192.168.120.3:49172 > Mar 9 11:04:08 drbldbn atftpd[10590]: Serving initrd-pxe.img to > 192.168.120.3:49173 > Mar 9 11:04:14 drbldbn dhcpd: Client 0:c:29:68:f3:23 requests > 1:3:6:c:f:1c:2a - DRBLClient - no dhcp-client-id<1s between vmlinuz-pxe and initrd-pxe.img while 6s between initrd-pxe.img and DHCP and still the same server. -- -Gene