J.O. Aho wrote:

> Aragorn wrote:
>
>> It's just that the Live CD attempted to start up X11 - which I had not
>> expected it to do - and then went a little crazy on the fact that there
>> is a PCI Radeon card (which always takes precedence as the primary
>> videocard) and a PCIe GeForce card.
>
> At least on older machines you could set the primary graphics card in the
> BIOS, wouldn't surprise me if there is a PCIe/PCI option in your BIOS.

Trust me, there isn't one, nor are there any jumpers on the motherboard to
select a primary graphics adapter - the motherboard doesn't even have
onboard graphics - and all information on the subject I've managed to dig
up suggests that a PCI videocard will always take precedence over a
PCIe/AGP card as the primary video adapter.

I was told by someone who builds computers himself that it's got something
to do with the IRQ, in the sense that a lower IRQ number would take
precedence, but I don't consider myself tech-savvy enough to corroborate or
argue this statement.

>> As for nVidia releasing a Xen-compatible driver - or let us have a wild
>> dream for a moment: having them open up their source code - that is not
>> going to happen. The best they will do is offer a driver that no longer
>> needs to be patched in order to run it inside a GNU/Linux system in a
>> Xen /dom0./
>
> No, they will not open up the source and the majority of distros won't
> have it as a default driver due the license.

nVidia has received an as yet still open invitation to collaborate with the
Xen developers, even without needing to open up their source code, and to
my knowledge they have totally consistently been ignoring this invitation
for over a year already so far.

On the other hand, it would appear that they have at least been silently
monitoring some of the Xen development and are now at least acknowledging
that there is such a thing as Xen and that virtualization really exists,
through their recommended use of a compile-time "IGNORE_XEN" variable.

nVidia has always had better drivers than ATI, but with ATI now being owned
by AMD and AMD opening up the driver code - including for older ATI
chipsets - this balance may soon find itself radically tipped over to the
ATI camp, and in that case, I will come to seriously regret that I opted
for an nVidia adapter and their proprietary drivers in the first place,
being a Free Software advocate myself.

My stance here was that no usable 3D acceleration was available for any
fairly recent videocards from FOSS drivers so far, and that it was thus
ethically allowed by sheer necessity to use a proprietary video driver.
With AMD opening up their driver code now, I find myself "committing a sin"
against my own principles by using nVidia.

(My motherboard has an nForce Professional chipset, but the specs for those
are open.)

>> In addition, I have very little knowledge of iptables and routing, and
>> I'll have to set up everything using a custom routing table, as I'll only
>> have one public IP address, but all virtual machines should have access
>> to the
>> internet. For /dom0,/ this only need be /ssh/ access, but I might set up
>> a /ssh/ DMZ inside one of the other virtual machines, so that one
>> must /ssh/ into that virtual machine first and then from there /ssh/ into
>> the /dom0./ This is probably the wisest solution. ;-)
>
> I did setup Xen on a test machine running CentOS, had no need of
> configuring iptables rules to access internet with domU. Of course if you
> want to protect ports, you have to do something. I would have recommended
> you to take a look at FireStarter, but it hasn't been maintained for a
> while and has some troubles with later kernels and gnome2 libs.

My main needs are the following: /domU/ must be able to access the internet,
but as I will have only one public IP address available, it'll have to be
done through NAT/routing. Firewalling will need to be taken care of on a
VM-specific manner, depending on the individual needs of each virtual
machine.

Certain ports will have to be forwarded to designated virtual machines - I
will be running three or four of them, including /dom0/ - such as port 22
for /ssh,/ port 80 for /http,/ the port range between 6660 and 6669 for an
IRC server - there will also be additional needed ports for this but I
don't know them from memory right now - and then most of the userspace
ports will have to be forwarded to the X11 /domU/ machine.

In addition, the motherboard has a second onboard Gigabit NIC, which will be
connected to my switch, and through which the other machines on my network
must be able to connect to the internet via NAT on the same machine as
which is running the virtual machine set-up.

I'm sure it'll all be quite easy to accomplish for someone experienced
in /iptables,/ but unfortunately I consider myself quite a novice in that
area as I have thusfar always relied upon GUI utilities such as /webmin/
for this purpose. :-/

> One of the disadvantages I see is the high load on the domU while making
> disk access, even if you have dedicated slices for them. I have been
> thinking of testing KVM instead and see if it's kinder on the load or not,
> but been too busy with other things.

KVM is an interesting approach to virtualization and its existence could
give the Linux kernel even more credibility as a viable corporate operating
system kernel - previously, UNIX-style kernel-based virtualization was only
available in Solaris, which still allowed for some FUD to circle in the
minds of those Pointy Haired Bosses (TM) who were at least willing to
consider something other than Crimosoft Wintendo on their server hardware -
and the project certainly has already come a long way in a short time, but
there is still a lot of work to be done, and at the moment I still consider
Xen to be the best and most stable option. It's faster than KVM and
requires less of a memory overhead because of the small hypervisor codebase
versus a fully-blown Linux kernel.

