1 01:00:00,233 --> 01:00:02,933 Hello and welcome. This is VCD 2 01:00:02,933 --> 01:00:06,000 Roundtable Episode 45. 3 01:00:06,966 --> 01:00:09,733 And in today's episode, we are going 4 01:00:09,733 --> 01:00:13,466 to talk about our expectations for 2025. 5 01:00:13,800 --> 01:00:17,166 But from what we discussed beforehand, it might go a bit 6 01:00:17,166 --> 01:00:20,066 into 2026 and stuff like that. 7 01:00:20,266 --> 01:00:21,633 My name is Yves Sandfort. I'm 8 01:00:21,633 --> 01:00:23,033 going to be the host for today. 9 01:00:23,433 --> 01:00:25,733 And with me are Sascha. 10 01:00:27,333 --> 01:00:29,666 Yeah, hello. Welcome to our episode. 11 01:00:30,866 --> 01:00:31,166 Matthias? 12 01:00:32,300 --> 01:00:33,666 Yeah, welcome. Happy new year 13 01:00:33,666 --> 01:00:36,199 2025. Welcome to this episode. 14 01:00:38,466 --> 01:00:39,800 So the last year ended a bit 15 01:00:39,800 --> 01:00:42,266 with the fact that we know that 16 01:00:43,000 --> 01:00:44,533 quite a few things are going to 17 01:00:44,533 --> 01:00:47,433 change in the service provider space. 18 01:00:47,433 --> 01:00:49,233 We know that Cloud Director in 19 01:00:49,233 --> 01:00:50,833 the long run is going to go away. 20 01:00:50,833 --> 01:00:52,733 We know VCF 9 is going to come. 21 01:00:53,033 --> 01:00:55,500 We know people are still on the V2T 22 01:00:55,500 --> 01:00:58,266 migration path and a lot of things, 23 01:00:58,266 --> 01:00:59,400 even though everybody is finished 24 01:00:59,400 --> 01:01:01,366 by now... it's just test environment, 25 01:01:01,633 --> 01:01:02,833 some rare ones which we are 26 01:01:02,833 --> 01:01:05,500 migrating (with a few thousand tenants). 27 01:01:06,300 --> 01:01:09,966 But that's a different story or not a different story. 28 01:01:09,966 --> 01:01:12,066 Basically all falls into the 29 01:01:12,066 --> 01:01:14,833 scenario: how should service providers 30 01:01:14,833 --> 01:01:19,633 prepare themselves for what's on the horizon with VCF 9 and 31 01:01:19,633 --> 01:01:21,933 VCD going to go away in the long run? 32 01:01:23,000 --> 01:01:26,633 And clearly a lot of this is looking into the crystal ball. 33 01:01:27,099 --> 01:01:29,533 The only things which we shared in the previous 34 01:01:29,533 --> 01:01:31,933 sessions for what we really fully know. 35 01:01:32,966 --> 01:01:36,333 But today's session is a bit more of a crystal ball session. 36 01:01:36,566 --> 01:01:39,333 So we are going to take our own personal opinions on what 37 01:01:39,333 --> 01:01:41,033 we think, how this is going to be. 38 01:01:41,400 --> 01:01:44,433 We are going to throw in a bunch of information which we 39 01:01:44,433 --> 01:01:46,599 currently discuss with the service providers 40 01:01:46,599 --> 01:01:49,500 who actually come in and originally say, "Hey, we 41 01:01:49,500 --> 01:01:51,266 are going to wait until all of this is over." 42 01:01:51,533 --> 01:01:52,900 Where I say, "this brought 43 01:01:52,900 --> 01:01:55,633 you as far as your V2T migration. 44 01:01:55,633 --> 01:01:57,266 You are now migrating unsupported 45 01:01:57,266 --> 01:01:59,066 into hopefully something supported." 46 01:01:59,433 --> 01:02:02,599 So let's kick off the discussion. 47 01:02:03,000 --> 01:02:04,166 Matthias, do you want to throw 48 01:02:04,166 --> 01:02:05,633 in a first statement on that one? 49 01:02:07,166 --> 01:02:09,400 Yeah. Thanks for that. 50 01:02:10,500 --> 01:02:13,066 We already discussed a lot, 51 01:02:13,066 --> 01:02:14,966 which is common knowledge so far, 52 01:02:15,500 --> 01:02:17,699 that VCF 9 will be the new golden 53 01:02:17,699 --> 01:02:19,466 standard in terms of basic infrastructure. 54 01:02:19,500 --> 01:02:24,400 So VCF 5.2.x, which is the current version, will be 55 01:02:24,400 --> 01:02:28,633 replaced or migrated to VCF 9. 56 01:02:29,633 --> 01:02:34,366 And what we also know is VCF 9 will be different, a little 57 01:02:34,366 --> 01:02:36,366 bit different from the behavior, 58 01:02:37,300 --> 01:02:39,866 from a role distribution between 59 01:02:39,866 --> 01:02:42,466 the different components within VCF. 60 01:02:43,533 --> 01:02:47,033 And Cloud Directors, you said, will go away. 61 01:02:49,133 --> 01:02:52,366 What will stay? That's not a crystal ball part. 62 01:02:53,533 --> 01:02:55,366 We have the second product, which 63 01:02:55,366 --> 01:02:57,599 is called today Aria Automation. 64 01:02:58,733 --> 01:03:01,966 And this will also not really go away, but... 65 01:03:01,966 --> 01:03:04,900 Cloud Director and Aria Automation 66 01:03:04,900 --> 01:03:09,166 will be merged into something we call VCF Automation. 67 01:03:09,533 --> 01:03:18,666 But I assume that VCF Automation will be partly a 68 01:03:18,666 --> 01:03:22,933 descendant or offshoot of Aria Automation, 69 01:03:23,333 --> 01:03:29,666 but other parts will move to the vSphere stack of VCF, 70 01:03:29,666 --> 01:03:32,366 or the vSphere part of VCF will be, for example, call 71 01:03:32,366 --> 01:03:34,033 Namespaces and stuff like this. 72 01:03:34,666 --> 01:03:37,633 So I think that that's a huge game changer. 73 01:03:40,866 --> 01:03:43,800 We need to understand how that 74 01:03:43,800 --> 01:03:47,099 new part of VCF Automation will work, 75 01:03:47,266 --> 01:03:53,466 which capabilities it offers, and which features are 76 01:03:53,466 --> 01:03:55,300 available from the beginning. 77 01:03:56,266 --> 01:04:00,800 Because what we saw on the roadmap is kind of VCF 78 01:04:00,800 --> 01:04:02,466 Automation will be there from the beginning, 79 01:04:03,500 --> 01:04:07,833 but presumably not offering all features which are planned 80 01:04:07,833 --> 01:04:09,966 over the lifetime of the product. 81 01:04:10,266 --> 01:04:12,466 So the beginning will be challenging. 82 01:04:13,333 --> 01:04:15,733 And I think a question will be -- Sascha, 83 01:04:15,900 --> 01:04:19,699 maybe you have a good answer to this one -- should... 84 01:04:20,266 --> 01:04:23,133 if I'm a CSP, and I'm currently 85 01:04:23,133 --> 01:04:24,466 ramping up a new infrastructure, 86 01:04:25,133 --> 01:04:26,466 what should I aim for? 87 01:04:26,500 --> 01:04:32,000 Like, I know Cloud Director will go away sooner or later. 88 01:04:32,866 --> 01:04:33,699 Should I wait? 89 01:04:34,099 --> 01:04:39,933 Should I still be using Cloud Director to implement all 90 01:04:39,933 --> 01:04:41,666 the business requirements I have 91 01:04:41,666 --> 01:04:43,266 and for features from the customers? 92 01:04:43,733 --> 01:04:48,733 Or should I wait or just skip the business? 93 01:04:50,099 --> 01:04:51,433 Yeah, that's a really good question. 94 01:04:51,433 --> 01:04:54,233 We had this discussion with a lot of service providers. 95 01:04:54,533 --> 01:04:58,833 So, you know, with the White Label program, we get in 96 01:04:58,833 --> 01:05:00,866 contact with a lot of service providers. 97 01:05:01,733 --> 01:05:04,500 And many of them are currently not using it. 98 01:05:04,500 --> 01:05:06,466 They only used the license model in 99 01:05:06,466 --> 01:05:09,133 the past, but now figured out that with VCF, 100 01:05:10,133 --> 01:05:12,533 and all the Cloud Director stuff is included. 101 01:05:13,266 --> 01:05:17,133 They might have to take a look inside and with many 102 01:05:17,133 --> 01:05:19,400 discussion and design discussions 103 01:05:19,400 --> 01:05:21,633 of the complete environments and Health Checks. 104 01:05:23,500 --> 01:05:26,099 We showed them that this old structure, 105 01:05:26,099 --> 01:05:29,733 where you have vSphere and multi-tenancy, 106 01:05:31,033 --> 01:05:34,599 try to use multi-tenancy on vSphere, that doesn't work. 107 01:05:34,833 --> 01:05:37,300 That doesn't work on vSphere, that doesn't work on NSX. 108 01:05:39,733 --> 01:05:42,766 With all of that combined, we need to clearly say, "hey, 109 01:05:42,766 --> 01:05:45,766 you need a multi-tenant solution. 110 01:05:45,833 --> 01:05:50,366 You need it and you are not able to wait 111 01:05:50,366 --> 01:05:53,666 until VCF comes with multi-tenant solutions, 112 01:05:53,666 --> 01:05:55,333 especially for the shared environments. 113 01:05:56,300 --> 01:05:58,800 So what we heard is that we will get 114 01:05:58,800 --> 01:06:02,566 multi-tenancy in a basic way with VCF 9 115 01:06:02,566 --> 01:06:07,566 and we'll get shared support or for shared 116 01:06:07,566 --> 01:06:09,433 workload domains for the service providers, 117 01:06:10,866 --> 01:06:12,466 beginning with 9.1. 118 01:06:12,533 --> 01:06:16,500 So that means that not all of the features will be 119 01:06:16,500 --> 01:06:18,133 available in the first release. 120 01:06:19,366 --> 01:06:21,699 So from that perspective, I would 121 01:06:21,699 --> 01:06:23,633 clearly recommend every customer, 122 01:06:23,866 --> 01:06:25,699 every service provider who is not 123 01:06:25,699 --> 01:06:27,800 using a real multi-tenant solution, 124 01:06:28,633 --> 01:06:30,466 still start with VCD. 125 01:06:31,166 --> 01:06:33,366 So VCD is the right product for it. 126 01:06:33,566 --> 01:06:35,166 Also for service providers who are 127 01:06:35,166 --> 01:06:38,466 using VCD, still go the route with VCD. 128 01:06:39,500 --> 01:06:41,766 I think we have a really good product. 129 01:06:41,766 --> 01:06:42,866 It's a stable product. 130 01:06:43,266 --> 01:06:47,733 The customers like VCD with the multi-tenancy, 131 01:06:47,733 --> 01:06:49,866 not only for service providers who 132 01:06:49,866 --> 01:06:52,466 provide this to their customers, 133 01:06:53,166 --> 01:06:55,800 also for service providers who are 134 01:06:55,800 --> 01:06:58,900 using it for their own internal teams to, 135 01:06:59,233 --> 01:07:01,433 set permission on the different teams. 136 01:07:01,666 --> 01:07:03,466 Because, think about if you are a service provider. 137 01:07:03,533 --> 01:07:06,533 Service providers have 100,000 of customers, 138 01:07:07,166 --> 01:07:10,599 and everyone has access to all of the customers. 139 01:07:11,166 --> 01:07:11,966 That doesn't work. 140 01:07:12,733 --> 01:07:16,000 And if you explain this to your customer that hundreds of 141 01:07:16,000 --> 01:07:18,366 consultants have access to your environment, 142 01:07:19,033 --> 01:07:20,733 they will not be happy with that. 143 01:07:21,366 --> 01:07:24,633 So my absolute recommendation is 144 01:07:24,633 --> 01:07:27,933 to go with VCD. Also if you start, 145 01:07:29,433 --> 01:07:31,233 there will be an upgrade pass. 146 01:07:31,533 --> 01:07:34,833 Nobody knows who will create the update tools, 147 01:07:35,166 --> 01:07:36,500 or the migration tools 148 01:07:36,500 --> 01:07:40,766 from VCD to VCF for multi-tenancy, 149 01:07:41,233 --> 01:07:45,233 but there will be A. a way and B. a tool. 150 01:07:46,500 --> 01:07:49,866 And with this focus, I would clearly recommend it. 151 01:07:51,333 --> 01:07:53,466 If you are starting, start VCD. 152 01:07:54,500 --> 01:07:57,866 So if I get that correct, so maybe we 153 01:07:57,866 --> 01:08:01,733 should separate two different parts of CSPs, 154 01:08:02,000 --> 01:08:04,500 because we have CSPs working with a shared environment, 155 01:08:04,733 --> 01:08:06,199 what you have mentioned, and I 156 01:08:06,199 --> 01:08:08,166 agree with the route you suggested. 157 01:08:08,833 --> 01:08:13,266 But on the other hand, we have CSPs using dedicated 158 01:08:13,266 --> 01:08:14,733 environments for their customers. 159 01:08:15,133 --> 01:08:16,333 So I think we should separate 160 01:08:16,333 --> 01:08:18,033 those two stories from each other. 161 01:08:19,500 --> 01:08:26,366 Also what we saw so far in Roadmap is that VCF 9, 162 01:08:26,566 --> 01:08:30,366 so the first release, should be 163 01:08:30,366 --> 01:08:32,633 good to go for dedicated environments. 164 01:08:33,933 --> 01:08:39,566 And what Broadcom is offering is a VCF 9 assessment tool. 165 01:08:39,566 --> 01:08:41,466 It has a new name, but I'm not sharing the name. 166 01:08:43,500 --> 01:08:45,699 Let's stick with "VCF 9 Assessment Tool," 167 01:08:46,500 --> 01:08:50,266 which suggests if you can migrate your current 168 01:08:50,266 --> 01:08:52,699 infrastructure into VCF 9, yes or no. 169 01:08:53,500 --> 01:08:56,933 But I think if a CSP uses dedicated infrastructures 170 01:08:57,500 --> 01:09:00,866 and it solves all the requirements he has, 171 01:09:01,500 --> 01:09:04,699 there is no need to introduce Cloud Director to this part, 172 01:09:05,566 --> 01:09:09,833 speaking as of now, and stick with the dedicated approach 173 01:09:10,500 --> 01:09:13,333 and maybe with VCF Automation at a later 174 01:09:13,333 --> 01:09:16,899 stage if it solves any business requirements. 175 01:09:18,100 --> 01:09:21,766 The big question from my perspective also there is... 176 01:09:22,733 --> 01:09:29,966 and we do not yet have the ability to look into VCF 9. 177 01:09:29,966 --> 01:09:32,233 So, we don't know the tenant 178 01:09:32,233 --> 01:09:35,933 availability of features included in VCF 9. 179 01:09:36,500 --> 01:09:37,266 And that's a problem. 180 01:09:37,466 --> 01:09:39,366 So, yeah, if you're running only 181 01:09:39,366 --> 01:09:42,500 dedicated environments, that might be an option. 182 01:09:43,066 --> 01:09:45,533 But the right answer you can only get 183 01:09:45,533 --> 01:09:48,699 first when you have a look in VCF 9, 184 01:09:49,066 --> 01:09:50,966 what features in multi-tenancy are 185 01:09:50,966 --> 01:09:53,833 available, because we have a big set of features. 186 01:09:54,533 --> 01:10:00,133 We don't know if all of these features will stay in VCF 9 187 01:10:00,133 --> 01:10:03,466 for multi-tenancy or only a part. 188 01:10:04,500 --> 01:10:07,933 So, I don't expect that all of 189 01:10:07,933 --> 01:10:10,333 these features will be included in VCF 9 190 01:10:10,333 --> 01:10:12,533 and also not for dedicated environments. 191 01:10:13,500 --> 01:10:16,766 With dedicated environments, with VCF, you have much more 192 01:10:16,766 --> 01:10:18,733 options to give the customers 193 01:10:19,500 --> 01:10:25,933 the ability to directly log into vSphere or NSX. 194 01:10:27,100 --> 01:10:30,066 But what we have currently with VCD is 195 01:10:30,066 --> 01:10:32,433 that a customer can create a network, 196 01:10:32,533 --> 01:10:33,800 that a customer can create 197 01:10:33,800 --> 01:10:36,566 Firewall rules in a very easy way 198 01:10:36,566 --> 01:10:40,666 without having this big knowledge you need on NSX maybe. 199 01:10:41,866 --> 01:10:44,866 Also, on other parts, how to configure the environment. 200 01:10:45,133 --> 01:10:52,199 It's very easy in VCD and you need much more and special 201 01:10:52,199 --> 01:10:56,166 knowledge on vSphere or VCF and NSX, 202 01:10:56,166 --> 01:10:58,533 if you go the path to share 203 01:10:58,533 --> 01:11:01,166 directly NSX manager and vSphere. 204 01:11:01,533 --> 01:11:07,133 In addition to that, we currently don't know if NSX with 205 01:11:07,133 --> 01:11:10,533 this interface will be available in VCF 9. 206 01:11:10,533 --> 01:11:12,866 Maybe much more will be 207 01:11:12,866 --> 01:11:15,833 integrated directly in the VCF 9 console 208 01:11:15,833 --> 01:11:20,566 and you don't have to do so much directly in NSX. 209 01:11:21,066 --> 01:11:23,466 That's the other topic we need to talk about. 210 01:11:23,533 --> 01:11:27,566 Currently, as we don't have greater insight into 211 01:11:27,566 --> 01:11:32,966 VCF, we have no idea what we can do. 212 01:11:33,600 --> 01:11:36,800 True. That's why we are just sharing some ideas we have. 213 01:11:37,633 --> 01:11:39,666 That's the whole story about this episode. 214 01:11:42,899 --> 01:11:44,366 It will be interesting. 215 01:11:44,933 --> 01:11:46,533 Dedicated environments, I think that's 216 01:11:46,533 --> 01:11:48,466 just one part and the second one is shared. 217 01:11:49,500 --> 01:11:56,566 I think what will be important is that right from the 218 01:11:56,566 --> 01:12:00,600 beginning, we're really focusing on VCF 9 219 01:12:00,600 --> 01:12:05,300 and also what the new tools and or the new product will 220 01:12:05,300 --> 01:12:07,233 offer from a future perspective. 221 01:12:08,266 --> 01:12:11,166 I think it's very important that we start from the 222 01:12:11,166 --> 01:12:16,466 beginning: coming up with ideas how to migrate from A to B, 223 01:12:17,500 --> 01:12:24,066 regarding VCF to VCF migration like 5.229 on top as well as 224 01:12:24,066 --> 01:12:29,466 in the near future from VCD to VCF Automation. 225 01:12:30,833 --> 01:12:35,933 Of course, there will be some tools supporting some or 226 01:12:35,933 --> 01:12:37,866 different migration scenarios, 227 01:12:37,866 --> 01:12:41,066 but as we saw in the past with V2T, 228 01:12:41,600 --> 01:12:44,199 the migration tool solves just the basics 229 01:12:44,199 --> 01:12:47,666 or standardized configurations and as soon as you have 230 01:12:47,666 --> 01:12:52,300 some custom built, the tool struggles to migrate 231 01:12:52,500 --> 01:12:55,766 and that's something that needs to be migrated manually. 232 01:12:56,000 --> 01:13:02,800 I assume the Cloud Director migration to VCF Automation will 233 01:13:02,800 --> 01:13:04,866 be even more complex. 234 01:13:05,500 --> 01:13:10,166 Even though you have standardized use cases, but a lot more 235 01:13:10,166 --> 01:13:13,100 compared to NSX, because you have some networking 236 01:13:13,500 --> 01:13:17,933 configurations and features. So in V it's 237 01:13:17,933 --> 01:13:21,366 named A and in T it's B and it migrate over. 238 01:13:21,733 --> 01:13:25,233 But in Cloud Director, you have way more different 239 01:13:25,233 --> 01:13:30,033 configuration options and the migration tool might be 240 01:13:30,500 --> 01:13:33,666 or the migration will be challenging. Every migration is 241 01:13:33,666 --> 01:13:35,800 challenging, but we need to come up with 242 01:13:35,800 --> 01:13:37,466 proper solutions right from the beginning. 243 01:13:38,500 --> 01:13:41,733 And we need to take a real deep look in all of this 244 01:13:41,733 --> 01:13:45,800 migration tools. So we saw it in the V2T migration tools. 245 01:13:46,033 --> 01:13:48,966 There are so many different versions coming out step by 246 01:13:48,966 --> 01:13:54,933 step, and also be skeptical if 247 01:13:54,933 --> 01:13:58,066 you run now the assessment tool, 248 01:13:58,066 --> 01:14:02,566 if it is available for VCF 9. That doesn't mean so. That 249 01:14:02,566 --> 01:14:03,466 will work for the enterprise. 250 01:14:03,533 --> 01:14:07,133 Absolutely. I'm positive that they're bringing out a really 251 01:14:07,133 --> 01:14:08,600 good product for the assessment, 252 01:14:09,466 --> 01:14:12,033 but I don't think that they have service 253 01:14:12,033 --> 01:14:15,233 providers in mind on this migration tool. 254 01:14:15,899 --> 01:14:23,399 So we also will spend a lot of time in the next months to 255 01:14:23,399 --> 01:14:25,933 check what's possible, what's not possible, 256 01:14:26,766 --> 01:14:29,566 what features will work, what features will not work maybe 257 01:14:29,566 --> 01:14:31,466 with VCF 9 in the first versions, 258 01:14:32,500 --> 01:14:36,199 because I think the Assessment Tool will not cover all of 259 01:14:36,199 --> 01:14:38,133 these different scenarios you have 260 01:14:38,133 --> 01:14:39,666 currently on a service provider side. 261 01:14:40,533 --> 01:14:41,666 That will be a challenge. 262 01:14:42,833 --> 01:14:47,466 Yeah, it's a more. So, yeah, the first assessment tool will 263 01:14:47,466 --> 01:14:51,966 be a more generic approach, like trying to cover just VCF 264 01:14:51,966 --> 01:14:58,066 without having any specialized entity 265 01:14:58,066 --> 01:15:00,466 behind that like an enterprise or a CSP. 266 01:15:01,500 --> 01:15:06,100 I think it will be by its nature more enterprise focused, 267 01:15:06,100 --> 01:15:08,566 because that's the majority of the customers. 268 01:15:10,666 --> 01:15:15,833 But I assume that the first version will just check what's 269 01:15:15,833 --> 01:15:18,233 the current VCF configuration 270 01:15:18,233 --> 01:15:20,533 from an SDDC manager perspective. 271 01:15:21,666 --> 01:15:25,600 Can this configuration, because that's the part of VCF, it 272 01:15:25,600 --> 01:15:27,466 has one central configuration. 273 01:15:27,533 --> 01:15:34,566 Can this configuration be migrated to VCF 9? Yes or no? 274 01:15:35,266 --> 01:15:37,766 And I think that's pretty straightforward. 275 01:15:38,566 --> 01:15:40,933 But again, I agree. That's just the infrastructure 276 01:15:40,933 --> 01:15:43,766 configuration which can be 277 01:15:43,766 --> 01:15:46,566 decided on is it migratable? Yes or no? 278 01:15:47,199 --> 01:15:49,866 But it's not validating any use case 279 01:15:49,866 --> 01:15:51,466 which is built on top of the configuration. 280 01:15:52,500 --> 01:15:55,899 And that's a different story. And that's where you 281 01:15:55,899 --> 01:15:58,666 differentiate between an enterprise and a CSP. 282 01:16:00,333 --> 01:16:03,466 Absolutely. And that's the topic we need to cover. 283 01:16:03,533 --> 01:16:12,133 Also I'm very interested in the 284 01:16:12,133 --> 01:16:14,800 timelines of the third party vendors. 285 01:16:15,766 --> 01:16:21,199 So how long will it be until all of the backup vendors 286 01:16:21,199 --> 01:16:24,399 and replication vendors will 287 01:16:24,399 --> 01:16:27,466 cover all of the new VCF 9 topics. 288 01:16:27,500 --> 01:16:33,666 Because I think there will be a lot of major changes also 289 01:16:33,666 --> 01:16:36,233 in vSphere, vCenter and so on. 290 01:16:36,833 --> 01:16:40,399 And that makes it not easy for the third party vendors to 291 01:16:40,399 --> 01:16:44,233 directly change and get the product certified. 292 01:16:46,066 --> 01:16:50,566 But honestly, Sascha, that's not VCF 9 really. We had that 293 01:16:50,566 --> 01:16:53,600 topic every single vSphere version in the 294 01:16:53,600 --> 01:16:56,166 past. So don't get me wrong on that one. 295 01:16:56,766 --> 01:17:00,600 Absolutely. But as we're talking about some major changes 296 01:17:00,600 --> 01:17:05,566 maybe in VCF 9, if we take a look 297 01:17:05,566 --> 01:17:09,699 at what happens in the past, it will take much longer as we 298 01:17:09,699 --> 01:17:12,300 get support for this third party products. 299 01:17:13,000 --> 01:17:19,866 To like major change. You might be too young for that. 300 01:17:20,699 --> 01:17:24,800 Or think about like the change from 4 to 5 in the 301 01:17:24,800 --> 01:17:27,733 past. That was major and it took 302 01:17:27,733 --> 01:17:32,433 like months for the vendors to adjust. 303 01:17:32,533 --> 01:17:38,966 So the changes between the latest versions like 6 to 7, 7 304 01:17:38,966 --> 01:17:48,133 to 8 were not that big because the product behavior changed 305 01:17:48,133 --> 01:17:50,433 in small features, which added a 306 01:17:50,433 --> 01:17:52,466 ton of value for the customers. 307 01:17:52,533 --> 01:17:58,000 But the product change itself wasn't that that big from my 308 01:17:58,000 --> 01:17:59,833 perspective. And then also the 309 01:17:59,833 --> 01:18:01,933 APIs didn't change that much. 310 01:18:02,566 --> 01:18:06,866 I think what I saw is that the third party vendors were 311 01:18:06,866 --> 01:18:11,833 pushing towards getting certified with the new 312 01:18:11,833 --> 01:18:15,466 version. Whatever blocked them to get certified. 313 01:18:15,500 --> 01:18:19,800 Maybe it's the money. Maybe it's the process or whatever. 314 01:18:20,433 --> 01:18:24,933 But I think the changes weren't that big. But with VCF 9 315 01:18:24,933 --> 01:18:26,933 you have no clue what's the underlying infrastructure. 316 01:18:27,633 --> 01:18:30,333 What the underlying infrastructure will be. Let's call it 317 01:18:30,333 --> 01:18:35,566 VCF 9. There will be a vSphere stack in there. Whatever the 318 01:18:35,566 --> 01:18:37,899 name will be and the version will be. 319 01:18:38,533 --> 01:18:43,566 It could be 8.8 update 4. It could 320 01:18:43,566 --> 01:18:46,566 be vSphere 9. I have no idea what. 321 01:18:47,866 --> 01:18:52,266 I clearly think that they want to go to version 9 in 322 01:18:52,266 --> 01:18:55,100 all products. Because otherwise it 323 01:18:55,100 --> 01:18:58,666 makes no sense to jump from VCF 5 to 9. 324 01:18:59,966 --> 01:19:03,466 That's true. But the question is, is it a new product or 325 01:19:03,466 --> 01:19:07,866 just a name or a version change? Because we saw in the past 326 01:19:07,866 --> 01:19:10,566 in a few coincidences that they just 327 01:19:10,566 --> 01:19:14,433 changed the number like Log Insight; 328 01:19:14,699 --> 01:19:17,466 I know now it's called Aria Operations for Log. 329 01:19:17,466 --> 01:19:19,133 But in the past... VCF Log? 330 01:19:20,566 --> 01:19:25,133 Jesus Christ. They switched. Back then it was vRealize 331 01:19:25,133 --> 01:19:29,066 Log Insight. But they changed from 4.7 to 8 to streamline 332 01:19:29,066 --> 01:19:31,933 the version numbers. So it could be also 333 01:19:31,933 --> 01:19:35,466 something like this. Tons of possibilities. 334 01:19:38,033 --> 01:19:41,866 Yes, it becomes really interesting. But let's cover one 335 01:19:41,866 --> 01:19:46,300 other topic. We got this question from many service 336 01:19:46,300 --> 01:19:50,833 providers currently. They are still on NSX-V. So Eve covered 337 01:19:50,833 --> 01:19:53,466 Yves covered it at the beginning at the intro. 338 01:19:54,500 --> 01:19:58,733 What should service providers do: stay on NSX-V and 339 01:19:58,733 --> 01:20:03,433 wait for VCF 9 to try to do a complete migration or 340 01:20:03,433 --> 01:20:07,233 whatever? So I think we also should cover this topic. 341 01:20:07,233 --> 01:20:10,466 Pardon the interruption. And I'm really looking forward to 342 01:20:10,466 --> 01:20:13,533 the statement of Yves. But we have a question in the chat. 343 01:20:14,033 --> 01:20:18,233 Oh, see, I have voice command. 344 01:20:19,633 --> 01:20:23,733 So the question is, "When will VCF 9 be released? 345 01:20:23,733 --> 01:20:27,899 Will VCD 10.6 be the last standalone version? 346 01:20:27,899 --> 01:20:31,600 version of the city? We really heavily rely heavily on 347 01:20:31,600 --> 01:20:33,066 cloud director and so on and so forth. 348 01:20:33,466 --> 01:20:37,433 So I think the short answer is as far as we know 10.6 will 349 01:20:37,433 --> 01:20:41,100 be the last standalone version of Cloud Director. 350 01:20:41,100 --> 01:20:43,500 Currently it's 10.6.0.1. 351 01:20:45,500 --> 01:20:48,133 I don't know if we are allowed to share a VCF 9 release 352 01:20:48,133 --> 01:20:50,733 date. There is a roadmap with which 353 01:20:50,733 --> 01:20:53,466 has a date suggestion. Sascha is nodding. 354 01:20:54,500 --> 01:21:00,433 So the idea is, VCF 9 will be released in 355 01:21:00,433 --> 01:21:03,233 the middle of this year. So that's public. 356 01:21:04,899 --> 01:21:12,033 And VCF 9 will not have a shared workload domain support 357 01:21:12,033 --> 01:21:17,766 for tenancy. That will come with version 9.1 358 01:21:17,766 --> 01:21:20,766 which will be released in 2026. 359 01:21:21,500 --> 01:21:26,133 And yes, it's currently the plan that 10.6 is the last 360 01:21:26,133 --> 01:21:29,933 standalone version or version of VCD. It will be integrated 361 01:21:29,933 --> 01:21:34,833 in VCF -- no longer being a dedicated product. I would say 362 01:21:34,833 --> 01:21:38,466 the features will be integrated in VCF. 363 01:21:39,500 --> 01:21:46,833 Not the product and if this is the last 364 01:21:46,833 --> 01:21:52,833 version, so I would absolutely expect that there will be a 365 01:21:52,833 --> 01:21:57,233 new version that supports VCF 9 in VCD. 366 01:21:59,166 --> 01:22:01,466 But it will be a 10.6 something release. 367 01:22:02,500 --> 01:22:06,933 Yeah, 10.6 something, 10.7. Nobody knows what will be the 368 01:22:06,933 --> 01:22:10,600 name of it. From that perspective, 369 01:22:10,600 --> 01:22:14,466 there will be no new features in the future. 370 01:22:15,500 --> 01:22:20,333 So maybe rephrase it a little bit. So 10.6, speaking as of 371 01:22:20,333 --> 01:22:22,500 today, does not support VCF 9. 372 01:22:23,500 --> 01:22:26,399 Right. And there will be from a timeline perspective, 373 01:22:26,399 --> 01:22:30,733 a timeframe where we have a Cloud Director 374 01:22:30,733 --> 01:22:34,466 version, whatever the name will be, which supports VCF 9. 375 01:22:35,500 --> 01:22:38,933 And that's the migration window we will have in the future. 376 01:22:39,166 --> 01:22:44,166 But we as comdivision will heavily keep track on all 377 01:22:44,166 --> 01:22:46,666 the different features and versions and then have a 378 01:22:46,666 --> 01:22:50,466 migration solution ready by the time it needs to be ready. 379 01:22:51,500 --> 01:22:54,866 Absolutely. But to cover also the second part of the 380 01:22:54,866 --> 01:23:00,466 question about the web interface or the interface of VCD. I 381 01:23:00,466 --> 01:23:02,466 don't think that Broadcom will 382 01:23:02,466 --> 01:23:06,466 migrate this view from VCD in VCF. 383 01:23:07,500 --> 01:23:13,966 I more expect that we get more like a VCF or vCenter view 384 01:23:13,966 --> 01:23:18,633 for the customers. Maybe not on the host side, but on the 385 01:23:18,633 --> 01:23:23,133 VM side, on the network side, that we get it more in that 386 01:23:23,133 --> 01:23:26,466 way than on the VCD way that we have currently. 387 01:23:26,533 --> 01:23:31,633 So that will be my expectation. But again, we don't... 388 01:23:31,633 --> 01:23:34,699 The VCD UI for tenants is great, but it's 389 01:23:34,699 --> 01:23:38,500 complex. And if you have no clue what to do, it's like it's 390 01:23:38,500 --> 01:23:40,466 overwhelming from from a feature perspective. 391 01:23:41,500 --> 01:23:45,300 So I assume that the UI will change, because it changed a 392 01:23:45,300 --> 01:23:50,033 lot with 10.6 and it will change again massively, but it 393 01:23:50,033 --> 01:23:55,500 will offer a reduced feature set towards the tenant to just 394 01:23:55,500 --> 01:23:58,066 come up with the features that tenant really needs. 395 01:23:58,066 --> 01:24:00,633 What Broadcom thinks a tenant will need and 396 01:24:00,633 --> 01:24:02,466 everything else will be a managed service. 397 01:24:03,933 --> 01:24:12,399 I'm not sure if they will reduce the features, because as we 398 01:24:12,399 --> 01:24:16,866 got in the last year, the message from Broadcom directly, 399 01:24:17,733 --> 01:24:21,533 "hey, these are our dedicated workload domains, 400 01:24:21,533 --> 01:24:24,833 sell dedicated workload domains to the customers. 401 01:24:24,833 --> 01:24:26,766 And the customers want to have those features 402 01:24:26,766 --> 01:24:28,733 So from the Broadcom perspective. 403 01:24:28,733 --> 01:24:34,699 But, not via Cloud Director. Correct, but but over VCF. 404 01:24:34,699 --> 01:24:38,733 But that's the question. Like VCD UI, how will VCF UI 405 01:24:38,733 --> 01:24:40,066 towards the tenant look like? 406 01:24:40,833 --> 01:24:42,166 How will the permissions look like? 407 01:24:42,566 --> 01:24:44,899 Which can be shown, what can be 408 01:24:44,899 --> 01:24:47,199 hidden in the UI. That will be a big game. 409 01:24:47,966 --> 01:24:55,733 Absolutely. But as we... So from my perspective, the new 410 01:24:55,733 --> 01:25:00,000 interface for tenants on dedicated workload domains, 411 01:25:00,000 --> 01:25:03,533 they should have the same experience like they have in 412 01:25:03,533 --> 01:25:05,866 their home cloud with VCF local. 413 01:25:06,966 --> 01:25:11,133 So from that idea, I think we get a permission set where we 414 01:25:11,133 --> 01:25:14,233 can say, "that's allowed for the customer and that's not." 415 01:25:14,233 --> 01:25:19,199 Like we have it currently with VMC on AWS, AVS, GVZ and so 416 01:25:19,199 --> 01:25:23,266 on. So you can... Or the hyperscalers can limit it, but you 417 01:25:23,266 --> 01:25:26,533 have the normal vSphere view. 418 01:25:26,533 --> 01:25:30,566 I think, from my perspective, it will go in that 419 01:25:30,566 --> 01:25:34,066 direction because many of the service providers and also 420 01:25:34,066 --> 01:25:37,399 normal customers complain that they don't have the normal 421 01:25:37,399 --> 01:25:39,266 vSphere view like they expect. 422 01:25:40,466 --> 01:25:44,566 Cool. And guys, to all our folks listening to us, and 423 01:25:44,566 --> 01:25:45,733 that's a cool part. So Sascha 424 01:25:45,733 --> 01:25:47,466 and I, we agree that we disagree. 425 01:25:48,500 --> 01:25:51,566 But that's a cool thing having multiple opinions and that's 426 01:25:51,566 --> 01:25:54,899 clear that clearly shows that we have no knowledge. It's 427 01:25:54,899 --> 01:25:57,300 just our opinions we are currently sharing. 428 01:25:58,466 --> 01:26:01,533 Thanks. Thanks for a great question. But Sascha, PTI, 429 01:26:01,533 --> 01:26:05,000 pardon eruption. You were to ask Yves a great question. 430 01:26:08,366 --> 01:26:09,466 Could you repeat the question? 431 01:26:10,500 --> 01:26:17,733 Yes. It was on the side where we covered or got many 432 01:26:17,733 --> 01:26:19,833 requests from customers. Also 433 01:26:19,833 --> 01:26:23,133 this morning we talked about it: NSX-V. 434 01:26:23,466 --> 01:26:28,399 So if I'm now on NSX-V, should I do the transition to T or 435 01:26:28,399 --> 01:26:33,866 should I stay on V until VCF 9.1 is out 436 01:26:33,866 --> 01:26:35,466 and then migrate directly or whatever? 437 01:26:36,500 --> 01:26:42,833 So maybe Matthias, you will cover this question. 438 01:26:43,533 --> 01:26:47,566 I thought Yves was covering the answer? 439 01:26:48,933 --> 01:26:52,366 I think I have audio back. Not ideal audio, but I have some 440 01:26:52,366 --> 01:26:58,533 audio back. But I think the answer is very simple. We don't 441 01:26:58,533 --> 01:27:02,100 know what else the migration path is going to look like. 442 01:27:02,100 --> 01:27:05,366 So we now and VMware promised there will be a migration path 443 01:27:05,366 --> 01:27:10,566 from current VCD to whatever the new thingy, multi-tenancy 444 01:27:10,566 --> 01:27:12,566 thingy is going to be called. 445 01:27:12,933 --> 01:27:15,933 So from that perspective, you should definitely do that. 446 01:27:16,133 --> 01:27:19,666 There will be absolutely no way that Broadcom or VMware is 447 01:27:19,666 --> 01:27:21,333 going to invest anything to get you 448 01:27:21,333 --> 01:27:23,466 from NSX-V to whatever the new thing is. 449 01:27:24,500 --> 01:27:26,466 There will be no way into a VCF 450 01:27:26,466 --> 01:27:29,633 9. So the solution is very clear. 451 01:27:29,633 --> 01:27:32,933 You currently have a pathway which is still working to get 452 01:27:32,933 --> 01:27:37,699 you from NSX-V with whatever VCF version you are on to VCF 453 01:27:37,699 --> 01:27:41,333 5.2 in combination with VCD and 454 01:27:41,333 --> 01:27:42,466 all of these wonderful things. 455 01:27:42,533 --> 01:27:47,266 So don't wait. Don't delay it, because 456 01:27:47,266 --> 01:27:52,000 every day you delay it, 457 01:27:52,000 --> 01:27:56,033 the less chance there is if there is something going wrong, 458 01:27:56,033 --> 01:27:59,466 if there is a possibility to get anyone from Broadcom to 459 01:27:59,466 --> 01:28:00,966 reacting to this from a support 460 01:28:00,966 --> 01:28:03,733 perspective is shrinking on a daily basis. 461 01:28:03,733 --> 01:28:06,466 There are not that many people left who actually can answer 462 01:28:06,466 --> 01:28:08,566 anything on NSX-V. I mean, let alone 463 01:28:08,566 --> 01:28:10,466 that even the extended support is out. 464 01:28:11,033 --> 01:28:13,666 Let alone security incidents and all of these wonderful 465 01:28:13,666 --> 01:28:16,533 scenarios. So there is basically no choice. 466 01:28:16,800 --> 01:28:21,733 You need to move from V to T/VCF at the fastest pace. 467 01:28:21,966 --> 01:28:24,433 Actually, if you are still on V, you 468 01:28:24,433 --> 01:28:27,633 can directly move from V into VCF 5.2. 469 01:28:27,633 --> 01:28:30,066 Yes, you might need new hardware and everything else, but 470 01:28:30,066 --> 01:28:32,066 overall you delay the project so long 471 01:28:32,066 --> 01:28:34,100 that you most likely have to do that anyway. 472 01:28:35,500 --> 01:28:39,866 And prepare then to actually move from there to VCF 9. 473 01:28:40,399 --> 01:28:43,566 But there will be no options and Broadcom also made very, 474 01:28:43,566 --> 01:28:48,100 very clear that in the future, the time they are accepting 475 01:28:48,100 --> 01:28:49,766 that people are running outdated 476 01:28:49,766 --> 01:28:51,533 and old versions is going to shrink. 477 01:28:51,766 --> 01:28:54,133 They want to have everybody on the same level, on the same 478 01:28:54,133 --> 01:28:57,800 grade and all of these things more like operating a cloud. 479 01:28:57,800 --> 01:28:59,466 There should be no difference for a customer. 480 01:28:59,500 --> 01:29:03,433 When you closely watch Hock's keynote, he says very clearly 481 01:29:03,433 --> 01:29:06,266 he doesn't want to have any difference for a customer 482 01:29:06,266 --> 01:29:09,500 experience on-prem to public cloud, 483 01:29:09,500 --> 01:29:11,300 which also comes back to Sascha's point. 484 01:29:11,300 --> 01:29:14,033 I'm also with him. The user interface from VCD -- 485 01:29:14,266 --> 01:29:17,133 my personal opinion also is that it's going to be 486 01:29:17,133 --> 01:29:20,300 be the same like in vSphere or anything else, because of 487 01:29:20,300 --> 01:29:22,433 same overview, same usability everywhere. 488 01:29:22,500 --> 01:29:27,633 But based on the fact of the same usability, Broadcom needs 489 01:29:27,633 --> 01:29:30,800 to get every service provider globally on the same software 490 01:29:30,800 --> 01:29:33,633 version, most likely as soon as possible because in 491 01:29:33,633 --> 01:29:36,266 reality, let's face it, even Microsoft has different 492 01:29:36,266 --> 01:29:38,166 rollout phases and things like 493 01:29:38,166 --> 01:29:39,466 that over the different sides. 494 01:29:39,733 --> 01:29:43,033 So that's going to be a reality across all of them. 495 01:29:43,033 --> 01:29:45,466 But yeah, that's my opinion on it. 496 01:29:45,533 --> 01:29:48,833 So get going because it's not going to get easier. 497 01:29:48,833 --> 01:29:50,333 It's just going to get more and more 498 01:29:50,333 --> 01:29:52,666 difficult and more and more risky on a daily basis. 499 01:29:55,933 --> 01:29:57,166 So now, Matthias, up to you. 500 01:29:58,866 --> 01:30:02,166 Oh, we're already in the famous last words phase, right? 501 01:30:02,833 --> 01:30:04,966 Because we're way over time, 502 01:30:04,966 --> 01:30:06,933 but it's always the same with us. 503 01:30:06,933 --> 01:30:08,333 If we start discussing and sharing 504 01:30:08,333 --> 01:30:11,300 knowledge, it's like, yeah, time flies by. 505 01:30:12,766 --> 01:30:22,933 Yeah, so I think what I expect for 2025 and the future is 506 01:30:22,933 --> 01:30:27,066 a massive standardization this year 507 01:30:27,066 --> 01:30:32,433 with VCF 9 and what you said, streamlining UIs for 508 01:30:32,433 --> 01:30:34,366 on-prem for public cloud, that 509 01:30:34,366 --> 01:30:36,466 will be 2026, but it's an expectation. 510 01:30:36,533 --> 01:30:41,533 This year will be introduction of VCF 9, starting 511 01:30:41,533 --> 01:30:45,033 migrations to VCF 9, getting hands-on VCF 512 01:30:45,033 --> 01:30:48,366 9 and getting familiar with the product. 513 01:30:48,366 --> 01:30:53,300 That's what I expect in 2025 and us coming up with cool new 514 01:30:53,300 --> 01:30:58,266 use cases and product usages and product packaging for 515 01:30:58,266 --> 01:31:02,266 the first like dedicated infrastructure bits and pieces. 516 01:31:02,533 --> 01:31:04,333 That's what I'm looking forward to. 517 01:31:04,500 --> 01:31:07,733 That's what I expect from 2025. 518 01:31:10,266 --> 01:31:11,566 Sascha, famous last words. 519 01:31:12,500 --> 01:31:16,933 Yes, so I expect a few years of changes 520 01:31:16,933 --> 01:31:20,433 now with all of the migration phases again. 521 01:31:21,066 --> 01:31:21,966 We had V2T. 522 01:31:21,966 --> 01:31:26,766 We are still in V2T and now planning for going to VCF 9. 523 01:31:29,933 --> 01:31:32,533 For my last words, I absolutely recommend 524 01:31:32,533 --> 01:31:35,333 to take a look what features you are using. 525 01:31:36,233 --> 01:31:38,000 Maybe also send it to us. 526 01:31:38,666 --> 01:31:40,566 Send your products and your features in 527 01:31:40,566 --> 01:31:43,000 VCD to us that you are currently using. 528 01:31:43,533 --> 01:31:47,300 We will ccollect that info and meet with 529 01:31:47,300 --> 01:31:50,633 Broadcom to show which products are used. 530 01:31:51,633 --> 01:31:55,833 Because currently, I think they have a lot of customers 531 01:31:55,833 --> 01:31:59,166 where they have big relationships, especially on the 532 01:31:59,166 --> 01:32:02,166 Pinnacle partner stuff, that they take care of. 533 01:32:03,000 --> 01:32:05,766 But currently, they more or less don't pay as much attention 534 01:32:05,766 --> 01:32:07,033 to the Premiere partners and the registered ones, 535 01:32:07,033 --> 01:32:09,566 so the secondary white label ones. 536 01:32:10,366 --> 01:32:16,166 And I think we should create a big list of features that 537 01:32:16,166 --> 01:32:18,066 our service providers currently using. 538 01:32:18,466 --> 01:32:19,399 Share it with us. 539 01:32:19,399 --> 01:32:20,466 We will share it with Broadcom. 540 01:32:20,533 --> 01:32:24,633 Also, maybe feature requests that can be integrated in 541 01:32:24,633 --> 01:32:28,666 future versions so that we can bring it to the development 542 01:32:28,666 --> 01:32:32,466 team of Broadcom and ask if there is a potential option to 543 01:32:32,466 --> 01:32:33,800 bring it in and the new product. 544 01:32:38,500 --> 01:32:43,466 So that being said, I think it's as we agree on. 545 01:32:43,466 --> 01:32:44,833 You need to get to the current versions. 546 01:32:45,266 --> 01:32:46,933 That's one of the most important things. 547 01:32:48,899 --> 01:32:51,233 Also, if you want to be relevant for your customers, 548 01:32:51,533 --> 01:32:54,300 because Broadcom is also going to look for the customers 549 01:32:54,300 --> 01:32:57,033 and service providers which are on current versions. 550 01:32:57,266 --> 01:32:59,733 We already know that they are tracking that currently for 551 01:32:59,733 --> 01:33:01,666 licensing purposes and other things, but 552 01:33:01,666 --> 01:33:03,266 there will be more reasons behind that. 553 01:33:04,133 --> 01:33:06,466 So better be sure to be up to date. 554 01:33:06,466 --> 01:33:10,066 If you need any help, feel free to reach out to us. 555 01:33:10,533 --> 01:33:12,866 One last word. 556 01:33:13,333 --> 01:33:16,766 Starting in February, for at least the service providers 557 01:33:16,766 --> 01:33:20,433 which are working with us on the training side, which are 558 01:33:20,433 --> 01:33:22,766 White Label or in any other way related to us. 559 01:33:22,766 --> 01:33:27,066 We are going to also host a monthly webinar where we cover 560 01:33:27,066 --> 01:33:28,233 all the latest and greatest 561 01:33:28,233 --> 01:33:31,966 news around the VMware ecosystem. 562 01:33:32,633 --> 01:33:34,500 And based on that, also what 563 01:33:34,500 --> 01:33:36,466 we are really knowing about VCD. 564 01:33:36,533 --> 01:33:39,000 The reason for the webinar is it gives us a bit more 565 01:33:39,000 --> 01:33:41,733 freedom because we can get everybody to sign an NDA first. 566 01:33:42,966 --> 01:33:44,133 That gives us a bit more 567 01:33:44,133 --> 01:33:46,399 flexibility on what we can cover there. 568 01:33:46,399 --> 01:33:49,533 If you are interested in that, also feel free to ping 569 01:33:49,533 --> 01:33:51,433 one of us and we can see if we can 570 01:33:51,433 --> 01:33:53,666 get you enlisted for that one as well. 571 01:33:54,266 --> 01:33:58,833 That being said, this was our first episode for 2025. 572 01:33:59,533 --> 01:34:04,500 We are going to be, at least Sascha and I, with Broadcom 573 01:34:04,500 --> 01:34:07,033 next week in Orlando, depending on when 574 01:34:07,033 --> 01:34:09,766 this podcast comes out that might already be in the past, 575 01:34:09,766 --> 01:34:10,966 but the week of Jan. 21st. 576 01:34:11,500 --> 01:34:15,533 Some partners are invited by Broadcom to actually meet in 577 01:34:15,533 --> 01:34:18,333 Orlando for some advisory boards. 578 01:34:19,233 --> 01:34:20,800 As you might expect, comdivision is going 579 01:34:20,800 --> 01:34:23,466 to be there and we are going to cover that. 580 01:34:23,533 --> 01:34:26,366 We are going to cover some latest changes on the Knights 581 01:34:26,366 --> 01:34:31,833 Program and then we are going to basically be for the 582 01:34:31,833 --> 01:34:34,033 comdivision Kickoff back here in Dubai. 583 01:34:34,933 --> 01:34:37,933 And we are also going to do an episode, I think, from here 584 01:34:37,933 --> 01:34:39,833 as well as far as I remember, like 585 01:34:39,833 --> 01:34:41,966 what we did at all the last kickoffs. 586 01:34:43,433 --> 01:34:47,766 So that being said, have a wonderful remainder of the week 587 01:34:47,766 --> 01:34:49,733 and whenever you listen to it... 588 01:34:52,666 --> 01:34:57,933 Matthias, not everybody has the day done by the afternoon. 589 01:35:00,933 --> 01:35:05,133 Good, everybody, thank you for listening in. Goodbye. 590 01:35:05,966 --> 01:35:07,366 Have a great weekend, bye.