voted

VirtIO would definitely be nice since it looks like the VPS's are reporting as KVM or HVM with QEMU last I checked. Would love to see this as a standard option.

I wonder why virtio is not used, is it the choice of kernel on the guests? It seems to be the official KVM way.

It only depends on what parameters they use to kvm and at the moment they're not configurable and are unfortunately set to emulate realtek and IDE. I'm hoping they make this configurable so we can choose virtio. Linux guests are not a problem as virtio is supported in 2.6.30 and after if I remember correctly.

@Moisey any comments on this, 133 votes is not bad :).

We've deployed virtio as a Labs (Beta) feature for older customers where they can set it during a new droplet create.

We are going to run with that for a few days and see if there are any odd issues we run into with virtual servers failing to ping after creation and then roll that out to older customers again to reset their running virtual servers to virtio.

If all of the testing looks good from there then we will continue to roll out more support for more customers for virtio.

Thanks

Guys,

I have some preliminary benchmark result using hdparm and bonnie++.

https://gist.github.com/kenn/4741999 - without virtio
https://gist.github.com/kenn/4742470 - with virtio

Highlights:

- Sequential block writes: Comparable
- Sequential block reads: 2x faster in block reads, CPU is nearing saturation
- Random Seeks: 1.5x faster, but CPU usage is 29% vs 80% - Virtio is much lighter
- Sequential file creates: 2x faster
- Sequential file reads: both are too fast to measure. :)
- Sequential file deletes: 1.5x faster
- Random file creates: 1.5x faster
- Random file reads: too fast :)
- Random file deletes: 1.5x faster
- Latency: No notable difference in any tests

Everything looks better with Virtio, clearly a big win.

@Moisey Thanks for this, will reinstall a droplet with virtio once the custom images feature is ready.

@Kenn Thanks for the benchmark, this is quite useful.

Upvote!

this looks interesting... virtio is definitely the way to go.

I wonder how far this is from being available. It is almost a month from the Moiseys comment, so it might be not that far. If it would be only a week or so, I'd rather wait for it to be completed before moving in here. Any testers needed?

Just open a ticket if you dont see if in your create droplets page and we'll verify you and you'll have access to it.

Is it possible to use VirtIO on existing Arch droplet?

We have not added this functionality to the front-end but you can request virtIO to be enabled on a running droplet by opening a ticket for the time being.

Thanks!

Are your hosts using vhost-net (and your kvm configured to use it?)

virtio network and virtio disk was design for virtual machine, I use it when creating vm on smartdata center.

Given that you are evaluating virtio-net, have you looked at vhost-net for acceleration of the virtio-net driver in the host kernel? Definitely worth looking at, though looks to me like qemu might go with virtio-net with data plane (to match the virtio-blk+dataplane that went in to qemu 1.4).

This is enabled on my droplet right now and I can tell everyone that the network reliability is much higher now. Before I could download a test 100MB file at about 13 MB/s but when doing a speed test through my VPN server I would only get a reading of about 3 - 5 Mbit connection speed.

After my droplet has Virtio enabled I have seen my 100MB test file download much much faster. I actually just did a test and it downloaded at 38.9M/s and when I run a speedtest through speedtest.net I get connection speed readouts of 30 - 50 Mbit.

Thumbs up from me :D Good work D.O, much more stable experience now.

We have enabled VirtIO for default on all creates both via the CP and the API.

We've also added documentation to the API on how to enable/disable this during creates.

Marking as completed. =]

Is there a way to tell from within the guest whether you're using virtio?