Title: Netchannel: A VMM-level Mechanism for Continuous, Transparent Device Access During VM Migration
1Netchannel A VMM-level Mechanism for Continuous,
Transparent Device Access During VM Migration
- Sanjay Kumar
- PhD Candidate, Georgia Tech
- In Collaboration with
- Prof. Karsten Schwan
2I/O Location Transparency
- Accessing I/O devices irrespective of location
- Transparency required for legacy systems
- An important objective of I/O virtualization
- VM migration, remote device access
- Current I/O virtualization lacks this feature
- I/O virtualization layer expects local device
- Usually relies on other technologies
- Hardware, e.g. FC SAN (costly)
- Software, e.g. iSCSI, NFS (non-transparent,
inefficient) - Need transparent and efficient VMM level mechanism
3Location Transparency Benefits
- Virtual device migration
- Device hot-swapping
- Remote device access
4Virtual Device Migration (VDM)
- Continued access to I/O devices after live VM
migration - Migrating virtual device state along with VMs
- Issues
- Handling pending I/O transactions
- Minimizing device state transfer time
5Device Hot-Swapping (DHS)
- Dynamically changing VMs virtual device to
physical device mapping - For performance, reliability
- Issues
- Consistent state transfer b/w the two devices
with minimal service disruption - Migrating potentially huge amount of data
6Transparent Device Remoting (TDR)
- Transparently providing VMs with access to remote
devices - Utilizing the existing I/O virtualization
infrastructure - Issues
- High-level semantics become complex
- Data-sharing, caching
7Utility of Transparent Device Remoting
Handheld
Backup DVD-drive
Server
Network
Compute Blade
Compute Blade
I/O Blade
8Netchannel Software Architecture
Local Machine
Remote Machine
Service VM
Service VM
Guest VM
Network
Device Virtuali- zation
Mid- Point
Dev Client
Device Server
device driver
Hypervisor
Hypervisor
device
vdevice
device
9Virtual Device Migration
Machine M1
Remote Machine
Service VM
Guest VM
Operating System
Device Virtualization
Network
Mid- Point
device driver
Hypervisor
Device Server
VM Migration
Netchannel
Machine M2
Service VM
Device
Device Virtualization
Mid- Point
Hypervisor
10Netchannel vs. Resubmit Latency
Pending Reqs. Incomplete Reqs. Netchannel Latency Resubmit Latency
5 0 1.94 ms 23.43 ms
12 0 2.74 ms 40.29 ms
16 1 12.93 ms 45.01 ms
23 5 23.41 ms 81.23 ms
26 2 16.69 ms 85.46 ms
32 7 29.24 ms 96.90 ms
Time taken in handling pending disk requests
during live VM migration
11Device Hot-Swapping
Device1
Network
Machine M1
Service VM
Guest VM
Device Replication
Device Virtualization
Mid- Point
device driver
Hypervisor
Device2
12Transparent Device Remoting
Local Machine
Remote Machine
Service VM
Service VM
Guest VM
Network
Device Virtualization
Mid- Point client
Mid- Point server
Device Virtualization
device driver
Hypervisor
Hypervisor
device
vdevice
13Implementation
- Netchannel implemented in Xen
- Works for block and USB devices
- Provides access to remote disks (RVBD)
- Access granularity at USB port level (RUSB)
- Tested for bulk and isochronous devices
14Transparent Device Remoting
- Testbed description
- Two Dell Poweredge 2650s connected through a
gigabit switch - Each machine has 2.28 GHz, 2-way HT Xeon CPUs and
2 GB RAM - Iozone file I/O benchmarks used
Write throughput of block devices
15Netchannel Latency
Latency incurred by one block device request
16Virtual Device Migration and Device Hot-Swapping
Migrated MySQL Server
B
VM
Client1
I
Apache Httpd
Client2
VM
A
II
Jakarta Tomcat Servlet Server
Original MySQL Server
MySQL server migration in RuBIS online auction
benchmark
17RuBIS DB VM migration and Hot-swapping
Effect on RUBiS Throughput due to MySQL Server
Migration
18Ongoing and Future Work
- Disk hot-swapping for reliability
- Managing VM migration
- Virtualizing mobile devices
19Netchannel Summary
- Handling I/O devices during
- Live VM migration
- Device hot-swapping
- Remote device access
- Provides a transparent and cost-effective solution
20Questions/Comments
- ksanjay_at_cc.gatech.edu
- http//www.cc.gatech.edu/ksanjay