Virt-manager: IDE disks

Crash Consistent is the issue here, that I would see. When there are "real" backups that are full, rather than non-quiesced, why bother taking a backup if it isn't reliable? Reliability is the biggest factor in whether you consider a backup useful. It's not like you could use this and tell a client that you took a backup.

In bold are the four that I would find most interesting and would only very rarely consider anything further. They range from free to pricy, self supported to enterprise support, and cover basically any possible scenario. Beyond those, I've had a lot of good luck with Netbackup in the enterprise.

In bold are the four that I would find most interesting and would only very rarely consider anything further. They range from free to pricy, self supported to enterprise support, and cover basically any possible scenario. Beyond those, I've had a lot of good luck with Netbackup in the enterprise.

Agentless isn't an option here, period. Beyond that, why you have a "preference" for this kind of thing is an additional problem. IT should not have preferences, we should want proper solutions, however they work. Desiring a specific way of doing it, that can't be done, is an emotional mismatch.

Agentless isn't an option here, period. Beyond that, why you have a "preference" for this kind of thing is an additional problem. IT should not have preferences, we should want proper solutions, however they work. Desiring a specific way of doing it, that can't be done, is an emotional mismatch.

Since KVM doesn't support working agentless today (outside of very specialty systems like Scale HC3), you are at a starting point of having eliminated all working backups and only looking at a category that doesn't work. So naturally it will feel like your choices are limited, because there are literally zero.

But this should not make you feel that the choices are limited, the proper reaction is to step back and say "I'm doing something wrong, I'm not looking at the goal (to protect the servers), I'm stuck in the weeds of an emotional "want" rather than a business "need"."

Right. So you've identified the problem - an emotional breakage. You have to fix that, period. It's not a viable reaction. You need to step back and figure out why an emotion is driving you rather than reason and goal orientation.

Everyone has their emotions and preferences, but there is no place in IT for those emotions to creep into our decision making. None. The moment we've done that, we move from being IT pros into being purchases in a consumer process.

So in IT, one of our most important skills is learning to set the emotional preferences aside and focus rationally on goals and logical decision making.

I love the idea of agentless, it's great. But it's only an idea in this case. And one that honestly, isn't important at all. Sure, conceptually it is neat, but that's all that it is. From a business or technical perspective, it's just a pointless thing that only sounds cool because we improperly use the term "agentless" even though there is an agent. Even the title of the category is engineered to invoke an emotional reaction, and it works.

So, now that you know that there isn't an option for a working agentless backup for KVM... do you want to go with a non-working backup system that you can't claim to really be a backup, or do you want to pursue something that can actually take what is considered a backup by the industry to protect the workloads? What is the end goal that you are trying to achieve?

I realize that in a lab, playing with anything is fun. But this would be considered a waste of resources to focus on something that conceptually can't be deployed in any real world scenario.

Why are you listing those? We've already looked at vProtect and we know from their own site that they don't take a working backup. So what's your goal in listing these?

You said Scale was the only one that had KVM "agentless"?

That works. HYCU requires that you replace KVM, as does Scale. Yes what they use is based on KVM, but it isn't just KVM. It's a custom new product made from KVM.

And vProtect doesn't take working backups (they state it at least half a dozen times on their site just from a casual look.)

Trilio can work only with OpenStack and only using Nova and beyond that, I've not researched if it can still work with just KVM.

The point being, none of these come close to meeting the criteria of being able to take a backup of KVM's VMs themselves. They all require either KVM to be replaced, or a storage layer that they use so that direct KVM would fail, or don't make working backups.

Ah, sounds like they never made the product. Maybe it will come soon. But from looking at their website, it appears to be something they are might be preparing to make, but don't have yet? Their RHV information definitely states that it is RHV on top of Nova (OpenStack storage layer) and that it is Nova doing the work to make it possible.

Which if you do a KVM based OpenStack deployment, it is possible to take backups for workloads on KVM, but it's not a backup of KVM as people mean it - meaning you can't just have a KVM based system and take a backup. It's an OpenStack system and if it also has KVM, that's not a problem.

Because the issue is that KVM lacks CBT (Change Block Tracking) which is the only currently working way to make an agentless backup system work. Without it, backups that don't have an agent are only crash consistent and are expected to lose data, randomly not boot, etc.

OpenStack's Raksha layer provides CBT for the OS ecosystem. This is not done in KVM, but at the storage layer of the cloud infrastructure. Raksha is primarily available for Nova (and Cinder to a lesser extend.) So if you are using Nova, and you have the Raksha layer, then companies like Trilio can use Raksha to build a working agentless backup system.

That backup system would work regardless of the hypervisor running on top of the stack, so Xen, KVM, whatever. So is there a specific way to make it work with KVM, yes. Is it a KVM backup, no.

So you can have scenarios, like OpenStack or Scale HC3 where you get what you need. But it doesn't apply to RHV / oVirt scenarios.

This is why agentless for KVM and Xen never come up on the radar, it's essentially in the "theory" stages. But it isn't a big deal, because the whole agentless thing is really just a weird sales tactic in the VMware / Hyper-V space from the era when they were trying to convince people to go virtual and so they made up weird benefits and made them sound way more important than they were. In the Xen and KVM space (which is older, at least for Xen), no one really ever cared much as agent based backups were pre-existing, fit more general use cases, and often worked better. So the desire for CBT and agentless systems never really arose.

That's not to say that people don't want it, they do. But they tend to see it as pretty inconsequential. Lacking it doesn't hurt those ecosystems in any way.

Looks like IDE to me, they probably renamed it to SATA for the millenials not to get scared by the older term (and for QEMU, any IDE was always closer to SATA because the access to the disks was always serial, one virtual controller device per disk)

Looks like IDE to me, they probably renamed it to SATA for the millenials not to get scared by the older term (and for QEMU, any IDE was always closer to SATA because the access to the disks was always serial, one virtual controller device per disk)

Right, ATA basically means IDE. IDE was formalized into ATA and renamed. SATA means ATA over Serial, since the physical piece is meaningless in a VM, definitely some funky marketing to put the physical piece into the name.