Search results

Hi to my knowledge openvz/virtuozzo has such a feature if you start your VEs from one template and make hardlinks as new VEs; do updates only via your master-template and so on - then you can get some additional performance per hardware-node, but usually this works only if you're in control and...

just my 2 cents - virtio has been discussed (especially on network drivers) several times. the basically always working solution is to go for intel e1000 networking instead of virtio for the VMs. virtio networking typically breaks in high-load environments, eg. pinging all day works fine, but...

Hi I know this has been brought up in the past, but I would like to try to argue for it: "uname -a" on proxmox tells me no details about which iteration of the pve-kernel 2.6.32-6 the system is running. Therefore in case of updates like this one there is no way of telling with a simple command...

Hi while you are at it - maybe you could incorporate the IPv6 fix (for the missing default route) too (proposed and in git of upstream here: http://bugzilla.openvz.org/show_bug.cgi?id=2023 ) thank you again for your work, hk

Hi again setting the IP to: IP_ADDRESS="10.116.5.1/32" resolves this issue. Now I only got the issue to fix this for any container manually. I'd highly appreciate a fast-pushed update for vzctl as the upstream vzctl is fixed already. Regards hk

well, according to http://git.openvz.org/?p=vzctl;a=shortlog;h=vzctl-3.0.29.3 there has been some trouble on the netmask side. I'll try to config the VEs using Proxmox and set a specific netmask...

well, the correct netmask was there before, but some update in proxmox seems to have broken this. I tested with ubuntu-6.06-i386-minimal and debian-3.1-i386-minimal based VEs - they seem to acceppt the inet6 ::1/128 without any problems, therefore this I have to take back. but the netmask is...

well, I just tried vzctl --version vzctl version 3.0.29.3 this now builds: iface venet0 inet6 static address ::1 netmask 128 into interfaces - so something seems to have changed in this ... but - it builds correctly: auto venet0:0 iface venet0:0 inet static address 10.116.5.3 netmask...

OSTEMPLATE="debian-3.1-i386-minimal"

because we get IPv6 configured in a debian-3.1 :) (which was a bug I already got fixed in upstream several months ago)