1 01:00:00,133 --> 01:00:02,333 Hello and welcome. 2 01:00:02,333 --> 01:00:08,500 This is the vCDRoundtable, Ep. 44. 3 01:00:08,500 --> 01:00:10,500 And today's main topic is 4 01:00:10,500 --> 01:00:13,266 VMware Cloud Director Availability. 5 01:00:13,699 --> 01:00:16,366 While we are doing the live recording still in 2024, 6 01:00:16,733 --> 01:00:20,333 you might already be in 2025 whenl you hear the podcast 7 01:00:20,333 --> 01:00:22,066 of it due to the holidays. 8 01:00:22,866 --> 01:00:24,699 So pick whatever you want to 9 01:00:24,699 --> 01:00:27,000 do, either Happy Holidays, Happy 10 01:00:27,000 --> 01:00:28,800 New Year, or whatever fits you. 11 01:00:29,500 --> 01:00:32,733 So that being said, Matthias, welcome. 12 01:00:34,433 --> 01:00:35,533 Yeah, welcome, everyone. 13 01:00:36,933 --> 01:00:39,133 Looking forward to the recording, Sascha. 14 01:00:40,699 --> 01:00:41,300 Yeah, welcome. 15 01:00:42,933 --> 01:00:47,233 And yeah, Happy Holidays, Happy New Year, whatever. 16 01:00:50,533 --> 01:00:53,933 Yeah, also from my side, Happy Holidays, Happy New Year, 17 01:00:53,933 --> 01:00:56,900 and welcome to episode 44. 18 01:00:59,900 --> 01:01:00,133 Good. 19 01:01:00,500 --> 01:01:03,333 So today's topic was suggested by Sascha. 20 01:01:03,800 --> 01:01:05,933 He wanted to talk a bit with all of us 21 01:01:06,033 --> 01:01:08,199 about vCloud Director Availability. 22 01:01:09,300 --> 01:01:10,533 So give it a go. 23 01:01:11,033 --> 01:01:13,933 Yeah, with the new service provider program starting 24 01:01:14,500 --> 01:01:18,233 April last year, so that was announced 25 01:01:18,433 --> 01:01:22,933 that the VCDA is only available for disaster recovery 26 01:01:23,366 --> 01:01:27,266 for all of the service providers who 27 01:01:27,266 --> 01:01:31,333 are using it in the past, who had used it in the past. 28 01:01:31,766 --> 01:01:33,699 And that's now changed. 29 01:01:34,233 --> 01:01:37,900 And I think it's a good release now 30 01:01:38,000 --> 01:01:40,699 that it is, again, on the price list. 31 01:01:41,000 --> 01:01:42,599 So we have it on VCDA. 32 01:01:42,933 --> 01:01:47,300 So we have VCDA and DR, on the price list, 33 01:01:47,866 --> 01:01:51,599 on the product, VMware Live Recovery protected VM. 34 01:01:52,766 --> 01:01:57,666 And I think it's a huge benefit 35 01:01:57,666 --> 01:01:59,199 for a lot of service providers 36 01:01:59,333 --> 01:02:02,500 because as we talked with service providers in the past, 37 01:02:02,500 --> 01:02:04,300 they said clearly, "hey, we 38 01:02:04,300 --> 01:02:06,133 want to start with Cloud Director. 39 01:02:06,133 --> 01:02:11,233 We want to start with VCDA and not only for migration..." 40 01:02:11,466 --> 01:02:15,066 because for migration only, it was still 41 01:02:15,066 --> 01:02:18,066 on the price list as available for everyone for free. 42 01:02:18,066 --> 01:02:20,000 So you can use it. 43 01:02:21,466 --> 01:02:24,933 But now it's there also for the DR components. 44 01:02:24,933 --> 01:02:31,400 It has a price tag or list price of $400 USD per VM. 45 01:02:32,633 --> 01:02:38,466 So it's not cheap, but I think if you 46 01:02:38,466 --> 01:02:40,699 have the real scenarios with your customers, 47 01:02:41,199 --> 01:02:44,866 you can offer a great benefit to your customers. 48 01:02:45,733 --> 01:02:47,933 But such a 400 per year. 49 01:02:48,766 --> 01:02:49,000 Yes. 50 01:02:51,000 --> 01:02:54,966 So every price, every list price on the Broadcom price list 51 01:02:54,966 --> 01:02:56,699 for service providers is per year. 52 01:02:58,566 --> 01:03:00,400 But keep in mind that's also-- 53 01:03:00,733 --> 01:03:01,366 it's an add-on. 54 01:03:01,633 --> 01:03:05,633 And for add-ons, Broadcom only accepts commits. 55 01:03:05,933 --> 01:03:08,033 Or did we get any different information 56 01:03:08,233 --> 01:03:12,000 that this one is actually going to be a bit more flexible? 57 01:03:12,699 --> 01:03:16,633 No, in the price list footnote, it says that 58 01:03:16,633 --> 01:03:20,366 there is no on-demand for add-ons. 59 01:03:21,833 --> 01:03:26,166 So that means you need to commit to your add-on, 60 01:03:26,599 --> 01:03:31,599 but that also means you get your discounts on the add-on. 61 01:03:34,633 --> 01:03:41,233 And with the new pricing model that you can only 62 01:03:41,233 --> 01:03:48,366 do add-ons and expand/extend the commit 63 01:03:48,533 --> 01:03:52,633 on a yearly base, so you have to pay yearly upfront. 64 01:03:57,433 --> 01:03:59,866 OK, so enough of the license talk. 65 01:03:59,866 --> 01:04:00,833 What can we use it for? 66 01:04:04,000 --> 01:04:08,000 Yeah, so you are able to use it to do complete disaster 67 01:04:08,233 --> 01:04:11,166 recovery scenarios so that you have, for example, 68 01:04:11,199 --> 01:04:13,900 a customer running their complete environment on-prem 69 01:04:14,466 --> 01:04:16,400 and only wants to use your 70 01:04:16,400 --> 01:04:18,666 data center for disaster recovery 71 01:04:18,933 --> 01:04:19,666 scenarios. 72 01:04:20,699 --> 01:04:23,699 And so that means they're 73 01:04:23,699 --> 01:04:25,400 syncing all of the virtual machines 74 01:04:25,400 --> 01:04:26,400 in your data center. 75 01:04:27,199 --> 01:04:30,033 And then you can start all of the virtual machines 76 01:04:30,266 --> 01:04:31,633 in the case of a disaster. 77 01:04:35,133 --> 01:04:37,433 I think that's actually-- so that's 78 01:04:37,433 --> 01:04:39,433 one of the use cases we covered, I think, 79 01:04:39,566 --> 01:04:44,599 before already in a previous podcast, the scenario 80 01:04:44,933 --> 01:04:48,366 that this is a very common tool for migration services 81 01:04:48,366 --> 01:04:51,266 as well, so that customers can actually use it. 82 01:04:51,699 --> 01:04:54,466 Or service providers can use it to onboard customers 83 01:04:54,599 --> 01:04:55,900 because it's pretty straightforward. 84 01:04:56,266 --> 01:04:58,366 All the end customer needs to deploy, 85 01:04:58,366 --> 01:04:59,699 whether it's for migration or 86 01:04:59,699 --> 01:05:01,366 for disaster recovery purposes, 87 01:05:01,933 --> 01:05:05,400 is to deploy an on-prem appliance, which you then 88 01:05:05,466 --> 01:05:06,533 connect to your vCenter. 89 01:05:07,300 --> 01:05:09,599 And then off you go, you can then 90 01:05:09,633 --> 01:05:12,666 start replicating your virtual machines. 91 01:05:12,666 --> 01:05:15,666 You can also move seed data with a hard disk 92 01:05:15,666 --> 01:05:16,966 from on-prem to the cloud. 93 01:05:17,199 --> 01:05:19,166 So for the bandwidth impaired 94 01:05:19,166 --> 01:05:21,033 people, let's call it like that. 95 01:05:22,033 --> 01:05:23,933 If they can't actually get their... 96 01:05:26,099 --> 01:05:27,533 that was not funny, Matthias... 97 01:05:29,633 --> 01:05:32,333 and that they can actually send in hard disks 98 01:05:32,333 --> 01:05:33,599 so that you have the initial 99 01:05:33,599 --> 01:05:36,599 seed data on the central system. 100 01:05:37,133 --> 01:05:38,233 And stuff like that. 101 01:05:38,233 --> 01:05:42,099 So those are possibilities to make the overall data 102 01:05:42,233 --> 01:05:43,733 movement a bit easier. 103 01:05:44,699 --> 01:05:47,599 What you can also do in the past, 104 01:05:47,599 --> 01:05:51,266 that was an extra cost, because NSX layer 2 VPN 105 01:05:51,500 --> 01:05:53,566 was an extra feature or was only 106 01:05:53,566 --> 01:05:55,033 included in the upper licenses. 107 01:05:55,666 --> 01:05:57,800 As we have all of that included now, 108 01:05:57,800 --> 01:06:04,366 you can now establish L2 VPNs for your VCDA scenarios, 109 01:06:04,500 --> 01:06:05,599 more or less included. 110 01:06:06,333 --> 01:06:07,900 So that gives you also the ability 111 01:06:07,900 --> 01:06:10,366 if you do a step-by-step migration of a customer 112 01:06:10,533 --> 01:06:15,699 to establish layer 2 VPN with the help of VCDA, 113 01:06:16,099 --> 01:06:18,300 and then actually move VM by VM over, 114 01:06:18,500 --> 01:06:21,633 and then finally switch over central routing and things 115 01:06:21,633 --> 01:06:22,133 like that. 116 01:06:22,500 --> 01:06:25,866 So this is still, from a migration perspective, 117 01:06:26,066 --> 01:06:27,900 a very attractive solution. 118 01:06:29,900 --> 01:06:31,400 When we look at the architecture, 119 01:06:31,599 --> 01:06:34,599 you don't need any additional VPN or stuff like that. 120 01:06:34,666 --> 01:06:36,300 All of that comes out of the box. 121 01:06:37,666 --> 01:06:42,400 The initial setup, I would say, is not necessarily 122 01:06:42,500 --> 01:06:43,800 100% straightforward. 123 01:06:43,800 --> 01:06:45,500 There are a few hiccups here and there, 124 01:06:45,500 --> 01:06:49,633 which you need to master to work around when it comes down 125 01:06:49,699 --> 01:06:53,666 to licensing, certificate changes, and stuff like that. 126 01:06:53,666 --> 01:06:56,733 You really need to think about all the different components 127 01:06:56,900 --> 01:07:00,533 and bits and pieces of the system, which is not always 128 01:07:00,699 --> 01:07:03,633 that, let's say, intuitive from that perspective. 129 01:07:04,500 --> 01:07:06,933 But it gives you that capability as well. 130 01:07:08,066 --> 01:07:13,133 So that is, from an overall setup perspective, 131 01:07:13,533 --> 01:07:14,366 pretty easy. 132 01:07:15,300 --> 01:07:17,933 You have different components-- the tunnel, the manager, 133 01:07:18,333 --> 01:07:20,099 and the replication services. 134 01:07:20,099 --> 01:07:22,533 Replication services are required per cluster 135 01:07:23,433 --> 01:07:24,566 that you establish them. 136 01:07:25,033 --> 01:07:29,066 But overall, it's pretty straightforward and simple 137 01:07:29,133 --> 01:07:30,199 design, from that perspective. 138 01:07:36,300 --> 01:07:37,833 Anything you want to add, Matthias? 139 01:07:40,266 --> 01:07:42,266 Yeah, a few thoughts from my side, 140 01:07:42,266 --> 01:07:46,033 because more from a technical perspective, 141 01:07:46,433 --> 01:07:48,966 the first -- what I would advise if you are talking 142 01:07:48,966 --> 01:07:50,199 about the replication appliance 143 01:07:50,199 --> 01:07:51,599 which provides the replication 144 01:07:51,599 --> 01:07:54,733 services per cluster, please 145 01:07:54,733 --> 01:07:57,066 make sure that that virtual machine 146 01:07:57,066 --> 01:07:58,699 has enough CPU resources. 147 01:07:59,599 --> 01:08:02,433 So because of the three virtual machines we have, 148 01:08:02,466 --> 01:08:07,666 the replication appliance is the one really consuming tons 149 01:08:07,666 --> 01:08:10,099 and tons and tons of CPU cycles. 150 01:08:12,099 --> 01:08:15,933 So either make sure the virtual machine has a high priority 151 01:08:15,933 --> 01:08:22,566 in terms of shares or even reserve the CPUs for that VM, 152 01:08:22,566 --> 01:08:23,899 because otherwise, you will 153 01:08:23,899 --> 01:08:25,899 have a big or massive performance 154 01:08:25,899 --> 01:08:26,466 impact. 155 01:08:28,466 --> 01:08:30,433 Resulting in customers complaining about, 156 01:08:30,466 --> 01:08:33,733 I try to replicate in virtual machines, but it takes ages. 157 01:08:36,600 --> 01:08:40,399 Another, from a technical standpoint of view, topic that 158 01:08:40,466 --> 01:08:44,600 I would like to cover is not the replication bit. 159 01:08:44,800 --> 01:08:46,666 It's more the cloud to cloud bit, 160 01:08:47,466 --> 01:08:50,899 because you can use VCDA to replicate or migrate 161 01:08:50,899 --> 01:08:52,899 workloads between cloud infrastructures. 162 01:08:53,733 --> 01:08:58,399 I think that's interesting for our CSP folks running 163 01:08:58,500 --> 01:09:04,633 multiple vCD instances, or even a single vCD 164 01:09:04,633 --> 01:09:06,333 instance with multiple data 165 01:09:06,333 --> 01:09:09,500 centers spread across a certain area. 166 01:09:11,433 --> 01:09:14,133 If you replicate vApps-- 167 01:09:15,000 --> 01:09:18,533 I'm now skipping virtual machines because the topic is not 168 01:09:18,533 --> 01:09:19,500 related to VMs. 169 01:09:19,699 --> 01:09:22,633 It's a vApp specific topic. 170 01:09:23,466 --> 01:09:26,899 Not all vApp properties are replicated. 171 01:09:28,733 --> 01:09:31,466 So before starting that game, you need 172 01:09:31,466 --> 01:09:35,266 to test if all the features you're using within the vApps 173 01:09:35,466 --> 01:09:36,333 are replicated. 174 01:09:37,133 --> 01:09:40,733 So my main thoughts are like, vApp edges... 175 01:09:42,466 --> 01:09:44,000 vApp edges are not replicated. 176 01:09:44,866 --> 01:09:48,600 It's an issue sometimes. 177 01:09:48,600 --> 01:09:51,966 So you need to have an automation in place, 178 01:09:52,500 --> 01:09:54,966 even if the automation is called 179 01:09:54,966 --> 01:09:57,933 "Sascha, who tracks down the changes 180 01:09:57,933 --> 01:09:59,500 and configurations in that area." 181 01:10:00,800 --> 01:10:01,000 No. 182 01:10:03,600 --> 01:10:11,600 Another important topic is that specific vApp network 183 01:10:11,600 --> 01:10:13,600 configurations are not replicated. 184 01:10:14,600 --> 01:10:16,266 And one of the biggest bugger 185 01:10:16,266 --> 01:10:19,733 is the Guest VLAN-allowed flag. 186 01:10:20,699 --> 01:10:22,199 If you have vApp networks 187 01:10:22,199 --> 01:10:23,899 with the Guest VLAN-allowed flag, 188 01:10:24,333 --> 01:10:25,966 this flag is not replicated. 189 01:10:27,500 --> 01:10:29,133 I know it's just a minor setting, 190 01:10:29,133 --> 01:10:32,500 but it could cause major issues. 191 01:10:34,199 --> 01:10:36,800 So before doing the 192 01:10:36,800 --> 01:10:39,100 cloud-to-cloud thing and dealing with vApps, 193 01:10:39,899 --> 01:10:42,033 test all the features you are using. 194 01:10:42,033 --> 01:10:44,600 Otherwise, you might end up in 195 01:10:44,600 --> 01:10:46,466 hours and hours of troubleshooting. 196 01:10:51,300 --> 01:10:53,366 But you like hours and hours of troubleshooting. 197 01:10:54,533 --> 01:10:56,566 Yes, I know. 198 01:10:56,566 --> 01:10:59,800 Don't get it wrong. 199 01:10:59,800 --> 01:11:03,300 So VCDA is a great product if you know to deal with it. 200 01:11:04,399 --> 01:11:08,266 The logs are pretty good because 201 01:11:08,266 --> 01:11:11,899 they tell you exactly what the issue is. 202 01:11:12,933 --> 01:11:14,800 And you need to get used of 203 01:11:14,800 --> 01:11:17,433 the VCDA product behavior itself. 204 01:11:17,500 --> 01:11:20,500 If we're now changing topics again. 205 01:11:21,933 --> 01:11:24,500 So you install, you deploy VCDA, you 206 01:11:24,500 --> 01:11:26,399 deploy all the virtual machines you need 207 01:11:26,466 --> 01:11:28,966 at the service provider side, 208 01:11:28,966 --> 01:11:30,899 maybe at the customer side, wherever, 209 01:11:31,800 --> 01:11:33,733 but especially on the CSP side -- 210 01:11:35,199 --> 01:11:37,733 please stick with the deploy order 211 01:11:38,466 --> 01:11:41,333 from the documentation. Otherwise, it's not working. 212 01:11:41,899 --> 01:11:42,633 It's that simple. 213 01:11:43,500 --> 01:11:47,199 You need to get used to how to handle the certificates. 214 01:11:49,199 --> 01:11:54,899 Because you need to start with the replication. 215 01:11:54,899 --> 01:11:55,600 It's not the replication. 216 01:11:55,600 --> 01:11:57,633 It's the replication manager appliance. 217 01:11:59,033 --> 01:12:01,833 And then you trust the certificates 218 01:12:01,833 --> 01:12:04,699 from Cloud Director, from the vCenter. 219 01:12:05,199 --> 01:12:09,033 So because VCDA relies on the SSO of the vCenter, 220 01:12:09,866 --> 01:12:11,199 you need to trust all the certificates 221 01:12:11,199 --> 01:12:12,433 and you add the replication appliance. 222 01:12:12,466 --> 01:12:14,566 You need to do the exact same 223 01:12:14,566 --> 01:12:16,100 thing on the replication appliance. 224 01:12:16,300 --> 01:12:18,833 Then you deploy the tunnel appliances, one or many. 225 01:12:19,133 --> 01:12:20,133 You need to do the exact same 226 01:12:20,133 --> 01:12:21,133 thing on the tunnel appliances 227 01:12:21,800 --> 01:12:25,100 and accept the certificates vice versa back and forth. 228 01:12:25,766 --> 01:12:28,600 You need to get used to that procedure. 229 01:12:30,366 --> 01:12:33,000 Because as soon as you change a certificate somewhere, 230 01:12:33,600 --> 01:12:37,066 like in the vCenter, because it just expired, that simple, 231 01:12:37,800 --> 01:12:39,666 you need to start over and over 232 01:12:39,666 --> 01:12:42,199 and over trusting certificates. 233 01:12:43,600 --> 01:12:47,333 It's a lot easier if you use a proper PKI, 234 01:12:48,600 --> 01:12:50,800 because then it's implicitly trusted. 235 01:12:51,600 --> 01:12:54,399 If you trust the root, it's easier to handle. 236 01:12:56,933 --> 01:12:58,233 So the certificates are 237 01:12:58,233 --> 01:13:01,733 challenging, but you get used to it. 238 01:13:01,733 --> 01:13:03,866 But that's what I meant with the log files. 239 01:13:04,466 --> 01:13:08,633 If VCDA is not working for any 240 01:13:08,633 --> 01:13:10,433 reason, so something got disconnected, 241 01:13:11,133 --> 01:13:12,300 and you look into the log files, 242 01:13:12,533 --> 01:13:14,366 it tells you exactly which 243 01:13:14,366 --> 01:13:16,533 certificate is not working anymore 244 01:13:16,533 --> 01:13:20,199 and which connection is not trusted. 245 01:13:22,000 --> 01:13:25,666 And the biggest issue in the game 246 01:13:25,666 --> 01:13:29,033 is still the vCenter SSO connection. 247 01:13:29,266 --> 01:13:31,733 If this one is not working, it's not 248 01:13:31,733 --> 01:13:33,433 really telling you what is not working, 249 01:13:33,466 --> 01:13:36,933 but rather VCDA refuses to do anything. 250 01:13:38,366 --> 01:13:39,966 So the log files are key. 251 01:13:40,600 --> 01:13:42,600 And of course, the net rule. 252 01:13:43,199 --> 01:13:45,733 If you remember playing around with 253 01:13:45,733 --> 01:13:47,399 the net rule for the tunnel appliance, 254 01:13:47,966 --> 01:13:49,933 if the net is not in place, you 255 01:13:49,933 --> 01:13:53,333 can't get a replication up and running. 256 01:13:53,933 --> 01:13:57,633 Even though if you use it on-prem, 257 01:13:58,500 --> 01:14:06,633 you kind of build a fake net rule to tease something 258 01:14:06,633 --> 01:14:08,800 and get VCDA up and running 259 01:14:08,800 --> 01:14:10,899 because that is something which is key, 260 01:14:11,566 --> 01:14:12,500 at least currently. 261 01:14:14,233 --> 01:14:15,833 So you can work around that. 262 01:14:16,333 --> 01:14:19,033 These are just some technical insights. 263 01:14:20,866 --> 01:14:22,866 So on the other hand, if you use 264 01:14:22,866 --> 01:14:24,433 it within your own infrastructure, 265 01:14:25,466 --> 01:14:28,033 it's not a big deal having a 266 01:14:28,033 --> 01:14:31,399 throughput of like 10 gigabits in VCDA. 267 01:14:32,366 --> 01:14:35,466 It just consumes all the CPUs it has, 268 01:14:35,466 --> 01:14:38,600 but it's doing 10 gigabits 269 01:14:40,833 --> 01:14:44,233 because we have just 10 gigabits at some point. 270 01:14:45,466 --> 01:14:48,033 Maybe it could do even more, but that's pretty cool. 271 01:14:49,000 --> 01:14:51,199 And of course, it's just integrated into the Cloud Director UI. 272 01:14:53,466 --> 01:14:56,300 You just click on more, go to VCDA, and 273 01:14:56,300 --> 01:14:58,500 configure outgoing incoming replication, 274 01:14:58,699 --> 01:14:59,433 whatever you need. 275 01:15:00,100 --> 01:15:04,033 So from a user perspective, it's simple. 276 01:15:05,166 --> 01:15:07,766 It's integrated, and it's straightforward. 277 01:15:08,100 --> 01:15:10,399 And you know exactly what you're doing as a user. 278 01:15:10,600 --> 01:15:13,433 Like, am I trying to migrate a workload, 279 01:15:13,733 --> 01:15:18,066 or is my intention to create a 280 01:15:18,066 --> 01:15:19,433 disaster recovery replication, 281 01:15:19,500 --> 01:15:23,833 including RPO, RTO, what's the sync interval, 282 01:15:24,433 --> 01:15:26,899 as Yves already mentioned, like some bandwidth 283 01:15:26,899 --> 01:15:28,600 throttling, whatever is needed. 284 01:15:29,133 --> 01:15:30,600 So it's simple. 285 01:15:30,600 --> 01:15:31,366 It's straightforward. 286 01:15:31,833 --> 01:15:34,533 There is no need for a CSP to write like 287 01:15:34,533 --> 01:15:37,166 pages and pages and pages of instructions 288 01:15:37,166 --> 01:15:39,800 for their customers to reduce 289 01:15:39,800 --> 01:15:41,600 support tickets and questions like, 290 01:15:41,833 --> 01:15:44,466 "oh, how am I using the product (and stuff like this)?" 291 01:15:45,399 --> 01:15:47,666 So I still love it. 292 01:15:53,433 --> 01:15:59,600 Any thoughts, Toby? Yeah, at the underlying 293 01:15:59,600 --> 01:16:02,866 infrastructure, as you actually mentioned already, 294 01:16:05,066 --> 01:16:08,733 since VCDA is utilizing the same 295 01:16:08,733 --> 01:16:10,333 stack like vSphere replication, 296 01:16:11,000 --> 01:16:13,600 at the end, the replication appliances 297 01:16:13,600 --> 01:16:16,133 are some sort of vSphere replication. 298 01:16:17,500 --> 01:16:18,800 Please, be aware that you need to 299 01:16:18,800 --> 01:16:23,133 enable the VM kernel services on your ESXi. 300 01:16:23,466 --> 01:16:25,600 Otherwise, you run into the issue 301 01:16:25,600 --> 01:16:27,000 that you don't have a replication. 302 01:16:27,466 --> 01:16:28,500 That's a good one. 303 01:16:29,633 --> 01:16:32,333 But also, which is a great one 304 01:16:32,333 --> 01:16:34,399 on one hand, because for ages, 305 01:16:34,733 --> 01:16:39,800 I think something around 6.5, there have been vSphere 6.5, 306 01:16:40,500 --> 01:16:44,399 we have now also the possibility to enable a vSphere 307 01:16:44,399 --> 01:16:46,600 replication dedicated VM kernel port, 308 01:16:47,533 --> 01:16:50,533 which also brings me the great 309 01:16:50,533 --> 01:16:54,233 opportunity to separate my traffic from my, 310 01:16:54,933 --> 01:16:56,600 let's call it frontend network, where 311 01:16:56,600 --> 01:17:01,033 really my VMs have the communication path. 312 01:17:01,033 --> 01:17:02,633 So I can really separate also 313 01:17:02,633 --> 01:17:04,800 the whole replication traffic. 314 01:17:05,100 --> 01:17:06,533 And everyone, please have in mind, and 315 01:17:06,533 --> 01:17:08,600 this more and more comes into the game 316 01:17:09,500 --> 01:17:11,699 with the latest updates from vSphere 317 01:17:11,699 --> 01:17:17,133 itself, that the VM kernel adapter 318 01:17:17,466 --> 01:17:19,199 or the management VM kernel adapter 319 01:17:19,199 --> 01:17:21,666 really now becomes more and more the limitation 320 01:17:22,466 --> 01:17:25,199 of roughly about 400, 500 megabits 321 01:17:25,199 --> 01:17:28,000 per second, which is a hardcore limit. 322 01:17:28,000 --> 01:17:31,000 It's not the limit which is solved where we can 323 01:17:31,000 --> 01:17:32,766 reconfigure, what we can reconfigure, 324 01:17:33,466 --> 01:17:36,399 because now all of the backend 325 01:17:36,399 --> 01:17:40,566 services like backup, so the VADP 326 01:17:40,566 --> 01:17:42,600 proxy and stuff like this can now 327 01:17:42,600 --> 01:17:44,899 run on dedicated VM kernel adapters. 328 01:17:45,633 --> 01:17:49,233 That's more the reason why the management 329 01:17:49,233 --> 01:17:51,733 VM kernel now has really the bandwidth limit. 330 01:17:52,000 --> 01:17:54,100 So please do not utilize the 331 01:17:54,100 --> 01:17:57,666 management stack for all of the "story." 332 01:17:58,466 --> 01:18:01,566 Enable a dedicated VM kernel port for 333 01:18:01,566 --> 01:18:03,633 the whole vSphere replication story, 334 01:18:03,633 --> 01:18:06,000 and then you get much more performance. 335 01:18:07,633 --> 01:18:11,533 And also, as Matthias mentioned, you need to, on one hand, 336 01:18:11,533 --> 01:18:14,133 you can work with CPU reservation 337 01:18:14,466 --> 01:18:16,699 or you deploy more replication appliances. 338 01:18:17,366 --> 01:18:20,833 Depends what your... yeah, you can. 339 01:18:23,066 --> 01:18:25,433 Tunnel. Tunnel appliances, yeah, sorry. 340 01:18:25,466 --> 01:18:27,899 But the replication consumes the CPU... 341 01:18:28,300 --> 01:18:34,033 Yeah. But nevertheless, yeah, if you need, 342 01:18:35,300 --> 01:18:37,199 if you have many sessions to your 343 01:18:37,199 --> 01:18:40,000 customers on-prem, for example, Toby, that's true. 344 01:18:40,633 --> 01:18:42,033 If you have many sessions, 345 01:18:42,800 --> 01:18:44,766 please deploy more Tunnel appliances. 346 01:18:45,233 --> 01:18:46,600 And the Tunnel appliances also 347 01:18:46,600 --> 01:18:48,133 supports an HA configuration. 348 01:18:50,133 --> 01:18:52,600 So I think that that's also very 349 01:18:52,600 --> 01:18:54,433 interesting if you're losing an ESXi 350 01:18:54,500 --> 01:18:57,666 or if you're losing an appliance for whatever reason, 351 01:18:57,666 --> 01:19:00,133 have at least a second one in place for HA. 352 01:19:02,199 --> 01:19:04,433 But I think in that case, you need a load balancer. 353 01:19:04,833 --> 01:19:05,733 You need a load balancer. Yeah. 354 01:19:05,733 --> 01:19:07,233 You need to have load balancer in front, 355 01:19:07,933 --> 01:19:11,699 which is currently still something I can say, 356 01:19:12,033 --> 01:19:13,666 talking about VCF, we can 357 01:19:13,666 --> 01:19:16,533 still utilize the NSX load balancer. 358 01:19:17,133 --> 01:19:21,833 If we go with the ALB, we can utilize ALB or Avi, sorry, 359 01:19:21,833 --> 01:19:23,433 it's not ALB anymore, it's Avi 360 01:19:24,466 --> 01:19:27,399 And on the other hand, we can also 361 01:19:27,399 --> 01:19:29,533 utilize any kind of hardware appliances 362 01:19:29,533 --> 01:19:30,666 or hardware load balancers 363 01:19:30,666 --> 01:19:33,100 like Fortinet and stuff like this. 364 01:19:34,833 --> 01:19:39,333 Talking, or utilize this, place it 365 01:19:39,333 --> 01:19:41,433 in front of your Tunnel appliances. 366 01:19:41,933 --> 01:19:42,633 Tunnel server appliances. 367 01:19:47,433 --> 01:19:50,433 Talking about certificates, you mentioned before, Matthias. 368 01:19:51,466 --> 01:19:55,899 There is a solution, it's called VMware Cloud Foundation. 369 01:19:57,433 --> 01:19:59,333 And inside Cloud Foundation, we 370 01:19:59,333 --> 01:20:01,899 have a proper certificate integration, 371 01:20:03,066 --> 01:20:08,000 also certificate exchange or replay store is there. 372 01:20:08,266 --> 01:20:11,699 So maybe our service provider should have a look into VCF. 373 01:20:13,100 --> 01:20:15,433 But is VCDA part of VCF? 374 01:20:16,466 --> 01:20:21,199 No, but the certificate in the 375 01:20:21,199 --> 01:20:23,000 backend where I connect my VCDA. 376 01:20:24,199 --> 01:20:27,066 Okay, you mean using VCF as an intermediary? Yes. 377 01:20:31,600 --> 01:20:33,066 That makes perfect sense, yeah. 378 01:20:34,399 --> 01:20:38,533 I think, and also, but there I'm not really 100% sure, 379 01:20:38,800 --> 01:20:43,466 is VCDA part of the Cloud Provider Lifecycle Manager? 380 01:20:45,766 --> 01:20:46,333 I think yes. 381 01:20:46,333 --> 01:20:48,100 I think it's VCP LCM. 382 01:20:48,966 --> 01:20:53,033 VCP LCM, is there VCDA embedded? 383 01:20:53,866 --> 01:20:54,066 Yep. 384 01:20:55,100 --> 01:20:57,933 Then you would also have the perfect solution for replacing 385 01:20:57,933 --> 01:21:02,566 certificates on VCD and VCDA on the other hand. 386 01:21:03,399 --> 01:21:06,266 So you can also utilize the VMware 387 01:21:06,266 --> 01:21:07,666 Cloud Provider Lifecycle Manager. 388 01:21:08,466 --> 01:21:12,000 Then you have also there Day 2 operations for certificates. 389 01:21:13,466 --> 01:21:15,300 I like Lifecycle Manager. 390 01:21:15,533 --> 01:21:16,500 Lifecycle Manager is like... 391 01:21:16,500 --> 01:21:17,033 Yeah, yeah. 392 01:21:17,466 --> 01:21:20,199 So I respect everyone's opinion. 393 01:21:24,466 --> 01:21:26,766 Matthias is not a big fan of automation as 394 01:21:26,766 --> 01:21:28,633 long as he hasn't done the automation himself. 395 01:21:29,133 --> 01:21:29,766 That's true. 396 01:21:29,966 --> 01:21:35,133 A lot of automation and even VCP LCM is 397 01:21:35,133 --> 01:21:39,000 a great product, but it still has issues. 398 01:21:40,466 --> 01:21:45,800 It's not working as smooth as I would love to have it. 399 01:21:45,833 --> 01:21:50,033 Especially the repository management is a PITA. 400 01:21:51,533 --> 01:21:53,733 Done it, been there, figured out how 401 01:21:53,733 --> 01:21:55,300 it works without any documentation. 402 01:21:55,699 --> 01:21:59,433 Sorry to say, but guys, we're honestly speaking over here. 403 01:22:00,233 --> 01:22:05,600 Yeah, I highly recommend for that, because it is a little 404 01:22:05,600 --> 01:22:07,433 bit tough with the NFS server and stuff like this. 405 01:22:08,466 --> 01:22:12,500 But I highly recommend the blog post from Tomas Fojta. 406 01:22:14,466 --> 01:22:15,100 Tomas is working. 407 01:22:17,966 --> 01:22:18,899 Let's say 80%. 408 01:22:21,766 --> 01:22:22,533 But see, that's not... 409 01:22:22,533 --> 01:22:23,000 He doesn't have that. 410 01:22:24,066 --> 01:22:27,333 But if you are a customer and actually get automation done 411 01:22:27,333 --> 01:22:28,533 by Matthias, they are no 412 01:22:28,533 --> 01:22:30,933 shortcomings, no hiccups, no nothing with them. 413 01:22:30,933 --> 01:22:32,433 They always run 100% perfectly. 414 01:22:33,466 --> 01:22:38,366 Or there is no chance to troubleshoot it yourself at all. 415 01:22:40,533 --> 01:22:44,166 That must definitely work easily because, as I learned from 416 01:22:44,166 --> 01:22:45,966 you, good code documents itself. 417 01:22:47,399 --> 01:22:47,600 Absolutely. 418 01:22:48,533 --> 01:22:50,833 Dude, we had the discussion on Monday. 419 01:22:52,633 --> 01:22:55,600 At least I refused doing a change, that's correct. 420 01:22:55,899 --> 01:22:58,033 But at least I added a comment that 421 01:22:58,033 --> 01:23:00,433 I did a change and what I changed. 422 01:23:01,466 --> 01:23:05,633 I'm still refusing to do the change, but I commented it. 423 01:23:07,466 --> 01:23:10,533 I made the comment in your name. 424 01:23:11,899 --> 01:23:12,100 No. 425 01:23:18,699 --> 01:23:19,433 No, no, no. 426 01:23:20,033 --> 01:23:22,666 I think VCDA, coming back to our 427 01:23:22,666 --> 01:23:26,433 story, is a valid and good solution. 428 01:23:26,500 --> 01:23:30,266 What people should keep in mind also, even though we now 429 01:23:30,266 --> 01:23:33,300 have a lot of flexibility when it comes down to restore 430 01:23:33,300 --> 01:23:36,166 points for the DR part, this is 431 01:23:36,166 --> 01:23:41,833 not replacing a backup solution. 432 01:23:43,000 --> 01:23:43,133 No. 433 01:23:43,533 --> 01:23:47,199 This is not meant to provide you with any kind like 434 01:23:47,199 --> 01:23:52,833 application safe backups, application wear backups, or file 435 01:23:52,833 --> 01:23:54,433 level recovery, or any of these things. 436 01:23:55,466 --> 01:23:58,933 This is just a migration and DR solution. 437 01:24:00,000 --> 01:24:05,766 This is very, very important because if you're solely, 438 01:24:06,033 --> 01:24:09,433 actually, depending on this one, you might get a surprise. 439 01:24:09,433 --> 01:24:12,333 If something doesn't work, you always should have a proper 440 01:24:12,333 --> 01:24:15,800 backup solution, which typically comes back to the argument, 441 01:24:15,800 --> 01:24:20,433 from me, that you then actually might not have both in one. 442 01:24:21,533 --> 01:24:24,399 All of it has advantages and disadvantages. 443 01:24:25,000 --> 01:24:27,733 Yes, having backup and DR solution in one 444 01:24:27,733 --> 01:24:29,899 solution makes sense to a certain degree. 445 01:24:29,899 --> 01:24:31,600 The other way around makes sense as well. 446 01:24:32,199 --> 01:24:34,733 In the end, it's up for your specific decision. 447 01:24:35,100 --> 01:24:37,800 And for your specific use case, you could also have 448 01:24:37,800 --> 01:24:39,133 something where you have a local 449 01:24:39,133 --> 01:24:43,266 backup somewhere, which you have access to. 450 01:24:43,266 --> 01:24:46,533 And then you have DR to the cloud and/or versa. 451 01:24:47,733 --> 01:24:48,433 Those are all possibilities. 452 01:24:48,500 --> 01:24:53,566 By the way, you can also, it's not only that you can use 453 01:24:53,566 --> 01:24:58,100 this as a DR on-prem to the cloud or cloud to cloud, you 454 01:24:58,100 --> 01:25:00,800 could also build DR cloud to on-prem. 455 01:25:01,466 --> 01:25:04,100 So if you are moving into the cloud and you want to be sure 456 01:25:04,100 --> 01:25:06,699 that at any point in time, you could actually reactivate 457 01:25:06,699 --> 01:25:09,100 your local data center, you could build it and set it up 458 01:25:09,100 --> 01:25:11,100 like that as well, considering that 459 01:25:11,100 --> 01:25:12,933 your service provider allows you to. 460 01:25:13,199 --> 01:25:14,433 But technically, this is possible. 461 01:25:14,466 --> 01:25:16,600 Technically, it would even be 462 01:25:16,600 --> 01:25:18,733 possible to do this between service provider. 463 01:25:18,933 --> 01:25:21,699 There is just one interface missing for that, which we are 464 01:25:21,699 --> 01:25:24,733 aware as and provided up until today. 465 01:25:25,000 --> 01:25:26,899 But in theory, you could clearly 466 01:25:26,899 --> 01:25:28,699 use this between two cloud providers. 467 01:25:31,866 --> 01:25:35,833 One thing to add, because, yes, as you mentioned, there are 468 01:25:35,833 --> 01:25:38,766 many, many solutions available which provide backup and 469 01:25:38,766 --> 01:25:41,333 replication also from a cloud 470 01:25:41,333 --> 01:25:43,433 provider, Cloud Director, not cloud provider... 471 01:25:43,500 --> 01:25:46,366 but from a CloudDdirector perspective, what I would like to 472 01:25:46,366 --> 01:25:50,899 mention here, this is on one hand, from my perspective, 473 01:25:50,899 --> 01:25:54,066 a big advantage of VCDA, is that VCDA 474 01:25:54,066 --> 01:25:56,433 is not relying on any kind of snapshot. 475 01:25:56,500 --> 01:26:00,733 So you can do the replication 476 01:26:00,733 --> 01:26:05,899 directly integrated in the stack. 477 01:26:05,899 --> 01:26:08,300 So you don't need to utilize any kind of snapshot 478 01:26:08,300 --> 01:26:12,399 technology or any kind of snapshot on your virtual 479 01:26:12,399 --> 01:26:14,399 machines, which is a big advantage 480 01:26:14,399 --> 01:26:16,966 compared to other third-party solutions. 481 01:26:17,933 --> 01:26:19,733 On the source side? 482 01:26:19,733 --> 01:26:20,600 On the source side. 483 01:26:20,600 --> 01:26:21,699 On the source side, yes. 484 01:26:21,699 --> 01:26:24,433 Our side is snapshots. I just wanted to be sure. 485 01:26:25,466 --> 01:26:30,766 But mainly I care about the source side because still, also 486 01:26:30,766 --> 01:26:36,833 with the improvement of vSAN... and vVols and stuff 487 01:26:36,833 --> 01:26:41,199 like this, we still see or we still know that snapshots can 488 01:26:41,199 --> 01:26:44,133 sometimes be a little bit of a 489 01:26:44,133 --> 01:26:47,800 pain regarding performance. 490 01:26:49,466 --> 01:26:56,033 And before we come to an end, we still make to announce a 491 01:26:56,033 --> 01:27:01,333 change. Guys, it was wrong. So VCDA is not part of VCD LCM 492 01:27:02,766 --> 01:27:02,966 Okay. 493 01:27:03,800 --> 01:27:09,933 So to say VCDA is standalone. It's not part of SDDC 494 01:27:09,933 --> 01:27:12,466 manager. It's not part of VCD LCM. 495 01:27:12,466 --> 01:27:15,533 So VCDA currently has no lifecycle 496 01:27:15,533 --> 01:27:17,733 management built around the product. 497 01:27:22,000 --> 01:27:25,300 If we say something wrong, we need to change it. 498 01:27:25,600 --> 01:27:28,433 Yeah, I was actually also of the opinion that it was 499 01:27:28,433 --> 01:27:31,433 included and that it would automatically roll out into 500 01:27:31,433 --> 01:27:33,166 certificate management. But so 501 01:27:33,166 --> 01:27:34,533 then I'm sure that I'm wrong. 502 01:27:34,533 --> 01:27:35,233 That'd be so great. 503 01:27:37,866 --> 01:27:42,000 Yeah, I mean, it's I wouldn't as it's currently not there. 504 01:27:42,000 --> 01:27:44,866 It's not going to come anymore. That's the only thing which 505 01:27:44,866 --> 01:27:49,100 we can be sure for certain, because with the end of life 506 01:27:49,100 --> 01:27:51,966 announcements of vCD and everything else. 507 01:27:52,600 --> 01:27:55,133 But what we learned is never say never. 508 01:27:57,466 --> 01:28:00,433 Yeah, in this in this scenario it's... 509 01:28:01,466 --> 01:28:03,833 Right. Yeah, I heard that before. 510 01:28:05,466 --> 01:28:09,133 I mean, it's in the past when we had the Aria Automation 511 01:28:09,133 --> 01:28:15,199 story or back then vCAC to VCD that those were scenarios 512 01:28:15,199 --> 01:28:18,766 where it is different. And as I said already in the videos, 513 01:28:18,766 --> 01:28:23,033 which we provided to our Challenge Days and Architecture 514 01:28:23,033 --> 01:28:25,066 Think Tank audience and the communities. 515 01:28:26,466 --> 01:28:32,300 I would actually bet very highly that 516 01:28:32,300 --> 01:28:35,633 VCD 10.6 is going to be the latest release. We will see 517 01:28:35,633 --> 01:28:39,733 just patches that it that's it. That's done. That's gone. 518 01:28:41,600 --> 01:28:45,699 And I would actually also, not 100% sure about all 519 01:28:45,699 --> 01:28:49,066 the things on the Aria Automation side, because Broadcom and 520 01:28:49,066 --> 01:28:51,800 CA also has an automation platform, which has a far greater 521 01:28:51,800 --> 01:28:53,433 integration into many, many other products. 522 01:28:54,466 --> 01:28:59,033 But that's a completely different story. But when you look 523 01:28:59,033 --> 01:29:01,100 at VCD, I think it's only a 524 01:29:01,100 --> 01:29:03,366 question of the timeline is going to stick. 525 01:29:03,899 --> 01:29:07,100 But that it's going to go away is very, very clear. The 526 01:29:07,100 --> 01:29:10,133 announcement have been very, very clear. Broadcom has been 527 01:29:10,133 --> 01:29:14,166 very, very clear towards customers in some enterprise 528 01:29:14,166 --> 01:29:18,199 customers who are using VCD that they need to start looking 529 01:29:18,199 --> 01:29:20,433 into something else because it's going to go away. 530 01:29:21,466 --> 01:29:26,666 So that is nothing I question at this point in time. So I 531 01:29:26,666 --> 01:29:30,800 would really take a good bet on that it's only a 532 01:29:30,800 --> 01:29:36,333 matter of if it's going to be '26, '27, or '28. 533 01:29:36,333 --> 01:29:38,066 But it's only a matter if it's going to 534 01:29:38,066 --> 01:29:40,633 be one or two years longer. But that's it. 535 01:29:44,466 --> 01:29:45,433 Yes. 536 01:29:45,500 --> 01:29:46,100 Yes. 537 01:29:48,699 --> 01:29:51,800 Okay. Now we need a new title for our Roundtable as well. 538 01:29:52,399 --> 01:29:59,466 Yeah, for sure. Before we close it also, please be aware 539 01:29:59,466 --> 01:30:09,166 that by the 30th of January, 2025 all VMware.com 540 01:30:09,166 --> 01:30:10,633 links will be decommissioned. 541 01:30:10,633 --> 01:30:14,633 So especially the docs. will not be available anymore. 542 01:30:14,633 --> 01:30:16,233 There will be also no forwarding. 543 01:30:16,566 --> 01:30:20,899 So please change all of your links to techdocs.broadcom.com 544 01:30:20,899 --> 01:30:25,300 com dot com because the sites will be decommissioned as 545 01:30:25,300 --> 01:30:28,600 late as January 30. 546 01:30:29,966 --> 01:30:30,333 Yes. 547 01:30:32,233 --> 01:30:32,433 That is so true. 548 01:30:32,500 --> 01:30:35,933 And it's also it was at least in one note, which I have 549 01:30:35,933 --> 01:30:39,033 seen. I'm not sure if you saw the same Toby. At the same 550 01:30:39,033 --> 01:30:42,500 point in time, at least what I saw is Broadcom is going to 551 01:30:42,500 --> 01:30:46,433 discontinue all, let's say, end of life and of service 552 01:30:46,433 --> 01:30:50,633 documentation as long as you are not in extended support. 553 01:30:53,399 --> 01:30:53,433 Yes. 554 01:30:53,466 --> 01:30:58,233 Yes. All knowledge base, all everything. So, for example, 555 01:30:58,233 --> 01:31:01,100 if you still if you have vSphere 6.5 extended 556 01:31:01,100 --> 01:31:04,199 support, you can still get documentation. The space 557 01:31:04,199 --> 01:31:06,300 articles, if you are not in extended 558 01:31:06,300 --> 01:31:08,333 support, all of that will be gone as well. 559 01:31:08,333 --> 01:31:12,333 Yeah, it'll all be gone, and only if 560 01:31:12,333 --> 01:31:15,266 you have acquired extendedsupport, will you still get the 561 01:31:15,266 --> 01:31:17,533 documentation. So there will be a huge 562 01:31:17,533 --> 01:31:20,433 cleanup coming up, or depending on the VCD release, 563 01:31:20,500 --> 01:31:26,733 have been in the in the last week. So, yeah. 564 01:31:27,766 --> 01:31:31,533 But this is very important for those customers who are 565 01:31:31,533 --> 01:31:35,033 still sticking around on all outdated versions, it's like if 566 01:31:35,033 --> 01:31:38,100 you were depending on doing your own support because you 567 01:31:38,100 --> 01:31:39,433 don't have support or anything like that anymore, 568 01:31:39,466 --> 01:31:44,233 be prepared that all of this is going to be a lot more 569 01:31:44,233 --> 01:31:48,600 interesting, because you will not 570 01:31:48,600 --> 01:31:51,833 necessarily get access to the documentation anymore. 571 01:31:52,600 --> 01:31:57,766 And especially the whole... and still we know that some 572 01:31:57,766 --> 01:32:01,000 some guys are still running it, the 573 01:32:01,000 --> 01:32:04,433 whole NSX vSphere story is also now gone. 574 01:32:04,500 --> 01:32:10,533 Now it is gone. Depends when you see the 575 01:32:10,533 --> 01:32:14,466 episode. So there will be no downloads anymore. There will 576 01:32:14,466 --> 01:32:19,333 be no documentation anymore for NSX for vSphere. So this is 577 01:32:19,333 --> 01:32:21,199 also something which has been 578 01:32:21,199 --> 01:32:26,233 changed with the 31st of December. 579 01:32:36,033 --> 01:32:38,399 Good. Any other final words, Matthias? 580 01:32:39,866 --> 01:32:41,199 We still love certificates. 581 01:32:43,899 --> 01:32:45,066 You are the expert for 582 01:32:45,066 --> 01:32:48,133 certificates. No, I'm not. I just love them. 583 01:32:48,666 --> 01:32:50,933 If you have any questions, I think you're also. 584 01:32:51,500 --> 01:32:54,866 The expert at drawing three red 585 01:32:54,866 --> 01:32:57,433 perpendicular lines with transparent ink. 586 01:32:57,800 --> 01:33:00,833 Yes, I think you're totally also marked for the holidays. 587 01:33:01,066 --> 01:33:02,399 that any issues with certificates 588 01:33:02,399 --> 01:33:03,466 will actually be escalated to you. 589 01:33:05,600 --> 01:33:08,333 Hopefully I'm so looking forward to it. 590 01:33:09,333 --> 01:33:11,366 Sascha, take him for that one. I'm pretty 591 01:33:11,366 --> 01:33:14,333 sure you will find something. 592 01:33:14,666 --> 01:33:17,033 Of course there will be something. It's always the same. 593 01:33:19,166 --> 01:33:19,933 Sascha, final words. 594 01:33:21,066 --> 01:33:24,433 Yeah, take a look at VCDA. Maybe it's a good opportunity 595 01:33:24,433 --> 01:33:28,800 for you and your customers to grow a bit of your business. 596 01:33:29,366 --> 01:33:31,466 And if you have questions, feel free to reach out to us. 597 01:33:35,633 --> 01:33:35,933 Toby 598 01:33:36,500 --> 01:33:38,466 Yeah, thanks for listening. As 599 01:33:38,466 --> 01:33:40,233 Sascha mentioned, have a look into VCDA. 600 01:33:41,800 --> 01:33:45,899 Yeah, that's it for, from my side, for episode 44. Yves. 601 01:33:47,466 --> 01:33:52,500 Yeah, thank you all for listening. Thank you for 2024 for 602 01:33:52,500 --> 01:33:54,633 all the ones who have been live 603 01:33:54,633 --> 01:33:57,000 listening or later on listening into the podcast. 604 01:33:58,466 --> 01:34:02,133 As we, as the team gets together for our comdivision 605 01:34:02,133 --> 01:34:06,233 kickoff in 2025, we will also revisit the format of this 606 01:34:06,233 --> 01:34:09,800 one and actually see how we can make this more interesting. 607 01:34:10,100 --> 01:34:14,266 There have been already a few ideas been submitted, how we 608 01:34:14,266 --> 01:34:18,233 can actually make this more focused on you, the community. 609 01:34:18,699 --> 01:34:20,433 So we are looking forward to that one. 610 01:34:20,500 --> 01:34:25,000 Next year is going to be a lot of news around VCF and many 611 01:34:25,000 --> 01:34:28,600 other things on how we integrate these with VCD still. 612 01:34:28,600 --> 01:34:31,500 How the new multi-tenancy for VCF is going to look 613 01:34:31,500 --> 01:34:35,199 like. All of these things. So there will be a lot of 614 01:34:35,199 --> 01:34:38,800 topics. So I can imagine that we might even have more than 615 01:34:38,800 --> 01:34:40,433 just one or two episodes per month. 616 01:34:40,466 --> 01:34:45,333 And we try to build at the beginning of the year, maybe a 617 01:34:45,333 --> 01:34:47,166 schedule with dates already so that 618 01:34:47,166 --> 01:34:49,833 it's easier for you to follow in live. 619 01:34:51,399 --> 01:34:55,000 Thank you all for listening. If you are listening in live 620 01:34:55,000 --> 01:34:57,566 or before the holidays, have a wonderful holiday and a 621 01:34:57,566 --> 01:35:01,466 great start in 2025. And if not, still, happy New Year.