VCD RoundTable

Hello and welcome.

This is the vCDRoundtable, Ep. 44.

And today's main topic is

VMware Cloud Director Availability.

While we are doing the live recording still in 2024,

you might already be in 2025 whenl you hear the podcast

of it due to the holidays.

So pick whatever you want to

do, either Happy Holidays, Happy

New Year, or whatever fits you.

So that being said, Matthias, welcome.

Yeah, welcome, everyone.

Looking forward to the recording, Sascha.

Yeah, welcome.

And yeah, Happy Holidays, Happy New Year, whatever.

Yeah, also from my side, Happy Holidays, Happy New Year,

and welcome to episode 44.

Good.

So today's topic was suggested by Sascha.

He wanted to talk a bit with all of us

about vCloud Director Availability.

So give it a go.

Yeah, with the new service provider program starting

April last year, so that was announced

that the VCDA is only available for disaster recovery

for all of the service providers who

are using it in the past, who had used it in the past.

And that's now changed.

And I think it's a good release now

that it is, again, on the price list.

So we have it on VCDA.

So we have VCDA and DR, on the price list,

on the product, VMware Live Recovery protected VM.

And I think it's a huge benefit

for a lot of service providers

because as we talked with service providers in the past,

they said clearly, "hey, we

want to start with Cloud Director.

We want to start with VCDA and not only for migration..."

because for migration only, it was still

on the price list as available for everyone for free.

So you can use it.

But now it's there also for the DR components.

It has a price tag or list price of $400 USD per VM.

So it's not cheap, but I think if you

have the real scenarios with your customers,

you can offer a great benefit to your customers.

But such a 400 per year.

Yes.

So every price, every list price on the Broadcom price list

for service providers is per year.

But keep in mind that's also--

it's an add-on.

And for add-ons, Broadcom only accepts commits.

Or did we get any different information

that this one is actually going to be a bit more flexible?

No, in the price list footnote, it says that

there is no on-demand for add-ons.

So that means you need to commit to your add-on,

but that also means you get your discounts on the add-on.

And with the new pricing model that you can only

do add-ons and expand/extend the commit

on a yearly base, so you have to pay yearly upfront.

OK, so enough of the license talk.

What can we use it for?

Yeah, so you are able to use it to do complete disaster

recovery scenarios so that you have, for example,

a customer running their complete environment on-prem

and only wants to use your

data center for disaster recovery

scenarios.

And so that means they're

syncing all of the virtual machines

in your data center.

And then you can start all of the virtual machines

in the case of a disaster.

I think that's actually-- so that's

one of the use cases we covered, I think,

before already in a previous podcast, the scenario

that this is a very common tool for migration services

as well, so that customers can actually use it.

Or service providers can use it to onboard customers

because it's pretty straightforward.

All the end customer needs to deploy,

whether it's for migration or

for disaster recovery purposes,

is to deploy an on-prem appliance, which you then

connect to your vCenter.

And then off you go, you can then

start replicating your virtual machines.

You can also move seed data with a hard disk

from on-prem to the cloud.

So for the bandwidth impaired

people, let's call it like that.

If they can't actually get their...

that was not funny, Matthias...

and that they can actually send in hard disks

so that you have the initial

seed data on the central system.

And stuff like that.

So those are possibilities to make the overall data

movement a bit easier.

What you can also do in the past,

that was an extra cost, because NSX layer 2 VPN

was an extra feature or was only

included in the upper licenses.

As we have all of that included now,

you can now establish L2 VPNs for your VCDA scenarios,

more or less included.

So that gives you also the ability

if you do a step-by-step migration of a customer

to establish layer 2 VPN with the help of VCDA,

and then actually move VM by VM over,

and then finally switch over central routing and things

like that.

So this is still, from a migration perspective,

a very attractive solution.

When we look at the architecture,

you don't need any additional VPN or stuff like that.

All of that comes out of the box.

The initial setup, I would say, is not necessarily

100% straightforward.

There are a few hiccups here and there,

which you need to master to work around when it comes down

to licensing, certificate changes, and stuff like that.

You really need to think about all the different components

and bits and pieces of the system, which is not always

that, let's say, intuitive from that perspective.

But it gives you that capability as well.

