> On Tue, Aug 4, 2020 at 7:37 PM <thomas(a)hoberg.net> wrote: > > This is good, you should not use export domain at this point. We have better > replacement (see my other mail). > I agree that one way should be enough, but it needs to work and ideally improve on usability generation on generation. > > I think you already found that OVA are not what you think they are. > They work for exporting > VMs from the same hypervisor and back, unless you have a tool that > know how to convert > OVA from one hypervisor to another like virt-v2v. I am used to deal with VMs very much like LEGO bricks. I have moved them between hardware and hypervisors ever since Mendel Rosenblum & friends managed to trick the 80486SL into running a hypervisor with the system management mode intended by Intel only to make DOS not eat batteries on luggable hardware. Windows systems have made huge improvements, moving p2v, v2v, p2p, even v2p, Linux requires some precautions and constraints I have learned to observe.
The the more sensible (not as polite...) question is to ask: Should I actually move these VMs? And you're right, that I should better not, use infrastructure as code etc. but that leads right to containers rather than VMs. I've used OpenVZ in production for more than a decade for that and even nested them with Docker to get both scale-in and scale-out benefits and less friction between ops and devs. But as your very own Roy Goland blogged in January '19, every cloud needs an anchor, contro place or service VMs, for which oVirt is just right... but also the outer-most loop, where infra as code delivers the lowest benefits. Still the lab infra I support as a side job is so small, and my coding has become so rusty (wrote a Linux emulator for a distributed ยต-kernel as part of my thesis when Linus still didn't know that task state segments are too klunky for task switching), that I'd just prefer to use an appliance now, but which I know to have proper REST/Python APIs in case it grows into something bigger. That doesn't change that any hypervisor should just support the elemental save/store/export/import operations in addition to start/stop/suspend/clone/migrate etc. VMware, XenServer, VirtualBox each probably aren't just minor players compared to oVirt/RHV and when you want to gain market share, bi-directional interoperability can lower barriers... even if they are a tad costly to maintain. In any case I currently blame the others for not understanding the OVAs QEMU is producing, at least until I can prove that wrong. > > > True, ease of use is important. But if you are going to do this a > lost, scripting the > operation is important, and oVirt has a very powerful API/SDK. > > > What you say is basically that having a backup is useful :-) Yes, when you promise your team that things will be easier and better with oVirt, it's nice when you can avoid them losing everything. > > How are you going to use the OVA on a bare metal machine? Not the typical emergency use case actually, even if I have done v2p on occasion. More typical would be that I'd just put (actually have) a VirtualBox on a normal Docker/Kubernetes compute node and just have that run a control plane/service VM that I had exported to cover this near disaster scenario of a failed cluster. Actually again for LEGO spirit and flexibility I was going to put oVirt, VirtualBox and Docker on our big GPU ML compute nodes and then put policies in place to control how and if workloads would ever migrate there, because each would be blind to one another. Alas, while Docker and VirtualBox get along fine, oVirt doesn't like to play with any of the other two, let alone both. > > Why do you need the desktop hypervisor? I would like to hear more > about this use case. Nothing magic, really just that developers sometimes like to build prototypes on their corporate Windows mobile workstations to work on them at home or even demo them to customers. VirtualBox isn't too bad but VMware workstation can make it very easy to just build an infrastructure out of LEGO VMs with a network included. Far less sophisticated than OVN and oVirt, but *everybody* can use it pretty much out of the box. Bare KVM is just not the same experience and I was actually very sad to notice, that VirtualBox and oVirt refuse to co-exist on a single host, even if both use KVM underneath! I got VirtualBox and VMware on my Windows machines without issues, and it's only HyperV that is getting increasingly exclusive, after a while when I could even run all three on a single machine. Not that anyone *should* do that, but then for type 2 hypervisors there is no (technical) reason not to play well and I don't want politics on *my* machines. And don't get me started on wanting to use nesting for the real LEGO experience! > > And if you need one, why not use something based on KVM (like > virt-manager) so disks > from oVirt can work without any change? This will make it easy to move > from oVit to desktop > hypervisor and back with relatively little effort. > You know, when somebody gives you a button, you tend to assume it's even easier than moving disks :-) I wouldn't actually assume that OVA export does much more than export disk images and add a few tags for the common subset of settings between hypervisors. And I was likewise quite surprised at the amount of work done by OVA import, when VirtualBox/VMware images were recognized. It's nice to see when it works, but I wasn't really expecting that. Linux is so hypervisor enabled and comes with built-in guest additions, that I haven't seen the need when moving VMs between VB/VMware/Hyper-V. And with Windows VMs, starting with W7/W2012 it's become almost a no-op, just pop it in and it will adjust with little more than a reboot, unless you want those virtio drivers for speed. > > Thanks Thomas, this is very useful feedback! I'll be happy to write up a long review of my experience if you would like that. I can type pretty fast, but few people like reading any more.. > > Nir Thank you for your time and patience! _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/RV2UWK7KAOOPTT6JRR4X7IWUNZHZGIDF/
