Hypervisor-Independent Live Storage Migration - xNBD

xNBD (code name, Ohikkoshi) is an advanced NBD server program enabling live virtual disk migration (a.k.a, block migration) over (wide-area) networks. It works with any VMMs (e.g., Xen, Qemu/KVM) supporting live VM migration.

xNBD works as a proxy server of the NBD protocol, and allows postcopy (lazy) migration for virtual disk blocks.After the execution host of a VM is switched to a destination host, the xNBD proxy server intercepts disk I/O requests and intelligently copies disk blocks from a source host.

Recently, we are working on extending xNBD to support wide-area live migration more efficiently. See the project page for the latest update.

Download

The latest development is ongoing at http://bitbucket.org/hirofuchi/xnbd .

Publications

  • A Live Storage Migration Mechanism over WAN and its Performance Evaluation,
    Takahiro Hirofuchi, Hidemoto Nakada, Hirotaka Ogawa, Satoshi Itoh and Satoshi Sekiguchi,
    Proceedings of the 3rd International Workshop on Virtualization Technologies in Distributed Computing (VTDC2009), pp. 67--74, ACM Publishing, Jun 2009,
    paper

Demonstration

We made a demo movie for the SC08 conference. Here is a booth flyer in SC08.
In this movie, we relocated both a VM and its virtual disk to another datacenter via a 100Mbps WAN.
A real-time monitor program shows disk I/O activities and its throughput at source and destination sites.

https://sites.google.com/site/grivonhome/live-storage-migration/xnbd-overview.png?attredirects=0     


There are 4 physical machine. At the source site,
  • vm-container-0-1 (Xen Host OS at Source Site)
  • gfm82 (not shown in movies) (xNBD server at Destination site)
At the destination site,
  • vm-container-0-2 (Xen Host OS at Destination Site)
  • gfm83 (xNBD proxy at Destination Site)
Watch movie 1 and movie 2 (open new windows).
  • (movie 1) First, we launched a VM at the source site. In the guest OS, kernel compile was started.
  • (movie 1) Next, we initiated live migration of the VM to the destination site. After all VM states were copied to the destination, the VM stopped at the source site, and started at the destination. Disk blocks were being gradually cached at the destination.
  • (movie 2) To complete storage migration, we started copying the reset of disk blocks from the source site to the destination. After this finished, VM and disk migration was completed; the VM did not depend on the source site anymore.

Contact

Feel free to contact me!
Takahiro Hirofuchi <t.hirofuchi _at_ aist.go.jp>
Ċ
xnbd-sc08flyer.pdf
(1158k)
Takahiro Hirofuchi,
Sep 3, 2009, 11:22 PM
v.1