Xen cloud platform v1.1 (given at Build a Cloud Day in Antwerp)

Editor's Notes

• #3: XenoServer : enablers as well the concept
• #4: Note: 10th birthday of the project is coming up
• #5: Hold this thought! We will come back to this later….!
• #9: Key notes:Just a subset of vendors, projects, etc. that build, use or provide services on top of Xen
• #10: PVOPS is the Kernel Infrastructure to run a PV Hypervisor on top of Linux
• #11: Dom 0:In a typical Xen set-up Dom0 contains a smorgasboard of functionality:System bootDevice emulation & multiplexingAdministrative toolstackDrivers (e.g. Storage & Network)Etc.LARGE TCB – BUT, Smaller as in a Type 2 hypervisorDriver/Stub/Service Domains: also known as Disaggregation
• #13: Device Model emulated in QEMUModels for newer devices are much faster, but for now PV is even faster
• #14: Automatic PerformancePV on HVM guests are very close to PV guests in benchmarks that favour PV MMUsPV on HVM guests are far ahead of PV guests in benchmarks that favour nested paging
• #17: Where are we?1) Linux 3 contains everything needed to run Xen on a Vanilla Kernel, both as Dom0 and DomU2) That’s of course a little bit of an old hat now3) But it is worth mentioning that it only took 5 years to upstream that PVOPS into the kernel
• #24: * Host Architectural Improvements. XCP 1.5 now runs on the Xen 4.1 hypervisor, provides GPT (new partition table type) support and a smaller, more scalable Dom0. * GPU Pass-Through. Enables a physical GPU to be assigned to a VM providing high-end graphics. * Increased Performance and Scale. Supported limits have been increased to 1 TB memory for XCP hosts, and up to16 virtual processors and 128 GB virtual memory for VMs. Improved XCP Tools with smaller footprint. * Networking Improvements. Open vSwitch is now the default networking stack in XCP 1.5 and now provides formal support for Active-Backup NIC bonding. * Enhanced Guest OS Support. Support for Ubuntu 10.04 (32/64-bit).Updated support for Debian Squeeze 6.0 64-bit, Oracle Enterprise Linux6.0 (32/64-bit) and SLES 10 SP4 (32/64-bit). Experimental VM templates for CentOS 6.0 (32/64-bit), Ubuntu 10.10 (32/64-bit) and Solaris 10. * Virtual Appliance Support (vApp). Ability to create multi-VM and boot sequenced virtual appliances (vApps) that integrate with Integrated Site Recovery and High Availability. vApps can be easily imported and exported using the Open Virtualization Format (OVF) standard.
• #26: Note: not exactly 1:1 with XEComparisons to other APIs in the virtualization space (source: Steven Maresca)Generally speaking XAPI is well-designed and well-executedXAPI makes it pleasantly easy to achieve quick productivityXAPI is set up to work with frameworkssuch as CloudStack and OpenStack. Some SOAPy lovers of big XML envelopes and WSDLs scoff at XML-RPC, but it certainly gets the job done with few complaintsExample codehttp://bazaar.launchpad.net/~nova-core/nova/github/files/head:/plugins/xenserver/xenapi/etc/xapi.d/plugins/   https://github.com/xen-org/xen-api/blob/master/scripts/examples/python/XenAPIPlugin.py
• #27: All elements on the diagram just shown are called classes:diagram omits another twenty or more minor classes.Visit the SDK documentation for documentation of all classes,Classes are the objects XCP knows about and exposes through API bindingsEach class has attributes called fields and functions called messages. We'll stick with 'attributes' and 'functions.'Classes on diagram:VM: A virtual machineHost: A physical XCP host systemPBD: physical block device through which an SR is accessedSR: Storage repositoryVDI: Virtual disk imageVDB: Virtual block deviceNetwork: A virtual networkVIF: A virtual network interfacePIF: A physical network interface
• #28: VM lifecycle (start, stop, resume) ... automation is the key pointLive snapshots: Takes a snapshot of a live VM (e.g. for disaster recovery or migration)Resource pools (multiple physical machines): XS & XCP onlylive migration: VM is backed up while running, onto shared storage (e.g. NFS) in a pool and when completed restarted elsewhere in that pool. disaster recovery: you can find lots of information on how this works at http://support.citrix.com/servlet/KbServlet/download/17141-102-19301/XenServer_Pool_Replication_-_Disaster_Recovery.pdf (the key point is that I can back up the metadata for the entire VM)Flexible storage: XAPI does hide details for storage and networkingI.e. I apply generic commands (NFS, NETAPP, iSCSI ... once its created they all appear the same) from XAPI. I only need to know the storage type when I create storage and network objects (OOL)Upgrading a host to a later version of XCP (all my configs and VMs stay the same) …and patching (broken now - bug, can apply security patches to XCP/XS or Dom0 but not DomU)
• #30: Automated Control/OpenFlow: e.g. Firewall rules, Access Control Rules (does help with things like Multi Tenancy – program visibility of a switch), Ford Locking (security mechanism – a VM can only use a particular MAC address, if you tamper with it can’t connect to the switch).Multi-tenancy: separate virtual networks for different cloud customersMonitoring: of course for charging per useQoS: rate limiting (customer pays for a specific amount of bandwidth)
• #37: Earlier this year, we released Xen 4.1I just put up the feature list, but I wont go through it in detail. I did want to point out that the focus of this release was onSupport for large systems and easier management of large systems with CPU poolksAs well as on securityAnd that is starting a trend to optimize the hypervisor for cloud use cases
• #38: Detailed ListGeneralDocumentation improvements (e.g. man pages)Lots of bug fixing of course.[edit]Toolsxl is now default toolstack and xend is formally deprecatedlots of xl improvements.we should highlight xend deprecation (not effectively maintained since 2008)Remus compression (compression of memory image improves performance)Prefer oxenstored when available (improves scalability!)Support for upstream qemu; nearing feature parity (non default still, but we want people to be testing it)Added libvchan to xen mainline(cross domain comms)[edit]XenImprovements to paging and sharing, enabling higher VM density for VDI use-casesEFI (extensible Firmware Interface) support for HV (i.e. if I have a machine that has EFI, I can use Xen on it)Support up to 256 Host CPUs for 64 bit h/v (from 128)Support dom0 kernels compressed with xzPer-device interrupt remapping (increases scalability)Support for pvhvm guest direct pirq injection (Performance improvement for PCI passthrough for Linux Guests)Intel SMEP (Supervisor Mode Execution Protection) supportMem event stuff? (Allows to externally observe what guests are up to and can be used for external virus checking - not sure what the right terminology is)Multiple PCI segment supportAdded xsave support(floating point)Lots of XSM / Flask fixes (security)AMD SVM "DecodeAssist" support (AMD CPU feature that avoids emulation and increases performance)[edit]Removed FunctionalityACM (alternative XSM to Flask) was removed (unmaintained)Removed vnet (unmaintained)[edit]Xen Development SupportCan build with clangAdded "make deb" targetLots of xentrace improvementsupdate ocaml bindings and make them usable by xapi (which previously had it's own fork of the same codebase)
• #40: Just one example of a survey, many morehttp://www.colt.net/cio-research/z2-cloud-2.htmlAccording to many surveys, security is actually the main reason which makes or breaks cloud adoptionBetter security means more adoptionConcerns about security means slowed adoption
• #41: So for a hypervisor, as Xen which is powering 80% of the public cloud – rackspace, AWS and many other VPS providers use Xen and with cloud computing becoming mainstream, furthering security is really importantOne of the key things there is isolation between VMs, but also simplicity as I pointed out earlierBut there are also a number of advanced features in Xen, which are not that widely know. So I wanted to give you a short overview of two of them
• #42: At this point I want to make a quick detour into the different hypervisor architectures from a viewpoint of security.Let’s look at type 1 hypervisor:Basically a very simple architecture, where the Hypervisor replaces the kernelThe architecture is significantly simpler that a Type 2 hypervisor, because it does not need to provide rich “process” semantics, like “user”, filesystems, etc.BUT: the trade-off is that all the device drivers need to be rewritten for each hardware platformType 2 is hosted- The hypervisor is just a driver that typically works with user-level monitor.HW access is intercepted by the ring 0- VM monitor passed to the User level Virtual Monitor, which passes requests to the kernelRe-use of device drivers is traded off against security and a large trusted computing base (green)
• #43: Dom 0:In a typical Xen set-up Dom0 contains a smorgasboard of functionality:System bootDevice emulation & multiplexingAdministrative toolstackDrivers (e.g. Storage & Network)Etc.LARGE TCB – BUT, Smaller as in a Type 2 hypervisor
• #44: Ask some questions
• #45: Example: XOARSelf-destructing VMs (destroyed after initialization): PCIBack = virtualize access to PCI Bus configRestartable VMs (periodic restarts): NetBack (Physical network driver exposed to guest) = restarted on timerBuilder (instantiate other VMs) = Restarted on each request
• #47: This is not pie in the sky: these features are actually in use already for desktop virtualization.I wanted to point out Qubes OS which is an OSS project in its second betaAnd a commercial Citrix product which makes use of these featuresIn the last 6 months there has been lots of talk in the community, how these features can be adopted for Server virtualization and I expect that we see adoption of these in XCP and commercial Xen products.But of course this is not easy: there are challenges around Configuartion and Usability
• #49: What about domain 0 itself?Once we've disaggregated domain 0, what will be left? The answer is: very little! We'll still have the logic for booting the host, for starting and stopping VMs, and for deciding which VM should control which piece of hardware... but that's about it. At this point domain 0 could be considered as a small "embedded" system, like a home NAT box or router.
• #50: PVOPS is the Kernel Infrastructure to run a PV Hypervisor on top of Linux
• #51: Let’s have a quick look at what’s new in the kernel 3.1Mainly usability improvementsThe most significant addition is the PCI back module which enables the kernel to pass PCI/PCIe devices to Xen guests3.2: see http://www.gossamer-threads.com/lists/xen/users/229720Quite a lot of features are planned to go into Linux 3.2 and beyond. I will just explain a few. For the rest, do talk to me afterwards3.2 Feature Discard: Tells the HW that disk sectors are unusedThis is good for Solid State DrivesBut it is also good for filers doing thin provisioning3.3 PV Spinlocks: Better performance under contention ACPI S3: Which gives us Suspend to RAM, which is good for Xen on Laptop Use casesThe key is that all this is about optimization and rounding out of features------------------3.2: hwclock -s: Makes time (i.e. wallclock, RTC time) handling work as expected for the dom0 administrator. "feature-barrier": Required for correctness by certain guests (SLES10, I think). AIUI various filesystem implementations rely on barriers to Yup (and Oracle's guests applicance thingies) actually do something for correctness. Without this there coudl be corruption (I wouldn't necessarily stand on stage and say that out loud though) Some form of it can appear if you unplug the machine right as it is writting data out. But I am not entirely sure how to reproduce that 100%.. But yes - barries and flushes provide a mechanism to do 'write meta data NOW', and then the normal data can be written. So that in case of power failure you can go back to the meta data and figure stuff out. So yes. corruption averted! "feature-discard": Used to indicate to h/w that disk sectors are unused. This is good for SSDs and also for filers which do thin provisioning since it improves wear-levelling and allows the space to be recovered respectively. <nods> Not sure what there is to say about the others.
• #52: http://www.gossamer-threads.com/lists/xen/users/2297063.3: PV spinlocks: PV spinlocks improve performance under contention by allowing lock takers to sleep/yield instead of spinning wasting scheduling quanta. The current PV spinlock replaces the entire spinlock algorithm/datastructure. The new work simply adds a PV slow path but keeps the core "ticket lock" algorithm. This is beneficial in terms of sharing more code (and hence perf analysis etc) with native. The benefit is that during high contention (so more guests using VCPUs that there are physical CPUS - think four guests, each using 2 VCPU, and the box only has four physical) we can schedule the guests appropiately instead of spinning uselessly wasting CPU resources. ACPI S3: Suspend to RAM. Useful for Xen on laptop type scenarios. Yeah, that one is taking longer than I thought. Got some feedback and will post a new set shortly. 3D graphics: THe RAM used by graphics cards has various constraints on the RAM which they use which we need to work with in order to make those cards work correctly It pretty much is in. Another graphics guy picked up the patches, reworked them even further and they are definitly in for 3.3. ACPU cpufreq: Power management, useful in servers etc. I suspect this also improves performance in some cases by allowing access to faster states. Still a bit behind sadly. The patches are "nicer" but still not sure how to make them even more nicer for Len. Will have to post them at some point. Maybe I shoudl do it on Dec 24th
• #53: So what does all that mean?Firstly, you can just Download the latest Linux distro, get the Xen package and you can get startedOf course that requires distros which have the Linux 3 kernel in itDebian Squeeze, Fedora 16, Ubuntu 10.10
• #54: Why should you help?There are lots of HW variants and our developers cant possibly test all of themSo if you do wangt to help ...If you see any issues: and that may mean bugs, unexpected behavior, unexpected performance: let is know such that we can fix it.
• #56: The key point here isXen ARM has a long historyUses paravirtualizationAnd supports a wide range of ARM processor featuresAs Kiko pointed out, there are quite few challenges in the ARM space such as complexity and Linux ports and that also affects XenSo for example to build Xen ARM, it was necessary to modify the ARM Linux kernel and we are facing questions such as a) do we try and upstream, or do we go for a clean start with newer ARM architectures
• #57: This slide is all about pointing out that there is pull for the ARM architectureCALXEDA| HP
• #58: Goals:Mobile, Client and Server for ARM Realtime capabilityMake sure that we have an architecturally clean start moving forward
• #60: Hold this thought! We will come back to this later….!
• #61: Performance : similar to other hypervisorsMaturity: Tried & Tested, Most Problems that are Problems are well knownOpen source: Good body of Knowledge, Tools