4.4 Release Talk Slides

4.4 Release Talk Slides

[Russell Pavlicek]

[-- Attachment #1.1: Type: text/plain, Size: 868 bytes --]

Folks,

I am giving my first 4.4 release talk at the Linux Foundation Collaboration Summit next week and I am trying to do the release justice.  I am trying to work up a decent deck of features and futures.

The attached deck is an ugly transliteration of the 4.4 Features list (in PDF and text).  I don't care about the format at the moment; just the content.

My questions for you all:


(1)    Any problems with the content as it is?

(2)    Any topics I should add or remove?

(3)    Any details you suggest I add?

(4)    What more should I add to the Futures section?

I have to put this puppy to bed by Friday, so any feedback over the next couple of days would be greatly appreciated.

Many thanks,

Russ Pavlicek
Xen Project Evangelist, Citrix Systems
Home Office: +1-301-829-5327
Mobile: +1-240-397-0199
UK VoIP: +44 1223 852 894


[-- Attachment #1.2: Type: text/html, Size: 7871 bytes --]

[-- Attachment #2: Xen Project 4-4 Features and Futures.pdf --]
[-- Type: application/pdf, Size: 492830 bytes --]

[-- Attachment #3: Xen Project 4-4 Features and Futures.txt --]
[-- Type: text/plain, Size: 6240 bytes --]

Xen Project 4.4: Features and Futures

Russell Pavlicek
Xen Project Evangelist, Citrix
Systems

\fXen Project 4.4 Features

\fImproved Flexibility in Driver Domains
• Linux driver domains used to rely on udev events in
order to launch backends for guests
– Dependency on udev is replaced with a custom daemon
built on top of libxl
– Provides greater flexibility in order to run user-space
backends inside of driver domains
– Example of capability: driver domains can now use
Qdisk backends, which was not possible with udev

\fImproved Event Channel Scalability
• Event channels are para-virtualized interrupts
• Previously limited to either 1024 or 4096 channels
per domain
– Domain 0 needs several event channels for each guest
VM (for network/disk backends, qemu etc.)
– Practical limit of total number of VMs to around 300500 (depending on VM configuration)

\fImproved Event Channel Scalability (2)
• New FIFO-based event channel ABI allows for over
100,000 event channels
– Improve fairness
– Allows for multiple priorities
– The increased limit allows for more VMs, which benefits
large systems and cloud operating systems such as
MirageOS, ErlangOnXen, OSv, HalVM

\fExperimental PVH Support
• PVH mode combines the best elements of HVM and
PV
– PVH takes advantage of many of the hardware
virtualization features that exist in contemporary
hardware

• Potential for significantly increased efficiency and
performance
• Reduced footprint in Linux and FreeBSD

\fTech Preview of Nested Virtualization
• Nested virtualization provides virtualized hardware
virtualization extensions to guests
– Can now run Xen Project, KVM, VMWare or HyperV
inside of a guest for debugging or deployment testing
– Also allows Windows 7 "XP Compatibility mode"
– Tech Preview not yet ready for production use, but has
made significant gains in functionality and reliability

• More information on nested virtualization: see Xen
nested

\fImproved Support for SPICE
• SPICE is a protocol for virtual desktops which allows
a much richer connection than display-only
protocols like VNC
• Added support for additional SPICE functionality,
including:
– Vdagent
– clipboard sharing
– USB redirection

\fGRUB 2 Support of Xen Project PV Images
• In the past, Xen Project software required a custom
implementation of GRUB called pvgrub
• The upstream GRUB 2 project now has a build target
which will construct a bootable PV Xen Project
image
– This ensures 100% GRUB 2 compatibility for pvgrub
going forward

\fIndirect Descriptors for Block PV Protocol
• Modern storage devices work much better with
larger chunks of data
• Indirect descriptors have allowed the size of each
individual request to triple, greatly improving I/O
performance when running on fast storage
technologies like SSD and RAID
• This support is available in any guest running Linux
3.11 or higher (regardless of Xen Project version)

\fImproved kexec Support
• kexec allows a running Xen Project host to be
replaced with another OS without rebooting
– Primarily used execute a crash environment to collect
information on a Xen Project hypervisor or dom0 crash

• The existing functionality has been extended to:
– Allow tools to load images without requiring dom0
kernel support (which does not exist in upstream
kernels)
– Improve reliability when used from a 32-bit dom0
– kexec-tools 2.0.5 or later is required

\fImproved XAPI and Mirage OS support
• XAPI and Mirage OS are sub-projects within the Xen
Project written in OCaml
• Both are also used in XenServer
(see http://xenserver.org/) and rely on the Xen
Project OCaml language bindings to operate well
• These language bindings have had a major overhaul
– Produces much better compatibility between XAPI,
Mirage OS and Linux distributions going forward

\fExperimental Support for Guest EFI boot
• EFI is the new booting standard that is replacing
BIOS
– Some operating systems only boot with EFI
– Some features, like SecureBoot, only work with EFI

\fImproved Integration With GlusterFS
• You can find a blog post to set up an iSCSI target on
the Gluster blog here

\fImproved ARM Support
• A number of new features have been implemented:
• 64 bit Xen on ARM now supports booting guests
• Physical disk partitions and LVM volumes can now
be used to store guest images using xen-blkback (or
is PV drivers better in terms of terminology)
• Significant stability improvements across the board
• ARM/multiboot booting protocol design and
implementation
• PSCI support

\fImproved ARM Support (2)
• Same DMA in Dom0 even with no hardware
IOMMUs (not sure what the implications of this are)
• ARM and ARM64 ABIs are declared stable and
maintained for backwards compatibility
• Significant usability improvements, such as
automatic creation of guest device trees and
improved handling of host DTBs

\fImproved ARM Support (3)
• Adding new hardware platforms to Xen Project on
ARM has been vastly improved, making it easier for
Hardware vendors and embedded vendors to port
to their board
• Added support for the Arndale board, Calxeda ECX2000 (aka Midway), Applied Micro X-Gene Storm, TI
OMAP5 and Allwinner A20/A30 boards
• ARM server class hardware (Calxeda Midway) has
been introduced in the Xen Project OSSTest
automated testing framework

\fEarly Microcode Loading
• The hypervisor can update the microcode in the
early phase of boot time
– The microcode binary blob can be either as a
standalone multiboot payload, or part of the initial
kernel (dom0) initial ramdisk (initrd)
– To take advantage of this use latest version
of dracut with --early-microcode parameter and on the
Xen Project command line specify: ucode=scan.
– For details see dracut manpage
and http://xenbits.xen.org/docs/unstable/misc/xencommand-line.html

\fXen Project Futures

\fStill More Fun to Come…
• Xen Automotive
– Xen Project in the entertainment center of your car?

• XenGT
– Virtualized GPU support

• Even More ARM Support
– On your server, in your phone, wherever…

• PVH stability and performance
– The new hypervisor mode to get harder and faster

\fQuestions?

Russell.Pavlicek@XenProject.org
Twitter: @RCPavlicek

\f

[-- Attachment #4: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: 4.4 Release Talk Slides

[Ian Campbell]

On Wed, 2014-03-19 at 01:26 +0000, Russell Pavlicek wrote:
> I have to put this puppy to bed by Friday, so any feedback over the
> next couple of days would be greatly appreciated.

Nothing major, but a few things I spotted:

"Improved Flexibility in Driver Domains"

        Another advantage is that things are now consistent between
        Linux and !Linux driver domains.
        
        IIRC it is also less racy (not risqé!) in various ways too.

"Experimental PVH Support"

        Clarify with "PVH Guest Support"? dom0 is pending for the next
        release IIRC.
        
        Say "reduced implementation footprint" perhaps? (trying to
        convey that the footprint in question is the amount of hacking
        around the guest's MM layer which is needed)
        
        Put a bullet "* Enable with pvh=1 in your config"? (likewise for
        each of these new things where such an option exists?)

"Tech Preview of Nested Virtualization"

        "provides... to *HVM* guests"

        The use of "Xen Project" on this slide seems out of
        context/clumsy. If plain "Xen" is not acceptable then perhaps
        "Xen Hypervisor"?

        Enable with "hap=1" and "nestedhvm=1"
        
"GRUB 2 Support of Xen Project PV Images"

        This is delivered by a grub release (I think it is in 2.02-beta,
        but 2.02 final isn't out yet)
        
        Not actually a Xen 4.4 feature. Not to say it isn't worth
        mentioning. AIUI it should work with older Xen too though.

"Improved ARM Support (2)"

        "Same DMA support". Should be "Some DMA Support" or "Sane..." or
        "Dom0 DMA support"? The implications of this stuff are that
        things work/don't crash ;-)
        
        on (3) The Allwinner processors are A20/A31 not A20/A30.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: 4.4 Release Talk Slides

[Russell Pavlicek]

Ian,

Thanks!  I will role those in and send out a modified version later for comment.  If anyone else has items to add, please let me know.

>The use of "Xen Project" on this slide seems out of context/clumsy. If plain "Xen" is not acceptable then perhaps "Xen Hypervisor"?

The problem here is the growing concern about proper use of trademark in externally-facing docs and presentations.  The guidance from Linux Foundation is to use "Xen Project" everywhere.  The old "Xen" mark is not owned by LF, and, hence, should not be used on the website, docs, and slides.  So even "Xen Hypervisor" is out of consideration.

Furthermore, since a trademark is an adjective, we shouldn't ever use "Xen Project" as a noun.  So, the former statement, "Now install Xen" becomes "Now install the Xen Project software" or something similar.   As graceful as snowshoes on a summer day, I know, but that's life in the big city.

Russ Pavlicek
Xen Project Evangelist, Citrix Systems
Home Office: +1-301-829-5327
Mobile: +1-240-397-0199
UK VoIP: +44 1223 852 894

-----Original Message-----
From: Ian Campbell 
Sent: Wednesday, March 19, 2014 5:43 AM
To: Russell Pavlicek
Cc: xen-devel (xen-devel@lists.xenproject.org)
Subject: Re: [Xen-devel] 4.4 Release Talk Slides

On Wed, 2014-03-19 at 01:26 +0000, Russell Pavlicek wrote:
> I have to put this puppy to bed by Friday, so any feedback over the 
> next couple of days would be greatly appreciated.

Nothing major, but a few things I spotted:

"Improved Flexibility in Driver Domains"

        Another advantage is that things are now consistent between
        Linux and !Linux driver domains.
        
        IIRC it is also less racy (not risqé!) in various ways too.

"Experimental PVH Support"

        Clarify with "PVH Guest Support"? dom0 is pending for the next
        release IIRC.
        
        Say "reduced implementation footprint" perhaps? (trying to
        convey that the footprint in question is the amount of hacking
        around the guest's MM layer which is needed)
        
        Put a bullet "* Enable with pvh=1 in your config"? (likewise for
        each of these new things where such an option exists?)

"Tech Preview of Nested Virtualization"

        "provides... to *HVM* guests"

        The use of "Xen Project" on this slide seems out of
        context/clumsy. If plain "Xen" is not acceptable then perhaps
        "Xen Hypervisor"?

        Enable with "hap=1" and "nestedhvm=1"
        
"GRUB 2 Support of Xen Project PV Images"

        This is delivered by a grub release (I think it is in 2.02-beta,
        but 2.02 final isn't out yet)
        
        Not actually a Xen 4.4 feature. Not to say it isn't worth
        mentioning. AIUI it should work with older Xen too though.

"Improved ARM Support (2)"

        "Same DMA support". Should be "Some DMA Support" or "Sane..." or
        "Dom0 DMA support"? The implications of this stuff are that
        things work/don't crash ;-)
        
        on (3) The Allwinner processors are A20/A31 not A20/A30.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: 4.4 Release Talk Slides

[Russell Pavlicek]

[-- Attachment #1: Type: text/plain, Size: 3521 bytes --]

Here's the latest version.

Thanks,

Russ Pavlicek
Xen Project Evangelist, Citrix Systems
Home Office: +1-301-829-5327
Mobile: +1-240-397-0199
UK VoIP: +44 1223 852 894


-----Original Message-----
From: Russell Pavlicek 
Sent: Wednesday, March 19, 2014 9:01 AM
To: Ian Campbell
Cc: xen-devel (xen-devel@lists.xenproject.org)
Subject: RE: [Xen-devel] 4.4 Release Talk Slides

Ian,

Thanks!  I will role those in and send out a modified version later for comment.  If anyone else has items to add, please let me know.

>The use of "Xen Project" on this slide seems out of context/clumsy. If plain "Xen" is not acceptable then perhaps "Xen Hypervisor"?

The problem here is the growing concern about proper use of trademark in externally-facing docs and presentations.  The guidance from Linux Foundation is to use "Xen Project" everywhere.  The old "Xen" mark is not owned by LF, and, hence, should not be used on the website, docs, and slides.  So even "Xen Hypervisor" is out of consideration.

Furthermore, since a trademark is an adjective, we shouldn't ever use "Xen Project" as a noun.  So, the former statement, "Now install Xen" becomes "Now install the Xen Project software" or something similar.   As graceful as snowshoes on a summer day, I know, but that's life in the big city.

Russ Pavlicek
Xen Project Evangelist, Citrix Systems
Home Office: +1-301-829-5327
Mobile: +1-240-397-0199
UK VoIP: +44 1223 852 894

-----Original Message-----
From: Ian Campbell
Sent: Wednesday, March 19, 2014 5:43 AM
To: Russell Pavlicek
Cc: xen-devel (xen-devel@lists.xenproject.org)
Subject: Re: [Xen-devel] 4.4 Release Talk Slides

On Wed, 2014-03-19 at 01:26 +0000, Russell Pavlicek wrote:
> I have to put this puppy to bed by Friday, so any feedback over the 
> next couple of days would be greatly appreciated.

Nothing major, but a few things I spotted:

"Improved Flexibility in Driver Domains"

        Another advantage is that things are now consistent between
        Linux and !Linux driver domains.
        
        IIRC it is also less racy (not risqé!) in various ways too.

"Experimental PVH Support"

        Clarify with "PVH Guest Support"? dom0 is pending for the next
        release IIRC.
        
        Say "reduced implementation footprint" perhaps? (trying to
        convey that the footprint in question is the amount of hacking
        around the guest's MM layer which is needed)
        
        Put a bullet "* Enable with pvh=1 in your config"? (likewise for
        each of these new things where such an option exists?)

"Tech Preview of Nested Virtualization"

        "provides... to *HVM* guests"

        The use of "Xen Project" on this slide seems out of
        context/clumsy. If plain "Xen" is not acceptable then perhaps
        "Xen Hypervisor"?

        Enable with "hap=1" and "nestedhvm=1"
        
"GRUB 2 Support of Xen Project PV Images"

        This is delivered by a grub release (I think it is in 2.02-beta,
        but 2.02 final isn't out yet)
        
        Not actually a Xen 4.4 feature. Not to say it isn't worth
        mentioning. AIUI it should work with older Xen too though.

"Improved ARM Support (2)"

        "Same DMA support". Should be "Some DMA Support" or "Sane..." or
        "Dom0 DMA support"? The implications of this stuff are that
        things work/don't crash ;-)
        
        on (3) The Allwinner processors are A20/A31 not A20/A30.

Ian.


[-- Attachment #2: Xen Project 4-4 Features and Futures.pdf --]
[-- Type: application/pdf, Size: 579573 bytes --]

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: 4.4 Release Talk Slides

[Mukesh Rathor]

On Wed, 19 Mar 2014 01:26:53 +0000
Russell Pavlicek <russell.pavlicek@citrix.com> wrote:

> Folks,
> 
> I am giving my first 4.4 release talk at the Linux Foundation
> Collaboration Summit next week and I am trying to do the release
> justice.  I am trying to work up a decent deck of features and
> futures.


Hi Russell,

JFYI... I'll be giving PVH talk on thurs at 3pm, right before you.

Will see you there. If anybody else from here will be there, please look
me up, I would like to say hi.

Mukesh

Re: 4.4 Release Talk Slides

[Russell Pavlicek]

Mukesh,

Absolutely!  I'd love to touch base.  I intend to be at your session as it is.

There are actually four different Xen Project sessions during that day, so it should afford us opportunity to say hello to other Xen Project folks as well.

Russ Pavlicek
Xen Project Evangelist, Citrix Systems
Home Office: +1-301-829-5327
Mobile: +1-240-397-0199
UK VoIP: +44 1223 852 894


-----Original Message-----
From: Mukesh Rathor [mailto:mukesh.rathor@oracle.com] 
Sent: Thursday, March 20, 2014 6:11 PM
To: Russell Pavlicek
Cc: xen-devel (xen-devel@lists.xenproject.org)
Subject: Re: [Xen-devel] 4.4 Release Talk Slides

On Wed, 19 Mar 2014 01:26:53 +0000
Russell Pavlicek <russell.pavlicek@citrix.com> wrote:

> Folks,
> 
> I am giving my first 4.4 release talk at the Linux Foundation 
> Collaboration Summit next week and I am trying to do the release 
> justice.  I am trying to work up a decent deck of features and 
> futures.


Hi Russell,

JFYI... I'll be giving PVH talk on thurs at 3pm, right before you.

Will see you there. If anybody else from here will be there, please look me up, I would like to say hi.

Mukesh

Re: 4.4 Release Talk Slides

[George Dunlap]

On Thu, Mar 20, 2014 at 3:36 AM, Russell Pavlicek
<russell.pavlicek@citrix.com> wrote:
> Here's the latest version.

Re "Improved flexibility for driver domains": I think the bottom line
is that before some functionality available for block devices in dom0
wasn't supported in Linux driver domains, and some functionality
supported in Linux driver domains wasn't supported in non-Linux driver
domains.  Now all dom0 functionality is supported in any kind of
driver domain.  Maybe "Disk driver domains are now feature complete"
might be a stronger wording?

Re event channel scalability: This is also important with VDI
deployments (which also typically have a high VM density).

Re nested virt -- not sure if these need to be on the slides, but you
should know them if you get asked:
 * Only 64-bit hypervisors are supported; which means, "XP
compatibility mode" is only supported on 64-bit Win7; on 32-bit Win7
nested virt won't work.  (This should be on the wiki page.)
 * The main reason nested-virt is still "tech preview" is that the L1
admin can do things (like PoD, memory sharing, &c) which may lock up
the host (L0).  If you trust your L1 guest admins, you should be able
to use it.

That's all I've got -- looks good overall. :-)

 -George

Re: 4.4 Release Talk Slides

[Russell Pavlicek]

George,

Thanks.  I've modified the deck accordingly.

Russ Pavlicek
Xen Project Evangelist, Citrix Systems
Home Office: +1-301-829-5327
Mobile: +1-240-397-0199
UK VoIP: +44 1223 852 894
________________________________________
From: dunlapg@gmail.com [dunlapg@gmail.com] on behalf of George Dunlap [dunlapg@umich.edu]
Sent: Monday, March 24, 2014 8:43 AM
To: Russell Pavlicek
Cc: Ian Campbell; xen-devel (xen-devel@lists.xenproject.org)
Subject: Re: [Xen-devel] 4.4 Release Talk Slides

On Thu, Mar 20, 2014 at 3:36 AM, Russell Pavlicek
<russell.pavlicek@citrix.com> wrote:
> Here's the latest version.

Re "Improved flexibility for driver domains": I think the bottom line
is that before some functionality available for block devices in dom0
wasn't supported in Linux driver domains, and some functionality
supported in Linux driver domains wasn't supported in non-Linux driver
domains.  Now all dom0 functionality is supported in any kind of
driver domain.  Maybe "Disk driver domains are now feature complete"
might be a stronger wording?

Re event channel scalability: This is also important with VDI
deployments (which also typically have a high VM density).

Re nested virt -- not sure if these need to be on the slides, but you
should know them if you get asked:
 * Only 64-bit hypervisors are supported; which means, "XP
compatibility mode" is only supported on 64-bit Win7; on 32-bit Win7
nested virt won't work.  (This should be on the wiki page.)
 * The main reason nested-virt is still "tech preview" is that the L1
admin can do things (like PoD, memory sharing, &c) which may lock up
the host (L0).  If you trust your L1 guest admins, you should be able
to use it.

That's all I've got -- looks good overall. :-)

 -George