Dear Gérard | VMSGenerations,

Thank you very much for your considered and detailed response.

VSI, need to curry up the gonadic gumption, and vertebral valour, and re-address the bare metal question, advancing it forward, tout de suite.

Perhaps the VMSGenerations group could amongst its members, identify two
rock solid, industry standard, server blades, one Intel, and one AMD,
though in the former case, not using the latest generation of CPUs -
from what I gather they are a bit dodgy.

As for Hypervisor/VMS, perhaps, this is an interesting option, to make
it a little more palatable to the VMS ecosystem:

https://blackberry.qnx.com/en/ultimate-guides/embedded-hypervisor
Best regards,

On 22/11/2024 2:24 am, VMSgenerations wrote:

Le 12/11/2024 à 23:59, Subcommandante XDelta a écrit :

Just some blue sky kite flying, perhaps not grounded on the current
revision levels of VSI reality - to be honest, I don't diligently keep
up with the technicalities.

But wouldn't be lovely if we had laptops that were running bare metal
VMS? - the likes of which we haven't seen since the Alpha Tadpole
(IIRC).

:

Dear Subcommandante Xdelta,

We really appreciate your interest in our work in general, and we're
glad you're asking us for advice.

The question you are asking is particularly interesting. It overlaps
with the concerns of our group but not in exactly the same terms.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <vhti7a$1sg3t$1@dont-email.me>, vlf@star.enet.dec.com (Subcommandante XDelta) wrote:

Perhaps the VMSGenerations group could amongst its members,
identify two rock solid, industry standard, server blades,
one Intel, and one AMD, though in the former case, not using
the latest generation of CPUs - from what I gather they are
a bit dodgy.

Blades are not as big a thing as they used to be, and supporting just two blades locks bare-metal VMS into that blade manufacturer's offerings.
When you have a niche OS, you don't want to give customers' finance
people an extra reason to dislike it.

As for Hypervisor/VMS, perhaps, this is an interesting option, to
make it a little more palatable to the VMS ecosystem:

https://blackberry.qnx.com/en/ultimate-guides/embedded-hypervisor

Demanding a hypervisor that isn't well-established in business IT is
another thing for customers' management to dislike.

The VSI plan is to run on the well-established hypervisors, and confine
the unfamiliar aspects of VMS to individual virtual machines. Sadly,
Broadcom's greed after taking over VMware is making that harder.

John

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/25/2024 7:34 AM, John Dallman wrote:

In article <vhti7a$1sg3t$1@dont-email.me>, vlf@star.enet.dec.com (Subcommandante XDelta) wrote:

As for Hypervisor/VMS, perhaps, this is an interesting option, to
make it a little more palatable to the VMS ecosystem:

https://blackberry.qnx.com/en/ultimate-guides/embedded-hypervisor

Demanding a hypervisor that isn't well-established in business IT is
another thing for customers' management to dislike.

The VSI plan is to run on the well-established hypervisors, and confine
the unfamiliar aspects of VMS to individual virtual machines.

That is the business requirement.

VMS must run on what the customers use.

Sadly, Broadcom's greed after taking over VMware is making that harder.

I don't think it really changes the relevant hypervisors.

They need to support ESXi, KVM and Hyper-V. Anything else?

Before Broadcom it may have been 75%-20%-5% - after Broadcom
it may be 30%-65%-5%, but that does not change VMS support
requirements.

Above is for on-prem production systems.

For public cloud it is given by the cloud vendor.

And dev systems is different. VirtualBox, Player/WorkStation,
KVM etc..

(I know VirtualBox has been pushed a lot for this, but given
peoples experience on both Windows and Linux has been very painful,
then VSI should probably consider dropping that)

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 25 Nov 2024 12:34 +0000 (GMT Standard Time), John Dallman wrote:

The VSI plan is to run on the well-established hypervisors, and confine
the unfamiliar aspects of VMS to individual virtual machines. Sadly, Broadcom's greed after taking over VMware is making that harder.

Think of it as making the job easier, by removing VMware from the list of “well-established hypervisors” ...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/25/2024 4:45 PM, Lawrence D'Oliveiro wrote:

On Mon, 25 Nov 2024 12:34 +0000 (GMT Standard Time), John Dallman wrote:

The VSI plan is to run on the well-established hypervisors, and confine
the unfamiliar aspects of VMS to individual virtual machines. Sadly,
Broadcom's greed after taking over VMware is making that harder.

