Hi Andy,
If I understand correctly, this ultimately gives an upgrade path from
Ubuntu 18.04 to 20.04 without having to use the kernel hack. So I
could request a vps for doing a migration as per
https://tools.bitfolk.com/wiki/Migrating_to_a_new_VPS , with the new
vps using pvh, and hence be able to install 20.04 happily.
If that's the case, it's something that would be of interest to me at
some point.
Regards,
Roger
On Wed, 4 Nov 2020 at 09:12, Andy Smith <andy@???> wrote:
>
> Hello,
>
> This email doesn't discuss anything that you need to change (or in
> fact CAN change, at the moment), it's mostly a status update and
> fishing for feedback so can be safely ignored.
>
> As you may know, all BitFolk VPSes currently run under Xen PV
> (paravirtual) mode. We would like to switch to PVH mode instead.
> Here's some notes about our investigations of PVH mode:
>
> https://tools.bitfolk.com/wiki/PVH
>
> On the one hand we can get started right away: BitFolk's hypervisors
> support it, the newer stable releases of Debian and Ubuntu support
> it, the mainline kernel supports it, the rescue VM will work, etc
> etc. All new customers can be run in PVH mode as long as they don't
> choose an older release.
>
> On the other hand, it's not quite that simple as there's still a
> huge amount of existing customers whose kernels won't support it.
>
> I think it probably makes sense to immediately switch the Rescue VM
> to PVH mode, and make all installers also use it where the chosen
> install is known to support it. i.e. make it so that if you go and
> install Debian buster or testing or Ubuntu 20.04 right now, it
> silently switches you to PVH mode, because it's known to work.
>
> At the same time, we can add a Xen Shell command to toggle you
> between PV and PVH so you can try it out. If it doesn't work you
> could switch back, try again later at your own leisure etc. We don't
> know what Linux distribution you are running and can't tell without
> snooping on your console, so we can't make a good enough guess on
> your behalf.
>
> I don't really want to make a big thing of this because it's too
> complicated, so I'm thinking of hiding it away unless you need it.
> New customers / installs shouldn't have to think about it. It's only
> a concern for those of you with older, possibly 32-bit installs. For
> that reason I don't think I want to expose any of these details on
> the web panel or allow switching of the guest type there.
>
> On the subject of 32-bit PV support the deadlines are fairly laid
> back as — assuming you have no need of running a 5.9+ kernel —
> 32-bit PV booting could possibly¹ continue to work until 2023, which
> is the security support EOL for the last version of Xen that will
> support it.
>
> We're currently using Xen 4.10 and 4.12, and with the release of
> Debian 11 (bullseye) I will probably be looking to rolling upgrade
> to that with Xen 4.14.
>
> Any questions or thoughts on this?
>
> Cheers,
> Andy
>
> ¹ It is conceivable that some new CPU side channel attack lands and
> it's found that there is no way to stop a PV guest from snooping
> on the memory of the hypervisor or other PV guests. In that case
> there will be a sudden scramble to switch everyone.
>
> --
> https://bitfolk.com/ -- No-nonsense VPS hosting
> _______________________________________________
> users mailing list
> users@???
> https://lists.bitfolk.com/mailman/listinfo/users
