Posted on | February 19, 2009 | 1 Comment
I receive two kinds of e-mail regarding Xen. Usually, people have specific questions, problems or errors to cure. Others are planning to deploy Xen and simply want feedback on design ideas based on what I’ve tried. I like the second kind of question the most, the conversations usually turn protracted and become quite interesting.
Someone asked me about deploying Xen on a single system image. A single system image (SSI) describes a case when many computers boot from and share a single disk. Typically, this means most computers in the network do not have hard disks installed, they all use a disk that is attached to a network. Sometimes, in this setting, all of the computers will contain one small hard disk to use for swap.
I told the person that if some other route existed, use it prior to setting up a single system image. Beyond the pain of contextually dependent symbolic links (CDSLs), you gain no real benefit by using a SSI with Xen save for a faster path to upgrade and central guest configuration. Either / or benefit is easily achieved by other means. Yes, domain checkpointing might be a LITTLE easier on a SSI, but not much.
However, the idea does interest me, if it can be simplified and offer more benefits WITHOUT kernel or Xen modifications. The point is, even if your using a single system image, you’re still using XMLRPC between each node, each node must still contain an independent store and there is no way to open a handle to a distant hypervisor on another node (i.e. using xc_interface_open()). You aren’t gaining much beyond more administrative headaches and another single point of failure.
I’m really, really eager to see Xen privileged operations hit mainline paravirt_ops, as it will open the door to many more interesting things. Until then, forward thinking still puts your head in the ‘clouds’ – as in cloud computing with single server / farm mentality.