10 on Tech Episode 011 – VCSA Migration with Emad Younis

Share with your friends


VMware has been pushing hard for the adoption of the vCenter Server Appliance over the original Windows-based deployment model for a few major releases of the product. As of recently, the VCSA has reached feature parity with the Windows version and there are many very good reasons to adopt a VCSA-based vCenter design. Once of the many challenges with adoption has been that brownfield migration from a Windows vCenter Server to the VCSA is challenging at best.

I’m pleased to have a longer-than-normal episode with Emad Younis to discuss this important announcement: Emad blogged about a week and a half ago on the VMware blog about the release of vSphere 6.0 Update 2m « the ‘m’ stands for “migration.” Update 2m provides a supported, GUI-based method of migrating from a Windows vCenter Server to the VCSA while everything remains intact – the basics like inventory and policies, but also historic performance and alarm data if you’d like! This is exciting for many customers, so I decided to waive the 10-minute episode regulation and dig in a little further. Please enjoy this great talk with Emad!

You can find the transcript of this episode below the player, and please be sure to subscribe to 10 on Tech on iTunes, Google Play, or Stitcher!

Show Transcript
James Green: Hello, and welcome to another episode of 10 on Tech. This week, I’ve got my friend Emad Younis on the show. If you want to get ahold of Emad, you can look him up on Twitter. He is @emad_younis. Emad is a Senior TME at VMware. He’s working with the vCenter Server Appliance. Emad, thanks for joining me. Appreciate it.
Emad Younis: Thanks for having me.
James Green: What we’re talking about today is something that you guys just announced a couple days ago which is a tool to help customers migrate from a Windows vCenter server to the vCenter appliance. I was a consultant for a number of years before I moved into the capacity that I’m in now, and that was something that came up all the time because since, what, maybe 5.1 time frame VMware has been saying, “This is the direction we’re headed and at some point, you got to get on the train here.” Obviously, there’s cases where people still have a really good reason to use a Windows vCenter server. A lot of cool stuff is happening with the VCSA, and over the last couple of versions the feature parody with the Windows vCenter server has come up to being about equal. You can scale it the same and support a lot of the same stuff. It’s really getting to a place where, at least in my opinion, a lot of people should be moving that way but doing that in the past has been non-trivial
  Just as a warning to our listeners, this is a topic that’s near and dear to me and to Emad too. I think that it’s something a lot of people are thinking about and will find interesting, so there’s a pretty high probability of this episode running longer than our usual 10 minutes but I hope it’s valuable. Emad, first before we dive into it, why don’t you just tell me high level what is the announcement? What is the tool and what is the purpose?
Emad Younis: Sure. We just announced vSphere 6.0 update 2M, M for migration. What that allows us to do is we can basically migrate the configuration inventory and alert data by default of a Windows vCenter server and bring that all to a vCenter server appliance too. We’ll get you up to the latest and greatest. We do all the heavy lifting for you. We also allow you an option, if you want to bring over your historical and performance data it’s as simple as a check box. The other great thing about the migration tool is we also assume and preserve the identity of your Windows vCenter. What that really means is we will bring over the IP address, FQDN, UUID, certificates, anything that is part of the identity of the vCenter server. Because we have other solutions that talk to vCenter, they don’t know any different. As far as they’re concerned, it’s the same vCenter server.
  That’s the gist of what the migration tool does. It’s basically what we used to do manually but on steroids. It does all the heavy lifting for us and we get to preserve that identity which is something we couldn’t do via scripting or manual
James Green: Yeah, and that bit is huge because I’ve, more times than I can count, just built a second one. Kind of rebuilt the same sort of thing, swung everything over, but then because the identity wasn’t maintained, there’s still a lot of things that have to be reconfigured and repointed. You have all the crazy stuff with SSO, and being able to maintain that identity as you move to the new appliance is going to be huge.
Emad Younis: The other cool thing, just real quick, is kind of what you mentioned. We don’t now have to stand up side by side and have to manage two vCenters. We automatically spin up a vCenter server appliance, and then we do the migration. We don’t have to worry about, “Am I going to manage two vCenters for another week or two?” It’s all done for you. The other key piece is this is a migration and an upgrade going on at the same time because we’re going from 5.5 to 6.0 update 2. The same rules apply when it comes to interop. You’re going to have to go out and make sure all your solutions are also going to be working with 6.0 in that regard. You want to do your homework before you start the migration.
James Green: Sure. Let’s talk about… I said that for a while VMware has been pushing people in the direction of VCSA but that’s not really a good enough reason to move. Let’s talk about why is it that people would want to start using the vCenter server appliance as opposed to the Windows-based vCenter server they may have been using in the past?
Emad Younis: Well, for obvious reasons. First, no operating system or database license dependency. At that point, you get that cost back in your pocket. There’s very minimal database maintenance that you have to do. In the case of Windows, you have to configure SQL and you have to maintain it. You have to do roll-up jobs, backups, things like that. We give you that time back. One-click patching in a sense. With Windows, you have to patch the operating system and depending on the organization that you’re in, you may also have to pass it along to another group, your virtualization group and they may have to update the vCenter portion. With the appliance, you patch everything all in one stack.
  The other great thing about the appliance is it’s really great to provision. We just deploy OVA or mount from ISO, and just go through the wizard. It’s a lot quicker than having to provision a Winders server, install the operating system. Even if you templatize it, you still got to go through the patching process then install vCenter. The appliance is just, once you get to the wizard, boom, done, up and running.
