In the previous posts of this series, we completed the configuration of Veeam Availability Console and on-boarded our first customer. In this third part, we are going to access the Console as a new customer, to so learn what we can do there.
I got this request from a colleague, who was helping out a service provider with this scenario: vCloud Director is using an external LDAP service, coming from a local Microsoft Active Directory, to authenticate all vCD users. Is Veeam vCloud Director Self-Service portal able to use this authentication and allow those users to use the portal? Let’s find out (hint: yes it works!).
In the previous post of this series, we installed and started the configuration of Veeam Availability Console. In this second part, we are going to look at the rest of the initial configuration, and plan for the first customer onboarding.
As Veeam is soon to release the final version of a new solution, called Veeam Availability Console, I started to study this software, since it’s a key component of Veeam strategy for Service Providers, which is my main focus as a Veeam employee. In this series of posts, I will explore the software, its architecture, how it works, and what can be done with it. In this first post, we’ll start with a bit of theory, and we’ll see how to install and configure it.
Veeam Backup & Replication 9.5 has introduced a complete set of self-service capabilities for VMware vCloud Director users. Service providers can offer these features to their users, and users can perform backups and restores in a complete self-service way.
However, because of network restrictions that are often in place in vCloud Director environments, some features like Item restores are not possible. So, some service providers asked me if it was possible to remove the ITEMS tab in the portal, just to make the user experience of the portal easier. Or maybe a provider doesn’t want to offer these capabilities at all to its customers. Whatever is the use case, there’s a way to remove the tab. Just remember, this is totally unsupported!
I started to install VMware vCloud Director in my new lab, as I want to be ready to test the upcoming Veeam Cloud Connect Replication v10, with its native support for this cloud management platform. One of the requirements of vCloud Director is NSX, so I started with its installation. As I hit some errors in the “NSX Host Preparation” step, I learned how to fix them manually and how to automate a bit VIB deployments.
In my job, I have to learn a lot about multiple topics of IT. Especially in the virtualization market, many people are usually well prepared when it comes to infrastructure, servers and storage, but I found out that the weakest point is many times networking. There are some topics that are obscure for many, like Layer2 vs Layer3, BGP, Spanning Tree, but there is one topic that is really important even for infrastructure guys, yet it’s almost unknown to them: Latency.
During Veeam replication jobs, your vCenter triggers the VM MAC conflict alarm. This happens because when a VM replica is created, it has the same MAC address and UUID as the original VM. This situation is totally expected because a newly created replica is an absolute copy of the original VM with exactly the same properties. This doesn’t create any issue, since the replicated virtual machine is not powered on, but more importantly because vCenter changes both replica’s MAC address and UUID. So, the issue is gone after a few moments, but the alarm remains in the console and it may be annoying. So, here’s how you can suppress the alarm.