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.
+1 to the caching of storage and networking info. This is the subject of another proposal I am working on. Right now, if I can remember the Storage Pool UUID that I was last using, I can recall all of the storage domains that were associated with it. Once I have these UUIDs, I can reconnect all of my storage again. I do want to make sure that once storage pools and the SPM go away, I will still have a means to recall my configured storage domains.
All connections info would be stored locally so no problem reaching domains, there is no conceptual difference between the 2.
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.
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.
Could you elaborate on what info for storage domains and networks must be localized? I would assume that for storage domains, there is the UUID and connection information. For networks, there is also a UUID and/or bridge name. Are these the only pieces of information?
Wrt network info, I just realized it doesn't need to be stored locally. Whenever we store VM info on a domain, we can check what networks it requires and store the networking info on the domain (separately as many VMs will share the same networking info, no need to duplicate).
If so, migration could work between two federated VDSM systems so long as a few rules were adhered to:
- Shared storage is connected to both instances and accessed using the
same UUID.
- Equivalent networks share the same name and UUIDs.
Indeed.
For now, my standalone web interface could rely on these rules being followed as a matter of convention. In the future, logic could be added to the storage domain connection process whereby a previously initialized SD could tell the API user what its existing UUID is. Then, as new vdsm instances discover the shared storage, they will all access it via the same UUID.
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.
To be clear, you are suggesting that we could store this metadata on an existing DATA Storage Domain, right? In that case I agree. There is no need to create a new type of storage domain (META) whose exclusive purpose would be the storage of this type of information.
Correct. But it's not straightforward, it requires a new feature for existing domains (we've been discussing this for a long time).
-- Adam Litke agl@us.ibm.com IBM Linux Technology Center _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel