Search results

Yep. With a normal fairly cheap gigabit ethernet network you can move VMs from one box to another manually or restore from a backup server quickly enough. In the unlikely event of a water landing, take ten minutes to install Proxmox VE on another 64-bit-capable server from CD and grab last...

Yeah, it doesn't want a physical interface, it wants an IP or multiple IPs. Example: inet_interfaces = 200.111.222.2, 200.111.222.4or just: inet_interfaces = 200.111.222.2

Oh, duh. I just looked more closely at the output you provided. You need to configure postfix in main.cf to listen on more than just localhost. Right now Postfix is bound to 127.0.0.1 only. Look for the line in Postfix's main.cf that says "inet_interfaces"

What does the IP_ADDRESS line look like in /etc/vz/conf/NNN.conf? Is the IP address you are using in the VZ container in the same subnet as your host system's ethernet interface?

Proxmox VE is a first release so it is a work in progress... what they've got already is VERY nice, and it sounds like the v1.0 release is going to fix most of the current deficiencies and missing things except for the extremely difficult bits like auto-failover clustering. For now I am more...

I am using two Xeon Quad-Core X5410s just fine with Proxmox VE. Yours would just be the same core/generation at a higher clock speed. I am currently running Win2k Server in production in a KVM and I have also started up WinXP numerous times just to jack around with it and it has always been...

RAID10 on what kind of controller? Perhaps then you don't need to change the default scheduler, so long as the information that this can happen to some and how to fix it is readily accessible, perhaps in the wiki.

Ok, thanks. For the benefit of anybody else looking through the forum: Change your network: line in your /etc/qemu-server/XXX.conf like so: network: macaddr=52:54:00:12:34:57,model=e1000,tapAnd so on for additonal KVMs, just increment the MAC address by one each time.

I just started up a second instance of KVM and the second instance's "e1000" virtual adapter was assigned the same default MAC address as the first existing KVM: 52:54:00:12:34:56. This of course collided with the first KVM... Both are using the bridging and both were assigned the same MAC...

Makes sense. What are you using? A single fast disk?

Thank you very much for your consideration and responsiveness. I can't find it right now, but I saw a couple things found via google where people are mentioning how they use the fancy new I/O schedulers except on "busy servers" for just this reason. It seems like the new default CFQ is designed...

Best guess is because I have half the I/O per second performance you do being that my disk setup is incredibly basic. But, really, does one expect to need four 10k RPM drives in a RAID10 just to run a low-traffic Plesk server with almost no I/O?

Nice disk(s) you've got there. Mine is pretty much what I'd expect out of a simple 7200RPM single-disk setup (which is actually a mirror on a 3ware controller) # pveperf CPU BOGOMIPS: 37243.82 REGEX/SECOND: 770397 HD SIZE: 94.49 GB (/dev/pve/root) BUFFERED READS: 47.83...

Well the only way you can reproduce it is to have other tasks trying to do constant little bits of I/O in the background... for example I have a Plesk server in a container and it's receiving about one piece of mail say every 1-3 seconds. Not very heavy, but if you telnet to the plesk server...

So if I have similar poor results on a 10k RPM drive, would you consider changing the default Proxmox kernel config to: CONFIG_DEFAULT_IOSCHED="deadline" So future new Proxmox users don't get a nasty surprise when they go to do backups? Proxmox is obviously more of a virtualization server to...

Considering the type of job this box is performing, nothing special. Two 500GB Seagate 7200RPM "ES" drives on a 3ware 8006-LP2 in a simple mirror. Since I don't follow along real closely with Linux (everything else is BSD around here), having a simple tar grind everything else on the system to...

A quick follow-up, I did some reading on the subject. I tried out the anticipatory scheduler as well and it had about the same results, ridiculous wait times for occasional I/O requests but not quite as long as the now-default cfq scheduler. Pretty nearly, though. Then I tried the deadline...

Has anybody else noticed the I/O scheduler seems to perform very "unfairly" ? During a vzdump I pretty much see the entire system's load average inside OpenVZ containers and even in the host just skyrocket up to 5-20 easily with no actual load on the system. Apparently everything that is not...

Thanks for testing that for me, I'm always afraid when I update perl it's going to blow up and lose all my existing installed modules. At least that's what happens if you ever update from, say, perl 5.8.7 --> 5.8.8.

I recently had it happen to me again. It actually went away after stopping and starting my one OpenVZ container... netstat on the host system immediately started working again. There's something amiss there.