A Fault Tolerant VirtualizationServer Based on Xen

Jürgen GroßVirtualization Kernel Developer

SUSE Linux GmbH, jgross@suse.com

Status Quo

3

Standard Xen Virtualization Server

SANLAN

dom0

Hypervisor

HVM pv

xenstore qemuBlock-

backendNet-

backend

4

Single Points of Failure in Xen Server

• Hypervisor

• Dom0

• Xenstore

• pv-Backends

• LAN/SAN peripherals in case of single path

5

Standard Xen Virtualization Server

SANLAN

dom0

Hypervisor

HVM pv

xenstore qemuBlock-

backendNet-

backend

6

Kinds of Failures

• Software errors (crashes, hangups)

• Fatal Hardware errors

• Non-fatal Hardware errors triggering software errors

• Planned downtimes due to software updates

• Planned downtimes due to hardware maintenance

Eliminating Single Points of Failure

8

Xen Server Today

SANLAN

dom0

Hypervisor

HVM pv

xenstore qemuBlock-

backendNet-

backend

9

Use Multipathing

• LAN and SAN resources still accessible in case of path failure

• Dom0 does multipathing for domUs

10

Use Multipathing

SANLAN

dom0

Hypervisor

HVM pv

xenstore qemuBlock-

backendNet-

backend

11

Move Xenstore Into Own Domain

• Mandatory step for eliminating dom0 being single point of failure

• Xenstore is still single point of failure, but dom0 high load won't slow it down any more

12

Move Xenstore Into Own Domain

SANLAN

dom0

Hypervisor

HVM pvxenstore

qemuBlock-

backendNet-

backend

13

Create Driver Domains

• LAN‒ One per interface card

‒ Multipathing done in guests

‒ Net-backend no longer single point of failure

‒ Driver domain can act as a managed switch

• Block‒ Multipathing still done in backend

‒ Further decoupling from dom0

14

Create Driver DomainsLAN: one per interface adapter

SANLAN

dom0

Hypervisor

HVM pvxenstore

qemu

Net-back

Block-back

Net-back

15

Introduce pv-SAN Backend

• Now one driver domain per interface card

• Multipathing done in guests

• Block-backend no longer a single point of failure

• In case of SAN topology aware guests PCI-passthrough of FC-cards to guest no longer necessary

• Driver domain acts as a SAN switch

16

Introduce pv-SAN Backendone per interface adapter

SANLAN

dom0

Hypervisor

HVM pvxenstore

qemu

SAN-back

Net-back

SAN-back

Net-back

17

Use Stub Domains for HVM domUs

SANLAN

dom0

Hypervisor

HVM pvxenstore stub

qemu

SAN-back

Net-back

SAN-back

Net-back

18

Make dom0 Restartable

SANLAN

dom0

Hypervisor

HVM pvxenstore stub

qemu

SAN-back

Net-back

SAN-back

Net-back

How to Reach This Goal?

20

TODO: Verification, Configuration

• Xenstore domain

• LAN driver domain

• Block driver domain

• Stub domains for HVM

21

TODO: Implementation

• Dom0 restart

• SAN pv backend

• Tooling for automatic creation of driver domains for each interface card

• Tooling for automatic restart of crashed infrastructure domains (dom0, driver domains)

• Support for software updates of infrastructure domains

• Support for hotplug of interface cards

• Support for live migration

Thank you.

22

Who is interested?

SUSE: ✔

23