On 30/05/12 18:15, Omer Frenkel wrote: > > > ----- Original Message ----- >> From: "Doron Fediuck" <[email protected]> >> To: [email protected], "Adam Litke" <[email protected]> >> 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 >> [email protected] >> 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 _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
