 Hi, I'm Founders and CEO of G-Converters. How is everyone liking the OpenStack Summit so far? I know it is a challenge to get a crowd excited after lunch. So let me try and make this exciting. We are the leading automated cloud migration technology companies. We have been developing the migrations and the backup scenes 2004. I would like to show OpenStack cloud migration introduction video before talking about today's topic. Cost savings, flexible resizing and scalability? If you wanted to transfer between 100 and 1000 servers to the cloud, how would you do it? How long would it take for all the required experts to reinstall the applications and databases? And how much would it cost? Would cloud migration be expensive and require extensive downtime for the expert reinstallation of applications and databases? There is no need to worry any longer about the complex cloud migration process. Z-Converter cloud migration sauce allows you to migrate from on-premises to cloud or from cloud to cloud simply and easily. You don't need to reinstall and reconfigure workloads. All it takes is a few clicks. Z-Converter's patented imaging migration technology makes the complicated reinstallation migration process simple and easy. With just a couple of clicks, you can complete your workload migration to the cloud. Z-Converter cloud migration migrates from on-premises to the cloud or from cloud to cloud in three steps, imaging, replicating and converting. These three steps of Z-Converter cloud migration minimizes human intervention when migrating on-premises to the cloud and eliminates the major problems of high-risk time-consuming and labor-intensive migration. Create a source image with a few clicks and replicate it on the target cloud. Then convert the replicated image to cloud instance. You can see that the source server in the migrated target instance is the same. That's it. You have successfully completed cloud migration. Z-Converter cloud migration helps enterprises or cloud service providers make cloud migration simple and easy. We are the open-stack corporate sponsors and the technology partners with Microsoft, the Amazon, the Google. And we help enterprises and cloud service providers make the cloud migration simple and easy. And our cloud migration softwares is open-stack compatible software. And now I'd like to talk about today's topic. Seven must-have features for hybrid and multi-cloud migrations or cloud-based recovery edge of service. We call this edge CRAS instead of DRAS. Let's look at this figure. This shows the hybrid or multi-cloud migration and the cloud-based DGS recovery edge of service picture. In order to do this, actually the virtual machines and bell metal servers, private cloud or public cloud should be moved to the open-stack cloud services with minimizing the production server services down times. And actually there is two services types. The first one is cloud migration type, which is run by our G-Cloud.net. That guys is support automated cloud migration stuff for the multiple cloud platforms. And below the cloud recovery managers, we are developing this cloud-based DGS recovery edge of services based on the cloud recovery managers. Actually both of the services, I'm going to talk about seven must-have features for cloud migrations than the cloud-based DGS recovery edge of services. And actually the seven must-have features and the multi-cloud migrations and CIRA services should be the attitude open-stack cloud migration should be able to support it with near zero downtime. Or vice versa, Amazon, Microsoft, Google, okay anyone can be migrated to the any multiple cloud platforms. Let's look at seven must-have features. Number one is live migration. Actually this live migration is, number one must-have cloud migrations or cloud-based DGS recovery edge of services feature. As you can see, in order to do this, if you have to stop your products and server, big enterprise company will not use the cloud migration software or will not use the cloud-based DGS recovery edge of services. Because of that, this live migration or it should be the mandatory options now. Process is very simple. And during your cloud migrations, you can't move on-premise test to the any cloud like open-stack cloud. During this, you don't need to stop your services like this video file, okay? And number two, and in order to use multi-cloud platform migrations or cloud-based DGS recovery edge of service test, if the similar hyphen visor migration should be supported and actually if you wanted to move the VMware virtual machine to the open-stack KVM, it should be the working, should be the move too. Yeah, actually we are the support of Bell Metal or virtual machine, any virtual machine to, any virtual machine migration combined with any cloud platforms. And number three, in order to omit the multi-cloud platform migrations or CRAS, the hybrid cloud migration should be supported. Actually, if we wanna move the Amazon cloud with Xen or KVM hyphen via, you can be moved to the open-stack flows with any hyphen visor like VMware, KVM or Xen or vice versa. Open-stack VMware or KVM can be migrated to the Microsoft cloud plus hyphen via or Amazon AWS plus KVM or Xen. This is the real hybrid cloud migration technology. For the multi-cloud migrations and actually the any private cloud combined with any hyphen visors, a need to be or should be moved to the any public cloud or any private cloud combined with hyphen visors. In other words, open-stack plus KVM can be migrated to the AWS plus KVM or Azure plus hyphen via can be back to open-stack plus KVM or open-stack plus VMware. That is the real multi-cloud migration technology. Actually, this technology is one of the most have multi-cloud platform CRAS and near future orchestration technologies. Cloud multi-cloud orchestration technology must have this technology. And number five, and actually the any disk format can be migrated to the any disk format. This figure show the source machine, so disk format is VMDK, but if you want to move to the open-stack plus KVM and you need to convert to QCAUTO or ROIDDISC, you should do this for the multi-cloud migration because the many public cloud services is running their open-source based hyphen visor. It means there the disk format should be the ROIDDISC or QCAUTO or VHDF, but many enterprise companies on-premise servers are running the VMware. It means there disk format is VMDK. If you cannot convert to your VMDK to QCAUTO, it means you cannot move your VMware on-premise server to open-stack plus KVM hyphen visor. In other words, you must use open-stack plus VMware. This is not the right way. Yeah, we solved these problems. If we want to move your VMware to the any hyphen visor with any cloud platforms, you can do in a few clicks. Or if you are running the Microsoft hyphen visor as a source machine on-premise test, you can move to the open-stack plus KVM or XAMP in a few clicks. That is one of the most-have features for multi-cloud platforms, migrations, and cloud-based digest-recovered services, or near-features, multi-cloud orchestration technologies. Number six, if your source machine on-premise server has 100 gigabyte disk size, you already adjust at 95 gigabyte. But you will expect after migrating to the target open-stack cloud or the public cloud like Amazon and Microsoft, you need to increase your disk size, like 100 gigabyte to 150 gigabyte. But if you cannot, if you must keep your original disk size, it will be one of the catastrophe, right? But you should be able to optimize your disk size when you do the multi-cloud migrations or cloud-based digest-recovered services. And seven, yeah, actually, this is one of the important features with live migration technologies. Yeah, when you move 100, 1000s on-premise server to the anti-cloud platforms, private or public cloud platforms, you don't want to stop your products in the server for a long time. Yeah, actually, our live migration technologies can use for sending full imaging files to the target. And after that, you might have the Delta data. In this case, you need to send or change the Delta data to the target in order to minimize the services on time. We are using two types of a near-zero downtime migration technology. The first one is for the file-level migrations, we are using the incremental file-level replication features. And if we want to move, if we are moving your database, actually, unfortunately, a database file consists of a very big one file. It means if you are using the file-level incremental replication technology, or when your database only one byte data changes, you need to send the whole database file. Because of that, we are providing the block-level replications. This technology, as you know well, only the change of a few bytes or bits will be replicated to the target. That is another type of near-zero downtime migration technology. This is the sevens that must have features in order to have the multi-cloud type of migrations or cloud-based disaster recovery edge services. And actually, this is a use case. We have a lot of use case migrations. We are providing the virtual migrations since 2007. And from the 2015, we are supporting the open-stack cloud migrations. I already told you, we are providing open-stack compatible software. And actually, we are already providing the seven must-have features for the open-stack cloud migrations and the other public cloud migrations. This customer is one of the global force of 500 customers. This customer has to move 500 workloads from the Bell Metal and the VMware to open-stack private cloud. They use the two types of hypervisor, KVM and VMware. Actually, to third, server is migrated to the KVM plus open-stack. It means the Bell Metal servers of VMware is migrated to the open-stack plus KVM hypervisor. It means our migration technology is convert the VMware to KVM, VMDK to QCAL2. And also, we supported disk resizing, optimization for this customer. And this year, this customer has a plan to move 200 workloads from the old open-stack to the latest open-stack. We are also support open-stack to the open-stack cloud migration. Yeah, actually, the operating systems and the applique workloads is like this. The on-premises operating system was Red Hat, Windows Server 2008, 2012. And workloads were Web, Was, and the databases. So I'm gonna show you a demo with our GCloud.NET website, a SaaS website. This demo is migrating from the AWS Windows Server to open-stack cloud instances, migration demo. Sorry. This is the AWS Source Machines. We installed the agent file on Source Machines. In order to register the Source Machine to our GCloud.NET cloud migration SaaS website. This is Source Machines registered just now. You can choose, create a new imaging file and you can choose the C or D drive. You wanna move to the open-stack. This demo, we use the existing instances created on open-stack. And this open-stack use the KVM hypervisor. You need to choose the hypervisor name. That is summary for the AWS open-stack migration. Now, we are going to start the migration process. First step is imaging step. Second step is replication from AWS to open-stack cloud. Third step is converting. It makes up and running on the open-stack. Actually, after completion of this cloud migrations, we are gonna check whether a migrated open-stack is working very well. This right side is open-stack cloud instances. We tried to log in. Yeah, same. Actually, we used the background, the write down AWS source. Because of that, target migrated open-stack cloud also has AWS source machine information now. Yeah, we don't, yes. Okay, I have one minute. Adding questions? Okay. Your question is how can you handle the live migration and block lab replication? License. Yeah, okay. How can you make the open-running? How can you convert it to the target cloud instances? Right? Yeah. Drivers, actually, we are installing the target drivers during our converting process. And unfortunately, actually, the target is hypervisors. And actually, one hypervisor generally has one single device driver. Because of that, this is relatively easier to convert it to the hypervisor. Yeah, however, if your target is a bell metal, there is a relatively very complicated. Because we need to prepare the whole type of device driver for the bell metal recovery. Okay. Yeah, thank you so much. Okay, have a great day. Bye.