Re: Back end domains : input desired

["B.G. Bruce" <bgb@nt-nv.com>]

On Mon, 2005-01-24 at 12:18, Mark A. Williamson wrote:
> > DOM0:  minimal linux install with LVM2 primarily for backending the ide
> > disks.
> 
> Fine.
> 
> > BE_NIC_0:  Back end NIC_0 domain (bridge) with minimal linux install -
> > no ip address assigned - using ebtables to filter/protect
> > BE_NIC_1:  Same as BE_NIC_0 only for NIC_1
> 
> This should work, although a recent post suggested there was some sort of bug 
> in the multiple backend support...
> 
> > BE_VNIC_2:  Back end for a "virtual nic"/bridge for DomU to DomU
> > communication (DMZ).
> 
> So does this have any connections to the physical network cards at all?

No. Could I possibly use the "dummy" driver to handle this requirement?

> The problem is that AFAIK the current code won't allow a domain to run a 
> backend driver unless it's controlling a real physical device.
> 
> > BE_MGMT:  firewall config/mgmt console (xwindows) (preferred x
> > displaying (direct) through AGP on console - is this possible) and
> > ntp/clock sync (can this happen here or does it have to happen on
> > DOM0?).
> 
> Clock sync can probably only occur from dom0 at the moment.  Likewise for AGP 
> access (although one user had some success in giving a graphics card to a 
> domU, it's not fully working yet).

Ok, I can live with that for the moment ... hopefully this will be
addressed in the near future?


> > 1)   I only seem to be able to compile the actual NIC drivers with DOM0
> > (e100/e1000/3c95x, etc).  Is this where I should be compiling them even
> > though the NIC's will be used in another DOM?  If not, how do I go about
> > compiling the drivers for the BE DOM'S? (they don't show up as options -
> > yes, I do have XEN_PHYSDEV_ACCESS and XEN_NETDEV_BACKEND enabled.
> 
> Just stick all the drivers you need into a xen0 kernel, then use that kernel 
> in any domain that's talking to the hardware.  You can use a xen0 kernel 
> anywhere.

Wow, so you can run "multiple" dom0 images (one real dom0) - is there
anything I need to add to the .sxp file to differentiate the non-dom0
domains from the real Dom0?

> > 2)  Even with pci_dom0_hide=(01,01,0)(02,00,0) as part of my grub.conf
> > (for the startup of xen.gz), I still see these devices under DOM0, is
> > this normal? lspci shows the devices as 0000:01:01.0 and 0000:02:00:0.0)
> > respectively.  Are my parameters to pci_dom0_hide correct?
> 
> Try physdev_dom0_hide - pci_dom0_hide is a bug that got introduced to the docs 
> at some point (I think it has now been fixed).

Not as of yesterday with regards to the doc available on your website.

> > 3)  Should I be using stable, testing or unstable for this?  NOTE:
> > stable and testing both are unable to attach xen console to ttyS whereas
> > unstable works correctly for this.
> 
> In general, use stable for production environments.  Testing is the "next 
> stable release" and so is quite stable itself (and may have additional bug 
> fixes).
> 
> > 4)  It would be preferred to run X in a domain separate from Dom0, but
> > still be accessible for use on the local console without having to
> > install X and a VNC client in DOM0.  Is this possible, or am I just
> > dreaming here?
> 
> Possible in theory, in practice this doesn't quite work yet.

Good to know - I'll try it anyways and see if I'm lucky one of the lucky
few, or if I have to wait.

> HTH,
> Mark
> 

Thanks for the input!

B.


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl