"No-one's asked"
Translation - the ones who want it already know that it doesn't do it and bought something else that does.
Tens of thousands of words have already been written about Microsoft's purchase of Nokia, and as far as The Register can tell, none of them are getting read by the hordes of sysadmins and developers that descended on the Gold Coast for TechEd. Mergers and acquisitions aren't the sort of thing that gets an audience to interrupt …
I can't imagine needing a VM which has 64 vcpus, if I were needing a system with that kind of processing power, I would certainly be running it on the native hardware. As for using other products: I don't know about VMware 5.x, but in my last job we tried to get ESX 4.1 running some high transaction/processing systems with only four vcpus and it simply couldn't handle the IO requirements we had, even when virtualised at 1:1 physical:virtual.
I daresay Hyper-v will be able to support more than 64 vcpus per vm by the time anyone seriously needs it. 640K, may I remind you, was a physical architectural limit, we're talking about software here, it's much easier to change.
Can anyone actually point towards any use of a VM with more than 64 vcpus?
RDP doesnt use memory in the same way.
This example shares memory between VMs, pretty much ignoring the network and Terminal Services.
I work with RDP everyday and can tell you it takes an age at the best of times to copy anything more than text. This tech means you dont need to rely on the network so much, or all the other guff that goes along with RDP, such as the compressed stream of data that gives you the desktop etc.
I know I am a bit out of touch with Windows. Last time I used it, I complained that the middle mouse button did not work. It turned out, left-button-select and middle-button-paste was something Microsoft did not support. You had to use ^C and ^V or whatever key each application had assigned.
Any cut and paste between servers will be done via remote log in as they do not have mice or monitors. X has been doing that for two and a half decades. Even Linux consoles (graphics cards switched to text mode to conserve resources) support cut and paste between remote machines.
I would like to congratulate Windows users for reaching the twentieth century, but I am not sure if they all have three button mice yet.
This post has been deleted by its author
The UNIX way works pretty well.
You have 2 buffers.
Problem is modern day Loonix breaks it completely and doesn't use them in a consistent manner.
(Along with messing around with the way the keyboard is mapped instead of just having meta -> ctrl -> alt seperately).
I like focus follow mouse but the people coding Linux desktop apps don't seem to get that either.
I use the keyboard for copy and paste in emacs or vi.
The reason it is so bad is it is an inconsistent mish mash of what Windows does and what UNIX used to do.
Windows users are now expecting to cut (or copy) and paste large objects.
I recently used a product on Windows (I can't remember what it was) where drag and drop copy between folders did not work. What they expected you to do was select a group of files, right-click-copy (or ^C), move pointer, click, and then either right-click-paste or ^V.
In this way, you could be copying multi-megabyte files. This will not work with a traditional X-Windows style cut buffer. I think this is what they are talking about when they are talking about cut-and-paste between VMs.
Even though I deal with HPC machines every day which do RDMA with the fastest interconnect in the market at the moment (at least I believe it is), I cannot understand how you can have remote access to another system's memory via RDMA faster than access to local memory. What this would imply is that the RDMA device (probably attached via PCIe) had access to the memory on a system faster than the processor. As the memory controllers of all current high performance machines are integrated on the processor die, I cannot see how it is possible for PCIe adapters to have faster access. If he is talking about VMs on the same machine, and using RDMA to access memory physically in the same system but in a different VM, the best he can do is have it running the same speed as 'local' NUMA memory.
I know they are talking about NUMA machines here, and that a processor may have to go across the internal system bus to talk to memory controllers attached to a processor on another die, but that across the bus access is not likely to be any less than the RDMA device that is in a similar position on the bus. Not unless the internal bus architecture of the system is seriously screwed up.
The only thing that I can imagine that he is talking about is having the memory 'mapped' and available via RDMA between two VMs on the same system faster than it could be copied across the interconnect from a remote (i.e. separate hardware system). That seems eminently possible, but that should not be a surprise.
It would be interesting to see whether the systems he has seen in the lab are the ones using PCIe4 as an interconnect.
"I cannot understand how you can have remote access to another system's memory via RDMA faster than access to local memory."
The main aspect of the session this related to was that when they teamed 4 network adapters and the transfer bottle-necked on the memory bus.
Given that RDMA is designed to be high-throughput and low latency, it is possible that it has fewer overheads than NUMA node memory access. It doesn't mean that a NUMA node on one computer can access memory on another computer faster than on the same device, it just means that the RDMA transfers can move data faster than the NUMA nodes can access it.
"It would be interesting to see whether the systems he has seen in the lab are the ones using PCIe4 as an interconnect."
According to Ben they were using 4x PCIe3 NICs. I didn't catch the specifics of the NICs, but he said they bottle-necked the PCI bus with 3 of them (well, 2 really - the third NIC made no difference to transfer rate). No doubt when they post the session recordings you can listen to what he said and figure it out.
"I know I am a bit out of touch with Windows. Last time I used it, I complained that the middle mouse button did not work."
That would be because you didn't know what you were doing. I've been using the middle button on my mice in Windows since the mid nineties. It would have been earlier, but I didn't get my first 3-button mouse until then.
Would you like me to list all the things that *NIX doesn't do the same as Windows and then complain about how *NIX is stuck in the 60's? I can if you like. Wouldn't mean anything more than your uneducated slam.
"I would like to congratulate Windows users for reaching the twentieth century, but I am not sure if they all have three button mice yet."
Thanks. I'm sure that one day you'll catch up with us though.
RDMA is secure. It does not give access to the whole of the address space of a system (or at least the implementations I have used don't).
What happens is that the OS on the controlling side of the RDMA transaction sets up a limited window to a region of memory that the remote machine can see. The remote machine has no access to memory outside of this window.
This makes the access as secure as the OS on the controlling machine which set up the window.
In the implementations I have seen, there is an architectural limit on the size of the memory region in the window. This means that it is simply not possible to expose the entire address space of a machine using RDMA.
100% agreeing with the absurdity of being able to access memory over the network link faster than from other processors in the system. If that's the case, just replace the bus interconnection with the network link and trash away at how incompetent hardware designers are. Which is not the case.
Likely the MS borg is talking about a corner case where this could potentially be true. Not in the general case.
Now, the security implications of this are huge, no matter how well designed the facility is. Remember, each exposed service is an increase attack surface. So unless you have NSA level skills you cannot be 100% sure that the implementation is bug free.
"the OS on the controlling side of the RDMA transaction sets up a limited window to a region of memory that the remote machine can see."
I can visualize the black and white hat hackers trying to find vulnerabilities that fool the controller into setting up different regions, different mappings and different sizes... just wait, someone will find a flaw.
"The remote machine has no access to memory outside of this window"
Except of course if there are any bugs in the implementation. Back to point one.
"there is an architectural limit on the size of the memory region in the window"
Of course there is, I agree, but...
"This means that it is simply not possible to expose the entire address space of a machine using RDMA"
Sounds like is more a matter of having to page different regions then and iterate over them. Shades of paged memory again...
"Sounds like is more a matter of having to page different regions then and iterate over them. Shades of paged memory again"
Except that the remote machine cannot manipulate the mapping registers that are used to control the window. If you can't manipulate these, then you cannot see memory outside of the region. And even the process on the local machine, which is running in non-privileged mode, cannot alter the mapping registers. This is a function of the OS, and is controlled by system call, with appropriate security.
I must admit that if you think that paged memory is a bad thing, then you must realise that you are condemning all current machine implementations that use virtual address spaces. All virtual address space machines use memory mapped pages to implement a linear virtual address within a physical address space, and also allow memory overcommitting (==using a page space on disk).
There are NO architectures currently that I know about that allow multiple processes in a strictly linear global address space that is the same as the OS. I don't know whether you work with some that I don't know about, or if you don't realise how modern systems work.
"What happens is that the OS on the controlling side of the RDMA transaction sets up a limited window to a region of memory that the remote machine can see. The remote machine has no access to memory outside of this window."
And MS software has never had any buffer overflow issues, so it must be secure.
I'm as into Microsoft bashing where it is deserved as much as anybody else, but in this case, just because it is Microsoft that does not mean there is a problem. You could say that pretty much every OS has buffer overflow exploits (it is one of the problems of writing in C after all, and that is a language that has been used extensively for OSs) thus it's not only Microsoft's problem.
In terms of the OS setting the window, It is really set up so that the hardware MMU does the guarding, not the OS. The OS sets up the window, and then the MMU enforces it. The OS may set it up wrongly, but assuming that it is correct and the MMU is bug free, it becomes impossible for the remote machine to move outside of the constraints of the window. This is not an OS issue.
If you distrust the MMU, then you must distrust all architectures that use virtual address spaces for processes as well, as they all use the capabilities of a HW MMU to enforce the issue. It's been that way for multi-tasking OS's with virtual address spaces for decades, and wintel since NT is no exception.
Obviously some people hiding behind the AC banner have forgotten their system architecture courses, or are just trolling because they don't understand in the first place.
Pretty much. Like JDX above, I ain't no sysadmin. However, I've been CTRL+Cing and CTRL+Ving between Virtualbox instances and various guest/host combinations for a while now. So long as the guest extensions are installed, what's the problem?
(And Windows 8 is still a shitty guest)
Regarding this bootnote comment:
Bootnote: Microsoft customers may not be asking for more than 64 virtual processors, but VMware customers are: the recently-released vSphere 5.5 can handle 4,096 virtual CPUs, rather more than Hyper-V, no matter what Armstrong says about who's on top.
You're comparing two different things. Armstrong is referring to the fact that Hyper-V VMs support up to 64 virtual processors per VM. You're referring to vsphere 5.5 handling 4096 virtual CPUs for a single physical server. Hyper-V has done this since Server 2012. VMware is just catching up in ESX 5.5. In addition, Hyper-V supports up to 64 nodes in a cluster and up to 8000 VMs in a cluster that twice ESX 5.5. VMware still hasn't caught up to WS 2012 Hyper-V and WS2012 R2 Hyper-V has even more.
The discussion from the floor about the 64-core limit during the session was specifically about the limitation of 64 cores available to the *HOST* operating system. Ben specifically stated that ALL cores on the system were available for VMs to use - although he did not discuss per-VM limits. The limitation is purely to do with how many cores the host is allowed to use.
And from talking to a bunch of other people after the session, the common theme (that seems to be completely avoided here) is that switching to Hyper-V was going to save a lot of money. One delegate was talking about moving from VMWare to Hyper-V because it was going to save him in excess of AU$20K per year on licensing alone.
Funny how the VMWare evangelists here aren't talking about the price, isn't it?