Think of it as making the job easier, by removing VMware from the list of “well-established hypervisors” ...

That is the direction. But it will take many years before ESXi usage
has declined enough to drop off that list. A lot of companies are
seriously pissed off over the price increases, but there are also
a lot of solutions where a migration from ESXi to KVM will be
considered too risky/costly, so the switch will first happen
when the solutions get replaced.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Just some blue sky kite flying, perhaps not grounded on the current
revision levels of VSI reality - to be honest, I don't diligently keep
up with the technicalities.

But wouldn't be lovely if we had laptops that were running bare metal
VMS? - the likes of which we haven't seen since the Alpha Tadpole
(IIRC).

I know "bare metal VMS" sounds like some unsafe sexual practice - and
I don't know the ins and outs (so to speak) of why it isn't common
practice, apart from the issues of device drivers writing, given the
plethora of devices and modules, that might have to be catered for.

Which is why the Frame.Work laptop initiative is a bright blessing:

https://frame.work/

I think Big Ken would have had grudging respect, or, indeed,
unreserved respect for what they have achieved.

If I wasn't such a "TrackPointer Tragic" ThinkPad veteran, this would
be my laptop platform of choice - CRU (FRU) heaven, and the
anthithesis of "enshittifcation".

As it is my current generations of ThinkPads will see me out, keeping
a weather eye on my running down system clock.

Quite possibly only a small set of device drivers would need to be
considered, if bare metal VMS was offered on their hardware platforms,
and given the elegance of their construction, field service
engineering would not have to be considered - people can roll their
own - nothing is soldered down that strictly doesn't have to be - CRU
heaven.

I think it would be the perfect marriage of VMS with third-party
hardware, and it would be a boon to the VMS ecosystem, to have such
available - it might even encourage new VMS shops being established -
new clients for VSI.

Given the modular I/O port design, they would be a boon to VSI
engineering for research, VSI Quality Assurnce for testing, VSI sales
for demonstrations, and existing, and possibly new, customers for
evaluating.

You could have two Ethernet port modules one for networking the other
for clustering computer interconnect, and two USB ports for Disk
shadow sets - the laptops would be cheap, perfect, Lego blocks for
exploring the VMS clustering and Shadow Set chops of VMS.

Further VSI could liaise with Frame.Work, and commission them to
design a Server Blade board, for running bare metal VMS, an Intel one,
and an AMD one, utilising "Gruntmaster 6000" (cf Dilbert, circa 2000)
CPUs and "GruntMaster 6000" GPUs (which seen all the rage these days,
with the AI hype).

The server board would have a RS232 port (well, just because!), but it
would also have (say) four narrow expansion slots to cater for DEC
specific I/O considerations - another boon for the VMS ecosystem.

And one of the genius aspects of the Frame.Work way, is that like the
Ship of Theseus, individual components, can be easily upgraded.

VSI management might have kittens and conniptions about how to price
VSI/VMS licenses for the laptops - but what is not made in margins,
may well be made in volume - I am sure if such laptops were available
to the VMS ecosystem, that they would fly off the shelves.

The 13" laptops for the Office, and portability, and the 16" laptops
for scientific and engineering workstations.

Anyways, that's my back of a beer coaster (lagered products) thesis &
proposal.

I'll leave it up to those who know what they are talking about to
weigh knowledgeably in.

And what might the VMSGenerations group think of it all?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 12/11/2024 à 23:59, Subcommandante XDelta a écrit :

Just some blue sky kite flying, perhaps not grounded on the current
revision levels of VSI reality - to be honest, I don't diligently keep
up with the technicalities.

But wouldn't be lovely if we had laptops that were running bare metal
VMS? - the likes of which we haven't seen since the Alpha Tadpole
(IIRC).

I know "bare metal VMS" sounds like some unsafe sexual practice - and
I don't know the ins and outs (so to speak) of why it isn't common
practice, apart from the issues of device drivers writing, given the
plethora of devices and modules, that might have to be catered for.

Which is why the Frame.Work laptop initiative is a bright blessing:

https://frame.work/

I think Big Ken would have had grudging respect, or, indeed,
unreserved respect for what they have achieved.

If I wasn't such a "TrackPointer Tragic" ThinkPad veteran, this would
be my laptop platform of choice - CRU (FRU) heaven, and the
anthithesis of "enshittifcation".

As it is my current generations of ThinkPads will see me out, keeping
a weather eye on my running down system clock.

