Re: [boinc_dev] vbox64 and virtualization

[Marius Millea]

Thanks for the explanation Rom, thats helpful. 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.

Marius


On Fri, Oct 16, 2015 at 1:55 AM, Rom Walton <r...@romwnet.org> wrote:

> What is supposed to happen is:
>
> When the VM shuts down, vboxwrapper parses the end of vbox.log looking for
> the possible error codes related to the VM extensions being disabled.  If
> found, it then writes the following to stderr
> 'ERR_CPU_VM_EXTENSIONS_DISABLED'.
>
> BOINC parses the stderr text when the app exits, if it detects the above
> text it sets a flag that says the VM extensions have been disabled on the
> machine.  In the sched_request file it is named .
>
> I recently updated vboxwrapper to support the newer error codes returned
> in VirtualBox 5.0:
>
> https://github.com/BOINC/boinc/commit/0ee90d7995118ff5fd00c68af734050172f7733a
>
> That commit should be in 26173 or above.
>
> - Rom
>
> List of VirtualBox error codes is in vbox_common.cpp:320-338
>
> What is written to stderr is in vboxwrapper.cpp:774-784
>
> -Original Message-
> From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of
> Marius Millea
> Sent: Thursday, October 15, 2015 7:31 PM
> To: BOINC-dev email list <boinc_dev@ssl.berkeley.edu>
> Subject: [boinc_dev] vbox64 and virtualization
>
> Hi all,
>
> Virtualbox can't run a 64bit guest OS unless you have virtualization (VT-x
> or AMD-v or whatever it might be called...) enabled in your BIOS. Hence no
> app which is plan class vbox64 should be sent to a host which does not have
> this enabled. Unfortunately I'm not seeing either happen. First, I turned
> off VT-x on my machine, rebooted and readded the project, and I'm still
> receiving vbox64 jobs. Should this be happening or is this a feature which
> does not exist yet?
>
> Secondly, it seems like vboxwrapper ought to catch this and shut down with
> some informative error message. From the source it looks like it does have
> some code which attempts to catch this, but at least on my system it
> doesn't seem to work. It gets stuck saying "Status Report:
> virtualbox/vboxheadless is no longer running." for a while, then gives me
> "Waiting to run (VM Hypervisor failed to enter an online state in a timely
> fashion)". Any ideas what's going on?
>
> Thanks,
>
> Marius
> ___
> boinc_dev mailing list
> boinc_dev@ssl.berkeley.edu
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
>
VirtualBox VM 4.3.30 r101610 linux.amd64 (Jul 10 2015 12:58:13) release log
00:00:00.034078 Log opened 2015-10-15T23:11:01.126818000Z
00:00:00.034079 Build Type: release
00:00:00.034081 OS Product: Linux
00:00:00.034082 OS Release: 3.13.0-65-generic
00:00:00.034083 OS Version: #106-Ubuntu SMP Fri Oct 2 22:08:27 UTC 2015
00:00:00.034103 DMI Product Name: 2342CTO
00:00:00.034109 DMI Product Version: ThinkPad T430
00:00:00.034169 Host RAM: 7686MB total, 5244MB available
00:00:00.034172 Executable: /usr/lib/virtualbox/VBoxHeadless
00:00:00.034172 Process ID: 12436
00:00:00.034173 Package type: LINUX_64BITS_UBUNTU_13_04
00:00:00.044921 Installed Extension Packs:
00:00:00.048370   Oracle VM VirtualBox Extension Pack (Version: 4.3.30 r101610; VRDE Module: VBoxVRDP)
00:00:00.051999 SUP: Loaded VMMR0.r0 (/usr/lib/virtualbox/VMMR0.r0) at 0xa07cd020 - ModuleInit at a07eb570 and ModuleTerm at a07eb800
00:00:00.052021 SUP: VMMR0EntryEx located at a07ecbe0, VMMR0EntryFast at a07ec820 and VMMR0EntryInt at a07ec810
00:00:00.053001 Guest OS type: 'Linux26_64'
00:00:00.055456 WARNING! 64-bit guest type selected but the host CPU does NOT support HW virtualization.
00:00:00.055536 fHMForced=true - SMP
00:00:00.059975 File system of '/var/lib/boinc-client/slots/1/vm_isocontext.iso' (DVD) is ext4
00:00:00.061477 File system of '/usr/share/virtualbox/VBoxGuestAdditions.iso' (DVD) is ext4
00:00:00.068500 Shared clipboard mode: Off
00:00:00.068946 Drag'n'drop mode: Off
00:00:00.071025 * CFGM dump *
00:00:00.071028 [/] (level 0)
00:00:00.071035   CSAMEnabled= 0x0001 (1)
00:00:00.071040   CpuExecutionCap= 0x0064 (100)
00:00:00.071041   EnablePAE  = 0x0001 (1)
00:00:00.071042   HMEnabled  = 0x0001 (1)
00:00:00.071042   MemBalloonSize = 0x (0)
00:00:00.071043   Name= "boinc_08cf100ffb36acff" (cb=23)
00:00:00.071044   NumCPUs= 0x000

