Comprehensive data protection for all workloads
Post Reply
ks.any.cloud
Service Provider
Posts: 55
Liked: 3 times
Joined: Mar 04, 2021 2:17 pm
Full Name: Kim Svane
Location: Denmark
Contact:

VBR13 Appliance other platforms

Post by ks.any.cloud »

Hi all,

I was recently discussing the two-disk requirement when deploying the Appliance. In my specific scenario, this requirement is causing several practical challenges.

My scenario
The hosting environment is a Red Hat–based VSI platform that supports QCOW2 and similar formats, but not OVA. Deploying via ISO is also not feasible. I attempted to integrate the ISO into a GRUB-based bootloader, but this quickly runs into UEFI-related constraints. The hosting platform appears to rely primarily on compatibility/legacy boot, where both BIOS and UEFI are technically available, but BIOS is the default.

A possible solution/workaround
This led me to consider whether a custom installation option for the Appliance could be viable. I understand that the repair/reinstall boot loader functionality would likely not work in such a scenario, as it presumably depends on the default two-disk layout.

Currently, disk2 i the OVA is used for:

/var/log
/var/log/audit
/var/lib/veeam

One possible alternative would be to move the /var/log and /var/log/audit directories to disk1, placed on a dedicated partition. This would still keep logs logically separated while allowing for capacity extension if required, without introducing a second disk.

The VEEAM repository path (/var/lib/veeam) would not necessarily need to be created during installation in this model, as a custom installation already prompts for the backup target. In my case, this would be object storage, but the same applies to other supported repository options.

I assume the second disk is also used for configuration and backup data. With a custom, single-disk setup, this would likely require defining an alternative location for configuration and backups.

Outcome/benefits for me(and maybe many more)
The main goal would be to allow deployment with a single disk. This would significantly simplify converting the primary disk to QCOW2 and deploying the Appliance on platforms beyond Hyper-V and VMware.

I hope this could be a potential improvement idea and would be interested in your thoughts on whether this could be feasible from a design and supportability perspective.
While discussing this here, im also discussing with the hosting provider.
Kim Svane @ any.cloud
HannesK
Product Manager
Posts: 15818
Liked: 3520 times
Joined: Sep 01, 2014 11:46 am
Full Name: Hannes Kasparick
Location: Austria
Contact:

Re: VBR13 Appliance other platforms

Post by HannesK »

Hello,

BIOS / UEFI: UEFI is mandatory. The appliances doesn't enforce UEFI secure boot, but that is the general idea. There are no plans to support BIOS and in 2026 every virtualization platform should support UEFI. Otherwise it would struggle with Windows TPM requirements.
Disk layout: I'm not sure I understand what the problem is to add a second disk to a VM
Installing from ISO: what is the challenge? Only the BIOS, or something else?

Best regards
Hannes
ks.any.cloud
Service Provider
Posts: 55
Liked: 3 times
Joined: Mar 04, 2021 2:17 pm
Full Name: Kim Svane
Location: Denmark
Contact:

Re: VBR13 Appliance other platforms

Post by ks.any.cloud »

Hi Hannes

BIOS / UEFI: It's not an issue as is, this issue was just one of many when i tried packing the ISO into a GRUB loader, that was converted to qcow2 - was able to boot, until the ISO told me UEFI was required. Even though the VM was set to use UEFI - might be an issue due to the way the iso was loaded by GRUB - but i did not investigate further.

Disk layout: The issue with the disk layout is that in some hyperscalers, it is not possible to load an ISO, which was why i tried the above. And also not possible to import more than 1 QCOW2 image. And each disk counts as a QCOW2 image. And also not possible to import the OVA.

So, what i ended up doing was:

Extract OVA, convert the 2 virtual disks to QCOW2.
Import the main disk(VeeamSA-disk-0) as QCOW2 image, and then deploy the VM(With a secondary empty disk) on our providers interface.
Upon booting the VM, it does not have the secondary disk(VeeamSA-disk-1) so it boots into emergency mode.

When i got here, i had to transfer then convert the secondary disk from QCOW2 to .img (i didn't want to transfer the file as .img since after converting it is seen as a 257GB file.)
So after i converted, i used dd to write the .img to the secondary disk - then i just had to import the disk/LVM etc. and then after a few adjustments i was able to boot up the appliance.


So, my conclusion here is, veeam could potential support more hosting providers, if this was made to a single QCOW disk, or single disk in OVA that could be converted and imported - when neither ISO or OVA is possible. (and yes, i know windows v13 is possible. But we wanted to run the appliance)
Kim Svane @ any.cloud
HannesK
Product Manager
Posts: 15818
Liked: 3520 times
Joined: Sep 01, 2014 11:46 am
Full Name: Hannes Kasparick
Location: Austria
Contact:

Re: VBR13 Appliance other platforms

Post by HannesK »

Hello,
it is not possible to load an ISO
yes, agree. Do you have remote console access in such environments or only serial console? I guess doing a network boot via PXE is also not an option?

Yes, based on customer demand, we consider providing more deployment options, but I cannot provide timelines or details yet.

Best regards
Hannes
ks.any.cloud
Service Provider
Posts: 55
Liked: 3 times
Joined: Mar 04, 2021 2:17 pm
Full Name: Kim Svane
Location: Denmark
Contact:

Re: VBR13 Appliance other platforms

Post by ks.any.cloud »

Hi Hannes

I have VNC access, but no PXE either.

Sounds good, would help many customers wanting to continue to use Veeam with other providers, sing agent backups - like us.
Kim Svane @ any.cloud
Post Reply

Who is online

Users browsing this forum: d.artzen, Semrush [Bot] and 84 guests