On 01/20/2015 04:43 PM, Alexandre Derumier wrote:
- if (Ext.isDefined(record.data.pending) && (record.data.pending !==
'')) {
+ if ((Ext.isDefined(record.data.pending) && (record.data.pending !==
'')) || rowdef.multiValues) {
Sorry, I remove that during my "cleanup". Just
>>Assuming that each socket defines a separate NUMA node? I thought
>>we can do:
>>
>>$node = $i % $number_of_numa_nodes;
Yes ;) (sorry, don't have sleep too much ;)
- Mail original -
De: "dietmar"
À: "aderumier"
Cc: "Daniel Hunsaker" , "pve-devel"
Envoyé: Mercredi 21 Janvier 20
>>Sigh, that is a problem, because each OS needs a different setting for
>>startup
>>memory.
>>Using 2 different configuration would solve that:
>>
>>memory: XXX # assigned at startup
>>dimm_memory: XXX # hot plugable memory
Seem good !
>>Sure. But we do not need 'unplug' when we 'add' memo
> I think we can also add numa nodes in the mapping,
> like this;
>
>
> #!/usr/bin/perl
>
> use strict;
> use warnings;
>
> my $dimm_id = 0;
> my $current_size = 0;
> my $dimm_size = 128;
> my $sockets = 4;
>
> my $node = 0;
>
> for (my $j = 0; $j < 16; $j++) {
> for (my $i = 0; $i < 16
> I never have think at something like that.
> It seem to solve all the problems :)
>
>
> (just one little note: we need to keep some "static" memory (qemu -m X), for
> vm start,
> because dimm modules are not readeable until initramfs is loaded).
Sigh, that is a problem, because each OS needs
I think we can also add numa nodes in the mapping,
like this;
#!/usr/bin/perl
use strict;
use warnings;
my $dimm_id = 0;
my $current_size = 0;
my $dimm_size = 128;
my $sockets = 4;
my $node = 0;
for (my $j = 0; $j < 16; $j++) {
for (my $i = 0; $i < 16; $i++) {
my $name = "dimm${d
> From look at the kvm args in the process list I see we have:
>
> hv_relaxed,hv_spinlocks=0x
>
> but the current recomendations are:
>
> hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time
>
This is a comment from current code:
if ($ost eq 'win7' || $ost eq 'w
>>I thought about using a simpler, fixed dimm mapping. For example:
Damn, you are good ;)
I never have think at something like that.
It seem to solve all the problems :)
(just one little note: we need to keep some "static" memory (qemu -m X), for vm
start,
because dimm modules are not readeab
> I thought about using a simpler, fixed dimm mapping. For example:
The following create a better mapping, and also shows the dimm size
a percentage of whole memory.
---
#!/usr/bin/perl
use strict;
use warnings;
my $dimm_id = 0;
my $current_size = 0;
my $dimm_size =
I thought about using a simpler, fixed dimm mapping. For example:
---
#!/usr/bin/perl
use strict;
use warnings;
my $dimm_id = 0;
my $current_size = 0;
my @dimm_sizes = (128, 512, 1024, 4096, 8192); # MB
for (my $j = 0; $j < 16; $j++) {
my $ind = ($j >= scalar(@dimm
On 21 January 2015 at 11:01, Lindsay Mathieson
wrote:
>
> http://blog.wikichoon.com/2014/07/enabling-hyper-v-enlightenments-with-kvm.html
>
> Will proxmox be enabling these or can it be done via editing of the VM
> conf file?
>
>From look at the kvm args in the process list I see we have:
hv
http://blog.wikichoon.com/2014/07/enabling-hyper-v-enlightenments-with-kvm.html
Will proxmox be enabling these or can it be done via editing of the VM conf
file?
Looks to be quite useful.
--
Lindsay
___
pve-devel mailing list
pve-devel@pve.proxmox.com
Thanks for your suggestion,
I think it could work, but currently unplug is not implemented in qemu,
I would like to test it to see if it's working fine. (I'll try to patch qemu
with last unplug patches from qemu mailing)
With this we can keep a simple memory form field (but we need to fix minimu
It's a bit more work internally, but changing the RAM size seems like a
task that could be handled without thinking about the add/remove process.
Present the user with a button/dialog to resize RAM, then hotplug and/or
unplug to arrive at the target. If they provide a larger value than what's
curr
it depend on the features we will implement in this!
This is not all.
But your right it would be better extend on from an other.
regards
Wolfgang Link
2015-01-20 18:29 GMT+01:00 Adrian Costin :
> I’ve been using a similar plugin for local zfs, basically a stripped down
> version of the ZFSPlu
BTW, how can I test this Alexandre??
2015-01-20 15:19 GMT-02:00 Gilberto Nunes :
> +1
>
> I am the one that want to see this feature in production environment
> It will be a plus...
>
>
>
> 2015-01-20 15:13 GMT-02:00 Alexandre DERUMIER :
>
> >>I wonder if memory unplug is a good idea? I assum
+1
I am the one that want to see this feature in production environment
It will be a plus...
2015-01-20 15:13 GMT-02:00 Alexandre DERUMIER :
> >>I wonder if memory unplug is a good idea? I assume that will be the
> fastest way
> >>to crash most OS?
> I personnaly need this feature. (I have
>>Can we keep the current interface, and automatically add/remove dimms?
The main problem is:
- we can only hotplug memory of multiple of 128MB
-for unplug,
if user have hotplugged dimm of 128MB, then dimm of 512MB, then dimm of 1G
I don't known how to manage the downgrade field.
1 possibi
>>I wonder if memory unplug is a good idea? I assume that will be the fastest
>>way
>>to crash most OS?
I personnaly need this feature. (I have customers which want to add/remove
memory, because we bill on that).
For linux, it should work without any problem, if you have memory use for
buffer
> what we can do
> -
>
> I think we can add a button "add-> memory hotplug", with a field with memory
> value wanted.
> We display the total memory in current hardware grid memory field. (memory +
> total of dimms memories).
>
> For unplug, create a button "delete->memory unplug",
> a
> For the display, do you want to display dimm device like another device ?
No, we can add an extra tab to display detailed information for advanced user.
In the hardware tab, I would like to keep displaying the overall sum of memory.
And I also want to have a simple way to add/remove RAM.
Can w
vmware vsphere cpu & memory hotplug video
http://www.petri.com/vsphere-hot-add-memory-and-cpu.htm
Seem that they simply use a classic memory field counter increment
(Note that memory unplug is not supported by vsphere, so it's a little more
simple).
what we can do
-
I think we ca
>>Form my point of view, this is much too complex. I just want to add RAM and
>>CPU
>>cores,
>>but I do not want to care about NUMA architecture or DIMMs. Many users are
>>not
>>familiar with
>>those concepts.
Ok, I think we can manage dimm numa placement for user if numa is enabled.
(Just f
Signed-off-by: Alexandre Derumier
---
www/manager/grid/PendingObjectGrid.js |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/www/manager/grid/PendingObjectGrid.js
b/www/manager/grid/PendingObjectGrid.js
index 7e37108..03a22b3 100644
--- a/www/manager/grid/PendingObjectGrid
Signed-off-by: Alexandre Derumier
---
www/manager/qemu/HardwareView.js |9 +
www/manager/qemu/ProcessorEdit.js |9 -
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/www/manager/qemu/HardwareView.js b/www/manager/qemu/HardwareView.js
index b0680cc..16b6a9d
Form my point of view, this is much too complex. I just want to add RAM and CPU
cores,
but I do not want to care about NUMA architecture or DIMMs. Many users are not
familiar with
those concepts.
How is that handled by other plattforms (vmware, xen, vbox)?
> 1)
> add memory device like disk, nic.
Signed-off-by: Wolfgang Link
---
PVE/Storage.pm|2 +
PVE/Storage/Makefile |2 +-
PVE/Storage/ZFSLocalPlugin.pm | 517 +
3 files changed, 520 insertions(+), 1 deletion(-)
create mode 100644 PVE/Storage/ZFSLocalPlugin.pm
d
Well,
I have thinked about it,
I have 2 ideas in mind
1)
add memory device like disk, nic.
But I think we can have up to 255 dimm, so maybe this will give confusion on
the main hardware grid.
2) add a new panelgrid (through a button in menu), to manage memory hotplug and
cpu hotplug.
I thin
> This patch allow to hotplug|define pc dimm devices memory
looks good, but how can we add this to the GUI?
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
applied, modified for new hotplug implementation:
https://git.proxmox.com/?p=qemu-server.git;a=commitdiff;h=25088687fe81c2d2671c6d0a0380f6c555f6ab4a
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo
So it is no longer possible to login on a fresh installed system?!
On 01/07/2015 08:49 AM, Wolfgang Link wrote:
Signed-off-by: Wolfgang Link
---
PVE/AccessControl.pm |7 ---
1 file changed, 7 deletions(-)
diff --git a/PVE/AccessControl.pm b/PVE/AccessControl.pm
index db85d08..29dba3
I applied the patch, but slightly changed the behavior, see:
https://git.proxmox.com/?p=pve-manager.git;a=commitdiff;h=8b0470b4e17aafee95a817cf93e005c7aeb55aaf
- Dietmar
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-
32 matches
Mail list logo
