A rather general answer. Traditionally the View in MVC would request the information it needs from the Model, and the Model knows nothing about the View. Data binding (very popular in Microsoft UIs) ties the View quite closely to the underlying Model, which conflicts with the traditional MVC.
So the solution is to have one model for the view to bind to and a different model which really is the Model. These are the View Model and Domain Model.
To your questions: The relationship between them is that the VM knows about the DM, not vice versa, and the VM has extra stuff in it specifically for the View to use. If you don't have a View with these requirements, you don't need a View Model at all.
In those cases where a VM is needed, I would recommend thinking of it as a wrapper over the DM. The VM will have properties unique to view, and will delegate requests for and updates to business data to the DM. There should be no duplication of logic between them.
When I've used this in WPF or Store apps the VM is the data binding context for the view, in close proximity, and the DM accessed through a formal interface, possibly far away.
I have no idea if there is a pattern for this -- my mind doesn't work that way.