Quite possibly only a small set of device drivers would need to be considered, if bare metal VMS was offered on their hardware platforms,
and given the elegance of their construction, field service
engineering would not have to be considered - people can roll their
own - nothing is soldered down that strictly doesn't have to be - CRU
heaven.

I think it would be the perfect marriage of VMS with third-party
hardware, and it would be a boon to the VMS ecosystem, to have such
available - it might even encourage new VMS shops being established -
new clients for VSI.

Given the modular I/O port design, they would be a boon to VSI
engineering for research, VSI Quality Assurnce for testing, VSI sales
for demonstrations, and existing, and possibly new, customers for
evaluating.

You could have two Ethernet port modules one for networking the other
for clustering computer interconnect, and two USB ports for Disk
shadow sets - the laptops would be cheap, perfect, Lego blocks for
exploring the VMS clustering and Shadow Set chops of VMS.

Further VSI could liaise with Frame.Work, and commission them to
design a Server Blade board, for running bare metal VMS, an Intel one,
and an AMD one, utilising "Gruntmaster 6000" (cf Dilbert, circa 2000)
CPUs and "GruntMaster 6000" GPUs (which seen all the rage these days,
with the AI hype).

The server board would have a RS232 port (well, just because!), but it
would also have (say) four narrow expansion slots to cater for DEC
specific I/O considerations - another boon for the VMS ecosystem.

And one of the genius aspects of the Frame.Work way, is that like the
Ship of Theseus, individual components, can be easily upgraded.

VSI management might have kittens and conniptions about how to price
VSI/VMS licenses for the laptops - but what is not made in margins,
may well be made in volume - I am sure if such laptops were available
to the VMS ecosystem, that they would fly off the shelves.

The 13" laptops for the Office, and portability, and the 16" laptops
for scientific and engineering workstations.

Anyways, that's my back of a beer coaster (lagered products) thesis & proposal.

I'll leave it up to those who know what they are talking about to
weigh knowledgeably in.

And what might the VMSGenerations group think of it all?

management is also a common request. So, at this moment, the world of
laptops is not part of our members’ priorities and concerns.

You quote Ken Olsen and we understand that your proposal is a vision.
Linking it to the frame.work operation is really relevant, since it's
part of the Digital culture to provide innovative alternatives, based on technical issues that may pose a problem. With the introduction of minicomputers, PdP and VAX, Digital transformed the use of computers in
the era of « mainstream of main frames ». In an age where sustainability
is essential, it's a real vision to join forces with initiatives like frame.work.

However, for the time being, this vision remains largely inaccessible,
and is not in line with today's most common needs in the current VMS
ecosystem.

On the other hand there are real needs for bare metal support in our environments. There are even cases where the use of a hypervisor is
completely impossible. In certain environments, where every IT operation
must be perfectly calibrated and safe, the use of hypervisors is more
than ill-received.

It's extremely important to maintain VMS's status as an exception in the extreme guarantee of safety, maintainability and longevity. It's
important that VMS can be used, if need be, as an OS that provides all
the environment's maintenance without an additional hypervisor layer.

These current practical reasons, combined with a very, very long-term
vision of proposing an alternative for the laptop, mean that we are very sensitive to your arguments.

The unavoidable question is that of platform support and drivers. For
our current needs in the server environment, our arguments are similar
to yours, albeit less broadly.

Clearly, our demand for bare metal support will be limited in two ways: quantity and time.

For what will be fairly exceptional requests for VMS use in bare metal,
users won’t be demanding a broad range of choices of options. One or
two basic configurations from a reliable manufacturer may suffice.

What's more, given the nature of the demand, it won't be necessary to
follow the race for new products and device qualification. We're talking
about applications such as industrial process control and clusters,
measuring their lifespan in decades. The bare metal chosen in 2024 has
every chance of being used until 2034.

It would seem that, in a similar way to your analysis, the need for bare
metal does not require VSI to follow an unsustainable race ahead. And
the image benefit for the ecosystem is certainly worth the investment.

Again, we agree with your view of the players who, in the long or very
long term, can bear the investment cost of development and support for
drivers. For the moment, VMS is a niche market, and bare metal with VMS
a niche market in a niche market. But those who have the need can
imagine investment and partnership solutions that would be profitable
for all. For our needs, there are probably ways to set up collaborations.

Your proposal is also interesting for its dynamics. The return of VMS as
an alternative must be able to handle different forms of deployment.
Bare metal (which is the case for 99 % of current VMS instances) is
certainly one of them, and VSI should be able to support it. Will this
lead to worldwide success à la Digital? The future will tell.

