To clarify, we're only really talking about the kernel here? So, if
(like me) you've upgraded your kernel and hence your Xen instance to 64
bit, but your userland is a mixture of 32 and 64 bit, you're OK?
(In my case: debian stretch, kernel 4.9. Clearly I ought to upgrade to
buster, which will enable PVH mode, but rather than continue with my ~8
years of cruft around the filesystem, did you say something about being
able to offer a spare guests on a short term basis for the purposes of
reimaging? I really ought get my head around Ansible and friends too...)
Ross
On 16/07/19 10:05 PM, Andy Smith wrote:
> Hi,
>
> Those running 32-bit VMs who haven't thought about
> upgrading/reinstalling them to 64-bit yet, please have a read of:
>
> “There are no current plans to remove support for 32bit PV
> guests from Xen, but it is very much in the category of "you
> shouldn't be using this mode any more".”
>
> https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg00827.html
>
> When Juergen asked for feedback on removing 32-bit guest support a
> year or two ago I told him that (at the time) more than 60% of
> BitFolk's user base was 32-bit and they'd need time to transition.
> Now that there is a stable grub release which supports PVH¹ booting
> Juergen is pushing this again and it will eventually go through to
> the Linux kernel.
>
> When Xen does remove 32-bit PV mode we can still continue to support
> 32-bit guests in PVH mode or HVM mode, so I will still make sure it
> works without customers having to do anything. But you should be
> clear that just because it will work doesn't mean it is a good idea!
>
> I have a round of updates to do and then I will start moving
> customers over to PVH mode where possible (requires 4.11+ kernel in
> guest).
>
> Cheers,
> Andy
>
> ¹ PVH mode guests run all the normal code paths of a kernel not
> under virtualisation except for their IO drivers like networking
> and block devices which are still paravirtualised for performance
> reasons. This results in a kernel that has a smaller attack
> surface as there is much less xen-specific code being used, it's
> faster and simpler. It also still doesn't require use of qemu on
> BitFolk's side. See:
>
> https://wiki.xen.org/wiki/Understanding_the_Virtualization_Spectrum
>
> for more information.
>
>
> _______________________________________________
> users mailing list
> users@???
> https://lists.bitfolk.com/mailman/listinfo/users
>
