WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: Back end domains : input desired

> 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?

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).

> Various front end DomU's:  for router/fw and various application layer
> gateways.

Right.

> My idea here is to be able to isolate the components into minimal
> operating environments allowing for specific need/application to be
> rebooted without having to reboot the entire box should that particular
> component be DoS'ed.

Makes sense.

> 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.

> 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).

> 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.

HTH,
Mark


-------------------------------------------------------
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel