How to escape VMware's pricey clutches with Virt-v2v Moving a VM from one host machine to another is easy. Moving VMs from one hypervisor to another is less trivial – but help is at hand. The Reg FOSS desk spent the weekend in sunny Brno at the European installment of Red Hat's annual developers' conference, DevConf.cz. One of the Lightning Talks we especially enjoyed was …
"Er isnt going to RHEL ..."
You are not going to RH or Proxmox or whatevs, you are going to Linux and KVM. That is open source with a capital GPL. The rest is packaging, with a few fripperies bolted on. Basically, you do have some choices that going all in with VMware, Xen, Nuttyanics, Hyper-V etc does not afford you. Even so, the great thing about virty is that you can move out from one to another by treating your VMs as physical and using the wealth of data and state movers.
Veeam have already announced that Proxmox will be supported in Q3 this year and Gostev has also stated on the forums that a 100% Linux stack for Veeam is rather more than a stretch goal. Note that you can already dump MSSQL for Postgres on the core product.
You may have also noticed that MS are now announcing "deprecation" for things like Exchange on prem and Office on RDS and so on. By around 2026/7 you will have one of two choices if you are lucky. You are all in on a cloud or you are not. If you want to have data sovereignty and possibly even a business, you need to plan now.
I am.
The rest is packaging, with a few fripperies bolted on
The reason that some organisations pay lots of money for commercial solutions is that the things that are "fripperies" for small scale deployments are pretty much essential for managing large estates. As the article says, core hypervisor functionality is quite commoditized - it's the management tools that people are really paying for. Not all users will require them and Broadcom seems to have acknowledged this in seemingly restructuring its business around its big customers that do - and will pay the price demanded. They've been incredibly hard-nosed about it, but I don't think you can fault their market analysis.
Not all users will require them and Broadcom seems to have acknowledged this in seemingly restructuring its business around its big customers that do - and will pay the price demanded. They've been incredibly hard-nosed about it, but I don't think you can fault their market analysis.
As the person who holds the system admin hat for virtualization in our small-medium sized organization (but falls into the governmental entity box for reasons), I absolutely take exception to the fact that we have to pay quite a lot more for support on our infrastructure than what we were paying, for no effective benefits. I could justify it if we were actually implementing a bunch of the features that will be included in our new support subscription, but we can't justify it because said features are aimed at much larger organizations than us, and frankly, it's annoying as all hell that we have to pay this ridiculous amount of money for stuff we don't need and will never use.
Microsoft has already thought of this question. Pick one of these. Confirm it on your own Windows host, if you want.
C:\Temp>wsl.exe -l -o
The following is a list of valid distributions that can be installed.
The default distribution is denoted by '*'.
Install using 'wsl --install -d <Distro>'.
NAME FRIENDLY NAME
* Ubuntu Ubuntu
Debian Debian GNU/Linux
kali-linux Kali Linux Rolling
Ubuntu-18.04 Ubuntu 18.04 LTS
Ubuntu-20.04 Ubuntu 20.04 LTS
Ubuntu-22.04 Ubuntu 22.04 LTS
Ubuntu-24.04 Ubuntu 24.04 LTS
OracleLinux_7_9 Oracle Linux 7.9
OracleLinux_8_7 Oracle Linux 8.7
OracleLinux_9_1 Oracle Linux 9.1
openSUSE-Leap-15.5 openSUSE Leap 15.5
SUSE-Linux-Enterprise-Server-15-SP4 SUSE Linux Enterprise Server 15 SP4
SUSE-Linux-Enterprise-15-SP5 SUSE Linux Enterprise 15 SP5
openSUSE-Tumbleweed openSUSE Tumbleweed
A little OT and I appeciate it's not suitable for most cases, especially complex Windows setups, but I've been having a blast with Docker and Kubernetes run Linux conatiners on Windows. Great for small apps and learning more about FOSS apps but also some useful skills in containerisation. I used to use VirtualBox for everything, even just firing up things like Rundeck, Zabbix, Postgres, SFTP server, etc, but I found Docker is perfect for small use cases where you need to learn the specific app without the huge overheads of installing a full distro.
> without the huge overheads of installing a full distro.
> Docker and Kubernetes run Linux conatiners on Windows.
But what is the overhead of setting up Kubernetes to run Linux Docker images under Windows in the first place?
And *huge* overheads? For
> even just firing up things like Rundeck, Zabbix, Postgres, SFTP server,
Those don't need large installs to run them, do they? And the last two, at least, can be run Windows native, so is it even worth running a Docker image (although I guess the image can contain a pre-made database?)
Having said that,
> but I've been having a blast
Good, nothing wrong with doing it for fun; just a bit sceptical about the claimed benefits if we follow suit.
Good skills.
You might like to dump the Windows bit and run Linux at the bottom or not! You have choice. However you do have to be careful not to use too many layers of re-direction, because that can murder performance.
You could start off with a Windows server, say 2022, slap on Hyper-V and also Docker and a container fiddler or you start off with a Debian box with Proxmox and install Docker and ... Or what about ....
I have no idea what a complex Windows setup might be (perhaps a bloody daft SCCM deployment) but with some capacity planning, you can do whatever the hell you like! You have CHOICE - run Linux on Windows or Windows on Linux or both or not.
It's actually all about the apps as it should be and not the OS behind.
You do you 8)
One of my colleagues tried to persuade me that this is what was happening. I tried to explain that containers can't actually change the underlying operating system in this way; that would require a virtual machine.
Another colleague stepped in and explained that this is, in fact, exactly what is happening. Docker is actually running on a Linux VM on top of Windows. The integration is sufficiently slick that it looks like it's running natively, but it's not really. So the "huge overhead" is still there, just not visible.
-A.
... is what I am using if I need to (re)virtualize Windows, either from bare metal of from VMware/HyperV/some obscure cloud hosting, unless I have full access to old server, in which case "qemu-img convert ..." is enough.
And there is nothing better that good old rsync to move Linux to KVM. Yes, it requires some manual work, but you can actually make it better: change fs to XFS, partitions layout - make bigger or separate /home, etc.
Sure :)
Fire up VM in any Linux rescue or live CD system (I use Opensuse), create partition layout per your needs, stop all services that could be modifying files on source machine, rsync everything to new VM, prepare boot loader, reboot... Yes, there is some manual work, but everything is customizable. Of course, you should really know what you are doing, so this is not for "average Joe"...
Resources: just google "rsync linux into vm" or something similar, but (as always) don't just copy-paste any of the answers, but be sure to understand what is going on in every step and modify it appropriately.
> Virt-P2V, which we described as ... sends it to a conversion host system, which then wraps it up to run in a KVM virtual machine.
> Well, it was a dozen years ago. Times have moved on ... introduced that tool's more contemporary sibling,
Um, ah, how to put this...
Virt-v2v *is* the software running on the "conversion host system". IOW in order to run the "older" Virt-P2V you first need to be running the "more contemporary" Virt-v2v as a server!
Virt-v2v is a lot more capable now than it was twelve years ago and it is definitely worth knowing about using it not as a server process, but as a command to convert between formats, however it has been there all these years, as the powerhouse that lets Virt-P2V work at all.[1]
[1] Actually, I rather wish they *were* separate, so then you could boot an ISO then into Virt-P2V to create the VM files with nothing more than some (separate) drive space to store them. But now, as then, you do need to get a copy of Virt-v2v running in a second machine, which just isn't as convenient. First-world problems, eh.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