The above said, I doubt that the load inside /dom0/ - you wrote /domU/ but I
take it you mean /dom0/ instead? - would really differ a lot when using KVM
rather than Xen. It is after all virtualization, which means that there
are multiple operating systems, each with their respective I/O
requirements, trying to access the same hardware simultaneously. So I
think the phenomenon is rather indigenous to the concept of virtualization
itself rather than to the virtualization technology used.

On the other hand, both Xen and KVM - and who knows, even VMWare - will
probably benefit a lot from the new and improved scheduler in the Linux
kernel, as well as from using the leaner /SLUB/ instead of the
traditional /SLAB./

By the way, I do indeed intend to give each operating system instance its
own dedicated slices where possible/needed and use NFS where otherwise
possible/recommended. The downside of this approach - I've always been in
favor of splitting off as much as possible from the root filesystems - is
that I will be needing more than the available 15 partitions.

IDE hard disks allowed for up to 63 partitions, while SCSI/SAS/SATA/USB
disks only allow for 15 partitions, or at least, unless you are lucky
enough to have one of the newer EFI-equipped machines, in which case 128
primary(!) partitions are possible. I have 4 SAS disks in the target
machine, but they are configured in a RAID 5 array and are thus seen as one
SCSI disk by the operating system. Ergo, I will have to set up LVM(2)
slices instead, which I've only done once before so far, but which also
seems like a very interesting technology to me. I do wonder as to how much
this extra level of hardware abstraction will impede on performance,
though.

Of course, in a virtualization environment where you have several virtual
machines running quite dedicated server tasks, your partitioning layout may
not need to be all that elaborate. There's a huge chance that */opt* and
*/usr/local* - which I normally also split off from */usr* - will be empty
anyway. */usr/src* and */usr/portage* can be shared via NFS. */tmp* can
be a /tmpfs./ */usr* itself could even be shared over NFS in its entirety
between minimally installed server VMs. */boot* is unneeded by any virtual
machine other than /dom0,/ et al.

I'm not sure whether such an approach is already possible with KVM - I
haven't exactly kept track of the KVM development itself in favor of my
interest in Xen and KVM still being rough around the edges - as I seem to
recall that KVM requires modified Qemu images to work with. Personally I
favor individual and independent slices rather than disk images mounted
over a loopback mechanism, but your mileage may of course vary.

On account of KVM, I'm also not sure on the status of SMP guests yet - in
theory, it /should/ be possible by now - nor on the use of 64-bit
guests. /lguest/ is also an in-tree virtualization project that comes with
the Linux kernel, but as I understand it /lguest/ would rather be an
experimental toy than a viable production-ready virtualization solution.

Again, your mileage may vary. ;-)

