Follow on Twitter
Post to Twitter
As more and more ISVs, IT organizations, resellers, integrators and consultants of all flavors become more aware and familiar with the new virtual appliance packaging capabilities in the DMTF VMAN initiative and the OVF capabilities Citrix is adding to its products, it is useful to identify some of the advanced capabilities of the Project Kensho OVF Tool.
New in the Project Kensho OVF Tool v1.3 is a variety of options aimed at making virtual appliance packages more feature rich. As a packaged entity, the attributes of the virtual appliance are important.
Attributes like encryption, compressing files, digitally signing and validating or verifying the content prior to import add tremendous value.
For example, if an ISV wanted to offer his XenServer based virtual appliance as an OVF, and had concerns about tampering with the OVF xml, the ISV has the option to digitally sign the OVF file. On import, the user can verify the signature, if the verification fails, this indicates a change to the file from what the ISV produced. ISVs also need to attach end user license agreement (EULA) information. During import, EULA text is presented to the user to accept or reject. The ISV has the ability to incorporate whatever text necessary to fulfill the EULA display requirement.
Another example is if an IT administrator must move a VM from one physical location to another and requires an export of the VM to do so. The contents (virtual disks) of the VM are sensitive and the administrator must secure them. The administrator can choose to create an OVF and encrypt the contents. As part of the process, she would like the appliance in a single file format (OVA). Using the Project Kensho OVF Tool, she has the flexibility to do this.
On import, there are also a number of options for the end user. Many are verification and validation whereas others enable the user with mapping the OVF's VM resources requirements (NIC, storage) to the resources available from the XenServer host.
Summing this up, we've produced an Advanced Features video to describe some of these options.
As we can see from these features, the world of advanced virtual appliance creation and consumption is quickly becoming very feature rich and enabling for all parties involved.
One of the more unique features about the Project Kensho OVF Tool v1.3 is its ability to manage Hyper-V servers. The Project Kensho OVF Tool can import OVF/VMDK from VMware products directly into Hyper-V servers as well as move content between Hyper-V and XenServer.
To assist with the understanding how quick and easy this is, we've produced a simple video that explains this process:
Some items to note with Hyper-V and XenServer compatibility:
- When moving Linux workloads around, if the XenServer derived Linux workload is paravirtualized (PV enabled), the workload will not function on Hyper-V. Use an HVM type of VM if the intent of the workload is for cross hypervisor compatibility between XenServer and Hyper-V.
- When moving Windows workloads around, Windows XP/Server 2003 and higher can be migrated between platforms without driver issues, e.g., one clobbering the other.
Share your experience and use cases on the forum. Thanks for your interest in Project Kensho and the virtual appliance future of XenServer!
Summary
Project Kensho OVF technology provides the Citrix ecosystem with excellent tools to create and consume virtual appliances based on the OVF standard. Project Kensho OVF technology is currently available in two utilities:
This article aims to describe basic use cases of each tool and where it fits within the greater context of deploying and consuming virtual appliances using the Open Virtualization Format (OVF).
Background
Project Kensho is a Citrix Labs endeavor tasked with de-risking and improving our understanding at applying DMTF OVF and CIM technology to XenServer.
In the case of OVF, the standard is new and exciting. Its potential to reduce costs and improve virtual machine deployment for Citrix internal and external partners and customers is enormous. Today, it is one of the most exciting technologies in the world of virtualization.
Project Kensho OVF technology is present in both the Project Kensho OVF Tool and XenConvert 2.0.1. Each tool is unique in how it uses OVF and its position in the user community.
In the simplest terms, the Project Kensho OVF Tool is aimed at OVF based virtual appliance creation and consumption where as XenConvert 2.0.1 is a P2V/V2V conversion utility supporting OVF virtual appliances.
Each offers the user different paths to create, convert and import OVF based virtual appliance content into XenServer.
Project Kensho OVF Tool
First released in October 2008 as an ongoing series of Tech Previews, the Project Kensho OVF Tool targets the creation and consumption of OVF based virtual appliances. This utility is part of the Project Kensho Tech Preview suite consisting of the Project Kensho OVF Tool and the Project Kensho XenServer CIM Interface.
The Project Kensho OVF Tool is a full featured import/export utility offering users the latest OVF capabilities. The utility accommodates both the XenServer and Microsoft Hyper-V hypervisors and has the ability to directly import VMware OVF/VMDK content without conversion.
Unlike XenConvert, the Project Kensho OVF Tool is not targeted at static file format or physical to virtual conversion. The utility requires the user to have administrative privilege to the hypervisor. It interfaces directly with the hypervisor enumerating VM content for export and identifying hypervisor hosts for import. The Project Kensho OVF Tool's primary function is to manage movement of OVF packages into and out of the hypervisor.
Project Kensho OVF Tool – Appliance Creation (Export)
Virtual appliance producers have the ability to create virtual machine appliances by exporting one or more virtual machine guests as an OVF package from either the XenServer or Hyper-V host.
OVF supports one or more virtual machines within a single package. This enables virtual appliance producers with the ability to package entire datacenter suites into a single file. This is very useful when distributing suites like XenApp or other multi-server products. Currently, the Kensho OVF Tool is the only Citrix utility capable of exporting OVF content directly from a hypervisor.
When exporting the appliance, the user has the ability to embed an End User Licensing Agreement (EULA) into the OVF. The EULA is presented during import forcing the consumer to agree or decline the terms of use of the appliance.
For added security, the user can digitally sign the OVF file and encrypt the virtual disk content. These features add additional value to the virtual appliance's integrity. Users can also compress and add a file manifest to OVF package.
Project Kensho OVF Tool – Appliance Consumption (Import)
Consumers of the OVF package have the option to import the virtual appliance into a XenServer or Hyper-V hypervisor. Among other features, the Project Kensho OVF Tool enables this process with features such as hardware mapping and integrity validation of the OVF package.
Hardware mapping eases post virtual appliance import configuration steps. For example, a user could map the network interface card (NIC) described in the OVF to the virtual networks unique to the target XenServer. The same support exists for storage and system mapping.
One highly useful feature is the direct import of VMware OVF/VMDK content into a XenServer or Microsoft Hyper-V environment. This capability reduces time and costs as Project Kensho implements fix up capabilities making migration of the VMDK easier and less time consuming.
XenConvert 2.0.1
As the first mainstream XenServer utility to adopt OVF, XenConvert 2.0.1 applies Project Kensho OVF technology to the conversion process. As a Physical to Virtual (P2V) and Virtual to Virtual (V2V) converter, XenConvert 2.0.1 now gives virtual appliance users a number of options to either create OVF content for import into XenServer or convert OVF content produced by 3rd party products like VMware.
Unlike the Project Kensho OVF Tool, XenConvert 2.0.1 does not require administrative rights to a XenServer in order to convert physical or virtual machine assets into formats compatible with XenServer. The utility can perform its conversion functions without any XenServer interaction. However, in scenarios where the user chooses to import into XenServer as part of the conversion process, the utility conveniently offers this capability thus requiring the user to authenticate to a XenServer with administrative credentials.
In the P2V scenario, XenConvert 2.0.1 facilitates the creation of an OVF based virtual appliance by using a physical machine as the appliance reference. This is a unique use case as the creator of the virtual appliance now has another avenue of flexibility in determining the source of the virtual appliance.
One helpful use case is converting an existing XenServer XVA virtual disk to an OVF/VHD package. This gives virtual appliance users the option to easily convert the XVA to a standards based virtual appliance format.
Another use case is converting from a VMware OVF/VMDK to XenServer. Kensho OVF technology allows XenConvert to convert and import VMware OVF content into a XenServer environment. This is very helpful when moving between hypervisors and gives users the freedom of OVF interoperability at the virtual disk level.
There are many more possible use cases employing Project Kensho OVF technology found in XenConvert 2.0.1. XenConvert 2.0.1 supports OVF packaging options like compression, digital signatures, encryption and archiving the OVF package as well as attaching EULA information to the virtual appliance.
For use cases where P2V and V2V conversion is a must, XenConvert is an excellent tool to convert and import OVF content into XenServer. And, it represents yet another method of creating and consuming OVF based virtual appliances.
Conclusion
Project Kensho OVF technology offers users a variety of options whether using the Project Kensho OVF Tool or XenConvert 2.0.1. Each utility allows creators and consumers of OVF based virtual appliances a variety of paths into XenServer creating flexibility for all users of the technology.
By providing tools to address the conversion of physical and virtual disk formats to XenServer as well as the import and export of OVF content, Citrix is actively positioning customers and partners for the move into the virtual appliance world.
Cloud Networking is secure and robust
You can create a complete end-to-end network from one cloud network, running on XenServer, through a VPN to another network in a different cloud. All servers and hosts communicate securely over SSL VPN. Amazon Machine Images are secured by the Amazon infrastructure using security groups.
The proof of concept speaks for itself. Between the Softlayer cloud and the Amazon EC2 cloud is running a site-to-site SSL VPN using Vyatta. All of the images in this architecture are running on XenServer. This proof of concept gives rise to many networking architectures for cloud computing.
The reason for using Vyatta site-to-site SSL VPN between the Softlayer and Amazon EC2 clouds is there needs to be a secure network between the two for the transfer of data. The Vyatta AMI (Amazon Machine Image) can also function as a complete router, firewall and DNS cache. The Vyatta SSL VPN router provides security with scalability. Suppose I wanted to separate the Vyatta SSL VPN from a Vyatta OSPF router, I would just launch another instance of the Vyatta AMI.
As you can see from the network diagram and video, complete routing from the Softlayer cloud to the Amazon cloud network is seamless, without having to buy any proprietary hardware. In fact, it is very low cost compared to traditional network solutions. Virtualized networking is here, it is fast, secure and cheap.
A CloudBurst happens when Citrix Workflow Studio determines that one of the devices in the Softlayer Cloud has reached a high watermark. WFS then instructs the NetScaler VPX to start sending traffic to the Cloud - CloudBurst.
To get your own cloud, go here
Configurations used
Vyatta SSL VPN (V1) - Datacenter Configuration
Vyatta SSL VPN (V2) - Cloud Configuration
XenApp VPN Client - Cloud Configuration
Links for this solution
Vyatta for XenServer - go here
Amazon EC2 - go here
XenServer is Free! - go here
XenApp - go here
Workflow Studio - go here
XenApp VPN Client - go here
Dell Server - go here
IP Addresses - go here
Watch This
Its powerful AppExpert!
Cloud Networking is fast
You can create a complete end-to-end network from the datacenter to the cloud. All cloud servers communicate securely over SSL VPN.
Between the datacenter and the Amazon EC2 cloud is a site-to-site SSL VPN built with Vyatta. On the XenApp server in the cloud runs the Citrix Accelerator which connects back to the Citrix Branch Repeater/WANScaler at the datacenter, to accelerate data connections. The Citrix Accelerator makes cloud computing fast, Vyatta makes it secure.
The reason for using Vyatta site-to-site SSL VPN between the datacenter and Amazon EC2 cloud is there needs to be a secure network between the two for the transfer of data. The Vyatta AMI (Amazon Machine Image) can also function as a complete router and firewall. The Vyatta SSL VPN router provides security with scalability.
As you can see from the network diagram and video, complete routing from the datacenter to the Amazon cloud network is seamless. Data resides at the datacenter and is accessed, over the SSL VPN, by the Application running in XenApp. The remote user connects to XenApp, runs the application, and the application delivers the data to the remote user, quickly and securely.
To get your own cloud, go here.
Configurations used
Vyatta SSL VPN (V1) - Datacenter Configuration
Vyatta SSL VPN (V2) - Cloud Configuration
Windows VPN Client - Cloud Configuration
Links for this solution
Vyatta - go here
Amazon EC2 - go here
XenServer is Free! - go here
XenApp - go here
XenApp VPN Client - go here
Dell Server - go here
IP Addresses - go here
Watch This
Its powerful AppExpert!
Network Virtualization is secure and routable
You can create a complete end-to-end network from your corporate datacenter, running on XenServer, through the VPN to the network in the cloud. All servers and hosts communicate securely over SSL VPN.
The best part about this solution is that when one vendor said that virtualization breaks the network, it really doesn't.
I just did the proof of concept between a Citrix datacenter and Amazon cloud services. Between the Citrix datacenter and the Amazon cloud, I am running a site-to-site SSL VPN. The SSL VPN running at the Citrix datacenter is running inside of XenServer on a Dell 2950 III server, optimized for virtualization.
The SSL VPN Gateway running in the Cloud is also running on Xen as a virtual appliance, or virtual gateway if you will. The Windows Server(s) in the cloud are connected to the SSL VPN using OpenVPN.
The reason for using OpenVPN on the Windows Server(s) to connect to the SSL VPN Gateway in the Cloud is twofold:
- Amazon doesn't allow the reconfiguration of default gateways on their Amazon Machine Images (AMIs). By configuring the OpenVPN client connection, you can send all traffic from the Windows Server (S3) through the SSL VPN gateway (V2), through the VPN (vtun0) Tunnel, through the SSL VPN gateway (V1) to the private network in the Citrix datacenter AND vice versa.
- Provides an extra layer of security for traffic traversing the intra-cloud network.
Its powerful AppExpert!
Border Gateway Protocol, open-source and it's para-virtualized. No more proprietary software and hardware, you can run as many copies of this as needed on one physical XenServer machine. As a proof point, we used the Vyatta Open Source router to build out our Link Load Balancing network in Santa Clara. The Open Source Vyatta is running on a Dell server. We configured the BGP routing protocol, but could have have also configured OSPF or RIP and redistributed the routes. This configuration has been proven to outperform the incumbents, and is less costly by a wide margin. Reduce opex and capex and start rolling this out today.
What is needed:
- Vyatta Open Source Networking Software
- A Dell Server that supports Virtualization
- XenServer Enterprise 4.1
The Network:
Watch this Video:
Tap into the power of AppExpert!
And it's FREE! Throw away those behemoths that suck power from every grid in the state and drain your budget. This baby is Free, Open Source and VIRTUAL, meaning you can run as many instances of this router as you want on your choice of hardware. What is even more gratifying is it's faster than the old router technology.
Vyatta has commoditized router, firewall and VPN deployment in the same way that Linux commoditized the operating system market. Vyatta open-source networking offers you an alternative to over-priced, inflexible products from proprietary vendors.
Vyatta software enables customers to build routing and security solutions using standard x86-based hardware of their choosing, ensuring networks will always meet performance requirements. Vyatta open-source software delivers the unique advantage of allowing customers to scale networks from the simplest LAN configurations to large BGP WAN edge configurations using a single software package.
Vyatta software includes support for most commonly used network interfaces, industry standard routing and management protocols, and all of these features are configurable via a single command-line interface (CLI) or web-based graphical user interface (GUI) - avail Q3'08. The integrated features and functionality make Vyatta software ideal for SMB, Branch Office, Enterprise and Service Provider deployments.
Summary of features:
BGP, OSPF, RIP, DHCP, QoS, IPSec VPN, VRRP, PPP, 802.1Q, Complete List.
This open source router is already running on XenServer in a large service provider in Europe. We are using it in our Citrix Ready program as a multi-link Intranet with connections to the Internet along with high availability link load balancing.
This para-virtualized Vyatta image runs as a virtual appliance in XenServer v3.2.1 and v4.1.
The XenServer Platform we are using:
- Dell Poweredge 2950 server.
- 2 x Intel 64-bit Quad-Core Xeon Processors, Model E5335 @ 2.00 GHz each, for a total of 8 CPUs.
- 2 Intel 82571EB Gigabit Ethernet (on-board)
- 2 Broadcom NetXtremeII Gigabit Ethernet
- 16 GB of memory.
- 300 GB of Storage.
- XenServer v4.1
- *note: CPU's must support virtualization technology.
Virtual Router - Install:
Virtual Router - Config:
Tap into the power of AppExpert.
Satori Group uses XenServer, XenApp or Citrix Access Essentials to simplify and streamline delivery of their solution to their customers using Citrix virtualization technologies. Nice implementation of the VADA concept.
"Working closely with Citrix and Microsoft, Satori Group developed a virtual appliance for delivering a complete application solution to customers. Virtual appliances are preinstalled, pre-configured, ready-to-run enterprise applications packaged with an operating system inside a virtual machine. In contrast, a virtual machine, by itself, does not include applications."
Full release: Satori Group Partners with Citrix to Create Virtual Appliances for Turnkey Application Delivery
Most of us know or have heard about Virtual Appliances. Mostly single purpose virtual machines usually running on some variant of Linux today. So why is this beneficial?
- Ease of installation - import the VM and start it up
- Preconfigured - maybe not fully preconfigured, but much more than having a stack of OS and product CDs and bare metal to start with
- Reduced maintenance costs - starting with a preinstalled and mostly configured solution tends to reduce the number of errors associated with the install and configuration when done from scratch
So why not a Virtual Application Delivery Appliance (VADA)? A preinstalled and mostly configured XenApp or CAE server that already has a targeted application published in the virtual machine. A virtual machine that I get from my ISV that I start on my XenServer server. Web Interface and PNAgent are already setup with defaults. I add my users to the published application and start delivering the app. Kind of a normal virtual appliance, but on digital steroids to enhance performance.
This is already starting to happen! Our Platform Development Group at Citrix has been increasingly having discussions with ISV alliance partners to do just what is explained above. Some are doing it; others are looking at the feasibility of doing it with their solution. They have an application, or multi-component software solution that they want to, or are required to deliver via Citrix Application Delivery, and they want to simplify the process for both the customer and themselves as much as possible. Maybe the deployment of the solution is a standalone environment and not to be part of a bigger farm. Maybe there are reasons that their solution should run on dedicated server(s) and they simply join an existing farm. In either case, by deploying their solution as a VADA (I'll let marketing guys change this acronym later), they can greatly reduce their installation/deployment cycle, and spend more time on training the customer on use of the solution, thus increasing customer satisfaction (VADA Bing VADA Boom!). Post-installation maintenance should also be lower, being a large percentage of the OS and application installation has been automated by creation of the tested baseline virtual machine image which already contains the OS, XenApp and the published application, all following best practices established in the ISVs controlled lab environment.
So why not just jump on this band wagon today? As always there's a few "gotchas".
- Licensing - while a bit easier on the Linux side, what we are discussing here is Microsoft Servers and Citrix Application Delivery products. Usually ISVs do not have access to distribute licenses for either of these.
- Server Virtualization Platform - So which platform does the ISV support (XenServer, VMWare, HyperV). I think you can see some of the benefits of having a standard virtual machine image format, and why it's good that 2 of the 3 vendors listed are working towards such a standard.
- Please add your "gotchas" below.
Intent of this thread is not to indicate the right or wrong way to approach the above scenario, but to get your feedback and ideas on the concept. I find this concept very intriguing. So give us and the other readers of this blog your input below. Respond with your "gotchas" or respond to others "gotchas" on how they should be resolved. I'll be sure to send a link to this post to our interested ISV partners, so they get the input.
I kicked it off, help me finish it!
References:
Satori Group VADA blog post