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
- Custom ISO creation (Offline)
- 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, …
- Stock Anaconda provides all we need
- 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
- Prosa
- CI
- http://jenkins.ovirt.org/job/ovirt-node-ng_master_build-artifacts-fc22-x86_64/
oVirt Node 4.0 (Next)
By Fabian Deutsch