--
Aragorn
(registered GNU/Linux user #223157)

Aragorn wrote:
> J.O. Aho wrote:

> and all information on the subject I've managed to dig
> up suggests that a PCI videocard will always take precedence over a
> PCIe/AGP card as the primary video adapter.
> I was told by someone who builds computers himself that it's got something
> to do with the IRQ, in the sense that a lower IRQ number would take
> precedence, but I don't consider myself tech-savvy enough to corroborate or
> argue this statement.

Ok, you could try to switch the IRQ numbering, if your BIOS has that option,
used to be more common on those old PCI/ISA motherboards.


> nVidia has received an as yet still open invitation to collaborate with the
> Xen developers, even without needing to open up their source code, and to
> my knowledge they have totally consistently been ignoring this invitation
> for over a year already so far.

nVidia has been quite unhelpful, as I have understood they haven't helped
anything with the nv driver (included in xorg/xfree) nor the new driver that
will include 3D-support, compare with AMD (formerly ATi), who has given out
information and code to the development of the xorg/xfree driver.
They may even open up the code for the closed source driver.


> nVidia has always had better drivers than ATI, but with ATI now being owned
> by AMD and AMD opening up the driver code - including for older ATI
> chipsets - this balance may soon find itself radically tipped over to the
> ATI camp, and in that case, I will come to seriously regret that I opted
> for an nVidia adapter and their proprietary drivers in the first place,
> being a Free Software advocate myself.

Yes, during the old ATi times I think there was kind of a small handful part
time developers who worked with the driver, while there was closer to 100
people at nVidia who worked with the nVidia driver.
I have been using nVidia for the most of my x86 based machines, as the driver
is better, but on all my other machines (Sparc and PowerPC), there hasn't been
any support and nVidia dropped the PowerPC project when Apple dropped the
PowerPC as the CPU in Macs, so I have gone with ATi cards on those, getting a
soso hardware 3D support from the open source drivers.


> (My motherboard has an nForce Professional chipset, but the specs for those
> are open.)

The forcedeth was developed without any help from nVidia, but nVidia did drop
their own network driver when they thought the forcedeth driver was good
enough. IMHO they haven't contributed much, they could do a lot more, but I
guess they feel they are big enough to not care about 5% of the user market.


> Certain ports will have to be forwarded to designated virtual machines - I
> will be running three or four of them, including /dom0/ - such as port 22
> for /ssh,/ port 80 for /http,/ the port range between 6660 and 6669 for an
> IRC server - there will also be additional needed ports for this but I
> don't know them from memory right now - and then most of the userspace
> ports will have to be forwarded to the X11 /domU/ machine.

I would suggest you to not use the port 22 for ssh, while I did I had damn a
lot of script kiddies trying to force them into my system using, even if it
wasn't working, I didn't like the long log reports I had about these tries, so
I switched to an alternative port.


> I'm sure it'll all be quite easy to accomplish for someone experienced
> in /iptables,/ but unfortunately I consider myself quite a novice in that
> area as I have thusfar always relied upon GUI utilities such as /webmin/
> for this purpose. :-/

As long as you manage to get things to run on virtual NICs, the NATing will be
the easy part, you will just to follow one of the many HOWTOs you can find at
the net.


>> One of the disadvantages I see is the high load on the domU while making
>> disk access, even if you have dedicated slices for them. I have been
>> thinking of testing KVM instead and see if it's kinder on the load or not,
>> but been too busy with other things.
>
> The above said, I doubt that the load inside /dom0/ - you wrote /domU/ but I
> take it you mean /dom0/ instead? - would really differ a lot when using KVM
> rather than Xen. It is after all virtualization, which means that there
> are multiple operating systems, each with their respective I/O
> requirements, trying to access the same hardware simultaneously. So I
> think the phenomenon is rather indigenous to the concept of virtualization
> itself rather than to the virtualization technology used.

No, I mean domU, the dom= has a low load.
The test I made was setting up 3 domU running Apache and making approx 10000
request per sec per domU.

With diskimage on file the load on each domU was up on 2.8, while dom0 was at 0.3.

With dedicated slices the load on each domU was up on 0.9 while dom0 was at 0.2.

Doing the same kind of attack on the dom0 don't result in much higher load
than 0.15 (if I remember it right)

This high difference in loads will it make difficult with rules that prevents
high loads.


> By the way, I do indeed intend to give each operating system instance its
> own dedicated slices where possible/needed and use NFS where otherwise
> possible/recommended.

If you want read only access, then NFS has the advantage that it's the server
that decides if the client has read/write access or not, while a dedicated
slice can always be remounted as read/write. But usually a local hard drive is
faster.


> Ergo, I will have to set up LVM(2)
> slices instead, which I've only done once before so far, but which also
> seems like a very interesting technology to me. I do wonder as to how much
> this extra level of hardware abstraction will impede on performance,
> though.

I have to say I haven't noticed any downside with my LVM that I share over NFS
to all my machines (just a small 500G /home).
I read a bit about zfs and it seems interesting, but I don't want it as a
userspace file system, which is what you get in Linux today.


> Of course, in a virtualization environment where you have several virtual
> machines running quite dedicated server tasks, your partitioning layout may
> not need to be all that elaborate. There's a huge chance that */opt* and
> */usr/local* - which I normally also split off from */usr* - will be empty
> anyway. */usr/src* and */usr/portage* can be shared via NFS. */tmp* can
> be a /tmpfs./ */usr* itself could even be shared over NFS in its entirety
> between minimally installed server VMs. */boot* is unneeded by any virtual
> machine other than /dom0,/ et al.

I never split out /usr/local, as it's always been more or less empty on all my
installs, /usr/src I did split out when I went to Gentoo. I try to split out
those parts where you have a lot of writes, as I see it more likely that
something will go wrong there and don't want it to affect the more static
parts of the file system.


> I'm not sure whether such an approach is already possible with KVM - I
> haven't exactly kept track of the KVM development itself in favor of my
> interest in Xen and KVM still being rough around the edges - as I seem to
> recall that KVM requires modified Qemu images to work with. Personally I
> favor individual and independent slices rather than disk images mounted
> over a loopback mechanism, but your mileage may of course vary.

I do agree on that too. I think KVM can access file systems via userspace,
haven't kept so much track about KVM nor Xen, just looked a couple of months
ago at the wikipedia where they compared a load of different virtualization,
where KVM was on top when it came to smoth file I/O.


> On account of KVM, I'm also not sure on the status of SMP guests yet - in
> theory, it /should/ be possible by now - nor on the use of 64-bit
> guests.

As I have understood, you don't dedicate CPUs in KVM, but each "node" will get
the required CPU usage to do it's work.


--

//Aho

J.O. Aho wrote:

> Aragorn wrote:
>
>> and all information on the subject I've managed to dig
>> up suggests that a PCI videocard will always take precedence over a
>> PCIe/AGP card as the primary video adapter.
>> I was told by someone who builds computers himself that it's got
>> something to do with the IRQ, in the sense that a lower IRQ number would
>> take precedence, but I don't consider myself tech-savvy enough to
>> corroborate or argue this statement.
>
> Ok, you could try to switch the IRQ numbering, if your BIOS has that
> option, used to be more common on those old PCI/ISA motherboards.

I'm not sure whether it does or doesn't, but it's largely irrelevant now.
The PCI card will be used for booting up the /dom0/ anyway - that's the
whole idea - and I intend to use the PCIe card for one /domU/ node only,
i.e. the X11 "workstation" virtual machine.

The motherboard is a Tyan Thunder n6650W (S2915) by the way, in case you're
interested. It's got a Phoenix BIOS, but don't ask me what version.

>> nVidia has received an as yet still open invitation to collaborate with
>> the Xen developers, even without needing to open up their source code,
>> and to my knowledge they have totally consistently been ignoring this
>> invitation for over a year already so far.
>
> nVidia has been quite unhelpful, as I have understood they haven't helped
> anything with the nv driver (included in xorg/xfree) nor the new driver
> that will include 3D-support, compare with AMD (formerly ATi), who has
> given out information and code to the development of the xorg/xfree
> driver. They may even open up the code for the closed source driver.

That is indeed AMD's intent, or so I have read. And this could seriously
shift the balance in videocard sales too.

>> nVidia has always had better drivers than ATI, but with ATI now being
>> owned by AMD and AMD opening up the driver code - including for older ATI
>> chipsets - this balance may soon find itself radically tipped over to the
>> ATI camp, and in that case, I will come to seriously regret that I opted
>> for an nVidia adapter and their proprietary drivers in the first place,
>> being a Free Software advocate myself.
>
> Yes, during the old ATi times I think there was kind of a small handful
> part time developers who worked with the driver, while there was closer to
> 100 people at nVidia who worked with the nVidia driver.

You can expect to see a major shift there once the code gets opened up to
the public. As good as proprietary nVidia drivers may be, they still do
contain some serious bugs, and the opening up of the AMD/ATi driver code
will most definitely yield far superior drivers. Hopefully, this will turn
out to be the lesson that nVidia needs to learn... :-/

> I have been using nVidia for the most of my x86 based machines, as the
> driver is better, but on all my other machines (Sparc and PowerPC), there
> hasn't been any support and nVidia dropped the PowerPC project when Apple
> dropped the PowerPC as the CPU in Macs, so I have gone with ATi cards on
> those, getting a soso hardware 3D support from the open source drivers.

With AMD now releasing their driver code as Open Source - including for
older ATi cards, or so they promised us - your 3D hardware acceleration
will gain a tremendous boost. You'll go straight from barely usable to
high end performance. ;-)

