I want to understand how the IO is sent to hard disk blocks from a virtual machine.
Does having a XFS or ext3 or ext4 etc. really matters inside a virtual machine, or it is just depended on the file system of the host machine?
What's the impact on IO when compared to Virtual machine and a physical machine?
The following are just my assumptions based on what I know. Please correct me if I'm wrong:
Let's say I am using a RAW image!
Example 1: Preallocation=full (Virtual Size = Disk Size)
- If I understood correctly, the disk blocks that would be used for Virtual machine are pre-allocated in this mode, and filled with Zeroes for unused data.
- And once a Guest OS is installed on that Raw disk, all these physical disk blocks are mapped to a virtual disk blocks (hard coded maps?).
- And any IO request made inside a virtual machine, the Guest OS kernel first processes it and sends a request to the virtual disk and that request is taken care by some kind of virtual abstraction service (I am guessing libvirtd) and is sent to hard disk controller. But what I don't get here is if the physical disk blocks are preallocted, the IO request should contain all the block addresses or the block maps so that the data is written only in one of those disk blocks. But how does such kind of an IO request is made to the hard disk controller and it seems really a major performance issue.
In this example, I completely excluded the filesystem of the host machine. I couldn't find a way to relate it.
Again all of this above is my giant assumption. I feel I am really wrong about the above idea. But I am hoping someone will correct me.
Example 2: preallocation=off (Disk Size = Actual usage)
- The disk blocks for Virtual Machine are not pre-allocated and are only allocated on actual disk usage.
- The same steps in example 1 applies here until the IO request is made to Hard disk controller, but here no need to request for specific blocks to be overwritten, as no preallocation is done here.
So, going back to my actual question. It seems the filesytem on virtual machine will do have an impact, as all the calls to IO are initiated from Guest OS kernel and later.
Huhhh confused!!!! :(
You can reach the block device with or without the filesystem. You can do:
and you can do:
Virtualisation systems do exactly the same. You can configure them to simulate the guest hard disk using the raw partition or some file. In the first case the host's file system doesn't matter, because actually there will be no filesystem. In the second case the filesystem you choose will have (minor) effect.
I think you are mostly concerned about this second way, so let's concentrate on this. File based virtualised "hard-disks" are just files. They can be simple raw files (you will see exactly the same bits in them as you would find if you cat a real hard disk) and they can be special format files with header info or even compression (like qcow). Anyhow they are just files.
Of course the underlying (host) filesystem does matter, because it hosts that big file. Some (most modern) filesystems can handle sparse files. Some do better job handling/deleting big files like XFS. Some can spread your files over the network like GlusterFS. In fact, you can have several layers of them. From the virtualisation system's point of view, the whole thing is transparent, it just need the file.
Access to physical device blocks on your hard disk can be very well abstracted. At the extreme you may want to build a RAID-array from physical disks, create an LVM volume on that RAID device, then create a new LVM partition on which you make an XFS filesystem, from which you make a GlusterFS network filesystem (along with some similar setup on other machines). Let's suppose you create a virtual machine which uses a qcow file located on this glusterFS. Disk writes on the ext4 filesystem created in you virtual machine will be propagated all over the layers. The guest kernel's disk IO will be translated to file writes by the virtualisation layer, which in turn processed by gluster, then by the XFS, LVM and the raid. Of course this will introduce some overhead and certainly slower than direct access.
You can easily simulate what the virtualisation does in case of raw files. Create a big file with dd, create partition on it, make a filesystem on that partition. You will have a "hard-disk" which is a file. You can now mount that filesystem, copy the OS, unmount, and start a virtual machine using your file as a disk! (You will have to boot from other device like virtual CD, or you have to install grub at the start of your disk-file, though).