We already have that in Toolkit.js?
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
see:
http://download.proxmox.com/debian/dists/wheezy/pve-no-subscription/binary-amd64/pve-kernel-2.6.32-39-pve_2.6.32-157.changelog
> On June 23, 2015 at 9:40 PM Alex Wacker wrote:
>
>
> Does the bugs fixed in https://openvz.org/Download/kernel/rhel6/042stab108.5
> affect the latest proxmox k
> the difficult part is to manage different configuration from differents os,
> but anyway on container creation we only support debian/redhat format ..
Just want to mention that I plan to support more that that in future ;-)
___
pve-devel mailing list
>>thanks, applied the whole series.
>>
>>but we need to fix ip configuration ...
I'll check that next week.
indeed
"
lxc.hook.mount
A hook to be run in the container's namespace after mounting
has been done, but before the pivot_root.
"
can do the job at start.
I'll try different things t
> lxc.mount.entry = /myguest/directory /myhost/directory none bind,create=dir
> 0 0
> lxc.mount.entry = /myguest/file /myhost/file none bind,create=file 0 0
>
>
> So, it could be possible to keep network config of guest in host filesystem.
>
> easy to update them :)
IMHO that just makes mig
thanks, applied the whole series.
but we need to fix ip configuration ...
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> lxc-attach -n container -s NETWORK -- /sbin/ip link ...
>
> From lxc doc:
> https://linuxcontainers.org/fr/lxc/manpages/man1/lxc-attach.1.html
> "Or, alternatively, use the -s to use the tools installed on the host outside
> the container:
> lxc-attach -n container -s NETWORK -- /sbin/ip link de
It's also possible to bind host directory/file inside guest
lxc.mount.entry = /myguest/directory /myhost/directory none bind,create=dir
0 0
lxc.mount.entry = /myguest/file /myhost/file none bind,create=file 0 0
So, it could be possible to keep network config of guest in host filesystem.
e
>>Well, we don't need to do ifdown/ifup to change ip address,
>>I already do it before in patch 2/3
oops, sorry, it's done it this patch 3/3
(could be done with "ip addr replace" instead "ip addr add")
- Mail original -
De: "aderumier"
À: "dietmar"
Cc: "pve-devel"
Envoyé: Vendredi 26
Hi,
>>I am not sure if you can update the IP configuration this way, because
>>the correct way to do it is dependent on the OS. For example
>>on debian I would expect something like this:
>>
>># ifdown ethX
>># rewrite config
>># ifup ethX
Well, we don't need to do ifdown/ifup to change ip
> fixme:
>
> -ip removal
> -ipv6 support
> -permanent guest file write config ?
Hi Alexandre,
very interesting patches!
I am not sure if you can update the IP configuration this way, because
the correct way to do it is dependent on the OS. For example
on debian I would expect something like th
Hi,
>>For the UI enabling and disabling cloudinit would then be
>>adding/removing a cloudinit device. It would then also not have to be
>>hardcoded to ide3 but be configurable to any block device like when
>>adding a hard disk.
I'm not sure but I think than sata/ahci controller are now migratable
We just talked this over a bit again.
If we keep going with this approach we could actually remove the
cloudinit config parameter and, similar to what Alexandre did in the
first patches, have an `ideX: cloudinit,storage=STOREID` parameter
enable cloudinit (but have it fix in the config rather than
The config-disk is now generated into a qcow2 located on a
configured storage.
It is now also storage-managed and solive-migration and
live-snapshotting should work as they do for regular hard
drives.
---
PVE/API2/Qemu.pm | 16 ++---
PVE/QemuMigrate.pm | 8 +--
PVE/QemuServer.pm
* Add ipconfigX for all netX configuration options and
using ip=CIDR, gw=IP, ip6=CIDR, gw6=IP as option names
like in LXC.
* Adding explicit ip=dhcp and ip6=dhcp options.
* Removing the config-update code and instead generating
the ide3 commandline in config_to_command.
- Adding a co
Changes since [PATCH v4]:
Instead of generating a separate ISO image file we now generate the
ISO into a qcow2 device which is storage-managed.
This does not only mean we don't need to rsync the file for
live-migrations, but we can also use the live-snapshot feature out of
the box.
It also allowe
From: Alexandre Derumier
Signed-off-by: Alexandre Derumier
---
PVE/QemuServer.pm | 181 +-
control.in| 2 +-
2 files changed, 179 insertions(+), 4 deletions(-)
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index ab9ac74..7956c5
> I have send a demo patch, using Ext.ux.IFrame.
>
> I only define 1 Frame id, so it's always the same which is reusing. (I have
> checked the dom to be sure).
>
> The frame is loaded when only when the tab is displayed.
>
> Resize is working fine.
>
> Please test ! :)
applied, so that the who
I have send a demo patch, using Ext.ux.IFrame.
I only define 1 Frame id, so it's always the same which is reusing. (I have
checked the dom to be sure).
The frame is loaded when only when the tab is displayed.
Resize is working fine.
Please test ! :)
- Mail original -
De: "aderumier"
Signed-off-by: Alexandre Derumier
---
www/manager/Makefile| 1 +
www/manager/qemu/Config.js | 8
www/manager/qemu/Console.js | 38 ++
3 files changed, 47 insertions(+)
create mode 100644 www/manager/qemu/Console.js
diff --git a/www/manager
Signed-off-by: Alexandre Derumier
---
www/manager/Utils.js | 150 +++
1 file changed, 150 insertions(+)
diff --git a/www/manager/Utils.js b/www/manager/Utils.js
index 7632822..b82b0a5 100644
--- a/www/manager/Utils.js
+++ b/www/manager/Utils.js
@@
>>But we can retry that with noVNC, although I am not really sure it
>>is a good idea to run several noVNC consoles within a single
>>browser window (perfromance, bugs, ...?).
don't known if we can define only 1 canvas and re-used it ? (not sure how it's
working with extjs).
or force the closin
> applied, thanks!
also applied changes to master branch now
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> resize is now off by default, and match previous behaviour.
>
> it can be enable passing resize=(scale|downscale|remote) to the url
applied, thanks!
Another thing I noticed is that it pops up the connect dialog when I open a
console
for a stopped VM. I guess we should avoid that?
Should be easy enough to only fire up the noVNC session when the user
switches to that tab... That way only one console is up at a time unless
they pop it out into a separate window.
On Fri, Jun 26, 2015, 01:31 Dietmar Maurer wrote:
> > I think also if we could add an extra tab "console" in vm
> I think also if we could add an extra tab "console" in vm
I have implemented that some years ago with the java applet,
but disabled it because of all those security popups.
But we can retry that with noVNC, although I am not really sure it
is a good idea to run several noVNC consoles within a
+1 embedded console!
On Fri, Jun 26, 2015, 00:11 Alexandre DERUMIER wrote:
> >>I would like to disable it by default, but allow to enable
> >>it with some checkbox on the GUI.
> ok, great.
>
>
> I think also if we could add an extra tab "console" in vm
> like on xenserver or vmware, now with res
resize is now off by default, and match previous behaviour.
it can be enable passing resize=(scale|downscale|remote) to the url
ex:
https://node1:8006/?console=kvm&novnc=1&vmid=100&vmname=test&node=node1&resize=scale
Signed-off-by: Alexandre Derumier
---
debian/patches/pveui.patch | 105 ++
28 matches
Mail list logo