Thanks again for your attention dear Subcommandante

VMSgenerations

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 12/11/2024 à 23:59, Subcommandante XDelta a écrit :

Just some blue sky kite flying, perhaps not grounded on the current
revision levels of VSI reality - to be honest, I don't diligently keep
up with the technicalities.

But wouldn't be lovely if we had laptops that were running bare metal
VMS? - the likes of which we haven't seen since the Alpha Tadpole
(IIRC).

I know "bare metal VMS" sounds like some unsafe sexual practice - and
I don't know the ins and outs (so to speak) of why it isn't common
practice, apart from the issues of device drivers writing, given the
plethora of devices and modules, that might have to be catered for.

Which is why the Frame.Work laptop initiative is a bright blessing:

https://frame.work/

I think Big Ken would have had grudging respect, or, indeed,
unreserved respect for what they have achieved.

If I wasn't such a "TrackPointer Tragic" ThinkPad veteran, this would
be my laptop platform of choice - CRU (FRU) heaven, and the
anthithesis of "enshittifcation".

As it is my current generations of ThinkPads will see me out, keeping
a weather eye on my running down system clock.

Quite possibly only a small set of device drivers would need to be considered, if bare metal VMS was offered on their hardware platforms,
and given the elegance of their construction, field service
engineering would not have to be considered - people can roll their
own - nothing is soldered down that strictly doesn't have to be - CRU
heaven.

I think it would be the perfect marriage of VMS with third-party
hardware, and it would be a boon to the VMS ecosystem, to have such
available - it might even encourage new VMS shops being established -
new clients for VSI.

Given the modular I/O port design, they would be a boon to VSI
engineering for research, VSI Quality Assurnce for testing, VSI sales
for demonstrations, and existing, and possibly new, customers for
evaluating.

You could have two Ethernet port modules one for networking the other
for clustering computer interconnect, and two USB ports for Disk
shadow sets - the laptops would be cheap, perfect, Lego blocks for
exploring the VMS clustering and Shadow Set chops of VMS.

Further VSI could liaise with Frame.Work, and commission them to
design a Server Blade board, for running bare metal VMS, an Intel one,
and an AMD one, utilising "Gruntmaster 6000" (cf Dilbert, circa 2000)
CPUs and "GruntMaster 6000" GPUs (which seen all the rage these days,
with the AI hype).

The server board would have a RS232 port (well, just because!), but it
would also have (say) four narrow expansion slots to cater for DEC
specific I/O considerations - another boon for the VMS ecosystem.

And one of the genius aspects of the Frame.Work way, is that like the
Ship of Theseus, individual components, can be easily upgraded.

VSI management might have kittens and conniptions about how to price
VSI/VMS licenses for the laptops - but what is not made in margins,
may well be made in volume - I am sure if such laptops were available
to the VMS ecosystem, that they would fly off the shelves.

The 13" laptops for the Office, and portability, and the 16" laptops
for scientific and engineering workstations.

Anyways, that's my back of a beer coaster (lagered products) thesis & proposal.

I'll leave it up to those who know what they are talking about to
weigh knowledgeably in.

And what might the VMSGenerations group think of it all?

Dear Subcommandante Xdelta,


We really appreciate your interest in our work in general, and we're
glad you're asking us for advice.

The question you are asking is particularly interesting. It overlaps
with the concerns of our group but not in exactly the same terms.

The users and professionals we represent essentially use VMS in a server environment most often linked to high availability services, quality requirements and long or very longterm durability. Remote management is
also a common request. So, at this moment, the world of laptops is not
part of our members’ priorities and concerns.

You quote Ken Olsen and we understand that your proposal is a vision.
Linking it to the frame.work operation is really relevant, since it's
part of the Digital culture to provide innovative alternatives, based on technical issues that may pose a problem. With the introduction of minicomputers, PdP and VAX, Digital transformed the use of computers in
the era of « mainstream of main frames ». In an age where sustainability
is essential, it's a real vision to join forces with initiatives like frame.work.

However, for the time being, this vision remains largely inaccessible,
and is not in line with today's most common needs in the current VMS
ecosystem.

On the other hand there are real needs for bare metal support in our environments. There are even cases where the use of a hypervisor is
completely impossible. In certain environments, where every IT operation
must be perfectly calibrated and safe, the use of hypervisors is more
than ill-received.

