Citrix XenServer - the end of the story

Today's post should have been 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, such as DomU snapshots, disk storages are clogged with incomprehensible “base copies” and with time the place ends completely. My inquiring mind still found out the reason for such inconvenience.


How ordinary snapshot systems work: LVM, ZFS (there’s generally a separate song, but the principle is the same) and others

• We have a disk at the moment (Dcurrent_real), we ordered snapshot. Snapshot is created instantly because
• Snapshot (delta) is designed to keep changes that have occurred since its creation.
• At the same time, only the Dcurrent_real disk physically exists, and somewhere there it is written delta
• The disk at the time of 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 not necessary

How do those designed by amateurs of Lord Govinda theirs work, snapshots in XenServer

• We order Dcurrent_real disk snapshot. From this point on, it simply ceases to exist because it is renamed into that very 'base copy'
• Snapshot (delta) is also intended 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 one.
• At the same time, there is physically a Dpast_real disk (the same base copy) + spelling delta.
• The disk at the time of snapshot is there 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 by and large the system still has to climb for the data in delta in both cases for writing, and for reading, we can read it from the delta or from the base copy, in fact, it’s all the same.
• But the question arises what to actually do with the delta - we can not kill him because Dcurrent_virtual will simply cease to exist. And he lives, works and gives the world data through DomU.
• Having come to their senses, friends release the coalesce-leaf tulzu, which is designed to alleviate suffering, at least temporarily, by combining Dpast_real and delta, but for this you need to minimally send DomU to suspend or even turn it off. As well as scratching a turnip in terms of how to find it all the same.

But why? After all, LVM supports the very right snapshots ... And all because the friends' tendency is this: gradually transfer XenServer users to Hyper-V. What got into Citrix will soon get into M $, everyone has known this for a long time. As a result, the disks first changed the format to Microsoft VHD and then there were tips that these disks should be stored on the local file repository as files rather than as LVM partitions. Apparently it was easier to copy in Hyper-V. As a result of such a scheme, it was necessary to implement a system of snapshots on storages in the form of files, and since there was nothing ready, the inquiring mind suggested option number 2 - dibilny.

At this point, the story ends and the transition to Solaris XVM begins, for which I even bought a caliper plan for a trial, I will keep the consequences in mind. In fact, except for bug 6882364, which I constantly stumble upon, XVM is stable and quite ready for production. Thanks for attention.
')
ps and if India were not a colony of Britain, it could have been very different ...