Search results

If a lonely hardware-raid-controller burn then it´s not just "not much more" ;) - In that case the hardware-raid is much worse than a software-raid. If you know what you are doning software-raid can be a good thing. We have a backup of important servers on tape but I never needed it to...

I understand you. :D Me too. Even if I have a machine with a "pseudo-hw-raid-controller" I prefer sw-raid with mdadm. Just if there is a real hw-raid I would use it. And there is still a risk to use hw-raid-controllers. They have some advantages in some cases but it´s hardware that can...

...it is still not released as stable on kernel.org nor included as stable kernel in Lenny yet? ;) - 2.6.24 is no "stable" openvz-kernel as well. What I would say: I don´t fear 2.6.24 even if it´s not marked stable yet (but I´m not fully lucky with it). Why should I dislike 2.6.26 when the...

I am still not lucky with 2.6.24 regarding OpenVZ live-migration and (hanging) putty-session. However live-migration does not work with any kernel (i tried) as it should. 2.6.26 does not freeze my session like 2.6.24 does but did not live-migrate machines built on CentOS4 or CentOS5 templates...

Yes I know. So you are not on the save side if you use HW-Raid (with battery). It´s just a little bit more secure in some cases and can make troubles too in other cases. For example if you would use your old server a little bit longer, your controller dies and you should buy lot of money to get...

Come on guys. With such arguments you can tell the kernel-maintainers to whipe out SW-Raid from linux-kernel totally. Nobody said SW-Raid is much better then HW-Raid. But SW-Raid is a good thing in many cases (not in every case). We use both, software-raid and hardware-raid sollutions for years...

You don´t have a battery on a cheap HW-Controller too. If you just use Raid1 (which is enough in many cases where expensive hardware is not available) you can forget this hw-controller-battery-stuff in my opinion anyway. We are talking regarding a desaster here. Right? But raid is no real...

Following results: 2.6.18 (vanilla+openvz-patch/config) - No hang at live-migration but 2.6.18 is old and live-migration does not work with all templates 2.6.24 (vanilla+openvz-patch/config) - Hangs at live-migration. 2.6.26 (vanilla+openvz-patch/config) - No hang at live-migration but...

Ok... I would try with some other (vanilla+openvz-patch) kernel too.

Not so far. Don´t understand me wrong - I think 2.6.24 is ok and it´s not the fault of proxmox or a to new kernel (btw. today I would prefer lenny than etch anyway :D ;)). When 2.6.27 would make the same failure than it´s clear some OpenVZ bug. But I can´t tell them it´s the same because it´s...

It seems the openvz-guys don´t like the source from there (and don´t trust the "proxmox-kernel" so far). ;) - It´s the same with proxmox 1.1. I´m in doubt that the bug is on the proxmox side. However I tried to test with another "clean" kernel on the proxmox-machines in the meanwhile (2.6.27...

Helped me too. I had some problems while creating the partitions the same way on the second harddrive (because the last cylinder of the first partition overlapped with the first cylinder of the second partition - don´t know why) but 'sfdisk -d /dev/sda | sfdisk /dev/sdb --force' did it (and...

Can somebody tell me where to find the current source of the kernel that is used in Proxmox 1.0? The date of the files that I found myself at ftp://pve.proxmox.com/sources (2008-10-29) differ from the date of the kernel that came with Proxmox 1.0 (2008-10-24), so I don´t really know... ...or...

I played with the live-migration of OpenVZ that should work now. But I´m not sure if live-migration is really useable now. If I´m just logged in via ssh (Putty) without doing anything there and do a live-migration it´s working fine. Sould mean: After migration I can still work in my Putty-Window...

Is there a way to enable a safer "destroy button"? That way it´s easy to remove an existing machine by mistake. Currently there is no "are you sure you want merciless nuke your VM and all data of it" question before your fully configured virtual machine would be deleted in seconds. :) I would...