Re: [boinc_dev] vbox64 and virtualization

[Christian Beer]

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
 tag. This is the plan_class I use at RNA World:
> 
> vbox64
> 
> 
> 70224
> 40010
> 
> 
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
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] vbox64 and virtualization

[Marius Millea]

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 
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
>  tag. This is the plan_class I use at RNA World:
> > 
> > vbox64
> > 
> > 
> > 70224
> > 40010
> > 
> > 
> 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
> boinc_dev@ssl.berkeley.edu
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
>
2015-10-16 12:59:25 (31557): vboxwrapper (7.7.26175): starting
2015-10-16 12:59:25 (31557): Feature: Checkpoint interval offset (239 seconds)
2015-10-16 12:59:25 (31557): Detected: VirtualBox VboxManage Interface 
(Version: 4.3.30)
2015-10-16 12:59:25 (31557): Detected: Minimum checkpoint interval (600.00 
seconds)
2015-10-16 12:59:25 (31557): Create VM. (boinc_6053e2c6604d57b1, slot#0)
2015-10-16 12:59:25 (31557): Updating drive controller type and model for 
desired configuration.
2015-10-16 12:59:26 (31557): Setting Memory Size for VM. (2048MB)
2015-10-16 12:59:26 (31557): Setting CPU Count for VM. (4)
2015-10-16 12:59:26 (31557): Setting Chipset Options for VM.
2015-10-16 12:59:26 (31557): Setting Boot Options for VM.
2015-10-16 12:59:26 (31557): Setting Network Configuration for NAT.
2015-10-16 12:59:26 (31557): Enabling VM Network Access.
2015-10-16 12:59:26 (31557): Disabling USB Support for VM.
2015-10-16 12:59:26 (31557): Disabling COM Port Support for VM.
2015-10-16 12:59:26 (31557): Disabling LPT Port Support for VM.
2015-10-16 12:59:26 (31557): Disabling Audio Support for VM.
2015-10-16 12:59:26 (31557): Disabling Clipboard Support for VM.
2015-10-16 12:59:26 (31557): Disabling Drag and Drop Support for VM.
2015-10-16 12:59:27 (31557): Adding storage controller(s) to VM.
2015-10-16 12:59:27 (31557): Adding virtual ISO 9660 disk drive to VM. 
(vm_isocontext.iso)
2015-10-16 12:59:27 (31557): Adding VirtualBox Guest Additions to VM.
2015-10-16 12:59:27 (31557): Adding network bandwidth throttle group to VM. 
(Defaulting to 1024GB)
2015-10-16 12:59:27 (31557): Enabling shared directory for VM.
2015-10-16 12:59:27 (31557): Enabling scratch shared directory for VM.
2015-10-16 12:59:27 (31557): Starting VM. (boinc_6053e2c6604d57b1, slot#0)
2015-10-16 12:59:29 (31557): Successfully started VM. (PID = '31929')
2015-10-16 12:59:29 (31557): Reporting VM Process ID to BOINC.
2015-10-16 12:59:29 (31557): Status Report: virtualbox/vboxheadless is no 
longer running.
2015-10-16 12:59:30 (31557): Status Report: virtualbox/vboxheadless is no 
longer running.
2015-10-16 12:59:31 (31557): Status Report: virtualbox/vboxheadless is no 
longer running.
2015-10-16 12:59:32 (31557): Status Report: virtualbox/vboxheadless is no 
longer running.
2015-10-16 12:59:33 (31557): Status Report: virtualbox/vboxheadless is no 
longer running.
2015-10-16 12:59:34 (31557): Status Report: virtualbox/vboxheadless is no 
longer running.
2015-10-16 12:59:35 (31557): Status Report: virtualbox/vboxheadless is no 
longer running.
2015-10-16 12:59:36 (31557): Status Report: virtualbox/vboxheadless is no 
longer running.
2015-10-16 12:59:37 (31557): Status Report: virtualbox/vboxheadless is no 
longer running.
2015-10-16 12:59:38 (31557): Status Report: virtualbox/vboxheadless is no 
longer running.
2015-10-16 12:59:39 (31557): Status Report: virtualbox/vboxheadless is no 
longer running.

Re: [boinc_dev] vbox64 and virtualization

[Marius Millea]

On Fri, Oct 16, 2015 at 2:23 PM, Marius Millea  wrote:

> 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
> 
> or here
> 
>  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?
>

There's two things I could find (keeping in mind this whole discussion is
Linux, someone should check how it plays out on Win/Mac).

* "dmesg | grep kvm" will show the line "kvm: disabled by bios" if
VT-x/AMD-v is disabled
* "sudo kvm-ok" will tell you also, but this requires sudo and installing a
package, so likely not an option.

Its beyond me to incorporate usage of this into the BOINC client, but I'll
leave it here as reference. I think it'd be something good to have.





> 2) whats going on with vboxwrapper
>
> Marius
>
>
>
> On Fri, Oct 16, 2015 at 2:01 PM, Christian Beer  > 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
>> > > 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
>> >  tag. This is the plan_class I use at RNA World:
>> > > 
>> > > vbox64
>> > > 
>> > > 
>> > > 70224
>> > > 40010
>> > > 
>> > > 
>> > 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
>> >   