So that is, from an overall setup perspective,

pretty easy.

You have different components-- the tunnel, the manager,

and the replication services.

Replication services are required per cluster

that you establish them.

But overall, it's pretty straightforward and simple

design, from that perspective.

Anything you want to add, Matthias?

Yeah, a few thoughts from my side,

because more from a technical perspective,

the first -- what I would advise if you are talking

about the replication appliance

which provides the replication

services per cluster, please

make sure that that virtual machine

has enough CPU resources.

So because of the three virtual machines we have,

the replication appliance is the one really consuming tons

and tons and tons of CPU cycles.

So either make sure the virtual machine has a high priority

in terms of shares or even reserve the CPUs for that VM,

because otherwise, you will

have a big or massive performance

impact.

Resulting in customers complaining about,

I try to replicate in virtual machines, but it takes ages.

Another, from a technical standpoint of view, topic that

I would like to cover is not the replication bit.

It's more the cloud to cloud bit,

because you can use VCDA to replicate or migrate

workloads between cloud infrastructures.

I think that's interesting for our CSP folks running

multiple vCD instances, or even a single vCD

instance with multiple data

centers spread across a certain area.

If you replicate vApps--

I'm now skipping virtual machines because the topic is not

related to VMs.

It's a vApp specific topic.

Not all vApp properties are replicated.

So before starting that game, you need

to test if all the features you're using within the vApps

are replicated.

So my main thoughts are like, vApp edges...

vApp edges are not replicated.

It's an issue sometimes.

So you need to have an automation in place,

even if the automation is called

"Sascha, who tracks down the changes

and configurations in that area."

No.

Another important topic is that specific vApp network

configurations are not replicated.

And one of the biggest bugger

is the Guest VLAN-allowed flag.

If you have vApp networks

with the Guest VLAN-allowed flag,

this flag is not replicated.

I know it's just a minor setting,

but it could cause major issues.

So before doing the

cloud-to-cloud thing and dealing with vApps,

test all the features you are using.

Otherwise, you might end up in

hours and hours of troubleshooting.

But you like hours and hours of troubleshooting.

Yes, I know.

Don't get it wrong.

So VCDA is a great product if you know to deal with it.

The logs are pretty good because

they tell you exactly what the issue is.

And you need to get used of

the VCDA product behavior itself.

If we're now changing topics again.

So you install, you deploy VCDA, you

deploy all the virtual machines you need

at the service provider side,

maybe at the customer side, wherever,

but especially on the CSP side --

please stick with the deploy order

from the documentation. Otherwise, it's not working.

It's that simple.

You need to get used to how to handle the certificates.

Because you need to start with the replication.

It's not the replication.

It's the replication manager appliance.

And then you trust the certificates

from Cloud Director, from the vCenter.

So because VCDA relies on the SSO of the vCenter,

you need to trust all the certificates

and you add the replication appliance.

You need to do the exact same

thing on the replication appliance.

Then you deploy the tunnel appliances, one or many.

You need to do the exact same

thing on the tunnel appliances

and accept the certificates vice versa back and forth.

You need to get used to that procedure.

Because as soon as you change a certificate somewhere,

like in the vCenter, because it just expired, that simple,

you need to start over and over

and over trusting certificates.

It's a lot easier if you use a proper PKI,

because then it's implicitly trusted.

If you trust the root, it's easier to handle.

So the certificates are

challenging, but you get used to it.

But that's what I meant with the log files.

If VCDA is not working for any

reason, so something got disconnected,

and you look into the log files,

it tells you exactly which

certificate is not working anymore

and which connection is not trusted.

And the biggest issue in the game

is still the vCenter SSO connection.

If this one is not working, it's not

really telling you what is not working,

but rather VCDA refuses to do anything.

So the log files are key.

And of course, the net rule.

If you remember playing around with

the net rule for the tunnel appliance,

if the net is not in place, you

can't get a replication up and running.

Even though if you use it on-prem,

you kind of build a fake net rule to tease something

and get VCDA up and running

because that is something which is key,

at least currently.

So you can work around that.

These are just some technical insights.

So on the other hand, if you use

it within your own infrastructure,

it's not a big deal having a

throughput of like 10 gigabits in VCDA.

It just consumes all the CPUs it has,