>> (My motherboard has an nForce Professional chipset, but the specs for
>> those are open.)
>
> The forcedeth was developed without any help from nVidia, but nVidia did
> drop their own network driver when they thought the forcedeth driver was
> good enough. IMHO they haven't contributed much, they could do a lot more,
> but I guess they feel they are big enough to not care about 5% of the user
> market.

Indeed, they are behaving like monopolists on account of their drivers.
Inevitably, proprietary source code will run into a wall, when time and
time again it becomes proved that the open source development model yields
more performant and less buggy code. More and more hardware vendors are
turning to GPL'ed software as the firmware for their devices, even now with
the stricter GPLv3 already in effect - the Linux kernel will of course
continue to be released under GPLv2 due to Linus's objections to v3.

>> Certain ports will have to be forwarded to designated virtual machines -
>> I will be running three or four of them, including /dom0/ - such as port
>> 22 for /ssh,/ port 80 for /http,/ the port range between 6660 and 6669
>> for an IRC server - there will also be additional needed ports for this
>> but I don't know them from memory right now - and then most of the
>> userspace ports will have to be forwarded to the X11 /domU/ machine.
>
> I would suggest you to not use the port 22 for ssh, while I did I had damn
> a lot of script kiddies trying to force them into my system using, even if
> it wasn't working, I didn't like the long log reports I had about these
> tries, so I switched to an alternative port.

Indeed, using non-standard ports for /ssh/ is something I'm already quite
accustomed to by now, even if only because it started out as a way to
circumvent my ISP's restrictions - they disallow access to ports beneath
1024 for end-users, although - as I've discovered only recently - this does
not apply to access to those ports from a machine within their own IP
range. In other words, if my next door neighbor is with the same ISP as I
am, then he could log into my system via /ssh/ (on the standard port),
provided that he knows my IP address and has a user account on my machine.

I do however plan to switch my ISP contract once the new machine is
installed. I'll be staying with the same ISP - out of necessity, as I'm on
cable internet and they have the monopoly on that over here - but I'll be
switching over to a professional-grade contract. Instead of two
semi-dynamic IP addresses I will now have one static IP address and twice
the download speed, plus much broader traffic quota. My upload speed will
unfortunately not go up, while they're planning on doubling the upload
speed for regular consumergrade connections during the first quarter of
this year. :-/

Another advice I offer to everyone - and which I've been implementing on my
own machines for years already as well - is to disable all root logins,
whether directly to the console or via /ssh./ Even though it is possible
to change the name for the root account, root is the login known to exist
on basically every UNIX-style machine, and thus the target login for brute
force break-in attempts. Likewise for /ftp/ and likewise all possible
Administrator logins on MS Glassware - as we've come to see for ourselves
from our logs; we don't use Windows on our servers and I don't Windows at
all on any of my machines.

