VMware: We're gonna patent hot-swapping your VMs' host OS VMware looks set to renew its relevancy with a new patent application. The patent application lists inventors Mukund Gunti, Vishnu Sekhar and Bernhard Poess and assigns the patent to VMware. The short version of the patent is that, if granted, VMware will have effectively patented the ability to hot swap a host server's …
"Encapsulating the applications for transport is the easy part"
Indeed. The hard part is encapsulating the state within the kernel, for example: open files, open sockets, dirty blocks in disk cache, device driver buffers.
If you can migrate all this then you can do in-place hot kernel swaps, which is really all we need.
Swapping out the userland is a non-problem, this can already be done - although an application which has the old version of a library open will still need to be restarted in order to pick up the new version of the library.
This post has been deleted by its author
VMware continue to solve the problems of the last decade despite clear and consistent evidence that the world has moved on. Software, new software that is, doesn't need the OS to be hot swapped in many cases because it's designed to be highly available and loosely coupled (buzzword BINGO, I know!) so that patching and other maintenance can be done by replacing rather than managing. Cattle vs Pets as they say, and VMware keep inventing ever more cosy dog baskets while Microsoft, Amazon and Google are creating ever simpler farming solutions.
>> Nobody wants to reboot these machines for updating
Then something is wrong with the whole set-up.
>> If this works, in theory telcos could update switches and routers without rebooting
So we make the switches & routers more expensive with all the extra hardware, while at the same time we do not solve the conundrum that you require two units for resilience.
Which leads me to think that these people who can not restart one of their core/whatever for patching are doing it wrong.
Patching without downtime is a solved problem if you care about it.
Also moving VMs out of a host is something that happens automatically on most decently set-up virtualization farms, and at most a VM loses a couple of network packets.
If my memory serves me right VMware excells at this, the vm is first activated on another host then stop on its current host once it is up and running on the other host.
The only problem that's not solved is when you have dedicated physical hardware for a VM, but no one does that in large scale deployments*, perhaps at home or for testing purposes.
Containers... we'll talk about it another day, and trust me the problem is not the OS the containers run on.
I guess VMware can do something clever with this, but I fail to see the "redefining future of IT" here.
* People who get upset by generalizations usually have low IQ.
>> >> If this works, in theory telcos could update switches and routers without rebooting
I remember 20 or so years back having to explain to a support engineer on a training class about the need to restart things after loading certain patches, he was amazed, he'd just joined from a tele switch manufacturer and said they'd been hot patching their switches for years. New kernel on a running switch, no problems, replace core shared libraries? of course why not.
This is old old old stuff
Ksplice updates the running kernel in memory, pausing execution while it does so. I assume the AIX system does the same. What VMWare are proposing is detaching a CPU and some RAM from the running OS (certainly Solaris & AIX already support this, I think Linux can on appropriate hardware too) then spinning up a new kernel/OS image on that before passing control of running applications to it. That is arguably more powerful than Ksplice which doesn't allow changes in data structures or platform. Arguably, you could migrate your hypervisor seamlessly from Xen to KVM to VMWare to HyperV using this technology although it would be horrendously complex to do so.
No this isn't prior art. As described they want to push a new kernel across the hardware. Ksplice is hot patching the running kernel and adjusting the filesystem to match, so Ksplice is prior art.
I remember patching a running SunOS kernel on a Sun 4 back in the 90s to allow a WAN application to continue running without interrupting the flow on the WAN. It was a bit hairy as I did it from the command line using adb, rather than by running a patching program. It was only a modest set of kernel changes and I could hardly have altered all the (450KB?) kernel by hand in a reasonable time, but a suitable program could have. I imagine that people did similar things with mainframes in the 1960s, to avoid downtime.
There will be limits to what you can alter in a running kernel, on current hardware architecture. This is a different way to approach the problem, but will also have practical limits.
I must be imagining things that I have a binary on my Linux system that was compiled in the mid 90s and still runs just fine. It was something a guy I knew from work at the time wrote that still comes in handy once in a while. Since I never had source and have no idea where the guy is, the binary is all I have. Still works, despite being 20 years old, and Linux changing executable formats from a.out to ELF, and the 32 to 64 bit transition...
> I can gleefully run 5000 containers on a standard 2 socket server today.
Yes. 5000 containers. Doing fsck all.
Chuck a bit of work at all of them and send us a picture of your glee!
I bet your typical webapp would get maybe 10% more req/s throughput contained vs VMed... if that. Benefits of containers are rapid spin up/tear down and full stack of microservices/endpoints on a single host. Not improved throughput.
Seriously though, happy to be proven wrong of course.
The vast majority of workloads out there do fuck all except eat lots of RAM. CPU utilization in most datacenters - even with virtualization - is pathetic. Containers just give us a way to drive even more density and hope to get slightly better usage from our workloads.
Whole lot of stuff just wants to sit around waiting for something to do.
I can agree with that. It blows my mind that I can run almost 4,000 VMs in 6U of UCS chassis and still have CPU to spare.
My point is:
- Webapp running in a single 64GB VM
- Webapp running in a single 64GB physical host
- X hundred containers of your webapp running on a 64GB physical host
You might improve your CPU utilisation but your webapp throughput will not improve as much as you think just, because, containers.
Where did I say I expected speeds to improve? I just expect to run more idle workloads. If I have 5000 workloads on my box and at any given time 64 of them are doing something, that's a lot. Incidentally, I have 72 logical processors on my 2P server, so I can have that many workloads doing their thing at any given time.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