It's extremely important to maintain VMS's status as an exception in the extreme guarantee of safety, maintainability and longevity. It's
important that VMS can be used, if need be, as an OS that provides all
the environment's maintenance without an additional hypervisor layer.

These current practical reasons, combined with a very, very long-term
vision of proposing an alternative for the laptop, mean that we are very sensitive to your arguments.

The unavoidable question is that of platform support and drivers. For
our current needs in the server environment, our arguments are similar
to yours, albeit less broadly.

Clearly, our demand for bare metal support will be limited in two ways: quantity and time.

For what will be fairly exceptional requests for VMS use in bare metal,
users won’t be demanding a broad range of choices of options. One or
two basic configurations from a reliable manufacturer may suffice.

What's more, given the nature of the demand, it won't be necessary to
follow the race for new products and device qualification. We're talking
about applications such as industrial process control and clusters,
measuring their lifespan in decades. The bare metal chosen in 2024 has
every chance of being used until 2034.

It would seem that, in a similar way to your analysis, the need for bare
metal does not require VSI to follow an unsustainable race ahead. And
the image benefit for the ecosystem is certainly worth the investment.

Again, we agree with your view of the players who, in the long or very
long term, can bear the investment cost of development and support for
drivers. For the moment, VMS is a niche market, and bare metal with VMS
a niche market in a niche market. But those who have the need can
imagine investment and partnership solutions that would be profitable
for all. For our needs, there are probably ways to set up collaborations.

Your proposal is also interesting for its dynamics. The return of VMS as
an alternative must be able to handle different forms of deployment.
Bare metal (which is the case for 99 % of current VMS instances) is
certainly one of them, and VSI should be able to support it. Will this
lead to worldwide success à la Digital? The future will tell.

Thanks again for your attention dear Subcommandante

VMSgenerations

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Mr Vanderhoeven :)

On 13/11/2024 9:59 am, Subcommandante XDelta wrote:

Just some blue sky kite flying, perhaps not grounded on the current
revision levels of VSI reality - to be honest, I don't diligently keep
up with the technicalities.

But wouldn't be lovely if we had laptops that were running bare metal
VMS? - the likes of which we haven't seen since the Alpha Tadpole
(IIRC).

I know "bare metal VMS" sounds like some unsafe sexual practice - and
I don't know the ins and outs (so to speak) of why it isn't common
practice, apart from the issues of device drivers writing, given the
plethora of devices and modules, that might have to be catered for.

Which is why the Frame.Work laptop initiative is a bright blessing:

https://frame.work/

I think Big Ken would have had grudging respect, or, indeed,
unreserved respect for what they have achieved.

If I wasn't such a "TrackPointer Tragic" ThinkPad veteran, this would
be my laptop platform of choice - CRU (FRU) heaven, and the
anthithesis of "enshittifcation".

As it is my current generations of ThinkPads will see me out, keeping
a weather eye on my running down system clock.

Quite possibly only a small set of device drivers would need to be considered, if bare metal VMS was offered on their hardware platforms,
and given the elegance of their construction, field service
engineering would not have to be considered - people can roll their
own - nothing is soldered down that strictly doesn't have to be - CRU
heaven.

I think it would be the perfect marriage of VMS with third-party
hardware, and it would be a boon to the VMS ecosystem, to have such
available - it might even encourage new VMS shops being established -
new clients for VSI.

Given the modular I/O port design, they would be a boon to VSI
engineering for research, VSI Quality Assurnce for testing, VSI sales
for demonstrations, and existing, and possibly new, customers for
evaluating.

You could have two Ethernet port modules one for networking the other
for clustering computer interconnect, and two USB ports for Disk
shadow sets - the laptops would be cheap, perfect, Lego blocks for
exploring the VMS clustering and Shadow Set chops of VMS.

Further VSI could liaise with Frame.Work, and commission them to
design a Server Blade board, for running bare metal VMS, an Intel one,
and an AMD one, utilising "Gruntmaster 6000" (cf Dilbert, circa 2000)
CPUs and "GruntMaster 6000" GPUs (which seen all the rage these days,
with the AI hype).

The server board would have a RS232 port (well, just because!), but it
would also have (say) four narrow expansion slots to cater for DEC
specific I/O considerations - another boon for the VMS ecosystem.

And one of the genius aspects of the Frame.Work way, is that like the
Ship of Theseus, individual components, can be easily upgraded.

