Citrix XenServer - End of Story

Today's post was supposed to be about a review of the Solaris COMSTAR architecture and examples of its work for building the FC-target. However, you need to put an end to the story with a product like XenServer. Start here , here and here . Summary for those who are too lazy to click on the links - for certain operations, for example, DomU snapshots, disk storages are cluttered with incomprehensible “base copies” and eventually the place runs out completely. My inquiring mind still found out the reason for this inconvenience.


How ordinary snapshot systems work: LVM, ZFS (here, in general, a separate song is true but the principle is the same) and others

• We have a disk at the moment (Dcurrent_real), we ordered a snapshot. A snapshot is instantly created.
• Snapshot (delta) is designed to store changes that have occurred since its inception.
• In this case, physically there is only the Dcurrent_real disc, well, somewhere delta is written there
• The disk at the time of the snapshot is obtained according to the scheme DpastVirtual = Dcurrent_real - delta
• Accordingly, since we have Dcurrent_real and it is real, delta, we can crash as soon as it is no longer necessary

How do the gentlemen of Govinda theirs designed by lovers, snapshots in XenServer

• We order a snapshot of the Dcurrent_real disc. From now on, it simply ceases to exist because it is renamed to the same 'base copy'
• Snapshot (delta) is also called to store changes, but changes in diametrically opposite time, i.e. not from the current state of the disk to the past, but from the past state to the current.
• In this case, physically there is a Dpast_real disk (the same base copy) + a snapshot of delta is written.
• There is a disk at the time of the snapshot right away - here it is, Dpast_real. But the disk is currently obtained by combining Dcurrent_virtual = Dpast_real + delta.
• In fact, in practice this does not slow down much, since the system by and large still has to climb over the data in delta in both cases for writing, and for reading - to figure out whether to read from delta or from base copy, in fact, it doesn’t matter.
• But the question arises of what exactly to do with delta - we cannot kill him because Dcurrent_virtual just ceases to exist. And he lives, works and gives the world data through DomU.
• Recollecting themselves, friends release the coalesce-leaf tool, which is designed to at least temporarily alleviate suffering by combining Dpast_real and delta, however, for this you need to send DomU to suspend at least or even turn it off. And they also scratch turnips in terms of how to find it all the same.

But why? After all, LVM supports the very correct snapshots ... And all because the trend with friends is this: gradually switch XenServer users to Hyper-V. What got into Citrix will soon fall into M $, everyone has long known this. As a result, at first the disks changed the format to Microsoft VHD and then there were tips that it was better to store these disks on the local file repository as files and not as LVM partitions. Apparently to make it easier to copy to Hyper-V. As a result of such a scheme, it was necessary to implement a snapshot system on storages in the form of files, and since there was nothing ready, an inquiring mind proposed option No. 2 - dibilny.

This is the end of the story and the transition to Solaris XVM begins, for which I even bought a support plan for testing, I will keep you informed about the consequences. In fact, except for bug 6882364, which I constantly stumble upon, XVM is stable and quite ready for production. Thanks for attention.

ps but if India had not been a colony of Britain, everything could have been completely different ...