James Green: The licensing piece is definitely important because if, say, you were dedicating a SQL server just to hosting vCenter databases, that’s I don’t know how much depending on your licensing agreement but lots of money by not running that. Potentially, depending on your licensing scheme, it’s not a Windows license that you have to pay for anymore. That’s big. The database thing is, on my list, probably the top though because another thing that I’ve seen 100 times in the field is a vCenter database has been migrated between SQL servers a couple of times over its lifetime and what a lot of people performing that migration don’t know is that those maintenance roll-up jobs, they don’t move with it so you have to recreate them on the far side.
  Since most people don’t know that, it doesn’t get done and then the vCenter database just gets massive and ugly. When you move over to the vCenter server appliance and start using the embedded database, you don’t have any of those maintenance problems anymore. It’s taken care of for you. That’s another really good reason I would recommend moving over. You said that it’s two things actually, it’s a migration and an upgrade. What I heard you say is it’s for anybody who’s running 5.5, any version if I’m not mistaken, and it’ll upgrade you to 6.0 update 2M.
Emad Younis: Sorry, it’s update two. M just stands for migration, so we just go to update two.
James Green: Sure, got it. Couple of questions. One, what’s the process if I’m running 5.1 or something even older but I want to migrate to the VCSA? How does that workflow go?
Emad Younis: If you’re on let’s say 5.0 or 5.1, first of all those went end of life at the end of August-
James Green: So shame on you.
Emad Younis: Yeah, but what happens is you’ll have to upgrade to 5.5 and once you’re at 5.5, then you can use the migration tool to get to 6.0 update two.
James Green: So upgrade and then run the tool. What about the other way? If I’m 6.0 already, I don’t really want to try and downgrade. What’s the process there?
Emad Younis: For right now, I would say hang tight and stay tuned. There’ll be more coming in this arena.
James Green: Got it. What if I’m just looking to migrating but for compatibility reasons or something, I want to say on the same version? Is that something that would be possible or is it always both an upgrade and a migration?
Emad Younis: Yeah, they’re both tied together. To use the migration tool, it’s all together.
James Green: You’re doing both. Okay, cool. One thing I wrote down that I heard you touch on earlier that I wanted to make sure to clarify is back to the identity thing. Even SSL certificates and that kind of stuff, performance data, it’s all moved over. Once you get everything swung over and the migration is complete. The experience really should be basically the same, right? An administrator’s going to go and log in, they’re going to see the same certificate at the same IP address. They’re also going to be able to see historical alarm data, performance data, all that kind of stuff right?
Emad Younis: Yeah. Like I said, all that will come over. The only thing that’s optional and it’s up to you is the performance and historical data. Once you do the, there’s a checkbox in the UI for that. That will actually, depending on the size of your database, may increase the time of your migration. You are correct. As far as an administrator is concerned, it is the same old vCenter. They’ll actually hit the same web client, all their favorites will still be there.
James Green: That’s great. Obviously because we’re doing a cut-over from one to the other, we should assume that there’s going to be a little bit of downtime. I was curious what that might look like, and I was pleased to find that there’s a Knowledge Base article out there already that helps you estimate how long that’s going to be. If you’re trying to plan this, make sure you go and check out the Knowledge Base. Find that article. From what I could see, a pretty small deployment could take as little as 30 minutes to get cut over. If you’ve got a very large environment you’re managing, it could be hours to tens of hours even if it’s huge. I would imagine just based on the size of most that I’ve seen, we’re talking a couple hours or less for migrating most deployments. Does that line up with what you’ve seen so far?
Emad Younis: Like I said, if you’re just doing the default, bringing over the config and inventory you’re looking somewhere between 30 minutes to maybe an hour. If you start bringing over your historical and performance data, again depending on database size, it’d take a little bit longer. You might want to do things by pruning your database, especially as you mentioned if you’ve been upgrading ever since like 3.x or 4.x. That database is just growing continuously, so might want to do some pruning, maybe run some roll-up jobs, things to compress that database and bring it over. If you think about it, when we used to do this manually, we didn’t care about bringing over performance or historical data. It was almost a clean slate.
  Now we’re giving you that opportunity. It’s just a matter of what’s your reasoning for bringing it over. Is it auditing purposes, or do you want to just bring over a clean slate like we always used to? Now you have a tool that will do the heavy lifting for you.
