On Wed, 2006-08-09 at 05:17 +0530, Ligesh wrote:
> Your arguments are valid in the case of domU-domU communication system, but
> not for dom0-domU. The dom0 will be, and should be aware of migrations and
> also there should be non-networking mechanism to manage and control every
> aspect of domU from dom0. This in my opinion, is a basic requirement. But I
> think ppp over serial port might be the exact thing what I was looking for.
> PPP doesn't provide domU-domU, but yes domU-domU actually defeats the entire
> purpose of Xen which is isolation, and also that Xen should be agnostic about
> the type of the OS running inside the domU.
i agree that dom0 may be considered special. regarding transparent
migration: flattening the network stack remains at the expense of
migrating or proxying the dom0-internal channel endpoint together with
the domain, right? together with either migrating or proxying whatever
entity/ies were connected to that endpoint. remember, if you want the
relocation to remain transparent, you'll need to guarantee that a
presumably stateful connection to whatever connected to domU remains
persistent. simple, if it's running on top of an IP layer hosted by a
virtual LAN, the former located _inside_ domU. that state gets
transferred as well, and IP routing of the LAN makes the relocation
transparent. if you lose that, you'll need to rebuild this feature
externally from domU, and that's a lot of complicated work and makes
your management infrastructure a whole more complex.
again, i totally agree that there's a lot to be gained from lightweight
host-local packet streams. but it will remain coming at a cost whenever
applied to domU, and the fun part is that what you originally wanted to
achieve, simplyfing domain management by short-circuiting the domU
access, will ultimately turn into something way more adventurous than
the IP-based approach as soon as migration comes into play.
LRR - Lehrstuhl für Rechnertechnik und Rechnerorganisation
Institut für Informatik der TU München D-85748 Garching
PGP Fingerprint: F5A4 1575 4C56 E26A 0B33 3D80 457E 82AE B0D8 735B
Description: This is a digitally signed message part
Xen-devel mailing list