Forums before death by AOL, social media and spammers... "We can't have nice things"
|    alt.os.linux.gentoo    |    Stupid OS you gotta compile EVERYTHING    |    17,684 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 16,212 of 17,684    |
|    J.O. Aho to Aragorn    |
|    Re: Virtual Machine (1/2)    |
|    05 Apr 08 15:24:01    |
      From: user@example.net              Aragorn wrote:              > I know OpenVZ, yes, and for a while I have also contemplated using it, along       > with checking out the KVM approach. :-) Gentoo has packages for OpenVZ in       > Portage, by the way, although they /may/ still be masked - this I don't       > know.              I haven't looked that far, but it seems to be unmasked according the Gentoo       Howto at the wiki, but this far dedicating hardware don't work more than for       NICs as far as I managed to figure things out, which means that OpenVZ won't       be an option for me.                     > Now, if you want to use graphics inside /domU/ and you want to be actually       > only run X11 there - and not in X11, with a remote connection to an       > application running inside /domU,/ which is what most people do but which       > is not the right way as it introduces a stability hazard to your management       > virtual machine by running X there - then you need to have a dedicated       > video adapter for the /domU/ machine.       > So far so good, but the problem there is that by default, the Linux kernel       > will still be using whatever it considers to be the primary video adapter -       > the one found at /dom0/ boot time - for non-graphical output. So if you       > want to use the dedicated /domU/ video adapter, you are stuck to only being       > able to use it in X11, which you _can_ easily set up by editing       > */etc/xorg.conf* and manually specifying the PCI address for that adapter.              I have been thinking of using 3 graphics cards, two PCIe and one PCI, where I       was hoping to be able to use the PCI card as the main graphics adapter, as       console output don't require any monster graphics cards.       While the desktop and the media-box instances I was hoping to give them a PCIe       graphics card each, both should be able to run at the same time.                     > This approach would then of course also mean that you'd have to have that       > operating system session configured to boot to runlevel 5, with a display       > manager, and that you wouldn't get any output during the character mode       > phase of the /domU/ boot and shutdown, unless you're willing to switch       > between monitors or monitor channels every time you switch back and forth       > between character mode and X11.              Yes, but in gentoo you default have initlevel 3 for graphical environment, as       people seems to only use "default", I do want to have things setup like in       RedHat where level 3 is multiuser mode with VT and level 5 is Xorg. Myself I       added graphical, no network as level 4 (reserved for future use in RedHat), so       I have an equivalent to level 2.                     > With the Xen approach as I have laid out above, if the evil driver hangs the       > kernel or even messes up the hardware framebuffer in such a way that you       > need a reboot to recover from it, then the damage would still be limited to       > that particular /domU/ virtual machine anyway, and your /dom0/ and       > hypervisor would be safe, and as such, so would your other /domU/ virtual       > machines be. So all of your individual server set-ups would continue to be       > available while you are rebooting your GUI workstation virtual machine.              *nods*       That is one of the strong benefits with Xen over the others, but OpenVZ has       easier resource management system, where you can make changes on the fly. As I       have understood Xen, you have to restart the instance before it gets the new       resources.                     > This is why it is wrong to run X11 in /dom0,/ unless /dom0/ is your       > workstation installation and is not to be considered mission-critical.       > Such a set-up would be good for using /domU/ as a testbed or sandbox only.       > My intent however is to have all /domU/ virtual machines be       > mission-critical, with the graphical virtual machine preferably being as       > stable as possible but acknowledging that it holds a risk due to having to       > use the evil proprietary nVidia driver for 3D graphics. If you don't need       > 3D acceleration, then you can use the more reliable (and less cumbersome to       > set up) FOSS "nv" driver.              No, I don't want a graphical environment for dom0, I want it to be as clean as       possible, the only thing I will run on it would be a NFS share, as I'm not       that happy about the file I/O in a domU and thinking about some kind of tftp       boots for the domUs.                     >> At the moment what I have thought about is "Firewall/Gateway" which has       >> more or less just a read only environment, File-server to share files,       >> Media-box (dedicated graphics, remote control), Desktop (dedicated       >> graphics, keyboard and mouse), Server running mail, web...       >       > If you need dedicated graphics in more than one unprivileged virtual       > machine, then you'll need to add an additional video adapter card for each       > of them. You can't share one videocard among multiple virtual machines,       > except via a virtual framebuffer. Likewise, your remote control apparatus       > will have to be hidden from /dom0/ and must only be accessed by one       > unprivileged virtual machine.              It had been nice if Xen had the same way to deal with hardware as OpenVZ have       for their network devices and you can do the change in realtime with no need       to reboot.                     > But then again still, this would not be feasible with OpenVZ. You'd need to       > use Xen for such a set-up. I would also set up the firewalling, NAT and       > gateway thing in /dom0,/ since that is the virtual machine that has access       > to the physical NICs in your machine. You should then also set up the Xen       > networking configuration to make use of routing instead of the default       > choice of bridging.              Was thinking about if it would be possible to dedicate a nic in a similar way       to a domU as a graphics card. IMHO it feels better if someone "hack" a domU       with only read only access to files, than getting access to dom0, and if       something would get messy then just restart the domU instead of a reboot of       the whole system.                     > If you want to use ethernet bridging set-up that Xen defaults to, then each       > of your virtual machines must have a dedicated IP address of its own, and       > this might be tricky with most ISPs. Mine for instance - Telenet here in       > Belgium - gives me only two public IP addresses (via semi-static DHCP) for       > my current contract, and when my machine will be fully set up, I intend to       > switch to a contract that gives me a guaranteed static IP address, but then       > I'll only have one.              My ISP allows just one public IP (thanks to someone smart person at that       company, it's a static one), but the majority os ISPs over here offers only       DHCP and with one dynamic ip-address.       I don't want any direct access to the other domUs from the outside, so       bridging ain't the option for me.                     > So if you do want bridging and your ISP only gives you one public IP       > address, then you should get a router and set that one up as the default       > gateway and firewall, and then you can have the router assign as many IP       > addresses to your Xen box as you like.                     [continued in next message]              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca