what is the difference between /dev/vda and /dev/sda

Question

I am preparing for a certification and have a locally installed CentOS7 (VirtualBox) and another instance in a cloud-based service.

On the local system I have a /dev/sda and on the cloud-based i have a /dev/vda.

Now I am wondering what this difference exactly means? Is there a standard (documentation?) for the naming of this devices, and what the different names stand for?

Edit:

I think this document is very useful to understand the naming: https://www.kernel.org/doc/Documentation/admin-guide/devices.txt

8 block SCSI disk devices (0-15)
      0 = /dev/sda      First SCSI disk whole disk
     16 = /dev/sdb      Second SCSI disk whole disk
     32 = /dev/sdc      Third SCSI disk whole disk
        ...
    240 = /dev/sdp      Sixteenth SCSI disk whole disk

But I could not find some information about /dev/vda.

Answer 1

Full Virtualization vs. Paravirtualization

/dev/sda is the first detected disk of IDE/SATA/SCSI type. In this case, emulated(full virtualized) by the hypervisor.

/dev/vda is the first detected paravirtualizated disk driver. It is faster than emulated sdX devices if both are referred to the same disk, because there are less overhead in its operation compared to an emulated drive.

References:

---

From http://www.ibm.com/developerworks/library/l-virtio/:

Full virtualization vs. paravirtualization

Let's start with a quick discussion of two distinct types of virtualization schemes: full virtualization and paravirtualization. In full virtualization, the guest operating system runs on top of a hypervisor that sits on the bare metal. The guest is unaware that it is being virtualized and requires no changes to work in this configuration. Conversely, in paravirtualization, the guest operating system is not only aware that it is running on a hypervisor but includes code to make guest-to-hypervisor transitions more efficient.

In the full virtualization scheme, the hypervisor must emulate device hardware, which is emulating at the lowest level of the conversation (for example, to a network driver). Although the emulation is clean at this abstraction, it's also the most inefficient and highly complicated. In the paravirtualization scheme, the guest and the hypervisor can work cooperatively to make this emulation efficient. The downside to the paravirtualization approach is that the operating system is aware that it's being virtualized and requires modifications to work.

From http://www.carfax.org.uk/docs/qemu-virtio:

What are paravirtual devices?

When running a virtual machine, the virtual environment has to present devices to the guest OS – disks and network being the main two (plus video, USB, timers, and others). Effectively, this is the hardware that the VM guest sees.

Now, if the guest is to be kept entirely ignorant of the fact that it is virtualised, this means that the host must emulate some kind of real hardware. This is quite slow (particularly for network devices), and is the major cause of reduced performance in virtual machines.

However, if you are willing to let the guest OS know that it's in a virtual environment, it is possible to avoid the overheads of emulating much of the real hardware, and use a far more direct path to handle devices inside the VM. This approach is called paravirtualisation. In this case, the guest OS needs a particular driver installed which talks to the paravirtual device. Under Linux, this interface has been standardised, and is referred to as the "virtio" interface.