Single user mode should be set up to require the root password, and the
bootloader should be password-protected for booting anything other than the
default. All static filesystems should be split off from the root
filesystem and mounted read-only. For myself, I also plan on setting up
the root filesystems themselves as read-only. Dynamic subtrees such as
*/var* and */tmp* should also be split off from the root filesystem - I
recommend /tmpfs/ for */tmp* - leaving the root filesystem itself to be as
small as possible. I even intend to split off */root* and have that
mounted read/write. As long as the directory exists, there shouldn't be
any problem for emergency scenarios. And well, if it doesn't, then the
root user's home directory will default to the root directory itself, so
it's still not a real problem.

(This machine here does have Windows on it (installed as a dualboot) but
that's because it was intended for my at-the-time fiancée, and the
engagement was broken off so it's uselessly consuming diskspace right now.
It'll be wiped clean upon the next install, which will in turn only be
after my new machine is installed. Until then, I need this machine here
for my daily work and I can't afford any downtime.)

>> I'm sure it'll all be quite easy to accomplish for someone experienced
>> in /iptables,/ but unfortunately I consider myself quite a novice in that
>> area as I have thusfar always relied upon GUI utilities such as /webmin/
>> for this purpose. :-/
>
> As long as you manage to get things to run on virtual NICs, the NATing
> will be the easy part, you will just to follow one of the many HOWTOs you
> can find at the net.

Yeah, I've already bookmarked a few HowTos. ;-)

>>> One of the disadvantages I see is the high load on the domU while making
>>> disk access, even if you have dedicated slices for them. I have been
>>> thinking of testing KVM instead and see if it's kinder on the load or
>>> not, but been too busy with other things.
>>
>> The above said, I doubt that the load inside /dom0/ - you wrote /domU/
>> but I take it you mean /dom0/ instead? - would really differ a lot when
>> using KVM rather than Xen. It is after all virtualization, which means
>> that there are multiple operating systems, each with their respective I/O
>> requirements, trying to access the same hardware simultaneously. So I
>> think the phenomenon is rather indigenous to the concept of
>> virtualization itself rather than to the virtualization technology used.
>
> No, I mean domU, the dom= has a low load.
> The test I made was setting up 3 domU running Apache and making approx
> 10000 request per sec per domU.
>
> With diskimage on file the load on each domU was up on 2.8, while dom0 was
> at 0.3.
>
> With dedicated slices the load on each domU was up on 0.9 while dom0 was
> at 0.2.
>
> Doing the same kind of attack on the dom0 don't result in much higher load
> than 0.15 (if I remember it right)
>
> This high difference in loads will it make difficult with rules that
> prevents high loads.

Having each of the nodes in /domU/ access its own slice is always
recommended over having file-backed filesystems in /dom0./ That's also why
UNIX systems traditionally prefer a dedicated swap partition over a
swapfile. Many people prefer using image files for simplicity, but there's
a definite tradeoff in performance.

>> By the way, I do indeed intend to give each operating system instance its
>> own dedicated slices where possible/needed and use NFS where otherwise
>> possible/recommended.
>
> If you want read only access, then NFS has the advantage that it's the
> server that decides if the client has read/write access or not, while a
> dedicated slice can always be remounted as read/write. But usually a local
> hard drive is faster.

Well, Xen also allows for a filesystem to be defined as read-only from
within /dom0,/ because the idea is that you present filesystems and/or
image files as block devices to /domU./ The configuration file makes you
specify whether the abstracted block device should be read-only or
read/write. ;-)

>> Ergo, I will have to set up LVM(2) slices instead, which I've only done
>> once before so far, but which also seems like a very interesting
>> technology to me. I do wonder as to how much this extra level of
>> hardware abstraction will impede on performance, though.
>
> I have to say I haven't noticed any downside with my LVM that I share over
> NFS to all my machines (just a small 500G /home).

Oh, that is good to know. ;-)

> I read a bit about zfs and it seems interesting, but I don't want it as a
> userspace file system, which is what you get in Linux today.

I haven't checked out /zfs/ yet, and quite frankly, I don't even know what
it's all about. I'll have to look into it later, but I intend to be
using /XFS/ as the filesystem on all my slices. The machine is hooked up
to two UPS'es (in series) and the RAID controller has a battery-backed
cache, so I should be safe there. ;-)

>> Of course, in a virtualization environment where you have several virtual
>> machines running quite dedicated server tasks, your partitioning layout
>> may not need to be all that elaborate. There's a huge chance that */opt*
>> and */usr/local* - which I normally also split off from */usr* - will be
>> empty anyway. */usr/src* and */usr/portage* can be shared via NFS.
>> */tmp* can be a /tmpfs./ */usr* itself could even be shared over NFS in
>> its entirety between minimally installed server VMs. */boot* is unneeded
>> by any virtual machine other than /dom0,/ et al.
>
> I never split out /usr/local, as it's always been more or less empty on
> all my installs, /usr/src I did split out when I went to Gentoo. I try to
> split out those parts where you have a lot of writes, as I see it more
> likely that something will go wrong there and don't want it to affect the
> more static parts of the file system.

