[Engine-devel] Enabling guest memory balloon device

[Doron Fediuck]

On 30/05/12 18:15, Omer Frenkel wrote:
> 
> 
> ----- Original Message -----
>> From: "Doron Fediuck" <dfediuck at redhat.com>
>> To: engine-devel at ovirt.org, "Adam Litke" <agl at us.ibm.com>
>> Sent: Sunday, May 27, 2012 10:31:22 PM
>> Subject: [Engine-devel] Enabling guest memory balloon device
>>
>> Hi All,
>> In the following wiki, there's a design for enabling the balloon
>> device,
>> which is currently disabled in engine setups. Other than enabling the
>> device,
>> this is also a step forward in the path to vdsm and MoM sub-project
>> integration.
>>
>> More details can be found here:
>> http://www.ovirt.org/wiki/Features/Design/memory-balloon
>>
>> P.S.
>> UI mockups should be updated soon.
>> --
>>
>> /d
>>
>> “Funny,” he intoned funereally, “how just when you think life can't
>> possibly get any worse it suddenly does.” --Douglas Adams, The
>> Hitchhiker's Guide to the Galaxy
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> 
> what does it mean template is not supported? (and why is it under ovf section?)
> this value will not pass to a template created from a vm? (although its mentioned in Backend-vdsm parts section)
The unsupported phrase is just for template changes. Template editing will not show it in UI (it actually doesn't
have the whole resource allocation part a VM has).
But, creating a new template from a vm will enable/disable the device based on the parent VM's value,

> 
> if this is a vm-device, why do we need it in vm_static?
We need a way for UI/REST to get the state of an existing VM. IE- does or doesn't it
enable a balloon device. This is similar to allow_console_reconnect or anything else
we need to know if it's enabled or not. I checked if UI and REST can enumerate existing
devices, but it gets to a logic that we better have in the backend and not in the client.

> 
> can you explain means the change in VmOldInfoBuilder?
Yep. This a part of the stable device addresses framework. Since this is working
on the new api with vdsm for 3.1 cluster, we need an empty implementation of it,
the same we have for other devices which are for 3.1 only. Take a look at
buildVmUsbDevices and buildUnmanagedDevices.

> shouldn't we just ignore it to keep old behavior? or we want to support ballooning in all clusters?
> (in Validations section it says only 3.1 is supported)
> maybe validation is needed on changing vm cluster command, in case changing to 3.0 cluster and balloon enabled.
We already have such cases now as a part of the stable device address API, working
in <3.1 cluster uses the old API, which builds the devices in a different way, ignoring
3.0 unsupported devices.

-- 

/d

"Forty-two," said Deep Thought, with infinite majesty and calm. --Douglas Adams, The Hitchhiker's Guide to the Galaxy