3:31 p.m.
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
11:15 a.m.
----- Original Message -----
From: "Doron Fediuck" <dfediuck(a)redhat.com>
To: engine-devel(a)ovirt.org, "Adam Litke" <agl(a)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(a)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)
if this is a vm-device, why do we need it in vm_static?
can you explain means the change in VmOldInfoBuilder?
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.
12:32 p.m.
On 30/05/12 18:15, Omer Frenkel wrote:
----- Original Message -----
> From: "Doron Fediuck" <dfediuck(a)redhat.com>
> To: engine-devel(a)ovirt.org, "Adam Litke" <agl(a)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(a)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
4591
days inactive
4594
days old
2 comments
2 participants
participants (2)
-
Doron Fediuck -
Omer Frenkel