On Mon, Sep 05, 2011 at 12:20:57PM +0300, Dan Kenigsberg wrote:
On Sun, Sep 04, 2011 at 03:16:08PM -0400, Ayal Baron wrote:
Once we get rid of "master domain" and "SPM", each domain can have its own are for storing small files (e.g. VM definition file).
A VM definition should be stored on only one domain (true for both RHEVM use case and any other use case) and if the VM has disks spanning multiple domains then management/user needs to decide which domain will hold this info (e.g. where the system disk is, or first domain which had a disk in it or whatever).
wrt Dan's comment, vdsm should have visibility to all the resources needed to run a VM. This means that if vdsm is to run VM-X which has disks on storage domain A and SD B then vdsm should be connected to both domains (same applies to networks). vdsm could locally cache storage and networking info so that when the VM references a storage or a network, we could automatically connect/configure whatever we need.
The "data-center-wide" bit is totally irrelevant as the storage is shared so as long as vdsm can access the domain, it's fine.
It is relevant. For example, we do not want two Vdsms creating different VMs with the same name or vmId. Your suggested scheme, where each Vdsm persists VM metadata on a storage domain that it sees, may lead to that.
I think this point underscores one of the differences between a RHEV-m managed environment and the stand-alone environment I am working on. In a RHEV-m data center, the manager must ensure that a VM can run on any host in the cluster. Therefore, it must prevent naming conflicts of the nature you are describing. In the standalone scenario, each host must be a completely independent entity with autonomy to create VMs as it sees fit. As a trade-off of that independence, there could be conflicts (or unavailable resources) during migration that can cause a fatal error. I would consider this to be perfectly normal in the standalone environment. An operator of a federated vdsm environment (two independent vdsm instances with migration capability) must be careful to choose unique vm names and ensure that shared storage is properly connected.
Only issue that needs to be resolved is how different nodes get the networking/storage connections info localized in the first place (obviously we can save whatever we see when a VM is run, but other vdsms are expected to know this info regardless. I believe this indeed would be the job of another layer, because vdsm as you say is single node and *this* operation is migration cluster wide.
This is also why I am reluctant to add VM database into Vdsm - I think it belongs to a higher level. Handling the removal of a defined VM on migration success seems very hard to do right - imagine destination crash just in the worst time. We need a distributed database for that.
Single node use case is very important, though. I would love to see a Vdsm sub-package that maintains a database of VM domains, as well of all other inter-node information.
No reason for this to be a separate DB and not just a local storage domain.
The DB may be a mere directory. But it has to be ONE.
I think ONE per VDSM is okay (as long as we check for conflicts when importing VMs from another instance).