[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