VSI management might have kittens and conniptions about how to price
VSI/VMS licenses for the laptops - but what is not made in margins,
may well be made in volume - I am sure if such laptops were available
to the VMS ecosystem, that they would fly off the shelves.

The 13" laptops for the Office, and portability, and the 16" laptops
for scientific and engineering workstations.

Anyways, that's my back of a beer coaster (lagered products) thesis & proposal.

I'll leave it up to those who know what they are talking about to
weigh knowledgeably in.

And what might the VMSGenerations group think of it all?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/25/2024 10:06 AM, Arne Vajhøj wrote:

And dev systems is different. VirtualBox, Player/WorkStation,
KVM etc..

(I know VirtualBox has been pushed a lot for this, but given
peoples experience on both Windows and Linux has been very painful,
then VSI should probably consider dropping that)

Arne

All I use is VirtualBox on Windows10 and Windows11 systems. Works great
out of the box on W10. It took a few W11 changes to avoid VB and HyperV
from bumping into each other but once I made those changes, VB works
fine on my W11 laptop. There are several of us internal folks that use VB.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/26/2024 12:46 PM, Arne Vajhøj wrote:

On 11/26/2024 11:41 AM, John Reagan wrote:

On 11/25/2024 10:06 AM, Arne Vajhøj wrote:

And dev systems is different. VirtualBox, Player/WorkStation,
KVM etc..

(I know VirtualBox has been pushed a lot for this, but given
peoples experience on both Windows and Linux has been very painful,
then VSI should probably consider dropping that)

All I use is VirtualBox on Windows10 and Windows11 systems.  Works
great out of the box on W10.  It took a few W11 changes to avoid VB
and HyperV from bumping into each other but once I made those changes,
VB works fine on my W11 laptop.  There are several of us internal
folks that use VB.

Not everyone can get rid of anything Hyper-V as other stuff may require Hyper-V.

There has been several with problems using VirtualBox on Windows
due to Hyper-V conflict.

For those that want to mess with it then VSI do have a page
about it:

https://wiki.vmssoftware.com/Windows_host_compatibility_settings_for_OpenVMS_on_x86_VirtualBox_guests

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/26/2024 11:41 AM, John Reagan wrote:

On 11/25/2024 10:06 AM, Arne Vajhøj wrote:

And dev systems is different. VirtualBox, Player/WorkStation,
KVM etc..

(I know VirtualBox has been pushed a lot for this, but given
peoples experience on both Windows and Linux has been very painful,
then VSI should probably consider dropping that)

All I use is VirtualBox on Windows10 and Windows11 systems.  Works great
out of the box on W10.  It took a few W11 changes to avoid VB and HyperV from bumping into each other but once I made those changes, VB works
fine on my W11 laptop.  There are several of us internal folks that use VB.

Not everyone can get rid of anything Hyper-V as other stuff may require Hyper-V.

There has been several with problems using VirtualBox on Windows
due to Hyper-V conflict.

And with the VMWare workstation being free even for commercial use now,
then I see VirtualBox as an unnecessary complication.

(VirtualBox on Linux apparently gives different problems, but there are
KVM and various derivatives there)

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/25/2024 10:06 AM, Arne Vajhøj wrote:

(I know VirtualBox has been pushed a lot for this, but given
peoples experience on both Windows and Linux has been very painful,
then VSI should probably consider dropping that)

As John said, I've only ever used VirtualBox on both Windows and Linux.
I've had no issues of any kind running VMS X86 under VirtualBox---or any
other OS I've run there (Windows XP, Windows 10, Ubuntu, FreeBSD,
AlmaLinux, NetBSD, and more).

Hunter

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/26/2024 12:27 PM, Hunter Goatley wrote:

On 11/25/2024 10:06 AM, Arne Vajhøj wrote:

(I know VirtualBox has been pushed a lot for this, but given
peoples experience on both Windows and Linux has been very painful,
then VSI should probably consider dropping that)

As John said, I've only ever used VirtualBox on both Windows and Linux.
I've had no issues of any kind running VMS X86 under VirtualBox---or any other OS I've run there (Windows XP, Windows 10, Ubuntu, FreeBSD,
AlmaLinux, NetBSD, and more).

Nothing requiring Hyper-V?

But OK maybe I am wrong. I have seen many posts from where
it is not working. But maybe there is x10 as many where it
just works (people rarely post to tell that something is
working).

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/26/2024 12:53 PM, Arne Vajhøj wrote:

