Here's the relevant lines from the scheduler log, vmx is there, and its present in /proc/cpuinfo as well.
2015-10-16 12:12:34.6279 [PID=66 ] [send] CPU features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl *vmx* smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms 2015-10-16 12:12:34.6596 [PID=66 ] [send] Sending app_version camb_boinc2docker 4 5 vbox64_mt; projected 14.64 GFLOPS Reading eg here <http://www.howtogeek.com/howto/linux/linux-tip-how-to-tell-if-your-processor-supports-vt/> or here <http://askubuntu.com/questions/103965/how-to-determine-if-cpu-vt-extensions-enabled-in-bios> it seems vmx appearing there just means your CPU supports it, not that it is actually enabled. Clearly in my case its disabled yet still shows up. So I suppose the questions are now, 1) is there a way BOINC can check if vmx is actually enabled? 2) whats going on with vboxwrapper Marius On Fri, Oct 16, 2015 at 2:01 PM, Christian Beer <[email protected]> wrote: > Did you restart the server processes just to make sure? The scheduler > should use the new plan_class.xml config instantly and not send you any > work. This seems to be a separate problem. > > So in theory the server shouldn't send you any task but it is. And the > vboxwrapper should recognize the error code but it isn't. Very strange. > > Next thing to check would be the scheduler_request and reply from the > client and the scheduler log on the server the interesting part there is > the cpu capabilities. This is where the BIOS setting is reported. There > should be no vmx or svm capability reported by your computer (as you > have HW accell turned off). > > Regards > Christian > > On 10/16/2015 01:47 PM, Marius Millea wrote: > > Thanks Christian, I added that option but same result. > > > > Its clear to me now that vboxwrapper is missing the fact that the VM > > doesn't start correctly. If you look at the attached stderr.txt, if > > says "Successfully started VM." Hence it never makes it to the part in > > the code that checks vbox.log for "VERR_VMX_MSR_VMXON_DISABLED" and > > hence never prints "ERR_CPU_VM_EXTENSIONS_DISABLED". > > > > I'm looking into why, any ideas? Otherwise yea it looks like the code > > to do exactly what you guys describe is there. > > > > Marius > > > > > > On Fri, Oct 16, 2015 at 11:42 AM, Christian Beer > > <[email protected] <mailto:[email protected]>> wrote: > > > > On 10/16/2015 11:16 AM, Marius Millea wrote: > > > However I'm using VBox > > > 4.3.30 and vboxwrapper 26175 so I don't think that's it. I'm > > attaching my > > > vbox.log, there's some errors in there about VT-x but searching > > > for ERR_CPU_VM_EXTENSIONS_DISABLED yields nothing. > > The vbox.log contains VERR_VMX_MSR_VMXON_DISABLED at the end. Which > is > > the VirtualBox errorcode to say you have a 64bit Guest but Hardware > > Virtualization is not enabled (it says so in the begining of the log > > too). This gets picked up by vboxwrapper and > > ERR_CPU_VM_EXTENSIONS_DISABLED gets output to stderr.txt in the slot > > directory which gets reported back to the server as part of the > > sched_request file. The stderr.txt shoud be visible as part of the > > failed task once it is reported. > > > > You should change the plan_class vbox64 to include the > > <vm_accel_required/> tag. This is the plan_class I use at RNA World: > > > <plan_class> > > > <name>vbox64</name> > > > <virtualbox/> > > > <is64bit/> > > > <min_core_client_version>70224</min_core_client_version> > > > <min_vbox_version>40010</min_vbox_version> > > > <vm_accel_required/> > > > </plan_class> > > This will not send a 64bit VM to a host that has no Hardware > > Virtualization enabled. This should really be the default as > > VirtualBox > > doesn't allow a 64bit guest without the HW Virtualization enabled. > > > > Regards > > Christian > > _______________________________________________ > > boinc_dev mailing list > > [email protected] <mailto:[email protected]> > > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > > To unsubscribe, visit the above URL and > > (near bottom of page) enter your email address. > > > > > > _______________________________________________ > boinc_dev mailing list > [email protected] > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. > _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
