oVirt Node 4.0 (Next)
A small introduction and overview
What is oVirt Node?
oVirt's Hypervisor OS for 8+ years
Minimal ready to use OS image
Appliance like
Installation/upgrade
Custom Installer TUI & Setup TUI
Easy to deploy, manage and upgrade
Known Issues
Installation
Limited
Different to use than Fedora/CentOS
Administration (TUI)
Limited (i.e. single NIC)
Showing its age
Known Issues
Customization
Custom ISO creation (Offline)
Adding 3rd party drivers is very limited
RPM installation at runtime (Online)
Adding 3rd party rpms is not possible
Hardware support
Affected by blacklisting
Root Causes
Read-only rootfs
Requires an intermediate persistency layer which is not transparent to applications
Requires custom SELinux rules
Blacklisting for minimiztaion
Specialized installer and administration UI
Goals
Align with Fedora/CentOS
wrt Installation, Administration, basic OS behavior
Retain a simple "appliance like" structure
Modernize how to interact with RHEV-H
Better customization
Under research: Configuration management friendly
Node Next
Core Changes
Adopt Anaconda for installation
Adopt Cockpit for administration
Provide a writable file-system
Installation
Let’s re-use Anaconda
Stock Anaconda provides all we need
EFI, iSCSI, multipath, kickstart support, …
New delivery format and storage layout
Small changes in the delivery format and storage layout to align with Anaconda’s capabilities
Different image format, delivered to the host through yum/RHN (not through Engine anymore)
Storage
Enforce a specific LVM usage pattern (imgbase)
Thinpool to hold read-only images
Writable snapshots for each image
One boot entry is auto-created for each snapshot
Special: /boot, /etc, and /var [1, 2]
Storage Layout
Storage implications
yum and rpm just work
But: Package database is reset between updates
Not recommended
The system can be configured like Fedora/CentOS
I.e.: Kernel tuning using sysctl, Custom boot arguments, …
Updates need special handling: Changes outside of /etc, /boot and /var need to be re-applied
Configuration management (ansible, puppet)
Upgrade
`yum update`
Delivery: Image in rpm through yum repositories
imgbased
Separates delivery image delivery from host-upgrade
Add image + snapshot + boot entry + sync
Sync /etc between snapshots
Number of upgrades is limited by disk size
Rollback: Select old entry, boot into old image
Special Paths
/boot
Not on LVM as grub2 can’t boot from thin snapshots
/etc
Synced from snapshot to the next
Upgrade and rollback are an easy A/B procedure
/var
Only moving forward
Local Administration
Move to Cockpit
Already available in Fedora/CentOS
Covers general OS aspects
Node specific functionality is added
Monitoring
Self Hosted-Engine Setup (planned)
Cockpit?
A modern web interface to system information and configuration
Available on CentOS, and Fedora
Advantages of Cockpit
Already supports many of the things the legacy TUI used to
Easy to use. Intuitive.
Well-architected and extensible.
Current gaps in Cockpit
Support for some legacy TUI options: kdump, SNMP. RFEs filed
Configuration is less “up-front” than SSH or console login into legacy. Use of a web browser is necessary
However, SSH can be used if needed
Summary: The bright side
Better alignment with Fedora/CentOS
Improved hardware support
Better usability
Easier customization
Improved CVE handling
Individual package updates for very urgent CVEs (planned)
Summary: Compromises
Slightly larger on-disk footprint
Still large updates (whole image, no delta)
Not decided if an Installation ISO will be provided
But: Is possible for offline installation
Kickstart needs to be created manually
Semi-automated with script
Links
Sources
https://gerrit.ovirt.org/gitweb?p=ovirt-node-ng.git;a=tree
https://gerrit.ovirt.org/gitweb?p=imgbased.git;a=tree
Prosa
http://dummdida.tumblr.com/tagged/node
CI
http://jenkins.ovirt.org/job/ovirt-node-ng_master_build-artifacts-fc22-x86_64/
Made with Slides.com