Netbus A Transparent Mechanism for Remote Device Access

Netbus: A Transparent Mechanism for Remote Device Access in Virtualized Systems Sanjay Kumar Ph. D Student Advisor: Prof. Karsten Schwan

Remote Device Access Transparent access to remote devices is becoming essential in various computing environments – datacenters, clusters and even in personal computing – Remote disks, backup drives, movie on a thin client etc. Essential in virtualized environment for VM migration – Easy for networked devices i. SCSI, NAS, SAN But what about non-networked devices? – NDB, DRBD etc. for block devices No support during VM migration Netbus: Provides transparent and generic access to remote devices – Virtual device migration and device hot-swapping

IPod on networked docking station Backup DVD-drive Blade-Server Networ k Blade-Server

Netbus Software Architecture Targets high-bandwidth, low-latency and reliable networks with single administrative domain – Datacenters, blade-servers, clusters, home and office LAN Similar to channels in pub/sub systems – Server exports the device (channel), Client connects (subscribe) to it Logical extension of frontend-backend approach to device virtualization – – Frontend can communicate with a remote backend Application layer client establishes the connection with server The fast path is inside kernel – Abstraction of a network bus Generic mechanism with device specific callback functions – Common Netbus header followed by device specific data – Data passed to device specific callbacks for further processing

Netbus: Software Architecture (contd. ) Local Machine Guest VM Service VM Local Machine Guest VM Add Device to VM device driver Service VM Add remote Dev. to VM Client device driver BE FE L-BE FE Remote Machine Network Service VM Server User R-BE Netbus Hypervisor vdevice Hypervisor device Kernel

Netbus: Software Architecture (contd. ) Virtual Device Migration – Migrate virtual devices along with VMs – Provides continuous access to VM’s devices after VM migration through Netbus – How to deal with pending I/O operations? Bring the device into a quiescent state before migration – No pending I/O operations – I/O operations get queued into the FE and complete after VM migration

Virtual Device Migration and Device Hot-swapping VM Migration Local Machine Guest VM Service VM Add remote Dev. to VM Client device driver L-BE FE Remote Machine Network Service VM Guest VM Server User device driver R-BE Kernel FE Netbus Hypervisor vdevice Hypervisor device vdevice

Netbus: Software Architecture (contd. ) Device Hot-swapping – Replace the remote device with an ‘equivalent’ local device while in operation – Increases throughput, removes network dependence, hardware maintenance – Useful for rarely migrated VMs – How to deal with pending IO operations Same as with virtual device migration – Can be combined with virtual device migration To complete both operations in one shot Netbus’ prototype implemented in Xen and works for block and USB devices

Netbus Evaluation Testbed description – Two Dell Poweredge 2650 s connected through a gigabit switch – Each machine has 2 2. 8 GHz, 2 -wat HT Xeon CPUs and 2 GB RAM – Iozone file I/O benchmarks used Write throughput of block devices

Write throughput of block devices without buffer caching

Netbus Latency incurred by various components in accessing IO devices

Virtual Device Migration My. SQL server migration in Ru. BIS online auction benchmark

Ru. BIS Database server VM migration Effect on RUBi. S Throughput due to My. SQL Server Migration

Effect on Iozone throughput due to VM migration and disk hot-swapping

Questions? ?

Remote Device Sharing device 1 vdevice 2 Host 1 Host 2 device 2 vdevice 4 Host 3 device 3 Host 4 device 4