[Engine-devel] VM hibernation to storage domain
Is there any reason anyone can think of why we would need to specify a specific storage domain for a VM to use when it hibernates? Ideally we could just grab any storage domain that has space and use it for hibernation (as long a we remember where we did it!). thoughts?
On 12/12/2011 19:22, Jon Choate wrote:
Is there any reason anyone can think of why we would need to specify a specific storage domain for a VM to use when it hibernates? Ideally we could just grab any storage domain that has space and use it for hibernation (as long a we remember where we did it!).
thoughts? _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Probably for the same reason we enforce all VMs disks to be on the same storage domain. Habit. But I also think it make sense, for the hibernation file to be in the same SD as the system disk. There's also a higher chance that domain will be online and available to the host. Y.
On 12/12/2011 01:46 PM, Yaniv Kaul wrote:
On 12/12/2011 19:22, Jon Choate wrote:
Is there any reason anyone can think of why we would need to specify a specific storage domain for a VM to use when it hibernates? Ideally we could just grab any storage domain that has space and use it for hibernation (as long a we remember where we did it!).
thoughts? _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Probably for the same reason we enforce all VMs disks to be on the same storage domain. Habit. Eliminating this dependency would be part of the feature to allow VMs to have their disks on multiple storage domains. But I also think it make sense, for the hibernation file to be in the same SD as the system disk. There's also a higher chance that domain will be online and available to the host. Y. Is it possible for ovirt-engine to identify which disk is the system disk?
What should the algorithm be for determining a storage domain to hibernate a diskless VM? It seems like things would be simplified if we did not restrict ourselves and could use any available storage domain regardless of whether the vm has disks or not.
On 12/12/2011 21:04, Jon Choate wrote:
On 12/12/2011 01:46 PM, Yaniv Kaul wrote:
On 12/12/2011 19:22, Jon Choate wrote:
Is there any reason anyone can think of why we would need to specify a specific storage domain for a VM to use when it hibernates? Ideally we could just grab any storage domain that has space and use it for hibernation (as long a we remember where we did it!).
thoughts? _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Probably for the same reason we enforce all VMs disks to be on the same storage domain. Habit. Eliminating this dependency would be part of the feature to allow VMs to have their disks on multiple storage domains. But I also think it make sense, for the hibernation file to be in the same SD as the system disk. There's also a higher chance that domain will be online and available to the host. Y. Is it possible for ovirt-engine to identify which disk is the system disk?
In several ways: 1. Guess. 2. The first 3. Use the one with the 'Is Bootable' flag. Y.
What should the algorithm be for determining a storage domain to hibernate a diskless VM?
None, we should only support S4 and say farewell to the external hibernation. I don't think there is a good enough reason to keep it (Ayal might disagree, but I disagree with his reasons).
It seems like things would be simplified if we did not restrict ourselves and could use any available storage domain regardless of whether the vm has disks or not.
Perhaps. What's the real benefit, except of freedom of choice? I personally would look at compressing that hibernation file, btw. Always annoyed me the size of it, and I expect fast compression to enable faster suspend-resume cycles. I believe libvirt support some compression methods. Y.
On 12/12/2011 21:04, Jon Choate wrote:
On 12/12/2011 01:46 PM, Yaniv Kaul wrote:
On 12/12/2011 19:22, Jon Choate wrote:
Is there any reason anyone can think of why we would need to specify a specific storage domain for a VM to use when it hibernates? Ideally we could just grab any storage domain that has space and use it for hibernation (as long a we remember where we did it!).
thoughts? _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Probably for the same reason we enforce all VMs disks to be on the same storage domain. Habit. Eliminating this dependency would be part of the feature to allow VMs to have their disks on multiple storage domains. But I also think it make sense, for the hibernation file to be in the same SD as the system disk. There's also a higher chance that domain will be online and available to the host. Y. Is it possible for ovirt-engine to identify which disk is the system disk?
In several ways: 1. Guess. 2. The first 3. Use the one with the 'Is Bootable' flag. Those all seem to have the possibility of getting the wrong disk. If
On 12/12/2011 02:10 PM, Yaniv Kaul wrote: the cost of getting the wrong disk is low anyway then I would argue that we don't need to find the system disk and we could hibernate alongside any disk.
Y.
What should the algorithm be for determining a storage domain to hibernate a diskless VM?
None, we should only support S4 and say farewell to the external hibernation. I don't think there is a good enough reason to keep it (Ayal might disagree, but I disagree with his reasons).
It seems like things would be simplified if we did not restrict ourselves and could use any available storage domain regardless of whether the vm has disks or not.
Perhaps. What's the real benefit, except of freedom of choice? I personally would look at compressing that hibernation file, btw. Always annoyed me the size of it, and I expect fast compression to enable faster suspend-resume cycles. I believe libvirt support some compression methods. Y.
The benefit is that we have one code path for hibernation. The user likely doesn't understand what happens during hibernation and likely doesn't care where the data is stored so we should choose the easiest path for us to implement. My (perhaps naive) assumption is that all storage domains are just as reliable and choosing one randomly will not be any worse than any algorithm we could design.
On 12/12/2011 10:31 PM, Jon Choate wrote:
On 12/12/2011 02:10 PM, Yaniv Kaul wrote:
On 12/12/2011 21:04, Jon Choate wrote:
On 12/12/2011 01:46 PM, Yaniv Kaul wrote:
On 12/12/2011 19:22, Jon Choate wrote:
Is there any reason anyone can think of why we would need to specify a specific storage domain for a VM to use when it hibernates? Ideally we could just grab any storage domain that has space and use it for hibernation (as long a we remember where we did it!).
thoughts? _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Probably for the same reason we enforce all VMs disks to be on the same storage domain. Habit. Eliminating this dependency would be part of the feature to allow VMs to have their disks on multiple storage domains. But I also think it make sense, for the hibernation file to be in the same SD as the system disk. There's also a higher chance that domain will be online and available to the host. Y. Is it possible for ovirt-engine to identify which disk is the system disk?
In several ways: 1. Guess. 2. The first 3. Use the one with the 'Is Bootable' flag. Those all seem to have the possibility of getting the wrong disk. If the cost of getting the wrong disk is low anyway then I would argue that we don't need to find the system disk and we could hibernate alongside any disk.
1. how about KISS and choose the disk the user flagged as type = system (the field already exists and is used today. iirc, backend doesn't even allow choosing more than one, etc.) 2. diskless VMs - fail the operation. it would fail if you try to hibernate from inside the guest as well (S4) which are considering moving to.
participants (3)
-
Itamar Heim -
Jon Choate -
Yaniv Kaul