[V13] Question regarding Veeam B&R 13.x

[Didi7]

Hi guys,

I would like to give Veeam B&R 13.x a try. I suppose internal internet proxies should provide access to veeam.com at minimum (or only) to be able to upgrade JeOS appliance, proxies and repositories, right?

Regards,
Didi7

[Gostev]

Hi, the actual repository is repository.veeam.com as far as I remember, however there are some other endpoints involved in the check for updates on veeam.com too, so either allow veeam.com or you will need to allow a few endpoints granularly according to the documentation, like a few under *.butler.veeam.com or autolk.veeam.com

[Didi7]

Great and thanks for replying so fast.

Deployment here will start soon ...

Regards,
Didi7

[Didi7]

Ok, this is what i get, when deploying the *.ova VBR Software Appliance ...



Is this expected behavior, when deploying this on a StandAlone ESXi 8.x build 24859861 host?

Regards,
Didi7

[Dima P.]

Hi Didi7,

Checking, stay tuned...

[Didi7]

I am missing the license file for v13 within my accounts to activate the VBR Software Appliance as well? Am I to early?

And what about the Veeam B&R 13.x full Windows build? Is this released later?

Regards,
Didi7

[Gostev]

1/ There's no special V13 license file in principle, use the same one you're using for V12.
2/ This is covered in the sticky FAQ topic.

[Didi7]

Allright Gostev, acknowledged!

Currently I am experiencing login problems and I am sure the password I enter is correct! During installation I was asked several times to provide a recommended password and to activate MFA, everything was good. Now I struggle to login.

Furthermore a reboot problem of the Software Appliance after installation, it was hanging in a screen with something mentioning ...

Rebooting or Booting Veeam Software Appliance but nothing happened, so I had to reset the VM.

[Gostev]

We're happy to answer product questions here but for help troubleshooting any technical issues, kindly contact our Customer Support directly.

[Didi7]

No problem, I just mentioned what I discovered here today.

Well, I will again deploy the Appliance (*.ova) using our vCenter later and otherwise use the ISO instead, if I should get the above message again.

Maybe password problems will vanish as well.

I might deploy a fully Linux based VBR-environment into our production network very soon to get rid of Windows here.

[Gostev]

Meanwhile I have some updates from QA @Didi7

They managed to reproduce the original error about extra disk image, this is caused by standalone ESXi being unable to process a signature file. This appears to be a known limitation of standalone ESXi, for example they found an HPE KB article about this issue. You will not encounter this error when using vCenter.

However, the error does not affect VSA deployment and can just be ignored. So your password problem is unrelated.

[Didi7]

Good to know!

To be honest, I did not expect that the error deploying the *.ova in StandAlone ESXi was somehow related to the password problems

Thanks
Didi7

[Didi7]

Ok, I spend some more time in helpcenter.veeam.com to get a slight idea how things are working in or with VBR 13.x and there are some further questions arising ...


*** I really plan to get VSA working asap in our production environment, it's awesome ***


1) Instead of deploying VSA with the *.ova file, I suppose alternatively we could create e.g. a VMware virtual machine with 8 cores, 16GB RAM, 2 hard disks (each with 240GB at minimum) and configure the VM OS type to 'Rocky Linux 64-bit', correct? That's at least, what I did and so far it works.

2) Browsing through all the options in the VSA, so far I see no option to deploy a Veeam Proxy or Repository Linux VM from the appliance, just as I can do e.g. with the Nutanix Proxy Appliance in VBR, as long as the plug-in is installed. Instead we need to download the Veeam Infrastructure Appliance ISO file, create e.g. VMware VMs with OS type 'Rocky Linux 64-bit' and deploy a VM with the VIA ISO file, correct? Finally, those deployed VMs can be added as a Veeam VMware Proxy or Veeam Repository within the VSA appliance, right?

3) Are there plans to add the full deployment of those JeOS 'Rocky Linux 64-bit' infrastructure appliances to the VSA? I understand that the VSA is in an early stage and more features will be added later.

As we already planned to use Veeam Hardened repositories on physical servers, this VIA ISO file is already a big improvement, as things get more and more automated.

Congrats Veeam!

@Gostev:
Btw, it was no password problem, sorry my bad!

[Gostev]

Thank you for your kind words, I'm very happy to hear that you're enjoying my baby

1. Yes, that's works if you want to install from ISO instead of OVA.

2. Correct.

3. It's a possibility. It was simply easier to keep VSA and VIA separate as a first step. Besides, it keeps VIA ISO size much smaller, and considering VIA can be used with VBR V13 on Windows as well, small ISO makes it easier.

[Didi7]

If things like that turn out really that good, it is well deserved.

Thank you for confirming my questions. Will keep experimenting with your baby today

I understand that it makes sense to keep ISO file sizes small and both (the VSA and VIA) separated. Importing that additional VIA ISO file later into the VSA appliance as a plug-in or whatever would be fine as well for me, as long as things could be automated more and more, like what Veeam has done with the deployment of the Nutanix Proxy Appliance. Just an idea from my side.

I will let myself surprise ... Veeam has surprised me so many times, since I first had a chance to incorporate the product into our production environment more than 10 years ago.

Sadly a couple of years ago someone here in our company decided to replace Veeam's product with the backup software of another vendor, but I kept pace with Veeam's products in a none-production environment and legal licences. And now is the time to return to Veeam and VSA comes at the right time.

I really enjoy to work with Veeam's product. I think they are top notch and your blogs, forums and helpcenter speak for themselves.

Regards,
Didi7

[Didi7]

Wow, my thread was [V13]-d

Our initial production environment is in place, which means 1x VSA using *.ova and 3x VIA using the ISO on 'Rocky Linux (64-bit)' VMs (a lot more machines will be deployed). Spend more time looking around, what can be configured and how it looks like. Great so far.