That is indeed the right idea. Lots of people recommend the very basic
partitioning layout to beginners, and it may indeed be the simplest thing
to do for a first-time install, so as to familiarize oneself with the world
of GNU/Linux, but I always do recommend split-offs, with the proper
explanations as to why it's better.

>> I'm not sure whether such an approach is already possible with KVM - I
>> haven't exactly kept track of the KVM development itself in favor of my
>> interest in Xen and KVM still being rough around the edges - as I seem to
>> recall that KVM requires modified Qemu images to work with. Personally I
>> favor individual and independent slices rather than disk images mounted
>> over a loopback mechanism, but your mileage may of course vary.
>
> I do agree on that too. I think KVM can access file systems via userspace,
> haven't kept so much track about KVM nor Xen, just looked a couple of
> months ago at the wikipedia where they compared a load of different
> virtualization, where KVM was on top when it came to smoth file I/O.

Well, I'm not sure what would happen if an nVidia driver goes berserk again
- as it often does here, causing X11 to freeze and garbling up the display
once I've killed X11 via the System Request keys, requiring a complete
reboot before you can see anything on the screen again - inside a virtual
machine running via KVM. I also have no idea of whether the nVidia driver
will even _work_ inside a KVM virtual machine.

I do know that the open source X.Org/XFree86 /nv/ driver has no problems
with virtualization, but then again, you lose hardware accelerated 3D
performance. :-/

>> On account of KVM, I'm also not sure on the status of SMP guests yet - in
>> theory, it /should/ be possible by now - nor on the use of 64-bit
>> guests.
>
> As I have understood, you don't dedicate CPUs in KVM, but each "node" will
> get the required CPU usage to do it's work.

Well, I don't really plan on dedicating CPUs to virtual machines - I do
however plan on restricting the amount of usable physical CPUs to at least
one of the virtual machines - but what I really meant was that in its early
stages, KVM could not use SMP guests. I know the kernel developers have
been working on that a lot in the meantime, but I haven't really monitored
their progress on the subject as I've been mainly concentrating on Xen as
my virtualization solution. ;-)

--
Aragorn
(registered GNU/Linux user #223157)

Aragorn wrote:
> J.O. Aho wrote:

>> I never split out /usr/local, as it's always been more or less empty on
>> all my installs, /usr/src I did split out when I went to Gentoo. I try to
>> split out those parts where you have a lot of writes, as I see it more
>> likely that something will go wrong there and don't want it to affect the
>> more static parts of the file system.
> That is indeed the right idea. Lots of people recommend the very basic
> partitioning layout to beginners, and it may indeed be the simplest thing
> to do for a first-time install, so as to familiarize oneself with the world
> of GNU/Linux, but I always do recommend split-offs, with the proper
> explanations as to why it's better.

I agree, but you see how distributions and users tries to copy things from
microsoft and apple and those don't split up things. Yes, it may be really
easy to setup things the first time, but quite many of the newer Linux users I
have seen haven't been keen on experimenting, they just been happy with what
they got, so they will keep on having one slice for everything and make a full
reinstall if something would go wrong when they install a new program.

Back in the days when I installed NetBSD on my Amiga 2000, you had to read a
bit of documentation before you managed to install it and I think thats a good
thing, as you get some understanding of the system you are using.


>> I do agree on that too. I think KVM can access file systems via userspace,
>> haven't kept so much track about KVM nor Xen, just looked a couple of
>> months ago at the wikipedia where they compared a load of different
>> virtualization, where KVM was on top when it came to smoth file I/O.
>
> Well, I'm not sure what would happen if an nVidia driver goes berserk again
> - as it often does here, causing X11 to freeze and garbling up the display
> once I've killed X11 via the System Request keys, requiring a complete
> reboot before you can see anything on the screen again - inside a virtual
> machine running via KVM. I also have no idea of whether the nVidia driver
> will even _work_ inside a KVM virtual machine.

The testing I have been doing with has involved just a simple cluster of
virtualized web servers, so haven't had any need of Xorg.


--

//Aho

J.O. Aho wrote:

> Aragorn wrote:
>
>> That is indeed the right idea. Lots of people recommend the very basic
>> partitioning layout to beginners, and it may indeed be the simplest thing
>> to do for a first-time install, so as to familiarize oneself with the
>> world of GNU/Linux, but I always do recommend split-offs, with the proper
>> explanations as to why it's better.
>
> I agree, but you see how distributions and users tries to copy things from
> microsoft and apple and those don't split up things.

Unfortunately, yes... It would seem that people have a tendency to learn
from the wrong examples... :-/

> Yes, it may be really easy to setup things the first time, but quite many
> of the newer Linux users I have seen haven't been keen on experimenting,
> they just been happy with what they got, so they will keep on having one
> slice for everything and make a full reinstall if something would go wrong
> when they install a new program.

And they will reboot without a reason, insist on installing a firewall for
consumergrade internet connections and desperately go looking for antivirus
software that runs on GNU/Linux - and of which they don't realize that it's
intended to scan for *Windows* viruses... :-/

> Back in the days when I installed NetBSD on my Amiga 2000, you had to read
> a bit of documentation before you managed to install it and I think thats
> a good thing, as you get some understanding of the system you are using.

My actual computing experiences started off before I had a computer of my
own, and back then the commonplace OS was DOS 3.30. My very own first PC
came with DOS 5.0 and Windows 3.0, but I only used that for about 6 months,
until 32-bit OS/2 became available for retail purchase. I then used OS/2
2.0 and 2.1 for 5 years.

Then I needed a new machine and I had already planned on switching to a
UNIX-style OS, but I had no internet connection at home, GNU/Linux was
still pretty much obscure to me, proprietary UNIX cost you an arm and a leg
and I had never heard of /Wine/ before, so whereas all of my friends ran
Windows 95, I chose a compromise solution and went for NT 4.0 Workstation.
I used that for two years, and then I discovered GNU/Linux via an article
in a computer magazine and a coincidental discovery of the tested
distributions from the magazine on the shelves of a software shop two weeks
later.

I selected Mandrake 6.0 PowerPack from the offer and used it in dualboot
with NT for about a month. Then it was January 1st 2000 and despite all
the Service Packs and Y2K updates, NT refused to boot. I was frustrated
because I had paid big money for that NT license, but in the month that I
had a dualboot - and in which I was not using my computer every day yet - I
had already found myself using GNU/Linux a lot more than I did NT.

GNU/Linux represented the UNIX-style OS that I had been wanting for years
already, and the GPL had won me over right away. I found that I really
only needed one operating system and that in the event of compatibility
problems, those would be the problems of the people choosing to use
proprietary software with proprietary document formats - not that
StarOffice couldn't open MS Office documents ;-) - and not mine. So my
choice was easily made. I've been using GNU/Linux exclusively since then.

The first thing I did before installing Mandrake 6.0 was read the manuals
that came in the box. And then when I had installed it, I checked out the
HowTos, and then the /man/ pages. I had no problem adjusting, but I do
confess that I had already read a book on (older) UNIX and that I already
had some minor unprivileged-user-level experience with UNIX, both from work
and from College, where we used UNIX terminals to write COBOL programs. ;-)