James Green: Sure. I have a couple questions about some of the more advanced portions of vCenter server. A lot of bigger shops out there prefer to use the distributed switch capability of vCenter and that’s something that the information for is stored in the database. You upgrade it separately from vCenter and it almost seems like a separate entity. If I’m using distributed switch, is that going to come over with the migration?
Emad Younis: Yeah.
James Green: I don’t have to reconfigure it, or walk over to a standard switch and then migrate and then walk back to a distributed switch?
Emad Younis: No, you don’t have to do any of that. Like I said, the config and inventory come over by default. Your distributed switch is part of that. It will migrate and you will see it come over
James Green: Okay. I guess what’s the process for Update Manager? I know a lot of people install Update Manager on their vCenter server. If I understand the migration process correctly, that vCenter server’s going to be shut down to keep an IP address conflict from happening. Do they need to move that off beforehand? What’s the process with Update Manager?
Emad Younis: Update Manager or anything, let’s say you have SRM or any other product that you have installed locally on your Windows vCenter server. You should externalize if you’re using it before doing the migration because as you alluded, during the migration process after we’ve pulled the data we’ll shut down that source vCenter server. It will no longer be accessible. As part of the process, we do join the appliance to the domain. What you may want to do, let’s say you forget something on that box. You can always un-check the NIC so there’s no IP conflict, power back on, but you’re going to have to log in locally. A good thing is we don’t make any changes to that source Windows vCenter which helps for a rollback plan.
James Green: Sure. Speaking of rollback plans, another thing I found while I was looking around at the announcement is there’s also a Knowledge Base article available already for the rollback process if things get stuck sideways somewhere there in the migration. If you attempt it and things start looking a little hairy, definitely go look in the Knowledge Base and there’s some really good guidance there for how to roll back or how to discover the issue that you’re having there. One of the things I mentioned before that I really like moving over to the embedded database that’s in the vCenter appliance. A lot of people, though, are using SQL or Oracle databases and they like it. If they’re going to perform this migration, does the database stay where it is or is the database always going to be copied over to the appliance.
Emad Younis: For the appliance, it’s always an embedded vPostgres. Whether they’re using SQL, Oracle, even SQL Express, we’ll migrate it over. Any database that’s supported today with vSphere 5.5 is what will migrate over.
James Green: That’s kind of VMware’s direction moving forward it seems like, except for Legacy support purposes VMware would prefer customers to be using that embedded database because it’s optimized for exactly the job that it’s doing.
Emad Younis: Exactly. If you think about it, the appliance now, the database, the application all in one. If you had any issues, contact VMware and it’s just one team to help to support you.
James Green: Yeah, that’s really the big thing. A single point of support where you get the VCSA team on the line and they can handle the whole thing whereas I’ve been on support calls, or support cases I guess, that went on for many calls because we’re getting passed around to different teams because this guy doesn’t know how to work on the vCenter database. Yeah, in this case when you get everything on the appliance, then you get the appliance support guys on the phone. They can work the case from start to finish and you’re in good hands. I have one more question before we’re done. We hear a lot about, especially organizations that are operating at scale trying to automate things like this. I saw that you can provide some configuration via JSON to make this migration totally automated. Am I understanding that correctly?
Emad Younis: Yeah. Just like in 6.0 where we introduced the JSON templates, now you can also use the JSON templates for migration that are built in. What’s neat about the migration is we allow migrations of virtual machines but we also will migrate a physical machine to a virtual appliance. Now the only part of the automation process there is we can’t automate a migration assistant on the physical box, but everything else is fair game.
James Green: Sure. Well, I can definitely see in my past life in professional services how that would’ve made my life a lot easier. I could just have that pre-configured and I would go into a customer’s site and look at what they’re doing, change a couple of lines, and then kick off the migration. Go get lunch. Just kidding. That would make my life a lot easier, so that’s really cool. Anything else you want to highlight about it? No, wait. I have an important question before we’re done. I’ve tested something like this, I don’t know, nine months ago? It was a VMware Fling. That’s something that’s on a separate part of VMware’s website, and Flings are developed by developers just as a little side project. They’re not officially supported and they’re just beta products basically. I want to make the distinction between whether or not this migration tool is a Fling or an official release from VMware.
Emad Younis: This is an official supported migration tool from VMware. The learnings came from the Fling, but this is officially supported.
James Green: Awesome, and that’s a huge difference for anybody that’s going to attempt this. You will be supported by VMware and this tool has been tested and validated, and they put a lot of effort into it. It’s very exciting. Okay, now answer my other question. Where should people go to find more about the tool?
Emad Younis: For more information, I would go to the vSphere blog. I’ll also be doing some other writing on my own blog at emadyounis.com.
James Green: Awesome. Thanks again, Emad, so much for being on the show. I appreciate it. If anybody who’s listening wants to get in touch with Emad, again, Twitter is a good place. @emad_younis. He’ll be happy to connect with you there. Thanks, Emad.
Emad Younis: Thanks for having me.
James Green

James is a Partner at ActualTech Media and writes, speaks, and consults on Enterprise IT. He has worked in the IT industry as an administrator, architect, and consultant, and has also published numerous articles, whitepapers, and books. James is a 2014 - 2016 vExpert and VCAP-DCD/DCA. Follow James on Twitter

No Comments

Post A Comment

Web Analytics