I just upgraded one node to 4.1-33 (no-subscription repo - not pvetest).
Love the new webui. Very nice.
Unfortunately, it appears that you can no longer set a VLAN tag for VLAN 1. My current network uses fully trunked VLANs (everything tagged, untagged traffic blocks). This has worked well...
Fair play to that. Jewel is close to release - but I imagine Proxmox 4.2 is closer so it won't make the cut. That is disappointing but understandable.
I gave that a shot with Infernalis but was never successful getting the permissions right so that things would launch.
May try it again with...
No rule says the third-node needs to be very capable - all it has to do is hold the quorum. Why not get a low-scale machine that can support Proxmox and add it to the cluster as a third node. You don't actually have to run any VMs on it (or you could even run trivial VMs like a PBX server)...
No one doubts that you probably comply with the letter of the GPL, but at the same time you violate every ounce of its spirit with your nag screens. Your choice to post this little excerpt of the GPL in response only proves that you have no concept of what it actually means.
And I'll ask...
Dietmar,
Lets make a little deal. Proxmox VE is built on the shoulders of so much free open source software that YOU did not contribute to and that YOU did not write - and Proxmox VE could not exist without Debian, KVM, the Linux kernel, etc, etc, etc...
When you show us the $ you've chosen...
Call me dense, but could someone please post the exact procedure to upgrade a node from 3.0 to 3.1 with the "no subscription" repository.
Probably thinking its a bit more than "apt-get update; apt-get dist-upgrade"...
I'll check this evening. But normally, "modprobe -r <unloaded module>" simply returns immediately rather than hanging.
Also - this is for shutdown on a system that doesn't even use OpenVZ. Do I risk anything by just commenting out the "modprobe -r" from the /etc/init.d/vz script? It can't do...
Apologies for digging up an old thread but I notice this was never answered/resolved. I now find I am having the same problem.
My config:
- Proxmox VE 3.0 with all updates from the stable repository (no pvetest).
- ZFS
- Samba
- Added drivers for a Mellanox ConnectX-EN 10Gbe card
All VMs...
I've got ZoL on Proxmox working following the instructions in the wiki. It was very straigh forward.
You can limit the size used by the ARC by adding a line to /etc/modprobe.d/zfs.conf
options zfs zfs_arc_max=536870912. # or any size in bytes you wish...
Doing this is very important - ZFS...
Wonder if you might explain why you removed it? A security issue? Customers asking you to remove it? Something else less obvious?
If you'd help people understand why then at least they'd know what benefit they are undoing when they try to put it back.
Check your BIOS settings. VT-d support is configurable in the BIOS and almost every HP server I have ever dealt with has this default "off". Dell servers too.
Found a bug when installing 3.0 RC2. The machine has an SSD for system/boot and 12 2TB drives for a ZoL-based NAS running along with Proxmox. Have been running this config with 2.3 for a while and the ZFS integration was done after installing proxmox so this bug may exist in 2.0 as well...
I don't think anybody is disputing that Proxmox VE is strong and getting stronger. The question posed was simple "is there a published roadmap". The correct answer to that is apparently no - the 'Roadmap' wiki contains a changelog and a couple of high level statements...it is not a 'roadmap'...
A Changlog is not a roadmap. It reports history - is written in the past tense.
A roadmap details future plans. Three high level statements ("Debian Wheezy", etc.) attached to a changelog hardly qualifies as a roadmap.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.