>> Well, I'm not sure what would happen if an nVidia driver goes berserk
>> again - as it often does here, causing X11 to freeze and garbling up the
>> display once I've killed X11 via the System Request keys, requiring a
>> complete reboot before you can see anything on the screen again - inside
>> a virtual
>> machine running via KVM. I also have no idea of whether the nVidia
>> driver will even _work_ inside a KVM virtual machine.
>
> The testing I have been doing with has involved just a simple cluster of
> virtualized web servers, so haven't had any need of Xorg.

Well, I do intend to have one virtual machine set up as a powerful
workstation, so it does matter to me. ;-)

--
Aragorn
(registered GNU/Linux user #223157)

Aragorn wrote:
> J.O. Aho wrote:

> And they will reboot without a reason, insist on installing a firewall for
> consumergrade internet connections and desperately go looking for antivirus
> software that runs on GNU/Linux - and of which they don't realize that it's
> intended to scan for *Windows* viruses... :-/

Don't forget that they have the urge to defragmentate the hard drives too,
they seem to be obsessed by it.


>> Back in the days when I installed NetBSD on my Amiga 2000, you had to read
>> a bit of documentation before you managed to install it and I think thats
>> a good thing, as you get some understanding of the system you are using.
>
> My actual computing experiences started off before I had a computer of my
> own, and back then the commonplace OS was DOS 3.30. My very own first PC
> came with DOS 5.0 and Windows 3.0, but I only used that for about 6 months,
> until 32-bit OS/2 became available for retail purchase. I then used OS/2
> 2.0 and 2.1 for 5 years.

I begun with a VIC20 back in the early 80's, not that much more than playing
games, but some simple programs in BASIC. Upgraded within the Commodore
product family, all the way up to Amiga 1200. In the mid 90's tested NetBSD on
the Amiga 2000, as I wanted to have something similar to what I had at
university, where all computers had SunOS. Wasn't until late 90's that I got
my first IBM compatible PC, running microsoft98, which had a load of frequent
blue screens when ever you the least wanted them, so decided to try out RedHat
6.0. The computer got a lot more stable, never even bothered to set up a dual
boot, Linux had all I needed and it was similar to SunOS/NetBSD from user
point of view.
Got a bit sad on RedHat when they released 8.0, it was buggy and ugly with
that crappy gnome2 (got anti-alias work a lot better in Gnome that it ever
done in gnome2), so I stayed with my RH7.3, upgraded it heavily, GCC3,
GLIBC2.3, KERNEL2.6 and even gnome2-libs. But it was a heck of a lot of work
to keep the system up to date after EOL for RH7.3, after a year I got a bit
tired of making my own RPMs and checking for bugs/security-holes, so switched
to another distro that gave me some freedom and had to switch to KDE as
support for gnome had more or less been dropped in every distro.


--

//Aho

Alex Buell wrote:

> On Tue, 08 Jan 2008 15:28:05 GMT, I waved a wand and this message
> magically appears in front of Aragorn:
>
>> > Thank goodness for x-chat - free if you can compile it!
>>
>> I wholeheartedly recommend KVIrc. ;-) I've been using it for 7 years
>> already - ever since version 0.9 or so. ;-)
>>
>> It's free - both as in "free beer" and as in "free speech" - and
>> while it's extremely userfriendly, it's also extremely powerful due
>> to its built-in scripting language. As a NetAdmin on an IRC network,
>> I heavily rely on it. ;-) It also accepts Perl or Python, I think.
>
> I've also used Bitch-X - just as good if console only.

