See the project Wiki for more technical how to.
All Cloudius OSv binaries collect and send data at each boot
We do this to collect usage metrics in order to allocate resources correctly.
If you build OSv from source, the monitoring agent is not enabled by default.
Monitoring message at boot
At boot time, the following message will be written to OSv dmesg log file:
This version of OSv will send a report each time it is booted to Cloudius Systems. For more on information collected, how and why it is stored, and how to disable reporting, see osv.io/osv-stat
A randomly generated UUID for each boot
Operating system name, always “OSv” (
Free memory at boot time
Command run at boot (
Processor count, if available
JVM version (if installed)
You can disable the monitoring system in cloud-init, starting with OSv version 0.15 beta. Use this configuration:
monitor-agent: enable: false
You can also build OSv from source yourself
Use the public mailing list for questions.
NewRelic on OSv
By Tzach Livyatan
New Relic is a popular real-time monitoring service for Web and mobile applications.
In the following post I will describe how to add a New Relic monitoring agent to your OSv virtual appliance, using Tomcat as an example.
Jolokia JMX connectivity in OSv
By Calle Wilund
OSv is a great way to run Java applications in the cloud, and it recently became just a little bit better. As you are probably aware, OSv exposes quite a bit of information and manageability options through its RESTful API, accessible through the built-in HTTP server. More or less from its inception, this API has exposed various aspects of the JVM and the Java Management Beans provided.
Designing an OS to run specifically as a cloud guest doesn’t just mean stripping out features. There are some other important problems with running virtualized that a conventional guest OS doesn’t address. In this post we’ll cover one of them.
NFV projects: extreme challenges for the guest OS
Network Function Virtualization (NFV) is the process of replacing dedicated network devices with virtual machines. Enterprise network managers and network operators are adopting NFV for several compelling reasons.
Reduce time to deploy and operator agility
Reduce capex by eliminating dedicated hardware
Reduce opex by reducing power requirements
However, NFV creates difficult latency and throughput requirements for the guest OS, and developers and integrators of NFV products will need a new generation of OS and infrastructure software to meet the demands of tomorrow’s network.
OSV has a unique set of features which makes it ideal for NFV products.
- Van Jacobson style network stack
- Minimal administration, without local config files
- Spinlock-free design
The cloud design allows OSv to simplify the stack, both looking down (towards the hardware) and looking up (towards the application).
limited hardware support: Xen, KVM, and Vmware. This dramatically simplifies the I/O stack.
optimized for running on top of a hypervisor
runs a single application and cooperates with it
Assimilate into the run time such as the Java Virtual Machine (JVM)
ISVs who offer a packaged application as a virtual machine image can benefit in several ways from releasing on OSv. The VM images for OSv-based virtual appliances are small, often only 12-20MB larger than the application itself. And the ISV does not need to maintain and support the large set of software and configuration required by even the simplest guest images on other platforms.
Network functions virtualization
Virtualizing network devices requires extreme low latency and high network throughput. OSv, with its Network Channels-based network stack, removes bottlenecks at the guest OS level.
Java application server
The user can upload an application WAR file, via a REST API, and the application runs without further configuration. The deployment process can be connected to a continuous integration system or IDE.
C and C++-based applications
Several C and C++ applications have been ported by OSV developers or third parties. Porting additional applications often requires only a two-line Makefile change. OSv can use unmodified shared libraries built on and for Linux. The images containing these applications can be downloaded and deployed as needed, with lower overhead than on legacy guest OSs.
OSv’s sub-second boot time makes it ideal for NoSQL and other applications requiring horizontal scaling or failover. It is often faster to boot a fresh OSv guest than to fail over to an already-running guest.
Management usage and API
OSv places all management endpoints in a single location: a simple, documented REST API. All management operations can be done using your chosen management tools, or your own scripts, over HTTP.
An optional in-browser dashboard is available. The dashboard provides live updates and includes:
OS basics such as memory usage and CPU load
Tracepoints for all system and application functionality
JMX endpoints (using the Jolokia JMX-over-REST connector)
Application-specific metrics, which can be added by the application developer.
REST API details
On a cloud environment of multiple instances, it is inefficient to interact with each instance using a conventional GUI or CLI designed for hardware servers. The OSv REST API simplifies management.
The latest version of the REST API specification
Details on how to interact with OSV using the API are in a Wiki article: OSv REST API.
The cloud-init mechanism provides a simple way to provide per-instance configuration parameters to an OSv VM at boot time. It is useful for booting many clustered instances of a horizontally scaled application such as a NoSQL database.
OSv cloud-init works the same way across public and private clouds, so a cloud-init configuration developed in-house will work anywhere you choose to deploy—perfect for hybrid cloud environments.
OSv is supported on the following Hypervisors
OSv differs from traditional systems in two respects:
First, OSv doesn’t have multiple address spaces. In an ordinary system, virtual address 0x200000 may be mapped to different physical pages (or the same page, sometimes, or to no page), depending on the process. In OSv an address is mapped to just one page. This means we don’t have to switch mappings when the processor stops running one process and starts running another.
The second difference is that OSv doesn’t maintain different permissions for the application and kernel. In a typical multiuser system, the kernel does not allow the the application to access kernel pages. This means it has to switch privilege levels when running kernel code, then switch back. OSv does not do this (expensive) switch; instead it relies on the hypervisor to protect applications from each other.
Redis on Amazon EC2
Redis is a simple service that fills a valuable niche between a key-value data store and a full-scale NoSQL database such as Cassandra. Redis supports not just key-value items, but also more advanced data structures such as sets and queues.
The following benchmark compares Redis (version beta-8) on OSv and on Ubuntu 14 AMI. To do that, we have just launched a new AMI, selected Ubuntu14.04, and launched it. We use the configuration file shipped with Redis by default, with one change: we disable disk activity.
On Ubuntu, Redis was run with:
numactl --physcpubind=1 redis-server ~/redis.conf
Using numactl considerably reduces the standard deviation as a result of Linux scheduling. The redis-benchmark command was run from another machine of the same type, running in the same zone and placement group.
Memcached is a popular in-memory key-value store. It is used by many high-profile Web sites to cache results of database queries and prepared page sections, to significantly boost site performance.
An unmodified memcached running on OSV was able to handle about 20% more requests per second than the same memcached version on Linux. A modified memcached, designed to use OSV-specific network APIs, had nearly four times the throughput.
Frequently asked questions
Why a new operating system?
Operating systems have evolved over decades to perform two distinct functions: manage the hardware, and provide isolation between the multiple applications and user running on the system.
However, in modern deployments, the hardware is virtualized, so there is very little for the operating system to manage. In addition, common deployment scenarios have one application per server, leaving the the isolation capabilities of the OS unutilized.