Posted by: MikeLaverick
when relevant content is
added and updated.
This session was about the future. Mendel identified an number of issues, the first being VMotion incompatiablity issues. He pointed out that the CPU vendors have introduced “Extended Migration” (AMD) and “FlexMigration” (Intel) to try and generate compatability where none previous existed. Mendel then went on discuss and demo 3 new features of Vi3.
Mendel announced “VMotion Storage”. Something that has been available to ESX 2.x.x to 3.0.1 is moving the VM files from one LUN to another. This feature is going to be extended for 3 to 3 “VMotion Storage” or what is sometimes called “DMotion”. This feature will be useful for people who lease storage, running out of space in a VMFS, or to much I/O one given LUN. Additionally, it could be used “migrate” from one storage type to another – say from NFS to iSCSI or iSCSI to SAN. Oddly, the feature is triggered using a CLI tool, despite the fact that you will need VirtualCenter (with VMotion) setup before hand. The features works with what VMware dubs “self-VMotion”. This is where the VM stays on the SAME ESX host, but its files are relocated to a different VMFS volume. Currently, this storage VMotion must does not work with VMotion – in other words you can’t simulantously move the VM’s files and ESX host location at the same time. They plan to allow this – hopefully before it is released.
As for RDM’s – they will not be supporting cloning the data in the RDM from one LUN to another – so this is NOT a replication technology, and its not about “high availability” or diaster recovery either. For the new feature to work you will have to do an upgrade of your ESX host software to expect to see this in ESX 3.5. As ever no-one is forthcoming on when this feature will be available. Unless you have signed an NDA of course!
As for negatives. You will need temporary memory and CPU cycles for this work -as affectively a duplicate VM is generated during the “move” provcess. So it will be something planned for off-peak times. On top of this – as it uses the VMware “Snapshot” feature you will need space for the deltas during the process itself. Hopefully, VMware will have fixed the multiple VMDKs on multilple VMFS problem with snapshots by the time of its release!
As for future improvements – there is possiblility that this copy process could be triggered by your SAN rather than being triggered by the VMkernel. They also hope to support the “Storage VMotion” of local virtual disks from one local VMFS to another servers local VMFS. They also indicated that there could be intergration with DRS. So on power on DRS decides the best datastore for your VM, and even move the VM to a VMFS where there is less disk contention. I’m not sure if the second idea is good one, but initial placement does help remove one of the decisions created when creating a VM on a DRS cluster.
Mendel when to discuss the impact of “Virtual Appliances”. He identified one of the hassles was the long download time for Virtual Appliances. This makes the VM affectively a “streamed virtual appliance. The VM is streamed down from VMware’s Virtual Appliance “Market Place”. Rather than being downloaded then loaded up – software downloads the files on demand to get the VM booted. They call this the “instant on” or “on demand” stream manager. The stream manager uses a prefetch routine – priortise blocks in the VM that are need first. The prefetch recorder knows what download first to start the boot process. They see this as being a tool for ISVs to deliver software very quickly. It also introduces the possiblity of streamed VDI (Virtual Desktops). This changes the software deliver paradigm from software on my PC or software as service – VM runs on the server. To a Hybrid model software on the server streamed to the end-user. So see this as like Softgrid/Softricity for Virtual Machines.
Last he end with a “High Availability” section. Detailing the “record the execution” feature now available experimentally in Workstation 6 where real-time activity is recorded and logged to disk, and replayed at will for application debugging purposes. This new feature has been dubbed “Continious Available” for ESX. In this case you have a primary and second VM on two different ESX hosts. The primary VM on the primary ESX host is continuelly sending the record data to the other VM – not to a log file. The two VMs held in synch. In the demo, when Mendal clicked the start menu you saw this happen on two VMs on two different ESX hosts at the SAME time! See it like two VMs mirrored. Next the pulled power cords out the back of the primary ESX host – and the other VM just kept on running. It was an Exchange server with 100+ of emulated user activity… So this is great – what everyone has been asking HA to do, which currently does do. Sounds great huh? But just remember if the primary VM has a BSOD – so will its mirror…