I have seen there are already some feature requests, also from us! Which means Gostev's baby gets attention

For now we have another question regarding MFA ...

Let's assume the entry for a VSA or VIA machine in the authenticator app disappears or accidentially gets deleted, how can we re-add the entry. Only during initial setup we saw the qr-code. How do I get to view this again? Or what is the solution in this case?

Now, time for some weekend activities and drag away a little bit from VSA and VIA (hard weekend) :p

Regards,
Didi7

[Gostev]

If MFA entry is lost then you can no longer confirm your identity, therefore you cannot be allowed to self-reset MFA.
So in this case you will need another host administrator to reset MFA for you.

[Didi7]

Ok, weekend is finished now and so far what's not to like about the new VSA and VIA components in this early release

Regarding MFA => I think I found a suitable solution how to manage and save MFA entries for each new component.

The environment is constantly growing now each day.

Soon, I will start with Hardened Repositories using the VIA ISO.

Now my next question, the Hardened Repository will be installed on physical servers, in this case HPE Gen11 servers. What about the support of the HPE Agentless Management Service, which is essential for iLO-devices to work and which gives you surveillance of your underlying storage subsystem?

Regards,
Didi7

[Gostev]

@Andreas Neufert you may know the answer to this due to the related project you're working on? I did not think iLO needs anything in the OS because it works even before the OS is installed? In other words, I thought iLO is a "motherboard feature" like BIOS, PXE boot, RAID controller management etc.

[kaffeine]

I suppose HP iLO works like iDRAC from Dell: you can get by using only the OOB features which are completely independent from the OS and "belong" to motherboard layer or you can go a step further and deploy the OOB-agents on the OS directly to expand the feature-set further and allow stuff like capturing super detailed OS/Drivers/Apps infos, trigger a multitude of commands, and so on.

For a pure hardware monitoring the direct OOB data is pretty adequate, so I suppose @Didi7 is probably referring the OOB-agents' features that capture the detailed storage I/O speeds and so on.

[Didi7]

Good morning everybody,

well, in fact without HPE Agentless Management Service in OS it is not possible to observe the state of hdd's. That's the only thing I am interested in => is the storage subsystem healthy?

All other things are nice to have, but personally I am not interested in.

Without HPE AMS in OS you get the following state in HPE iLO4, iLO5 and iLO6 ...

[HannesK]

in fact without HPE Agentless Management Service in OS it is not possible to observe the state of hdd's

that's strange. As far as I see (and remember), the "storage" that is marked green covers the disk status. And I remember iLO has the disk status even if no operating system is installed.

[Didi7]

Hello HannesK, the above screenshot is just an example how it looks like, when you are in BIOS or Intelligent Provisioning.

I will check the state in a VIA-deployed physical machine as soon as possible, specifically will mails be sent via SMTP, when I unplug HDDs manually.

[JaySt]

iLO does not need AMS for hardware component health monitoring. Installing it on a OS does provide a bit more information to iLO itself and iLO can make that available through SNMP when that is used to query the iLO interface instead of the OS itself.
I would say it's not required. Allthough, would be nice to have the option for installing it.
Read a bit more here: https://docs.rockylinux.org/10/ko/guide ... /hpe_amsd/
Gen10 and higher only needs the amsd service on everything other than Redhat and Suse distributions. no drivers or firmwares are included for the others. Drivers come with the distributions.
A possible additional (additional to the extra OS information provided to iLO) advantage for having the ability to only install the amsd agent is reduced fan speeds. Thermals could be a bit better when present in the OS.

[Andreas Neufert]

My understanding is that without HPE AMS client in the OS, the ILO can understand that RAID is broken or a disk failed, but it can not read the SMART information from the disks. We are checking with HPE if this does only count for SATA or if AMS client is needed as well for the SAS/NVMe SMART monitoring.

[JaySt]

Here's the page of the ilo user guide stating the difference between with and without amsd, with a bit more detail. It's the iLO7 user guid, but the table is the same for iLO 5 and 6.
it shows SMART drive monitoring is available either way, but probably not with all combinations and types of drives. NVMe drive monitoring is available if it supports MCTP

https://support.hpe.com/hpesc/public/do ... 2FFB7.html

[rteglgaa]

Good morning everybody,

well, in fact without HPE Agentless Management Service in OS it is not possible to observe the state of hdd's. That's the only thing I am interested in => is the storage subsystem healthy?

All other things are nice to have, but personally I am not interested in.

Without HPE AMS in OS you get the following state in HPE iLO4, iLO5 and iLO6 ...

But would you even hook up iLO/DRAC/IMM on a hardened server? Most of these management interfaces can destroy RAIDs, remote control the OS, etc. straight from the management ip/web page, which is something you probably don't want available, if the server is supposed to be hardened.

/Rasmus

[Didi7]

Hi, today I continued with the integration of the new VIA-based Rocky 64-bit Linux VMs, which here will serve as VMware Proxies.

As far as I understand, you don't need any credentials to make VIA-based VMs available in your 'Managed Servers' environment, when using 'Certificate-based authentication', right? Just click add 'And Server' and then Linux and that is the requirement to make those VMs useable as Proxies or Repositories as is in the old Windows environment.

Adding VIA-based Rocky 64-bit Linux VMs here takes a little bit more than 4 minutes (same VLAN). Is this expected behavior?

Regards,
Didi7

[Gostev]

Correct, the initial connection to VIA is passwordless, this is well covered in the VIA section of the What's New document. And once you've registered VIA with Veeam, you can assign one or more backup infrastructure roles to it using the usual process.

@pma can you comment wrt. to 4 min time to register? Seems a bit too long given not much is going on there in the process.