Re: [boinc_dev] vbox64 and virtualization

[Christian Beer]

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
> > 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
>  tag. This is the plan_class I use at RNA World:
> > 
> > vbox64
> > 
> > 
> > 70224
> > 40010
> > 
> > 
> 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
> boinc_dev@ssl.berkeley.edu 
> 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
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] vbox64 and virtualization

[Marius Millea]

On Fri, Oct 16, 2015 at 2:23 PM, Marius Millea  wrote:

> 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
> 
> or here
> 
>  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
>
>
Yea, can confirm "VBoxManage startvm" returns successfully on my system
even though the VM immediately dies with the VERR_VMX_MSR_VMXON_DISABLED
error. That's why vboxwrapper never catches it. Not sure if this is a VBox
bug and/or if its limited to my system.






> Marius
>
>
>
> On Fri, Oct 16, 2015 at 2:01 PM, Christian Beer  > 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
>> > > 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
>> >  tag. This is the plan_class I use at RNA World:
>> > > 
>> > > vbox64
>> > > 
>> > > 
>> > > 70224
>> > > 40010
>> > > 
>> > > 
>> > 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
>> > boinc_dev@ssl.berkeley.edu 
>> > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
>> > To unsubscribe, visit the above URL and
>> > (near bottom of page) enter 

Re: [boinc_dev] vbox64 and virtualization

[Rom Walton]

> Yea, can confirm "VBoxManage startvm" returns successfully on my system even 
> though the VM immediately
> dies with the VERR_VMX_MSR_VMXON_DISABLED error. That's why vboxwrapper never 
> catches it. Not sure if
> this is a VBox bug and/or if its limited to my system.

Well, it is a bug in vboxwrapper.  It may or may not be a change in behavior 
for VirtualBox.

Ideally, BOINC relies on vboxwrapper to tell it whether the host machine is 
properly configured to support running VirtualBox Virtual Machines.  
Vboxwrapper relies on VirtualBox.

