Oh, I'm not trying to argue anything else out there is better than ESXi, far from it. Just making the point that your original post was a bit lacking in accuracy.
Thing is, neither Xen nor KVM/QEMU are as capable as VMware for the things that VMware is good at. For example, it's typical in the VMware world to create a VMFS volume on an EMC block storage server and use this for virtual machine migration between physical hosts. This works because VMFS is a clustered file system that has some unique attributes that make it good for hosting virtual disk files (it's extent-based, for example, so it will keep the extents of a virtual disk contiguous, meaning that the elevator algorithm for disk management inside your VM actually works and you get close to real-world disk performance). Migrating a virtual machine is literally as easy as stopping it on host A and starting it on host B. I can't do anything of the sort with Xen or KVM/QEMU. Then there's VCenter, which provides a central GUI to manage an entire network's worth of virtual machines.
I don't know if you're just explaining this horrendously badly, or you really don't understand, but live migrations don't require stopping a VM to move it.
Xen has supported live migration for at least the last five years, I used to do it all the time on our home-rolled Xen clusters (before we migrated to VMware). I assume KVM does too, but I've never used it.
Don't get me wrong, I despise VSphere. I curse it every time I use it, and I've attempted a Xen or KVM/QEMU migration multiple times to get away from it. I had hoped that the release of Red Hat Enterprise Linux 5 with its fairly up-to-date KVM support, GFS cluster filesystem support, etc., could allow me to replace VSphere in our shop. Unfortunately to get adequate disk performance I ended up having to create LVM volumes to use as VM raw disks, qcow2 on top of any currently-existing Linux filesystem is a disaster. And once you're in the realm of LVM volumes, you're beyond any management tools available for managing KVM - not to mention that the way Linux volume groups currently work, you can't share the same volume group between multiple hosts because Things Go Badly, meaning you can't do the trick that VMware uses to do rapid migration via simply turning off the VM on system A and turning it back on, on system B. (There's some state storage required to do it seamlessly, but again, that's all handled by the shared storage).
I agree the management tools - particularly the "default" ones - are atrociously bad on Linux (and this is true pretty much across the board, not just for virtualisation). However, it is quite possible to share a VG across multiple Linux hosts (again, did it for years) using Clustered LVM. With that said, when clvm falls over, it falls over *hard* and usually requires rebooting hosts to recover (assuming it doesn't reboot them for your).
It is not inconceivable that the US will elect Big Brother bread-and-circuses socialists who model their ideas on the surveillance state of Britain, or religious whack-jobs who will simply say "God's law is higher than Man's law" and start criminalizing homosexuality, abortion, titty-pictures and religions that aren't Christian, or frothing-at-the-mouth Greenies who formalize in law the already-existing mapping of "skeptic" to "heretic".
Well, the first and last options are pretty close to inconceivable, at least for the America I lived in.
The second option, however, seems nearly inevitable.
To own a.22 target pistol, you need to spend about $5000 in total. Not for the pistol, no, that's cheap, but for the gun safe, the club membership etc etc etc.
I don't have a problem with guns. Indeed, I go skeet shooting with friends reasonably regularly.
However, I have to say I have _zero_ problems with laws requiring the safe storage of guns and at least some token gestures towards ensuring people are competent in their handling. Neither do any of my gun-toting mates I mooch shootin' time off.
I lived in the USA for a while, in Arizona, where it's not uncommon to see people wandering around with guns on them. Used to make me nervous - not because I was worried about someone going postal, but because I was worried about someone accidentally letting off a few rounds. Not to mention the potential for a simple verbal confrontation to escalate into gunfire.
I'll also throw a thanks out there for creating Slashdot. There have been very few sites I have visited - and participated in - more over the ~20 years I've been on the 'net.
Sure we are exempt. Set up the new box in DNS and DHCP server. 10 minutes to install a generic Debian base system using the default images, off a PXE boot. "apt-get install puppet" on the new machine. Configure puppet on the host to describe what the new machine should have:
Ie: just like Windows machines and properly configured Group Policies, SCCM, etc.
It's funny you bring up centralised configuration management when the tools available for it in the Unix world are - while potentially very comprehensive - horrendously awful to use.
Some people like to have complete access to their filesystem and not be hindered by their OS babysitting them [...]
I see. Do you feel equally "hindered" by memory protection and pre-emptive multitasking ?
[...] or worse replacing the missing file later without their authorization.
No file is going to get replaced without your authorisation.
On atleast two occasions I've had to overwrite cp and mv to fix an issue with compiling. Had I been dealing with a microsoft OS I would have needed to jump through a ton of hoops to do something similar if not boot to entirely different OS and do it from there.
Indeed. Such crazy "hoops" as creating a second copy of the cp or mv executables and using those to overwrite the originals. Mind-bending stuff.
A similar situation is organ harvesting. Society throughout most of the world has chosen to ban the selling of organs from humans even though implementing the practice would probably save thousands of people a year.
Somehow I think if we could grow an effectively infinite number of organs on demand, without any risk to "donors", organ harvesting would become unbanned pretty quickly.
I think that Amazon, Google, and Apple would all disagree with you.
Most companies are not Amazon, Google or Apple.
Further, even within those highly technology-driven companies, there are undoubtedly large sections of their IT departments which are nothing more than a cost centre. Indeed, I wouldn't be surprised if their internal organisational structure separated out the "product" IT from the "cost centre" IT.
You have the same "issues" when you are using any block device that isn't a simple, single physical device (eg: RAID, LVM, most SAN disk, most NAS disk). Heck, it's not true even for lots of single devices these days (SSDs, 4k drives masquerading as 512b drives, etc).
Businesses buy Intel, but they buy them in machines assembled by Dell et al. Building your own business machine hasn't made sense for a long time now, IMHO.
Yeah. Right up until the point you actually assess the costs of assembly and ongoing hardware maintenance.
Heck, I'm fairly indifferent towards Apple and even I can think of over half a dozen things that make a contemporary Macbook better than a four year old PC laptop. Your example stinks of the stupid.
For one thing, I don't think the article mentioned consumer drives specifically. These standards are just as applicable for servers - and for servers, the faster the drive, the better. Arguing that these SSDs are "fast enough" for servers is ludicrous - you can never have too much speed in your servers.
The article may not have specified consumer PCs, but the person I responded to did explicitly say "ordinary PCs". Though even most servers would not benefit from >600MB/sec per disk device. Heck, most of them wouldn't see any benefit from >150MB/sec, since individual drives that can exceed this outside of corner cases are still relatively uncommon, and there's generally not anything capable of *consuming* the data any faster.
But I'll give you an example of large datasets that a consumer (me) would use these types of speed for, on a daily basis: I download large HD video files from newsgroups, and the program first has to assemble the posts into RAR files, then check the files for corruption, then assemble and unpack them. These files can be 10's of GB, and all the above processes are very I/O bound. If I could run them on an SSD, they would complete in a fraction of the time, which means I could download even more.
Somehow I doubt the speed at which you can reassemble your movies is limiting how fast you can download. Unless you're mainlined into your Usenet server at a gigabit.
Also, your ability to reassemble - even with an SSD - is going to be limited by the write performance, which still isn't going to exceed 6GB/sec for any long period of time.
Installing an OS is also very dependent on the speed of your drive. If you can reinstall your OS in 12 minutes (that's how long it took with my SSD to install Windows 7) vs 45 minutes with a hard drive, that's a big gain. If you're a member of your IT department cloning a bunch of computers, that's a huge increase in your productivity.
Again, the limiting aspect there is the internal performance of the disk device itself, not its connection to the rest of the system.
Does my mother need such a fast SSD drive in her computer? No, of course not, she'd be fine with a slow SSD like you describe. But not every consumer wants "good enough" in their computers - that's why we have a range of options and enthusiast parts. I, for one, will choose the faster drive. I won't always use the increased speed, but when I need it I will sure appreciate it.
I'd be pretty confident in predicting even with the fastest SSDs today or within the next few years, you wouldn't be meaningfully constrained by a 600MB/sec per device limit for anything close to normal usage.
Let me introduce you to my music collection when I transfer it from one drive to another.
Right. What are you copying *to* ?
You are arguing, continually, from your own little point of view and applying it to everyone, saying that you are a typical user. What utter nonsense, and what hubris. You are also arguing from incredulity.
Actually, no, I haven't said anything about my needs, wants, behaviour, or anything else. I've just made the point that 600MB/sec *per device* is a phenomenal amount of data, and it's very hard to see anything in the "ordinary PC" space that would benefit in the slightest from greater speed.
Heck, even most servers would rarely see sustained disk performance past 100-200MB/sec.
Both of these would exceed the 100MB/s ATA link mentioned, and NEITHER of these are using my SSDs which are many times faster.
Your second example is clearly using a RAID array, so the first probably is as well.
Not only is this far from an "ordinary PC", but only at the very upper end (220MB/sec) *might* it really become limiting, because that 100MB/sec is per device.
Not to mention, it's still far away from the 300MB/sec of SATA2, and not within a bull's roar of the 600MB/sec of SATA3.
So all your applications are so small that they're loaded into RAM instantly just as soon as the access time (I'm assuming that's the latency you're talking about) has elapsed?
They're certainly small enough that the difference between 600MB/sec (or even 100MB/sec) and anything faster is irrelevant.
I dunno, when I load $BigProgram, my laptop sure seems to read a lot of stuff off of the hard drive and write it into RAM...;)
Well, get an SSD drive and you'll see a big difference.
Newer versions of Windows actually make this pretty easy to examine. Just fire up the "Resource Monitor" and do some stuff. If the graph for "Disk IO" isn't frequently bumping up against 150MB/sec, you wouldn't even be slowed down by SATA1.
Anyone who has more than 1 hard drive will notice.
Won't matter. SATA bandwidth limits are per device.
Having to ensure my hard drive and CD burner were on different cable to ensure that a consistent stream could be maintained sounds like a need for a higher speed link, note I said cd burner not dvd.
It's not the 1990s, and we'not dealing with ATA any more. Even if we were, the problem wasn't that the link was fast enough, it was that the protocol didn't allow two devices on the same cable to be active at the same time. A SCSI interface from the same era (and of slower performance) than ATA100 could daisychain half a dozen CD burners and still work.
Until static storage (HDD, SSD, whatever) is as fast to access as main system memory, it's not fast enough. I am not sure why this is hard to understand.
It's not at all hard for me to understand. I'm not even disagreeing.
The purpose of a tool is to make operations more efficient. The less time taken, the more (time) efficient the process. If you're not trading anything for that efficiency gain, why would you not take it?
My point is it's unlikely there's any operations on "the ordinary PC" that are coming anywhere close to the limits imposed by SATA3 (or SATA1, for that matter), so there's not going to be any gain from making it faster.
I hit it all the time on both my home machine and work machine. Copying large files (video), doing subversion updates, or dropbox scans/indexes, rebooting, etc etc
I sincerely doubt you're hitting the limits of the SATA interface doing that. Especially since a lot of the operations you mentioned are random access, you'll never even get close to streaming performance with them.
You might be hitting the limits of how fast the mechanical disk can deliver data to the interface. It's highly unlike you're hitting any limits of the interface.
But obviously you haven't done performance testing on SSDs.
Yes, I have.
That's what you're not getting. It's not just seek time difference, an SSD behaves as if it has a cache the same size as the disk itself.
I get it just fine. The point you seem to be missing is if there's nothing on the other end actually demanding all that data, then the fact so much of it can be delivered is irrelevant. The other part of that point is, that outside of benchmarks, there are very few (if any) tasks on the ordinary PC that demand data transfers that fast, for long enough to matter.
Slashdot Mirror
Oh, I'm not trying to argue anything else out there is better than ESXi, far from it. Just making the point that your original post was a bit lacking in accuracy.
I don't know if you're just explaining this horrendously badly, or you really don't understand, but live migrations don't require stopping a VM to move it.
Xen has supported live migration for at least the last five years, I used to do it all the time on our home-rolled Xen clusters (before we migrated to VMware). I assume KVM does too, but I've never used it.
I agree the management tools - particularly the "default" ones - are atrociously bad on Linux (and this is true pretty much across the board, not just for virtualisation). However, it is quite possible to share a VG across multiple Linux hosts (again, did it for years) using Clustered LVM. With that said, when clvm falls over, it falls over *hard* and usually requires rebooting hosts to recover (assuming it doesn't reboot them for your).
Well, the first and last options are pretty close to inconceivable, at least for the America I lived in.
The second option, however, seems nearly inevitable.
I don't have a problem with guns. Indeed, I go skeet shooting with friends reasonably regularly.
However, I have to say I have _zero_ problems with laws requiring the safe storage of guns and at least some token gestures towards ensuring people are competent in their handling. Neither do any of my gun-toting mates I mooch shootin' time off.
I lived in the USA for a while, in Arizona, where it's not uncommon to see people wandering around with guns on them. Used to make me nervous - not because I was worried about someone going postal, but because I was worried about someone accidentally letting off a few rounds. Not to mention the potential for a simple verbal confrontation to escalate into gunfire.
I'll also throw a thanks out there for creating Slashdot. There have been very few sites I have visited - and participated in - more over the ~20 years I've been on the 'net.
Ie: just like Windows machines and properly configured Group Policies, SCCM, etc.
It's funny you bring up centralised configuration management when the tools available for it in the Unix world are - while potentially very comprehensive - horrendously awful to use.
I see. Do you feel equally "hindered" by memory protection and pre-emptive multitasking ?
No file is going to get replaced without your authorisation.
Indeed. Such crazy "hoops" as creating a second copy of the cp or mv executables and using those to overwrite the originals. Mind-bending stuff.
Can you expand on the technique you might use to replace rm with rm ?
You don't need to reboot to replace open files in Windows, either, you just need to close whatever it is that has them open.
Somehow I think if we could grow an effectively infinite number of organs on demand, without any risk to "donors", organ harvesting would become unbanned pretty quickly.
Why is it any more creepy than an organ transplant ?
Most companies are not Amazon, Google or Apple.
Further, even within those highly technology-driven companies, there are undoubtedly large sections of their IT departments which are nothing more than a cost centre. Indeed, I wouldn't be surprised if their internal organisational structure separated out the "product" IT from the "cost centre" IT.
You have the same "issues" when you are using any block device that isn't a simple, single physical device (eg: RAID, LVM, most SAN disk, most NAS disk). Heck, it's not true even for lots of single devices these days (SSDs, 4k drives masquerading as 512b drives, etc).
Yeah. Right up until the point you actually assess the costs of assembly and ongoing hardware maintenance.
It doesn't really matter. If someone induces someone else to commit a crime for any reason, is that fact of inducement a defense ?
But DUI without causing an accident isn't a harmful action.
I can't think of any applications I have that want to load up 500MB of data at startup.
Processor power, RAM capacity, GPU performance. size, weight, battery life, connectivity, support.
Heck, I'm fairly indifferent towards Apple and even I can think of over half a dozen things that make a contemporary Macbook better than a four year old PC laptop. Your example stinks of the stupid.
The article may not have specified consumer PCs, but the person I responded to did explicitly say "ordinary PCs". Though even most servers would not benefit from >600MB/sec per disk device. Heck, most of them wouldn't see any benefit from >150MB/sec, since individual drives that can exceed this outside of corner cases are still relatively uncommon, and there's generally not anything capable of *consuming* the data any faster.
Somehow I doubt the speed at which you can reassemble your movies is limiting how fast you can download. Unless you're mainlined into your Usenet server at a gigabit.
Also, your ability to reassemble - even with an SSD - is going to be limited by the write performance, which still isn't going to exceed 6GB/sec for any long period of time.
Again, the limiting aspect there is the internal performance of the disk device itself, not its connection to the rest of the system.
I'd be pretty confident in predicting even with the fastest SSDs today or within the next few years, you wouldn't be meaningfully constrained by a 600MB/sec per device limit for anything close to normal usage.
Right. What are you copying *to* ?
Actually, no, I haven't said anything about my needs, wants, behaviour, or anything else. I've just made the point that 600MB/sec *per device* is a phenomenal amount of data, and it's very hard to see anything in the "ordinary PC" space that would benefit in the slightest from greater speed.
Heck, even most servers would rarely see sustained disk performance past 100-200MB/sec.
Your second example is clearly using a RAID array, so the first probably is as well.
Not only is this far from an "ordinary PC", but only at the very upper end (220MB/sec) *might* it really become limiting, because that 100MB/sec is per device.
Not to mention, it's still far away from the 300MB/sec of SATA2, and not within a bull's roar of the 600MB/sec of SATA3.
They're certainly small enough that the difference between 600MB/sec (or even 100MB/sec) and anything faster is irrelevant.
Well, get an SSD drive and you'll see a big difference.
Newer versions of Windows actually make this pretty easy to examine. Just fire up the "Resource Monitor" and do some stuff. If the graph for "Disk IO" isn't frequently bumping up against 150MB/sec, you wouldn't even be slowed down by SATA1.
Won't matter. SATA bandwidth limits are per device.
It's not the 1990s, and we'not dealing with ATA any more. Even if we were, the problem wasn't that the link was fast enough, it was that the protocol didn't allow two devices on the same cable to be active at the same time. A SCSI interface from the same era (and of slower performance) than ATA100 could daisychain half a dozen CD burners and still work.
It's not at all hard for me to understand. I'm not even disagreeing.
My point is it's unlikely there's any operations on "the ordinary PC" that are coming anywhere close to the limits imposed by SATA3 (or SATA1, for that matter), so there's not going to be any gain from making it faster.
I sincerely doubt you're hitting the limits of the SATA interface doing that. Especially since a lot of the operations you mentioned are random access, you'll never even get close to streaming performance with them.
You might be hitting the limits of how fast the mechanical disk can deliver data to the interface. It's highly unlike you're hitting any limits of the interface.
Yes, I have.
I get it just fine. The point you seem to be missing is if there's nothing on the other end actually demanding all that data, then the fact so much of it can be delivered is irrelevant. The other part of that point is, that outside of benchmarks, there are very few (if any) tasks on the ordinary PC that demand data transfers that fast, for long enough to matter.
Er, yes, in highly specific conditions.
Even today, you rarely see that sort of sustained performance from drives, even if they can sustain 150M/sec in benchmarks.
Having done a lot of performance profiling in my time, I think I've got a reasonable handle on disk bottlenecks. Bandwidth is rarely one of them.