On 11/26/2024 12:27 PM, Hunter Goatley wrote:

As John said, I've only ever used VirtualBox on both Windows and
Linux. I've had no issues of any kind running VMS X86 under
VirtualBox---or any other OS I've run there (Windows XP, Windows 10,
Ubuntu, FreeBSD, AlmaLinux, NetBSD, and more).

Nothing requiring Hyper-V?

The only thing I can remember ever using that needed Hyper-V is WSL2,
and you're right, I'm not currently actually using the two together, as
I'm running VirtualBox on a Linux system.

They can be used together on Windows, but VirtualBox has to run in its
software virtualization mode.

https://stackoverflow.com/questions/58031941/how-to-get-virtualbox-6-0-and-wsl-working-at-the-same-time

But OK maybe I am wrong. I have seen many posts from where
it is not working. But maybe there is x10 as many where it
just works (people rarely post to tell that something is
working).

My guess is that they didn't know about the URL above. 8-)

I haven't actually tried it recently. I used to run VirtualBox on a
Windows 10 system with WSL (the first version).

Hunter

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <vi23qd$2qcsq$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:

On 11/25/2024 7:34 AM, John Dallman wrote:

In article <vhti7a$1sg3t$1@dont-email.me>, vlf@star.enet.dec.com
(Subcommandante XDelta) wrote:

As for Hypervisor/VMS, perhaps, this is an interesting option, to
make it a little more palatable to the VMS ecosystem:

https://blackberry.qnx.com/en/ultimate-guides/embedded-hypervisor

Demanding a hypervisor that isn't well-established in business IT is
another thing for customers' management to dislike.

The VSI plan is to run on the well-established hypervisors, and confine
the unfamiliar aspects of VMS to individual virtual machines.

That is the business requirement.

VMS must run on what the customers use.

Sadly,
Broadcom's greed after taking over VMware is making that harder.

I don't think it really changes the relevant hypervisors.

They need to support ESXi, KVM and Hyper-V. Anything else?

One jopes Bhyve just works.

- Dan C.

Before Broadcom it may have been 75%-20%-5% - after Broadcom
it may be 30%-65%-5%, but that does not change VMS support
requirements.

Above is for on-prem production systems.

For public cloud it is given by the cloud vendor.

And dev systems is different. VirtualBox, Player/WorkStation,
KVM etc..

(I know VirtualBox has been pushed a lot for this, but given
peoples experience on both Windows and Linux has been very painful,
then VSI should probably consider dropping that)

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/26/2024 1:48 PM, Hunter Goatley wrote:

On 11/26/2024 12:53 PM, Arne Vajhøj wrote:

On 11/26/2024 12:27 PM, Hunter Goatley wrote:

As John said, I've only ever used VirtualBox on both Windows and
Linux. I've had no issues of any kind running VMS X86 under
VirtualBox---or any other OS I've run there (Windows XP, Windows 10,
Ubuntu, FreeBSD, AlmaLinux, NetBSD, and more).

Nothing requiring Hyper-V?

The only thing I can remember ever using that needed Hyper-V is WSL2,
and you're right, I'm not currently actually using the two together, as
I'm running VirtualBox on a Linux system.

They can be used together on Windows, but VirtualBox has to run in its software virtualization mode.

https://stackoverflow.com/questions/58031941/how-to-get-virtualbox-6-0- and-wsl-working-at-the-same-time

Which the linked SO article call "really slow".

But OK maybe I am wrong. I have seen many posts from where
it is not working. But maybe there is x10 as many where it
just works (people rarely post to tell that something is
working).

My guess is that they didn't know about the URL above. 8-)

I haven't actually tried it recently. I used to run VirtualBox on a
Windows 10 system with WSL (the first version).

WSL1 did not use Hyper-V so easier at that time.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/26/2024 11:41 AM, John Reagan wrote:

On 11/25/2024 10:06 AM, Arne Vajhøj wrote:

And dev systems is different. VirtualBox, Player/WorkStation,
KVM etc..

(I know VirtualBox has been pushed a lot for this, but given
peoples experience on both Windows and Linux has been very painful,
then VSI should probably consider dropping that)

Arne

All I use is VirtualBox on Windows10 and Windows11 systems. Works great out of
the box on W10. It took a few W11 changes to avoid VB and HyperV from bumping
into each other but once I made those changes, VB works fine on my W11 laptop.
There are several of us internal folks that use VB.

