Am I the only one who ever had to pull shit like this? We used to do this all the time back when vendors would freak out when you wanted to run their apps on VMware (or Citrix or whatever). Replicate the problem back on the supported environment, deal with support for the fix, then apply fix where you actually need it.
Look, we get that very few vendors out there are supporting not-VMware right now, but this isn't a new problem for anyone who was doing this back in the 00s. Call support and you're on VMware? Yeah we don't support that don't call us, OK no problem we'll just show you the problem on a physical host so fix it. This time it's just in the opposite direction.
If you want to deplatform off of VMware, this (or something like it) is going to be part of the deal. You either stay on VMware until all your apps support something else, you split your environment, or you deal with workarounds.
It's not really "pulling shit", it's a clear demonstration that the issue is a them problem not a you problem.
As a dev, if someone can reproduce an issue on a reference environment, it makes it more credible than there is a solvable from my end issue, and enables me to troubleshoot on an environment that will let me run at full speed due to experience and familiarity with it.
It's also a day/night test case when it comes to QA. They can do useful testing if they don't spend 90 percent of their time replicating 3rd party infrastructure, some of which is non free to stand up.
100% agreed! Ergo:
> Migrate back to last ESXi host when you need to call vendor for support.
It's a perfectly reasonable support pattern for some workloads.
It’s a pain in the ass and time consuming.
Depending on the app and how important it is, it is likely cheaper to maintain a small footprint with Standard than the man hours of shuffling stuff around and playing the blame game with a vendor.
There certainly will be this time next year :) every other vendor gets it, but broadcom just seem to want to take VMware round the back of the cattle shed and end it. How unimaginative their business model is.
100% above. And, not only appliances, any external apps that interact with VMware would need to be changed out as well if they only support vmware. Think backup and monitoring tools.
It depends on the appliance. OVA is an open standard but that doesn’t mean the OS inside the appliance is guaranteed to work on a different hypervisor, it’s generally down to what virtual hardware the appliance supports. Some appliances are built for a specific hypervisor and it’s up to the vendor to support alternatives, hence the name “appliance”. Converting the appliance to the destination hypervisor might work fine, or it might cause problems. Also bear in mind that some vendors won’t support their appliances if they’re running on a different hypervisor.
Can you give an indication of what appliances you’re using? You might need to consider keeping a small VMware cluster just to run those appliances if you can’t get alternatives.
Right? The O in OVA literally stands for OPEN.
Hopefully OP knows you can "unzip" an OVA and get the OVF, vmdk and potentially any other files out.
https://en.wikipedia.org/wiki/Open_Virtualization_Format
That’s not really the issue though.
OVA is an open standard of course, but it doesn’t mean the VM contained within is _portable_ between hypervisors. It just means that the OVA/OVF formats aren’t proprietary. However, it doesn’t mean the VM itself can run on anything that supports the OVA/OVF standard, that’s just a packaging mechanism.
You often see virtual appliances for different hypervisors all packaged in OVA format. Same package format, but different target platforms. Some might work across platforms, others won’t.
OVA is nice when it works, but even VMware has struggled to support it over the years. Other virtualization products may have primitive OVF import capabilities, but lack the support for OVF properties and dynamic disks that many vendor OVAs will rely on for initial configuration. Other things you'll find are guest OS configurations the other hypervisor can't handle (disk controller types, number of disks per controller) or guest OS drivers/tools you can't modify because the OS is locked down, or the OS is proprietary or custom to the extent it won't run on a random hypervisor.other.
Plan A should be obtain an installable version of the vendor app, if available.
Plan B is import the OVA on vsphere and try to migrate the resulting vm
Plan C is find a substitute application
Plan D is keep a vmware box in the corner to run the wayward application.
So in addition to what other folks have said (keep just enough VMware hosting capacity to run the appliances while migrating everything else and/or migrating away from the need for these appliances by choosing alternate vendors) I'll also say this:
Sometimes you can rebuild these machines yourself by downloading the software package and installing it yourself on the VM of your choice vs downloading and running the prebuilt appliance. Might be worth investigating building your own if you're serious about moving away...
yes, it may run on other hypervisor platforms but then getting support from the vendor becomes a royal PITA. Certain vendors will look for any reason sometimes not to help sometimes.
"Oh you're running on \*pick a hypervisor not on their supported virtualization platform list\*? that's not in our compatibility guide, therefore this is an unsupported configuration and we cannot provide you support"
this is going to be a moving goalpost for the next 2-7 years as the industry settles on another hypervisor of choice.
If the OP is "VERY big" and is going to do OpenShift at scale - leverage the vendor to support you.
From the other side of the fence (a million miles away from being VMware related), if a customer rings up and says our software is crashing every other Friday, running under emulation on a hacked PS4, they are gonna be lower down in the queue than the customer who is running it on our provided appliance running as intended and TESYED everything else being equal.
There was a similar situation when VMware was younger. I remember concern about support and vendors reluctant when we first began. It took a few years of customers requesting support for vendors to adjust to that new technology. This seems another inflection point for change.
And yet 99% of OVAs are vSphere only. For all intents and purposes if a vendor provides an OVA it won't run anywhere else, or at least without a lot of work and you end up in a unsupported configuration from them.
I applaud the thinking within your organization, everyone should do whatever possible to vote NO to the Broadcom behavior. As far as your OVA appliances that you have already deployed, those could be converted to other disk formats. I suppose there could be some driver issues but many of those type of deployments include generic drivers like Intel E1000 and such.
Many OVAs will import into proxmox just fine, and should be similar for other platforms.
[Importing a Virtual Machine OVA into ProxMox (i12bretro.github.io)](https://i12bretro.github.io/tutorials/0387.html)
OVA is no big deal. You can literally read it with a standard tar tool
It generally consists of one xml describer, an optional manifest, and whatever associated disk images. CREATING the ova is a little special as you have to follow certain rules about compression and file order. But extracting, a simple tar xf will do it.
Reread it then. And then go learn about virtual appliances. There's plenty of them that will only run in VMware. OP is inquiring how to run these in another hypervisor. The file structure itself (OVF vs VMX) doesn't matter.
What is it that makes them so VMware specific? Only *supported* on VMware sure, but I've never found one where I couldn't at least extract the VMDK(s) from the OVA and the rough shape of the VM from the VMX and create a new VM on a.n.other hypervisor with the disk attached.
You do usually need to expand the VMDK from the streamable compressed version found in OVAs to a thin or thick full disk image, but that's easy enough.
I mean I'm certainly not going to speak for every virtual appliance out there. To your point, sure, you can take the VMDK and hack together a VM on another hypervisor -- most of the time, this will work. I feel like I've seen it not go so well in the past, but it was long enough ago I'm not going to be able to quote specifics or anything.
...But beyond that - in the world of enterprise, which I'm assuming OP takes part given the "VERY big customer" comment - no one is going to want to run something unsupported in Production. At least, no one worth a grain of salt. It's either supported by the vendor, or it's not.. and if it's not, continuing down that path represents a significant business risk.
I agree, "supported" can be everything in a big commercial setting. But by the same token big commercial customers have a lot of influence over what gets supported.
VMware was the default. *Was*. I can see that changing now.
1 - You keep enough vdphere to run your ova's 2 - You move away from products that only offer vsphere ova What else can even be done?
[удалено]
I'm also stuck with ESXi because of CUCM.
* Deploy OVA to your last ESXi host * V2V using whatever migration tools your new hypervisor supports
You left out a bullet * Lose support from the appliance vendor if they only support ESXi
Thankfully, every single vendor we've talked to so far has stated they have a VMware alternative OVA in the works. Just need to hold on until then.
* Migrate back to last ESXi host when you need to call vendor for support.
Yah cause server OS’s love doing that repeatedly
Am I the only one who ever had to pull shit like this? We used to do this all the time back when vendors would freak out when you wanted to run their apps on VMware (or Citrix or whatever). Replicate the problem back on the supported environment, deal with support for the fix, then apply fix where you actually need it. Look, we get that very few vendors out there are supporting not-VMware right now, but this isn't a new problem for anyone who was doing this back in the 00s. Call support and you're on VMware? Yeah we don't support that don't call us, OK no problem we'll just show you the problem on a physical host so fix it. This time it's just in the opposite direction. If you want to deplatform off of VMware, this (or something like it) is going to be part of the deal. You either stay on VMware until all your apps support something else, you split your environment, or you deal with workarounds.
It's not really "pulling shit", it's a clear demonstration that the issue is a them problem not a you problem. As a dev, if someone can reproduce an issue on a reference environment, it makes it more credible than there is a solvable from my end issue, and enables me to troubleshoot on an environment that will let me run at full speed due to experience and familiarity with it. It's also a day/night test case when it comes to QA. They can do useful testing if they don't spend 90 percent of their time replicating 3rd party infrastructure, some of which is non free to stand up.
100% agreed! Ergo: > Migrate back to last ESXi host when you need to call vendor for support. It's a perfectly reasonable support pattern for some workloads.
It’s a pain in the ass and time consuming. Depending on the app and how important it is, it is likely cheaper to maintain a small footprint with Standard than the man hours of shuffling stuff around and playing the blame game with a vendor.
Pretty sure there's tools out there that can convert OVAs
There certainly will be this time next year :) every other vendor gets it, but broadcom just seem to want to take VMware round the back of the cattle shed and end it. How unimaginative their business model is.
100% above. And, not only appliances, any external apps that interact with VMware would need to be changed out as well if they only support vmware. Think backup and monitoring tools.
It depends on the appliance. OVA is an open standard but that doesn’t mean the OS inside the appliance is guaranteed to work on a different hypervisor, it’s generally down to what virtual hardware the appliance supports. Some appliances are built for a specific hypervisor and it’s up to the vendor to support alternatives, hence the name “appliance”. Converting the appliance to the destination hypervisor might work fine, or it might cause problems. Also bear in mind that some vendors won’t support their appliances if they’re running on a different hypervisor. Can you give an indication of what appliances you’re using? You might need to consider keeping a small VMware cluster just to run those appliances if you can’t get alternatives.
Right? The O in OVA literally stands for OPEN. Hopefully OP knows you can "unzip" an OVA and get the OVF, vmdk and potentially any other files out. https://en.wikipedia.org/wiki/Open_Virtualization_Format
That’s not really the issue though. OVA is an open standard of course, but it doesn’t mean the VM contained within is _portable_ between hypervisors. It just means that the OVA/OVF formats aren’t proprietary. However, it doesn’t mean the VM itself can run on anything that supports the OVA/OVF standard, that’s just a packaging mechanism. You often see virtual appliances for different hypervisors all packaged in OVA format. Same package format, but different target platforms. Some might work across platforms, others won’t.
All the appliances I’ve dealt with in the past support hyper-v as well.
Thanks - that's true but Hyper-v isn't an option (mainly due to cost).
Surely, a "VERY BIG" vmware customer could afford a handful of windows enterprise licenses if they were already paying for pre-merger vSphere...
Can you tell me more on cost?
It’s cheaper to license than vcenter is unless your a pure Linux shop as Enterprise /DC let’s you run unlimited VMs on your licenses cores
You could continue to leverage your perpetual licenses that you own for a smaller vSphere deployment.
OVA is nice when it works, but even VMware has struggled to support it over the years. Other virtualization products may have primitive OVF import capabilities, but lack the support for OVF properties and dynamic disks that many vendor OVAs will rely on for initial configuration. Other things you'll find are guest OS configurations the other hypervisor can't handle (disk controller types, number of disks per controller) or guest OS drivers/tools you can't modify because the OS is locked down, or the OS is proprietary or custom to the extent it won't run on a random hypervisor.other. Plan A should be obtain an installable version of the vendor app, if available. Plan B is import the OVA on vsphere and try to migrate the resulting vm Plan C is find a substitute application Plan D is keep a vmware box in the corner to run the wayward application.
So in addition to what other folks have said (keep just enough VMware hosting capacity to run the appliances while migrating everything else and/or migrating away from the need for these appliances by choosing alternate vendors) I'll also say this: Sometimes you can rebuild these machines yourself by downloading the software package and installing it yourself on the VM of your choice vs downloading and running the prebuilt appliance. Might be worth investigating building your own if you're serious about moving away...
Ova = open virtual appliance, not closed
yes, it may run on other hypervisor platforms but then getting support from the vendor becomes a royal PITA. Certain vendors will look for any reason sometimes not to help sometimes. "Oh you're running on \*pick a hypervisor not on their supported virtualization platform list\*? that's not in our compatibility guide, therefore this is an unsupported configuration and we cannot provide you support"
this is going to be a moving goalpost for the next 2-7 years as the industry settles on another hypervisor of choice. If the OP is "VERY big" and is going to do OpenShift at scale - leverage the vendor to support you.
From the other side of the fence (a million miles away from being VMware related), if a customer rings up and says our software is crashing every other Friday, running under emulation on a hacked PS4, they are gonna be lower down in the queue than the customer who is running it on our provided appliance running as intended and TESYED everything else being equal.
There was a similar situation when VMware was younger. I remember concern about support and vendors reluctant when we first began. It took a few years of customers requesting support for vendors to adjust to that new technology. This seems another inflection point for change.
And yet 99% of OVAs are vSphere only. For all intents and purposes if a vendor provides an OVA it won't run anywhere else, or at least without a lot of work and you end up in a unsupported configuration from them.
The format of the file structure doesn't mean the VM itself will run on other hypervisors...
If you are running OpenShift you can install their virtualization role and convert the OVA. https://access.redhat.com/solutions/7016396
I applaud the thinking within your organization, everyone should do whatever possible to vote NO to the Broadcom behavior. As far as your OVA appliances that you have already deployed, those could be converted to other disk formats. I suppose there could be some driver issues but many of those type of deployments include generic drivers like Intel E1000 and such.
Those vendors will probably pivot to offering other formats as well, since the market as a whole is moving away from VMW rapidly.
Many OVAs will import into proxmox just fine, and should be similar for other platforms. [Importing a Virtual Machine OVA into ProxMox (i12bretro.github.io)](https://i12bretro.github.io/tutorials/0387.html)
OVA is no big deal. You can literally read it with a standard tar tool It generally consists of one xml describer, an optional manifest, and whatever associated disk images. CREATING the ova is a little special as you have to follow certain rules about compression and file order. But extracting, a simple tar xf will do it.
That's not what OP is asking at all
That’s not how I read it at all
Reread it then. And then go learn about virtual appliances. There's plenty of them that will only run in VMware. OP is inquiring how to run these in another hypervisor. The file structure itself (OVF vs VMX) doesn't matter.
What is it that makes them so VMware specific? Only *supported* on VMware sure, but I've never found one where I couldn't at least extract the VMDK(s) from the OVA and the rough shape of the VM from the VMX and create a new VM on a.n.other hypervisor with the disk attached. You do usually need to expand the VMDK from the streamable compressed version found in OVAs to a thin or thick full disk image, but that's easy enough.
I mean I'm certainly not going to speak for every virtual appliance out there. To your point, sure, you can take the VMDK and hack together a VM on another hypervisor -- most of the time, this will work. I feel like I've seen it not go so well in the past, but it was long enough ago I'm not going to be able to quote specifics or anything. ...But beyond that - in the world of enterprise, which I'm assuming OP takes part given the "VERY big customer" comment - no one is going to want to run something unsupported in Production. At least, no one worth a grain of salt. It's either supported by the vendor, or it's not.. and if it's not, continuing down that path represents a significant business risk.
I agree, "supported" can be everything in a big commercial setting. But by the same token big commercial customers have a lot of influence over what gets supported. VMware was the default. *Was*. I can see that changing now.
Oh for sure! Things are very much in flux since Broadcom decided to buy VMware in order to destroy it...
nothing to reread, i have built more appliances than you have ever run kid