Indeed, I've also used BitchX at a time when I had a machine that couldn't
start X (due some serious hardware flaws), and I still use it (and
sometimes XChat) every once in a while for testing things from the point of
view of an unprivileged user connection. ;-)

--
Aragorn
(registered GNU/Linux user #223157)

J.O. Aho wrote:

> Alex Buell wrote:
>> On Tue, 08 Jan 2008 11:26:27 GMT, I waved a wand and this message
>> magically appears in front of Aragorn:
>>
>>> mIRC
>>
>> Thank goodness for x-chat - free if you can compile it!
>
> I prefer AmIRC, the best GUI based IRC client I have used, which that it
> could be ported to Linux too (sadly closed source).

I've never heard of AmIRC, but KVIrc is also GUI-based. It uses Qt for the
widgets, and it's extremely customizable and scriptable, Ã*nd it's Free
Software (GPL). ;-)

--
Aragorn
(registered GNU/Linux user #223157)

Aragorn wrote:
> J.O. Aho wrote:
>
>> Alex Buell wrote:
>>> On Tue, 08 Jan 2008 11:26:27 GMT, I waved a wand and this message
>>> magically appears in front of Aragorn:
>>>
>>>> mIRC
>>> Thank goodness for x-chat - free if you can compile it!
>> I prefer AmIRC, the best GUI based IRC client I have used, which that it
>> could be ported to Linux too (sadly closed source).
>
> I've never heard of AmIRC, but KVIrc is also GUI-based. It uses Qt for the
> widgets, and it's extremely customizable and scriptable, ànd it's Free
> Software (GPL). ;-)
>

AmIRC uses MUI, not greatest looking always, but works well.
http://www.vapor.com/amirc/

Requires: MorphOS or AmigaOS (can be used with UAE of course).

--

//Aho

De Vliegende Hollander wrote:

> The sentient life form Aragorn posted the following:
>
>> Arthur Hagen wrote:
>>
>>> singsingchow <singsingchow@gmail.com> wrote:
>>>
>>>> It's 2008 now.
>>>
>>> I'm sure they'll let you know in the GWN (Gentoo Weekly Newsletter)...
>>
>> I'm afraid there hasn't been any GWN anymore since October 15th 2007, nor
>> has the news section of the Gentoo website been updated since. :-/
>
> Worrying that is! Hope not a prelude to 'The End Of Gentoo' ®, this is...

First of all, I apologize is the following message might come across as a
trolling attempt. I assure everyone that this is certainly not my intent,
and those who know me well enough know that I'm certainly not a troll.

However, as I have been suspecting, there are some serious problems over at
the Gentoo Foundation, and the following article on SlashDot clearly
illustrates this, which is why I've decided to post a followup here...

http://linux.slashdot.org/firehose.pl?op=view&id=463482

<quote>

Gentoo Linux founder Daniel Robbins says Gentoo's leadership is
in crisis: "the Gentoo Foundation's charter has been revoked for
several weeks, which means that as of this moment the Gentoo
Foundation no longer exists." Robbins offers a solution: his return
as President of the Gentoo Foundation. According to Robbins: "If I
return as President, I will preserve the not-for-profit aspect of
Gentoo. Beyond this, you can expect everything to be very, very different
than how things are today."

</quote>

Daniel Robbins's full statement can be read here...:

http://blog.funtoo.org/

That which I find most worrysome are the words "...which means that as of
this moment, the Gentoo Foundation no longer exists." I really hope they
get their act together soon, and although I have some personal reservations
against Daniel Robbins over his previous employment at Microsoft's Linux
Lab - I can understand that a man needs to feed his family, but to go and
work for the enemy of all things Free and Open? - he is still the guy who
took the Gentoo initiative in the first place and who might therefore also
be the right person to bring Gentoo back on track with what it used to be -
the decisionmaking of the Gentoo Foundation's leadership over the last
couple of years has really left a lot to be desired, in my humble and
personal opinion. :-/

--
Aragorn
(registered GNU/Linux user #223157)