Video Screencast Help

VxT - Virtual Transport I/O model for x86 virtualization

Created: 31 Mar 2010 • Updated: 31 Mar 2010
srao's picture
+1 1 Vote
Login to vote

VxT - The Virtual Transport Project

Symantec has interest in porting many of its successful products to x86 hypervisor environments. However, such work is hampered by a lack of access to the proper resources and interfaces. Access to physical resources in a hypervisor environment is much the same as in an OS. The physical bus is the same and similar driver and service environments are avaialble. The problem arises in how physical I/O resources are provided to the guest virtual machine. Existing virtual device models do not abstract physical resources in a uniform way.  This leads to one-off drivers for basic support and not much else.  In order to open up the field of device driver emulation development, a set of abstractions akin to the device driver model are needed.  This is the purpose of VxT.

Ports of Symantec traditional products would benefit significantly from a published hypervisor I/O model that performed well. However, there is more to be gained. There is a strong link between platform virtualization and distributed services. A truly integrated service will allow for guest migration between physical boxes but also service migration between virtual and physcial settings.  In the final analysis, fully integrated platform management cannot mature without direct tie in to a well defined device model. A device model that works on physical as well as virtual devices. A device model that reflects the basic elements of distribution and physical platform support without distortion and unnecessary overhead. It is with this backdrop that VxT was conceived.

VxT abstracts the transport model, allowing for different kinds of physical transport between the hypervisor and the guest to be substituted without requiring changes to the driver emulation or the device driver in the guest.  Further, VxT provides a full modern bus abstraction, including bus attention signal, device plug discovery events and card discovery protocols.  In this way the full flexibility of modern bus device support can be brought to the virtualization arena.  Further, the abstraction of the hither-to physcial act of plugging a card allows for an entire new approach to system and data center wide resource provisioning.

KVM is the preferred hypervisor at least in part because it is based on Linux.  With Linux resources and VxT bus as the intermediary, it is possible to connect a device emulation in a Linux kernel directly with a device driver in a guest.  This has significant practical benefits when ramping up support within a community already well versed in Linux internals.

The present VxT source is a snapshot.  The Xen tree is tested and runs all of its elements. The experimental tree boots and runs on KVM.  The VxT RSH example program runs and nominal VxT authorization support is present.  However, patience is required as the tree is under development and many of the functions are not yet fully coded or tested.

Please post your comments and feedback below in the comments. Thanks!