This was working at one time.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Marius 
Millea
Sent: Friday, October 16, 2015 9:12 AM
To: Christian Beer <christian.b...@aei.mpg.de>
Cc: BOINC-dev email list <boinc_dev@ssl.berkeley.edu>
Subject: Re: [boinc_dev] vbox64 and virtualization

On Fri, Oct 16, 2015 at 2:23 PM, Marius Millea <mmil...@ucdavis.edu> wrote:

> 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-pr
> ocessor-supports-vt/>
> or here
> <http://askubuntu.com/questions/103965/how-to-determine-if-cpu-vt-exte
> nsions-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
>
>
Yea, can confirm "VBoxManage startvm" returns successfully on my system even 
though the VM immediately dies with the VERR_VMX_MSR_VMXON_DISABLED error. 
That's why vboxwrapper never catches it. Not sure if this is a VBox bug and/or 
if its limited to my system.






> Marius
>
>
>
> On Fri, Oct 16, 2015 at 2:01 PM, Christian Beer 
> <christian.b...@aei.mpg.de
> > 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 
>> > <christian.b...@aei.mpg.de <mailto:christian.b...@aei.mpg.de>> 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
>> >  

Re: [boinc_dev] vbox64 and virtualization

[Rom Walton]

What is supposed to happen is:

When the VM shuts down, vboxwrapper parses the end of vbox.log looking for the 
possible error codes related to the VM extensions being disabled.  If found, it 
then writes the following to stderr 'ERR_CPU_VM_EXTENSIONS_DISABLED'.

BOINC parses the stderr text when the app exits, if it detects the above text 
it sets a flag that says the VM extensions have been disabled on the machine.  
In the sched_request file it is named .

I recently updated vboxwrapper to support the newer error codes returned in 
VirtualBox 5.0:
https://github.com/BOINC/boinc/commit/0ee90d7995118ff5fd00c68af734050172f7733a

That commit should be in 26173 or above.

- Rom

List of VirtualBox error codes is in vbox_common.cpp:320-338

What is written to stderr is in vboxwrapper.cpp:774-784

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Marius 
Millea
Sent: Thursday, October 15, 2015 7:31 PM
To: BOINC-dev email list <boinc_dev@ssl.berkeley.edu>
Subject: [boinc_dev] vbox64 and virtualization

Hi all,

Virtualbox can't run a 64bit guest OS unless you have virtualization (VT-x or 
AMD-v or whatever it might be called...) enabled in your BIOS. Hence no app 
which is plan class vbox64 should be sent to a host which does not have this 
enabled. Unfortunately I'm not seeing either happen. First, I turned off VT-x 
on my machine, rebooted and readded the project, and I'm still receiving vbox64 
jobs. Should this be happening or is this a feature which does not exist yet?

Secondly, it seems like vboxwrapper ought to catch this and shut down with some 
informative error message. From the source it looks like it does have some code 
which attempts to catch this, but at least on my system it doesn't seem to 
work. It gets stuck saying "Status Report:
virtualbox/vboxheadless is no longer running." for a while, then gives me 
"Waiting to run (VM Hypervisor failed to enter an online state in a timely 
fashion)". Any ideas what's going on?

Thanks,

Marius
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
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
boinc_dev@ssl.berkeley.edu
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] vbox64 and virtualization

[Marius Millea]

Hi all,

Virtualbox can't run a 64bit guest OS unless you have virtualization (VT-x
or AMD-v or whatever it might be called...) enabled in your BIOS. Hence no
app which is plan class vbox64 should be sent to a host which does not have
this enabled. Unfortunately I'm not seeing either happen. First, I turned
off VT-x on my machine, rebooted and readded the project, and I'm still
receiving vbox64 jobs. Should this be happening or is this a feature which
does not exist yet?

Secondly, it seems like vboxwrapper ought to catch this and shut down with
some informative error message. From the source it looks like it does have
some code which attempts to catch this, but at least on my system it
doesn't seem to work. It gets stuck saying "Status Report:
virtualbox/vboxheadless is no longer running." for a while, then gives me
"Waiting to run (VM Hypervisor failed to enter an online state in a timely
fashion)". Any ideas what's going on?

Thanks,

Marius
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.