[Engine-devel] VM hibernation to storage domain

Yaniv Kaul ykaul at redhat.com
Mon Dec 12 19:10:14 UTC 2011


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 at 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.




More information about the Devel mailing list