Transcript
Hello, hello, welcome, welcome once again. As usual, my name is Alex and I would like to welcome you to our webinar. And this time we are going to talk about the zero downtime live virtual machine storage migration in Open Nebula. A very, very important feature, very high demand, highly requested feature. And here we are delivering that. And let me know if I'm audible, then just drop something in the chat like hi or maybe a number five, an exclamation mark. I mean, whatever suits you, but just to indicate that you can hear me well. And of course, as usual, we are going to talk a little bit about the topic. Then we will switch to live demonstration that will be led by one of my colleagues. But after that, we will go back to an open discussion about the topic, your questions and answers and our answers. So if you have any questions on the topic, then feel free to drop them in the chat so we can take them and address in order. And of course, we will start, we'll open that Q&A session with the questions that were sent to us beforehand. So for next webinars, if you have some questions, then feel free to drop them to us when you're registering, when you're signing up for that webinar. And it kind of helps. And also, it's good to have a few questions in a pocket before we actually go into a live Q&A session. All right, so let us talk about the topic. So, first of all, our agenda that was already briefly mentioned. But what is that live storage migration? Why you may need it? Well, first of all, as I mentioned, it was a highly requested feature. So it's in demand, and we must deliver that. And in 7.2, a very recently released version, we've introduced that Seridon time live storage migration. So right now, virtual machine disks can be moved across the data stores without any downtime. So previously, if you would need to migrate from one system data store to another system data store, then you would need to power down virtual machine. Which pretty much means that there is some sort of downtime. Maybe small downtime, maybe a little bit longer, but downtime is downtime anyways. So that was in past, in previous lives, let's say like that. So right now, we've introduced this feature. So right now, you can migrate your disks, your virtual machines from one system data store to another system data store with pretty much no downtime. So what currently supported the running virtual machine disk or disks, if you have more than one, then not every driver is currently supported. So it's the local data store. When you run virtual machines from directly attached local storage of the hypervisors, then shared data store is supported and LVM data store in the file mode. And for now, it's supported only with KVM hypervisors. As you may know, OpenAble supports other hypervisors as well, for example, LXC. So it's also supported, but this feature right now is limited down to KVM hypervisor only. And which is to a certain degree, a no brainer because KVM is the main virtualization technology that we support. And majority of you are using KVM. And KVM, as of my thinking, would benefit from this functionality much, much more. That's why it was obviously prioritized. Now, and then, well, why you may need that, you may wish to perform a maintenance or storage rebalancing. So if you have multiple virtual machines that are stressing out some specific storage, you may wish to kind of make it more balanced. And yeah, sometimes you need to conduct the maintenance on your shared storage A, so that you migrate your virtual machines without any downtime to that amazing storage B. Perform maintenance and then migrate them back or balance them in any other way. And then, well, go and do the maintenance on storage B. So storage maintenance is quite an important topic because whatever system is, well, it requires maintenance in either of the ways. And from time to time, you still need to do something. And yeah, of course, the cases when something went wrong and you actually need to troubleshoot and fix. And then you may need to really migrate those virtual machines away so you can perform full maintenance and maybe some stress tests. And, well, maybe power down it completely and disassemble. So things happen, right? Life is life. Anyways, then sometimes you need to upgrade the infrastructure. And, well, while a lot of times we can upgrade with, again, zero downtime because technology is already at a certain level that provides a lot of good balancing and hot swap and so on and so forth. Sometimes you really need to power it down. And, well, maybe sometimes you just need to swap the complete storage. Once again, you would like to have your virtual machines migrated, but they may run some critical workload on that. So, well, upgrading infrastructure is the case for that live migration. So you safely migrate your virtual machines and then don't think about any downtimes and match the SLAs that you've promised. And, of course, tiered storage as one of the cases and especially in a bigger environment or multi-tenant environment. So tiered storage may be something that can benefit from having that virtual machine live migration. So a lot of nice cases that we've just named. But, again, it's not limited to that. You may have your use case when you really need that live migration. And I would like to invite the colleague of mine, Neil Hansen, to the stage. And Neil is going to show you the demonstration, the live demonstration of that functionality. And after that, we will switch to questions. So I would like to remind you, if you have any questions on the topic, then please drop them in the chat. And we will address these straight after the live demonstration. So, Neil, the stage is yours. Welcome. Awesome. Thank you. Okay. So, yeah, I'll go over this brief demo. It's not going to be super long. I mean, in the end, it's pretty simple things happening. It just has to be orchestrated correctly and make sure things aren't going to fall apart as we change this. So, first, I'll have this list going up of the virtual machine disk. We can see right now it's on the Datastore 100. We can check in the history and see that it's in the system B, which is the... I'll check that really quick to show you the ID correctly. So, ID 100, and then we're going to move it to system A, and ID 0 in a live form. So, hold this, and we'll do the migrate live here. And running on the host one, so I'll make sure we select that same host. You can't change host and disk at the same time. Do them one at a time. It's much safer that way. And then since we're on system B, we're going to move over to system A here. And it's pretty quick and simple. It triggers up, and then here in a couple seconds, we should see this list update into having the... Oh, there's the message file at the new end. Now we're on Datastore 0, disk 3. Same virtual machine. And then we can go in here, and we can even move it back really quick just to show the back and forth. How quick and clean that is. We should have... there's the... in the process of it moving, and then there's it fully moved over. And then we can also do... let's see, this is ID 3. We can SSH into that and check the uptime, and sure enough, it's been up for over an hour. We didn't have any system interruption during the disk migration. The disk removed properly back and forth between the different system datastores. And then we can see that reflected here in the history tab as well. The different system datastores here. I mean, that's basically what it is, and also kind of, I guess, how it works in a way. We're simply moving the disk references over to the new system datastore, and then libvirt handles the cutover from one disk to another on the system. Cool. So, Neil, I think we can proceed to the question and answer section. I think so. Yeah, if anybody has any questions, we can... So, let's start with the ones that were sent to us beforehand. Can I migrate a virtual machine with multiple disks? Oh, yeah, of course. I mean, I guess I should have shown that in the demo. But, yeah, absolutely. Since VMs are assigned to specific system datastores, we move all disks at once, so you're not split among multiple system datastores. That's good. Okay, then, second question that was sent to us beforehand. What happens during a migration failure? Should that happen? I mean, yeah, if something takes too long, or you have some network interruption, sure. Well, so first, I guess, during the demo, you kind of saw that both disks existed at the same time. That's on purpose, because we want to make sure the cutoff happens before we remove the old disk. So, the process is we create the new reference to the disk, we have libvert cut over the transactions to that new disk in a live form, and then we remove the old disk reference after that's been achieved. So, if there's anything that happens during the failure, it rolls back to the original datastore. Well, it's good to know that we have a backup plan in case something goes wrong, right? Yeah, migration is touchy sometimes, depending on the underlying OS, and there's a lot of moving parts to it, so you got to be safe when doing that. And also, well, don't forget that, in general, things happen, and everything that's data-related is quite sensitive, in any case. So, you would like to ensure that there is some sort of a hiccup. And I think our question from the audience, does the process ensures continuity if something happens, pretty much goes hand-to-hand to the question that we had just right now. Right, yeah, it will restore it back to its previous state, yeah. Yeah, essentially, the final thing that happens is the cutover, so everything else before that is preparation. So, if something happens during that point, then nothing happens in the migration in the end. Right, so, yeah, we're going to consider that this question was also answered. Cool. Right, so, you're always welcome. And, of course, that goes without saying, but our documentation can give you maybe a more detailed information about that topic, or maybe some examples, and so on and so forth. So, if you have any struggles or any issues with that, or in general, like if you have any OpenAbular-related questions, then, first of all, documentation is your friend. A lot of examples, a lot of samples, a lot of use cases are covered there. Don't forget that we also host a lot of webinars, and they are sometimes on a specific topic. Sometimes they cover integration. Also, you may find some partner sessions and use case sessions where we're bringing our partners or customers to the stage. So, a lot of cool stuff happening, so feel free to join any webinar in the future. And I would like to mention that this particular session is being recorded, so we will publish it on our official YouTube channel. That, in fact, is not only storing our webinar recordings, but there are also other tips and tricks. There are also some specific how-tos, and so on and so forth. So, you can find that by visiting our YouTube channel. And, again, that video on that YouTube channel may actually answer the question that you have. And if you still have some questions, then, of course, visiting our community forum is a good place to start. So, you could, again, search for a question that you have, and maybe that was already answered by someone in the community. So, maybe there is a fix for that, or maybe there's a workaround, or maybe there's, in general, an explanation on how something works. Or, if there isn't, then feel free to open a topic, start a topic there, start a discussion, and, well, either community or even our own engineers are answering that. So, you may get an answer directly from our engineers by just posting on the forum page. So, feel free to visit that one, and, yeah, should you have any questions. But, right now, let us talk more. So, please feel free to drop your questions in the chat. Right, and we do have another one. So, what do you mean by shared storage? Maybe that requires a little bit more explanation what we mean by shared in this case. In this case, precisely, we're using the shared storage driver, the TMAD shared storage driver. So, it uses, like, QCOW2-based images, and we have the shared transfer manager, is what it's called, transfer manager driver. The shared uses QCOW2 files in the back end, and we have an NFS mount that connects them all. This still works with local SSH transfer. It just might take a few extra seconds to transfer the disk via SSH, but, yeah, this is what, in shared, essentially, also another term we use for shared data stores, which are data stores connected to all hosts. Hopefully, that answers both sides of the shared question. Yeah, I think that was enough, and, of course, you can always check the documentation. So, in case you need more detailed description on what the driver is and, like, what type of storage it actually covers, then please feel free to, again, check out the documentation. We have, like, a very nice table there with not only, like, the technology behind that, but also features that are supported with the storage driver, and, again, if you're making a decision whether you should go with, I know, LVM file or shared or, I know, Ceph, then that table can actually make your decision a tiny bit easier. Good. So, the next question about cross-VM migration. You brushed upon cross-VM migration. How would that work? I guess I'm not totally certain what you mean exactly, cross-VM migration. Yeah. Because, I mean, we're just migrating from one data store to another. You can migrate on hosts as well, but it'll be a separate – oh, yeah, yeah. Yeah, you can still migrate to hosts. I mean, that's been a feature for a while, for sure. You just can't do a host and disk at the same time. So, you can totally go in and transfer or migrate a VM back and forth live to the hosts, especially with shared data stores. We actually support that with SSH local data store too for live migration between hosts. So, now you have both host and data store live migration. Yeah, so I hope that answers the question. Yeah, so that's, as Neil said already, that virtual machine migration was implemented a while ago already. So, it's both the live migration and then just migration with downtime. So, yeah, that was a feature for a while, and now you can also migrate the disks between the storage. We have another question. How fast is the transfer? It depends on your data store configuration and your hardware. For a shared data store, it's nearly instant because we're mostly doing references to images. You have to copy the diff file between the two if it has a backing. If you're doing standalone, then it's the whole disk has to be transferred. So, it really depends. This is a very small disk. I think it's like 256 RAM. So, it's probably like a five gig disk or less. It's pretty instant. A one terabyte disk, I mean, if you've got a 25 gigabit link, then it shouldn't take too long. So, as usual, we would like to say that there is a lot of factors that you should count into that, right? Yeah. Yeah, hardware makes a huge difference on that stuff, for sure. Right. Okay. So, once again, I would like to say, please, if you have any questions, drop them in the chat. Okay. So, we have another one. Let me – is there any size limit? I assume no. I mean, yeah, it's your hardware. There's no limitation there. So, once again, the hardware or your environment is the only limit. Yeah. I mean, you can transfer. I think we support – I can't remember how many disks total. We support over 256 disks, I think, is what Libert – whatever Libert supports, because we can support all that. And each of the disks can be a terabyte if you have the storage space for it. That transfer would probably take away. Yeah, true. True that. Good. So, yeah. If you have any questions, then feel free to drop them in the chat. And, well, once again, explore our documentation if you still have these questions. And, of course, don't miss out on our upcoming webinars. And don't forget about our community forum and our community pages. So, yeah. Please, please, please. Your questions on the topic are very, very welcome. Okay. How would this feature behave against a virtual machine that has a secondary disk attached in a separate data store? So, one VM with two disks across two data stores. Well, we generally don't have that configuration because the virtual machine is assigned to a system data store rather than the disk itself. So, all the virtual machines should reside in the system data store. This is how our placement rules work with scheduling virtual machines and resources and stuff. I mean, if we have that configuration possible in the future, then it's going to be from one data store to another. Rather than having all the disks go to one data store. If we allow mixed data stores, then you're going to be able to choose which data store to which data store. Because we also have to have compatibility. So, we can say that pretty much this situation is not possible. Yeah, we generally don't have VMs with two different storage backends with the system data store. It's all in the same spot. Good. So, yeah. I would consider that this question is answered as well. Right. So, once again, feel free to drop your questions in the chat so we can answer them. Right. So, I think we don't have any questions. So, we can terminate the session. Once again, thanks for attending. Thanks for being with us. The session is recorded. So, if you need to recap it, rewatch it, then please visit our official YouTube channel and find this recording and many, many more. Thanks, Neil, for demonstrating the feature and also answering the question. And then, see you all next time. See you next time. Bye-bye.