Yes, and I've played with it in the past. Seemed to work Ok.

But as recently mentioned, development is one thing, but critical operational environment might be a bit more demanding. Do you have any opinions about VirtualBox in a critical operational environment. Just curious.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 26/11/2024 22:35, Dave Froble wrote:

On 11/26/2024 11:41 AM, John Reagan wrote:

On 11/25/2024 10:06 AM, Arne Vajhøj wrote:

And dev systems is different. VirtualBox, Player/WorkStation,
KVM etc..

(I know VirtualBox has been pushed a lot for this, but given
peoples experience on both Windows and Linux has been very painful,
then VSI should probably consider dropping that)

Arne

All I use is VirtualBox on Windows10 and Windows11 systems.  Works
great out of
the box on W10.  It took a few W11 changes to avoid VB and HyperV from
bumping
into each other but once I made those changes, VB works fine on my W11
laptop.
There are several of us internal folks that use VB.

Yes, and I've played with it in the past.  Seemed to work Ok.

But as recently mentioned, development is one thing, but critical
operational environment might be a bit more demanding.  Do you have any opinions about VirtualBox in a critical operational environment.  Just curious.

My biggest issues with Virtual Box is that when it gets one of it's
regular updates, as documented, it drops the PC's network, which is a
pain in the proverbial!

--
Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/26/2024 5:35 PM, Dave Froble wrote:

On 11/26/2024 11:41 AM, John Reagan wrote:

On 11/25/2024 10:06 AM, Arne Vajhøj wrote:

And dev systems is different. VirtualBox, Player/WorkStation,
KVM etc..

(I know VirtualBox has been pushed a lot for this, but given
peoples experience on both Windows and Linux has been very painful,
then VSI should probably consider dropping that)

Arne

All I use is VirtualBox on Windows10 and Windows11 systems.  Works
great out of
the box on W10.  It took a few W11 changes to avoid VB and HyperV from
bumping
into each other but once I made those changes, VB works fine on my W11
laptop.
There are several of us internal folks that use VB.

Yes, and I've played with it in the past.  Seemed to work Ok.

But as recently mentioned, development is one thing, but critical
operational environment might be a bit more demanding.  Do you have any opinions about VirtualBox in a critical operational environment.  Just curious.

My opinion is that you should read the official statements from VSI
about support. Nobody suggests using VB in a critical environment.
Will it work? I don't know. It has never failed me for the things I
do. I don't run a cluster. I don't have shared storage. I don't do
things that a real system does. I'm just a poor compiler guy picking up
rocks and pulling weeds in the field.

As for the network bounce at upgrade time, it hasn't been a problem for
me. I have PuTTY windows thru a WireGuard VPN back to VSI systems and
they don't drop. I've even been streaming a YouTube video and didn't
see a problem (I'm sure something had to recover, refetch, etc. in the browser).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 27 Nov 2024 14:09:20 -0500, John Reagan wrote:

Nobody suggests using [VirtualBox] in a critical environment.

I have a client using XCP-ng with Xen Orchestra in what is very much a “critical environment” <https://xcp-ng.org/>,
<https://xen-orchestra.com/>. He swears by it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/26/2024 12:54 PM, Arne Vajhøj wrote:

On 11/26/2024 12:46 PM, Arne Vajhøj wrote:

On 11/26/2024 11:41 AM, John Reagan wrote:

On 11/25/2024 10:06 AM, Arne Vajhøj wrote:

And dev systems is different. VirtualBox, Player/WorkStation,
KVM etc..

(I know VirtualBox has been pushed a lot for this, but given
peoples experience on both Windows and Linux has been very painful,
then VSI should probably consider dropping that)

All I use is VirtualBox on Windows10 and Windows11 systems.  Works
great out of the box on W10.  It took a few W11 changes to avoid VB
and HyperV from bumping into each other but once I made those
changes, VB works fine on my W11 laptop.  There are several of us
internal folks that use VB.

Not everyone can get rid of anything Hyper-V as other stuff may require
Hyper-V.

There has been several with problems using VirtualBox on Windows
due to Hyper-V conflict.

For those that want to mess with it then VSI do have a page
about it:

https://wiki.vmssoftware.com/ Windows_host_compatibility_settings_for_OpenVMS_on_x86_VirtualBox_guests

And a couple of new threads today including:
https://forum.vmssoftware.com/viewtopic.php?f=22&t=9321
which has link to a long instruction on how to get rid of
Hyper-V.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)