but it's doing 10 gigabits

because we have just 10 gigabits at some point.

Maybe it could do even more, but that's pretty cool.

And of course, it's just integrated into the Cloud Director UI.

You just click on more, go to VCDA, and

configure outgoing incoming replication,

whatever you need.

So from a user perspective, it's simple.

It's integrated, and it's straightforward.

And you know exactly what you're doing as a user.

Like, am I trying to migrate a workload,

or is my intention to create a

disaster recovery replication,

including RPO, RTO, what's the sync interval,

as Yves already mentioned, like some bandwidth

throttling, whatever is needed.

So it's simple.

It's straightforward.

There is no need for a CSP to write like

pages and pages and pages of instructions

for their customers to reduce

support tickets and questions like,

"oh, how am I using the product (and stuff like this)?"

So I still love it.

Any thoughts, Toby? Yeah, at the underlying

infrastructure, as you actually mentioned already,

since VCDA is utilizing the same

stack like vSphere replication,

at the end, the replication appliances

are some sort of vSphere replication.

Please, be aware that you need to

enable the VM kernel services on your ESXi.

Otherwise, you run into the issue

that you don't have a replication.

That's a good one.

But also, which is a great one

on one hand, because for ages,

I think something around 6.5, there have been vSphere 6.5,

we have now also the possibility to enable a vSphere

replication dedicated VM kernel port,

which also brings me the great

opportunity to separate my traffic from my,

let's call it frontend network, where

really my VMs have the communication path.

So I can really separate also

the whole replication traffic.

And everyone, please have in mind, and

this more and more comes into the game

with the latest updates from vSphere

itself, that the VM kernel adapter

or the management VM kernel adapter

really now becomes more and more the limitation

of roughly about 400, 500 megabits

per second, which is a hardcore limit.

It's not the limit which is solved where we can

reconfigure, what we can reconfigure,

because now all of the backend

services like backup, so the VADP

proxy and stuff like this can now

run on dedicated VM kernel adapters.

That's more the reason why the management

VM kernel now has really the bandwidth limit.

So please do not utilize the

management stack for all of the "story."

Enable a dedicated VM kernel port for

the whole vSphere replication story,

and then you get much more performance.

And also, as Matthias mentioned, you need to, on one hand,

you can work with CPU reservation

or you deploy more replication appliances.

Depends what your... yeah, you can.

Tunnel. Tunnel appliances, yeah, sorry.

But the replication consumes the CPU...

Yeah. But nevertheless, yeah, if you need,

if you have many sessions to your

customers on-prem, for example, Toby, that's true.

If you have many sessions,

please deploy more Tunnel appliances.

And the Tunnel appliances also

supports an HA configuration.

So I think that that's also very

interesting if you're losing an ESXi

or if you're losing an appliance for whatever reason,

have at least a second one in place for HA.

But I think in that case, you need a load balancer.

You need a load balancer. Yeah.

You need to have load balancer in front,

which is currently still something I can say,

talking about VCF, we can

still utilize the NSX load balancer.

If we go with the ALB, we can utilize ALB or Avi, sorry,

it's not ALB anymore, it's Avi

And on the other hand, we can also

utilize any kind of hardware appliances

or hardware load balancers

like Fortinet and stuff like this.

Talking, or utilize this, place it

in front of your Tunnel appliances.

Tunnel server appliances.

Talking about certificates, you mentioned before, Matthias.

There is a solution, it's called VMware Cloud Foundation.

And inside Cloud Foundation, we

have a proper certificate integration,

also certificate exchange or replay store is there.

So maybe our service provider should have a look into VCF.

But is VCDA part of VCF?

No, but the certificate in the

backend where I connect my VCDA.

Okay, you mean using VCF as an intermediary? Yes.

That makes perfect sense, yeah.

I think, and also, but there I'm not really 100% sure,

is VCDA part of the Cloud Provider Lifecycle Manager?

I think yes.

I think it's VCP LCM.

VCP LCM, is there VCDA embedded?

Yep.

Then you would also have the perfect solution for replacing

certificates on VCD and VCDA on the other hand.

So you can also utilize the VMware

Cloud Provider Lifecycle Manager.

Then you have also there Day 2 operations for certificates.

