Search results

I implemented the three edits proposed by Lord_Gaav and can confirm that it completely restores the behavior from 4.1-22. - The ability to set VLAN 1 as a tagged VLAN is restored - The VM operates correctly with the VLAN 1 tagged. - You can migrate a VM with VLAN 1 tagged to the fixed PVE host...

@fabian - can we get an update on the bug report with this info (I am not able to update it) and perhaps it expedited back into the next point release?

I know its probably too late to make it into 4.2, but FYI: http://ceph.com/releases/v10-2-0-jewel-released/

I appreciate opening the bug report, but the approach is quite soft ("if possible..."). Please note that selecting VLAN 1 as a tagged VLAN was fully supported in 4.1-22 and quietly went away with the UI changes and audits in 4.1-33. Getting this put back the way it was is actually quite...

I think your statement should be revised to read "VLAN 1 is normally used for untagged traffic...". I agree that in the default this is the case. But it is not universally true. Linux networking, including bridges and OVS, fully support the use of tagged traffic on VLAN 1 and setting the PVID...

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...

That's really too bad. Jewel brings a usable CephFS - and that's potentially huge.

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...

Thank you.

Storage live migration or offline only?

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...