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.
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.