I like Lifecycle Manager.

Lifecycle Manager is like...

Yeah, yeah.

So I respect everyone's opinion.

Matthias is not a big fan of automation as

long as he hasn't done the automation himself.

That's true.

A lot of automation and even VCP LCM is

a great product, but it still has issues.

It's not working as smooth as I would love to have it.

Especially the repository management is a PITA.

Done it, been there, figured out how

it works without any documentation.

Sorry to say, but guys, we're honestly speaking over here.

Yeah, I highly recommend for that, because it is a little

bit tough with the NFS server and stuff like this.

But I highly recommend the blog post from Tomas Fojta.

Tomas is working.

Let's say 80%.

But see, that's not...

He doesn't have that.

But if you are a customer and actually get automation done

by Matthias, they are no

shortcomings, no hiccups, no nothing with them.

They always run 100% perfectly.

Or there is no chance to troubleshoot it yourself at all.

That must definitely work easily because, as I learned from

you, good code documents itself.

Absolutely.

Dude, we had the discussion on Monday.

At least I refused doing a change, that's correct.

But at least I added a comment that

I did a change and what I changed.

I'm still refusing to do the change, but I commented it.

I made the comment in your name.

No.

No, no, no.

I think VCDA, coming back to our

story, is a valid and good solution.

What people should keep in mind also, even though we now

have a lot of flexibility when it comes down to restore

points for the DR part, this is

not replacing a backup solution.

No.

This is not meant to provide you with any kind like

application safe backups, application wear backups, or file

level recovery, or any of these things.

This is just a migration and DR solution.

This is very, very important because if you're solely,

actually, depending on this one, you might get a surprise.

If something doesn't work, you always should have a proper

backup solution, which typically comes back to the argument,

from me, that you then actually might not have both in one.

All of it has advantages and disadvantages.

Yes, having backup and DR solution in one

solution makes sense to a certain degree.

The other way around makes sense as well.

In the end, it's up for your specific decision.

And for your specific use case, you could also have

something where you have a local

backup somewhere, which you have access to.

And then you have DR to the cloud and/or versa.

Those are all possibilities.

By the way, you can also, it's not only that you can use

this as a DR on-prem to the cloud or cloud to cloud, you

could also build DR cloud to on-prem.

So if you are moving into the cloud and you want to be sure

that at any point in time, you could actually reactivate

your local data center, you could build it and set it up

like that as well, considering that

your service provider allows you to.

But technically, this is possible.

Technically, it would even be

possible to do this between service provider.

There is just one interface missing for that, which we are

aware as and provided up until today.

But in theory, you could clearly

use this between two cloud providers.

One thing to add, because, yes, as you mentioned, there are

many, many solutions available which provide backup and

replication also from a cloud

provider, Cloud Director, not cloud provider...

but from a CloudDdirector perspective, what I would like to

mention here, this is on one hand, from my perspective,

a big advantage of VCDA, is that VCDA

is not relying on any kind of snapshot.

So you can do the replication

directly integrated in the stack.

So you don't need to utilize any kind of snapshot

technology or any kind of snapshot on your virtual

machines, which is a big advantage

compared to other third-party solutions.

On the source side?

On the source side.

On the source side, yes.

Our side is snapshots. I just wanted to be sure.

But mainly I care about the source side because still, also

with the improvement of vSAN... and vVols and stuff

like this, we still see or we still know that snapshots can

sometimes be a little bit of a

pain regarding performance.

And before we come to an end, we still make to announce a

change. Guys, it was wrong. So VCDA is not part of VCD LCM

Okay.

So to say VCDA is standalone. It's not part of SDDC

manager. It's not part of VCD LCM.

So VCDA currently has no lifecycle

management built around the product.

If we say something wrong, we need to change it.

Yeah, I was actually also of the opinion that it was

included and that it would automatically roll out into

certificate management. But so

then I'm sure that I'm wrong.

That'd be so great.

Yeah, I mean, it's I wouldn't as it's currently not there.

It's not going to come anymore. That's the only thing which

we can be sure for certain, because with the end of life

announcements of vCD and everything else.

But what we learned is never say never.

Yeah, in this in this scenario it's...

Right. Yeah, I heard that before.

