Re: [Xen-users] 32bit DomU on 64-bit Xen

[Lionel Bouton <lionel-subscription@xxxxxxxxxxx>]

Petersson, Mats wrote the following on 24.10.2006 19:55 :
>  
> All user-mode code that doesn't make assumptions about the kernel or
> uses pre-compiled 32-bit kernel modeuls can be run on 64-bit kernel -
> but again, what is the benefit of running a complete 32-bit installation
> that is NOT part of a packaged distribution,

?!

>  when there is a (hopefully)
> some distribution that comes with the complete 64-bit set of "guaranteed
> by the distributor to work together" parts

Now I understand. We *need* 32 bit environments, see below.

>  - ok, so it may not ALWAYS
> work as the distributor says, but if you mix'n'match your own version of
> 32+64-bit parts, it's almost guaranteed that you're going to have SOME
> problems - at least the main distributors do put SOME effort into making
> sure what they distribut works... 
>
> All compatibility problems caused by the kernel being 64-bit would still
> remain. The only point I can see is that you save some diskspace by only
> installing 32-bit .so's, but with a limited installation of 64-bit
> tools, you'd not fill enough diskspace to REALLY make a huge difference.
>
>
> I just don't get the point, so if you could enlighten me as to why you
> would want to do this, I'll look further at any reason why it
> would/would not work... 
>   

Software support. I work for a software publisher. We have several
products which are (or will shortly be) available both for 64 and 32 bit
environments. I don't have HVM-capable hardware yet, mostly have 32 bit
support environments and don't want to install 32-bit Xen servers to
start moving them to 64 bit in order to follow the market in the
following years. So I'd like to run 32 bits DomUs on my Opteron servers
now and 64-bit DomUs later (with a mix of them in between)...

To put things more in context: we have a repository of DomUs (both
compressed disk images and whole configuration for each DomU) on a
dedicated (non Xen) server with a huge majority of 32bit DomUs (we don't
have 64-bit installations to support yet and are only moving 64 bit
development environments to Xen) that are dynamically transferred to a
Xen server. We use a small custom Xen admin console to handle our needs
(distributing DomUs on tens of servers, helping our users choose the
appropriate Xen server for their needs, managing DomU versioning,
system-wide backup, ...).

Currently when a client reports a problem in one of our software
product, we check if the appropriate support environment for the
software is up (based on the distribution it runs on and the actual
software versions, we can have more than 10 environments for a single
software product). If it isn't we click a button in the Web UI or launch
a script on the admin console to start it on one of the available Xen
servers. We then try to reproduce the problem and use a development
environment (other DomUs which are up most of the time) to correct it
once we find the source.
When updates from distributions used by our clients are available we
make a new version of the appropriate support environments and check
that these updates don't break anything before giving our clients the
green light (or handling the update ourselves depending on our contract
with them).
Currently all of this takes place on 32-bit environments. But this is
already starting to change for the development and integration
environments for which we use 64-bit distributions on top of 32-bit ones...

The only thing that we left out of our support environment is the kernel
(which can never be identical to the one of our clients because they
don't use Xen - yet - and even if we used HVM to run the same kernel we
couldn't actually support it because of the tiny device driver usage
differences: the devil is in the details). We have custom built kernels
and only create new kernels when one of our product environment needs it
(when a configuration isn't compatible with a new distribution or a
kernel feature is lacking, which... never happened since we started
using Xen). Anyway if the need for kernel-level support arise (it
happens when the solution involves not only our sofware but interfaces
with specific hardware), we simply request the client to pay for a full
hardware support environment and this is obviously completely separated
from the Xen environment.
So using 64-bit kernels for 32-bit distributions doesn' seem to be a
problem for us (as long as there's not an incompatibility between
userspace and kernelspace, and I don't think we have to support any
incompatible userspace and will have to in the foreseeable future).

Lionel

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users