I succesfully upgraded (by pkgrm and pkgadd) on a host running Solaris 11.4 VirtualBox 5.2.22 to 6.0.0 beta2.
The host has 'sxadm status smap' set to disabled (I didn't try with SMAP enabled but on VirtualBox 5.2.20 and 5.2.22 setting SMAP to disabled is a workaround for a kernel panic when the SMAP or "Supervisor Mode Access Prevention" of Solaris 11.4 prevents VirtualBox to access "disallow supervisor mode execution of text mapped only in userland").
I also installed (upgraded) the extension pack to Oracle_VM_VirtualBox_Extension_Pack-6.0.0_BETA2.vbox-extpack to get the NIC Intel PXE support and support for network boot of virtual machines.
I built a 'minimal-server' virtual machine (solaris guest) from an AI (automated installer) server using PXE network boot and this worked. Unfortunately it seems 6.0.0beta2 is *slower* than 5.2.20 because for a similar guest built with AI I observe in the install_log :
2018-11-02 18:56:19,774 InstallationLogger.generated-transfer-740-1 INFO
Download: Completed 367.11 MB in 125.35 seconds (2.8M/s)
and on a similar guest with 6.0.0beta2 also with a NIC Intel PRO/1000 MT Desktop set to "bridged adapter" in both cases for an 'ethernetstub' I get a slower installation now:
2018-11-19 18:16:13,749 InstallationLogger.generated-transfer-749-1 INFO Download: Completed 367.11 MB in 437.91 seconds (826k/s)
So on November 2, I built with Vbox 5.2.20 a Solaris guest over the (virtual) Intel NIC at 2.8 MB/s and now with Vbox 6.0.0beta2 the same process still works but seems slower at only 826kb/s three times slower.
I think the setups are comparable, maybe the upgrade to 6.0.0beta2 caused a slower network install ?
Finally congratulations to both the Solaris 11.4 team and the VirtualBox team for excellent software (both Solaris 11.4 and VirtualBox, I used VirtualBox 5.2.22 for a while and it felt stable and reliable, I look forward to test 6.0.0beta2 now.
A minor note is that on both Vbox 5.2.22 and 6.0.0 when I build Solaris guests (also running 11.4) they report (in both cases)
Impact : Oracle Solaris is not running with Spectre Vulnerability Mitigation Enabled
However this firmware related warning/error is not hindering me, the network issue described above is important but the fw. issue is less of an issue to me, although it would also be nice to get rid of it.
root@saturn:~# fmadm list
--------------- ------------------------------------ -------------- ---------
TIME EVENT-ID MSG-ID SEVERITY
--------------- ------------------------------------ -------------- ---------
Nov 19 19:22:17 e1be5a09-c12a-4877-9d65-d72b08c85ea5 SUNOS-8000-LG Major
Problem Status : open
Diag Engine : software-diagnosis / 0.2
System
Manufacturer : unknown
Name : unknown
Part_Number : unknown
Serial_Number : unknown
System Component
Manufacturer : innotek GmbH
Name : VirtualBox
Part_Number :
Serial_Number : 0
Firmware_Manufacturer : innotek GmbH
Firmware_Version : (BIOS)VirtualBox
Firmware_Release : (BIOS)12.01.2006
Host_ID : 00c862ce
Server_Name : saturn
----------------------------------------
Suspect 1 of 1 :
Problem class : alert.oracle.solaris.cpu.firmware.security
Certainty : 100%
FRU
Status : Active
Location : "/SYS/MB"
Manufacturer : unknown
Name : unknown
Part_Number : unknown
Revision : unknown
Serial_Number : unknown
Chassis
Manufacturer : Oracle Corporation
Name : VirtualBox
Part_Number :
Serial_Number : 0
Resource
Status : Active
Response : No automated response available
Impact : Oracle Solaris is not running with Spectre Vulnerability
Mitigation Enabled
Action : Update the CPU with Spectre capable microcode.
VirtualBox 6.0.0 beta2 on Solaris 11.4
Re: VirtualBox 6.0.0 beta2 on Solaris 11.4
I downgraded from 6.0.0.beta2 to 5.2.22 and obtained under 5.2.22 similar network speed as under 6.0.0.beta2.
Then I further downgraded back to 5.2.20 and have - in the same setting, with the same guest definition in fact - better network performance using the "bridged adapter" on top of the "etherstub".
I have now - after downgrading to 5.2.20 - when I build a Solaris guest in virtualbox using network install over an "etherstub" virtual switch :
root@saturn:~# grep 'Download: Completed' /var/log/install/install_log
2018-11-19 20:50:25,768 InstallationLogger.generated-transfer-738-1 INFO Download: Completed 367.11 MB in 128.91 seconds (2.7M/s)
So the performance of VirtualBox 5.2.20 seems 3 times better over Solaris virtual switch "etherstub" compared to 5.2.22 and 6.0.0.beta2.
Then I further downgraded back to 5.2.20 and have - in the same setting, with the same guest definition in fact - better network performance using the "bridged adapter" on top of the "etherstub".
I have now - after downgrading to 5.2.20 - when I build a Solaris guest in virtualbox using network install over an "etherstub" virtual switch :
root@saturn:~# grep 'Download: Completed' /var/log/install/install_log
2018-11-19 20:50:25,768 InstallationLogger.generated-transfer-738-1 INFO Download: Completed 367.11 MB in 128.91 seconds (2.7M/s)
So the performance of VirtualBox 5.2.20 seems 3 times better over Solaris virtual switch "etherstub" compared to 5.2.22 and 6.0.0.beta2.
Re: VirtualBox 6.0.0 beta2 on Solaris 11.4
6.0.0beta2 feels very usable but as indicated a bit slower than 5.2.20 with Solaris 11.4 guest VMs:
a SCP (secure copy) test of some zip files with VirtualBox 5.2..20 between a vm and the virtualbox host:
sol-11_4-repo_1of5.zip 100% 1877MB 49.6MB/s 00:37
sol-11_4-repo_2of5.zip 100% 1731MB 37.5MB/s 00:46
sol-11_4-repo_3of5.zip 100% 1690MB 37.2MB/s 00:45
sol-11_4-repo_4of5.zip 100% 2034MB 37.8MB/s 00:53
sol-11_4-repo_5of5.zip 100% 1850MB 38.6MB/s 00:47
the same scp between the same vm and the same virtualbox (same network) with 6.0.0 is slower:
sol-11_4-repo_1of5.zip 100% 1877MB 32.5MB/s 00:57
sol-11_4-repo_2of5.zip 100% 1731MB 28.8MB/s 01:00
sol-11_4-repo_3of5.zip 100% 1690MB 28.4MB/s 00:59
sol-11_4-repo_4of5.zip 100% 2034MB 29.3MB/s 01:09
sol-11_4-repo_5of5.zip 100% 1850MB 27.1MB/s 01:08
So this is 10MB/s slower in 6.0.0 compared to 5.2.20.
However this is perhaps not a network issue as the SCP also involves disk writes (to save the file) and the Automated Installer installation over the network (PXE install) also involves disk writes.
I tested with a target disk SATA but also with a virtual SCSI target, that doesn't seem to make a difference.
When I disable MP (multiprocessing) on Solaris using set use_mp=0 in the /etc/system that makes the VirtualBox 5.2.20 slower and makes it run at about the same speed as the guest under VirtualBox 6.0.0.
In any case, the VirtualBox 6.0.0 still feels very usable, it's nice work of the VirtualBox team to have the Solaris 11.4 OS/operating system well supported ...
Regards,
David
a SCP (secure copy) test of some zip files with VirtualBox 5.2..20 between a vm and the virtualbox host:
sol-11_4-repo_1of5.zip 100% 1877MB 49.6MB/s 00:37
sol-11_4-repo_2of5.zip 100% 1731MB 37.5MB/s 00:46
sol-11_4-repo_3of5.zip 100% 1690MB 37.2MB/s 00:45
sol-11_4-repo_4of5.zip 100% 2034MB 37.8MB/s 00:53
sol-11_4-repo_5of5.zip 100% 1850MB 38.6MB/s 00:47
the same scp between the same vm and the same virtualbox (same network) with 6.0.0 is slower:
sol-11_4-repo_1of5.zip 100% 1877MB 32.5MB/s 00:57
sol-11_4-repo_2of5.zip 100% 1731MB 28.8MB/s 01:00
sol-11_4-repo_3of5.zip 100% 1690MB 28.4MB/s 00:59
sol-11_4-repo_4of5.zip 100% 2034MB 29.3MB/s 01:09
sol-11_4-repo_5of5.zip 100% 1850MB 27.1MB/s 01:08
So this is 10MB/s slower in 6.0.0 compared to 5.2.20.
However this is perhaps not a network issue as the SCP also involves disk writes (to save the file) and the Automated Installer installation over the network (PXE install) also involves disk writes.
I tested with a target disk SATA but also with a virtual SCSI target, that doesn't seem to make a difference.
When I disable MP (multiprocessing) on Solaris using set use_mp=0 in the /etc/system that makes the VirtualBox 5.2.20 slower and makes it run at about the same speed as the guest under VirtualBox 6.0.0.
In any case, the VirtualBox 6.0.0 still feels very usable, it's nice work of the VirtualBox team to have the Solaris 11.4 OS/operating system well supported ...
Regards,
David
Re: VirtualBox 6.0.0 beta2 on Solaris 11.4
Using a target disk of type "SAS controller" for a Solaris 11.4 guest results in better performance (for the AI install) compared to IDE, SATA (default) or SCSI.
Using VirtualBox 6.0.0 and selecting SAS controller for the guest that I create, the install works at a speed comparable with the Virtualbox 5.2.20 / SATA speed :
grep 'Download: Completed' /var/log/install/install_log
2018-11-20 20:28:46,922 InstallationLogger.generated-transfer-737-1 INFO Download: Completed 367.11 MB in 129.90 seconds (2.7M/s)
The reason why I also tested setting MP (multiprocessing) to 0 (disabled) is because there is a bulletin on the Oracle site #6586621 which in fact advises not to use the old IDE device driver and points to some 'network' implications.
Anyway, there seem to be slight differences between 5.2.20 and 6.0.0/5.2.22 but not to the extent that it is a problem, because it is easy to just select SAS as the target disk controller and then I have the same performance again as I used to have with 5.2.20 and SATA.
Using VirtualBox 6.0.0 and selecting SAS controller for the guest that I create, the install works at a speed comparable with the Virtualbox 5.2.20 / SATA speed :
grep 'Download: Completed' /var/log/install/install_log
2018-11-20 20:28:46,922 InstallationLogger.generated-transfer-737-1 INFO Download: Completed 367.11 MB in 129.90 seconds (2.7M/s)
The reason why I also tested setting MP (multiprocessing) to 0 (disabled) is because there is a bulletin on the Oracle site #6586621 which in fact advises not to use the old IDE device driver and points to some 'network' implications.
Anyway, there seem to be slight differences between 5.2.20 and 6.0.0/5.2.22 but not to the extent that it is a problem, because it is easy to just select SAS as the target disk controller and then I have the same performance again as I used to have with 5.2.20 and SATA.
-
olaris2006
- Posts: 7
- Joined: 21. Nov 2018, 16:50
Re: VirtualBox 6.0.0 beta2 on Solaris 11.4
The kernel complains about vulnerabilities because it cannot load the CPU microcode in VirtualBox. This is normal and rather logical.stes wrote: A minor note is that on both Vbox 5.2.22 and 6.0.0 when I build Solaris guests (also running 11.4) they report (in both cases)
Impact : Oracle Solaris is not running with Spectre Vulnerability Mitigation Enabled
However this firmware related warning/error is not hindering me, the network issue described above is important but the fw. issue is less of an issue to me, although it would also be nice to get rid of it.
root@saturn:~# fmadm list
--------------- ------------------------------------ -------------- ---------
TIME EVENT-ID MSG-ID SEVERITY
--------------- ------------------------------------ -------------- ---------
Nov 19 19:22:17 e1be5a09-c12a-4877-9d65-d72b08c85ea5 SUNOS-8000-LG Major
Problem Status : open
Diag Engine : software-diagnosis / 0.2
System
Manufacturer : unknown
Name : unknown
Part_Number : unknown
Serial_Number : unknown
System Component
Manufacturer : innotek GmbH
Name : VirtualBox
Part_Number :
Serial_Number : 0
Firmware_Manufacturer : innotek GmbH
Firmware_Version : (BIOS)VirtualBox
Firmware_Release : (BIOS)12.01.2006
Host_ID : 00c862ce
Server_Name : saturn
----------------------------------------
Suspect 1 of 1 :
Problem class : alert.oracle.solaris.cpu.firmware.security
Certainty : 100%
FRU
Status : Active
Location : "/SYS/MB"
Manufacturer : unknown
Name : unknown
Part_Number : unknown
Revision : unknown
Serial_Number : unknown
Chassis
Manufacturer : Oracle Corporation
Name : VirtualBox
Part_Number :
Serial_Number : 0
Resource
Status : Active
Response : No automated response available
Impact : Oracle Solaris is not running with Spectre Vulnerability
Mitigation Enabled
Action : Update the CPU with Spectre capable microcode.
If you want to get rid of these harmless warnings during the boot you should uninstall these packages in your Solaris guests:
pkg uninstall microcode/amd microcode/intel
P.S. Many thanks for sharing your experience with Solaris 11.4!
P.P.S I'm not an Oracle employee.
Re: VirtualBox 6.0.0 beta2 on Solaris 11.4
Thank you, indeed after uninstalling the packages, the "cannot upgrade microcode on cpu0" error is gone during booting and the "Spectre" mitigation error is not raised any longer.
This required a reboot because a new BE (Boot Environment) is created : perhaps I can avoid this by excluding the microcode packages during the initial install (exclude the microcode packages in the AI manifest for the Vbox guests)
root@saturn:~# pkg list /system/microcode/*
NAME (PUBLISHER) VERSION IFO
system/microcode/amd 11.4-11.4.0.0.1.15.0 i--
system/microcode/intel 11.4-11.4.0.0.1.15.0 i--
after removal :
A clone of solaris exists and has been updated and activated.
On the next boot the Boot Environment be://rpool/solaris-1 will be
mounted on '/'. Reboot when ready to switch to this updated BE.
root@saturn:~# beadm list
BE Name Flags Mountpoint Space Policy Created
--------- ----- ---------- ------ ------ ----------------
solaris N / 51.35M static 2018-11-21 14:03
solaris-1 R - 1.56G static 2018-11-21 19:02
This required a reboot because a new BE (Boot Environment) is created : perhaps I can avoid this by excluding the microcode packages during the initial install (exclude the microcode packages in the AI manifest for the Vbox guests)
root@saturn:~# pkg list /system/microcode/*
NAME (PUBLISHER) VERSION IFO
system/microcode/amd 11.4-11.4.0.0.1.15.0 i--
system/microcode/intel 11.4-11.4.0.0.1.15.0 i--
after removal :
A clone of solaris exists and has been updated and activated.
On the next boot the Boot Environment be://rpool/solaris-1 will be
mounted on '/'. Reboot when ready to switch to this updated BE.
root@saturn:~# beadm list
BE Name Flags Mountpoint Space Policy Created
--------- ----- ---------- ------ ------ ----------------
solaris N / 51.35M static 2018-11-21 14:03
solaris-1 R - 1.56G static 2018-11-21 19:02
Re: VirtualBox 6.0.0 beta2 on Solaris 11.4
Actually even after removing the microcode packages, the "Spectre Vulnerability Mitigation" is still raised !
When I modify the AI manifest to
<software_data action="avoid">
<name>pkg:/system/microcode/amd</name>
<name>pkg:/system/microcode/intel</name>
</software_data>
the microcode packages are not installed during the Solaris installation but *still* the fmadm error is raised.
Not installing the microcode packages solves however a message during the boot of the virtualbox guest of not being able to update the microcode of the (virtual) CPU, so thanks for the suggestion.
The warning about the Spectre mitigation is raised I think by the "software-diagnosis" plugin of
/usr/lib/fm/fmd/plugins/software-diagnosis.conf pkg:/system/fault-management@11.4-11.4.0.0.1.15.0
As a workaround for getting rid of the fmadm "Major" error (which is in fact a harmless warning), I modified the configuration file for the "software-diagnosis" plugin to not load during boot.
/usr/lib/fm/fmd/plugins/software-diagnosis.conf
If I set that to not load (disable) the plugin then the FMD does not warn me any longer.
When I modify the AI manifest to
<software_data action="avoid">
<name>pkg:/system/microcode/amd</name>
<name>pkg:/system/microcode/intel</name>
</software_data>
the microcode packages are not installed during the Solaris installation but *still* the fmadm error is raised.
Not installing the microcode packages solves however a message during the boot of the virtualbox guest of not being able to update the microcode of the (virtual) CPU, so thanks for the suggestion.
The warning about the Spectre mitigation is raised I think by the "software-diagnosis" plugin of
/usr/lib/fm/fmd/plugins/software-diagnosis.conf pkg:/system/fault-management@11.4-11.4.0.0.1.15.0
As a workaround for getting rid of the fmadm "Major" error (which is in fact a harmless warning), I modified the configuration file for the "software-diagnosis" plugin to not load during boot.
/usr/lib/fm/fmd/plugins/software-diagnosis.conf
If I set that to not load (disable) the plugin then the FMD does not warn me any longer.