I mean, it's in the past when we had the Aria Automation

story or back then vCAC to VCD that those were scenarios

where it is different. And as I said already in the videos,

which we provided to our Challenge Days and Architecture

Think Tank audience and the communities.

I would actually bet very highly that

VCD 10.6 is going to be the latest release. We will see

just patches that it that's it. That's done. That's gone.

And I would actually also, not 100% sure about all

the things on the Aria Automation side, because Broadcom and

CA also has an automation platform, which has a far greater

integration into many, many other products.

But that's a completely different story. But when you look

at VCD, I think it's only a

question of the timeline is going to stick.

But that it's going to go away is very, very clear. The

announcement have been very, very clear. Broadcom has been

very, very clear towards customers in some enterprise

customers who are using VCD that they need to start looking

into something else because it's going to go away.

So that is nothing I question at this point in time. So I

would really take a good bet on that it's only a

matter of if it's going to be '26, '27, or '28.

But it's only a matter if it's going to

be one or two years longer. But that's it.

Yes.

Yes.

Okay. Now we need a new title for our Roundtable as well.

Yeah, for sure. Before we close it also, please be aware

that by the 30th of January, 2025 all VMware.com

links will be decommissioned.

So especially the docs. will not be available anymore.

There will be also no forwarding.

So please change all of your links to techdocs.broadcom.com

com dot com because the sites will be decommissioned as

late as January 30.

Yes.

That is so true.

And it's also it was at least in one note, which I have

seen. I'm not sure if you saw the same Toby. At the same

point in time, at least what I saw is Broadcom is going to

discontinue all, let's say, end of life and of service

documentation as long as you are not in extended support.

Yes.

Yes. All knowledge base, all everything. So, for example,

if you still if you have vSphere 6.5 extended

support, you can still get documentation. The space

articles, if you are not in extended

support, all of that will be gone as well.

Yeah, it'll all be gone, and only if

you have acquired extendedsupport, will you still get the

documentation. So there will be a huge

cleanup coming up, or depending on the VCD release,

have been in the in the last week. So, yeah.

But this is very important for those customers who are

still sticking around on all outdated versions, it's like if

you were depending on doing your own support because you

don't have support or anything like that anymore,

be prepared that all of this is going to be a lot more

interesting, because you will not

necessarily get access to the documentation anymore.

And especially the whole... and still we know that some

some guys are still running it, the

whole NSX vSphere story is also now gone.

Now it is gone. Depends when you see the

episode. So there will be no downloads anymore. There will

be no documentation anymore for NSX for vSphere. So this is

also something which has been

changed with the 31st of December.

Good. Any other final words, Matthias?

We still love certificates.

You are the expert for

certificates. No, I'm not. I just love them.

If you have any questions, I think you're also.

The expert at drawing three red

perpendicular lines with transparent ink.

Yes, I think you're totally also marked for the holidays.

that any issues with certificates

will actually be escalated to you.

Hopefully I'm so looking forward to it.

Sascha, take him for that one. I'm pretty

sure you will find something.

Of course there will be something. It's always the same.

Sascha, final words.

Yeah, take a look at VCDA. Maybe it's a good opportunity

for you and your customers to grow a bit of your business.

And if you have questions, feel free to reach out to us.

Toby

Yeah, thanks for listening. As

Sascha mentioned, have a look into VCDA.

Yeah, that's it for, from my side, for episode 44. Yves.

Yeah, thank you all for listening. Thank you for 2024 for

all the ones who have been live

listening or later on listening into the podcast.

As we, as the team gets together for our comdivision

kickoff in 2025, we will also revisit the format of this

one and actually see how we can make this more interesting.

There have been already a few ideas been submitted, how we

can actually make this more focused on you, the community.

So we are looking forward to that one.

Next year is going to be a lot of news around VCF and many

other things on how we integrate these with VCD still.

How the new multi-tenancy for VCF is going to look

like. All of these things. So there will be a lot of

topics. So I can imagine that we might even have more than

just one or two episodes per month.

And we try to build at the beginning of the year, maybe a

schedule with dates already so that

it's easier for you to follow in live.

Thank you all for listening. If you are listening in live

or before the holidays, have a wonderful holiday and a

great start in 2025. And if not, still, happy New Year.