Search results

v0.80.1 Firefly released

OSD = Object Storage Daemon. The deployments I have seen use one dameon per spindle and some number of daemons per node. Barring a poorly engineered node, the "RAID-0 effect" is typically constrained by NIC bandwidth. For a Proxmox host that does not utilize 10gigE or Inifiniband NICs, OSDs...

http://www.redhat.com/about/news/press-archive/2014/4/red-hat-to-acquire-inktank-provider-of-ceph

How many spindles are you planning to use for Ceph? Surely more than one? You can start with one spindle per OSD, with the OSDs run under Proxmox.

I believe this is an artifact of putting the veth in the same subnet as the host venet. Do you actually need an address in that subnet? Perhaps to access other VMs?

Thanks mostly to Mr. Holmes, I now have my basic OVS configuration working on PVE. There appear to be some challenges when using VLANs with CTs. To summarize: Assigning venet IP addresses would really be the best option, but does not appear work with VLANs. Assigning a veth interface and...

Check, understood. Any idea how I can remove the specific trunks and allow all? trunks=all and trunks=* are not valid expressions. Changing to vlan_mode=access did not remove them either. The vlan_mode= option does not appear to be well documented (no mention in the man pages, not much online.)

I was growing suspicious about the switch, so I did some testing between the two routers on newly-created VIFs. No connectivity through the Cisco, but everything worked using an unmanaged TrendNet switch. This morning I moved the Proxmox host and both internal router NICs to the unmanaged...

I have OVS mostly working inside the host, with CTs and KVM guests able to communicate on various VLANs and subnets. I do not seem to be able to get these tagged VLAN packets to enter or leave the host on the physical Ethernet, which should trunk them to the upstream switch, which will then...

No argument there. Yes, this is indeed the issue. Something needs to add the veth to the bridge. It should probably be done by the GUI when the veth is created. I think the VLAN problems deserve a new thread. I suspect few people are reading all the way to the bottom of this one. Thanks...

Now that the internal VLAN is working, it needs to be able to survive a reboot. Adding allow-vmbr0 veth103.0 iface veth103.0 inet manual ovs_type OVSIntPort ovs_bridge vmbr0 ovs_options tag=11 to /etc/network/interfaces didn't quite work. auto veth103.0 allow-vmbr0...

Seems like the NIC is not responding to ARPs which led me to http://ckdake.com/content/2008/vlans-in-openvz.html (admittedly a 5+ year old post.) but: root@pve1:/proc/sys/net/ipv4/conf# cat vlan11/proxy_arp 0 root@pve1:/proc/sys/net/ipv4/conf# cat eth0/proxy_arp 0...

open88 is actually an untagged interface -- mostly there for testing to see if tags are causing the issues. I'm seeing the same results you are within the box -- including the rather annoying need to re-establish OVS bridges after restarting containers. However, I'm not seeing VLAN packets...

Adding an untagged veth to the CT did not work as expected either: NETIF="ifname=eth0,bridge=vmbr0,mac=BE:A3:F8:E2:73:E0,host_ifname=veth103.0,host_mac=F6:5A:BA:DE:60:0E;ifname=eth1,bridge=vmbr0,mac=A2:38:7F:B8:C3:D4,host_ifname=veth103.1,host_mac=46:CC:6C:C7:DA:3F" root@pve1:~# ovs-vsctl...

Same results as before -- CT can ping the host in VLAN 11, but not the router out on the wire. Is there a trick to getting tagged packets to leave the box? [root@sipx /]# ifconfig eth0 172.16.11.23 netmask 255.255.255.0 [root@sipx /]# ifconfig eth0 Link encap:Ethernet HWaddr...

Thanks -- still not quite clear on the sequence you used. Create the veth before the CT is started, then start the CT, then add the veth number which was created by the add script? Edit -- tried that and it seems to work: root@pve1:~# vzctl start 103 Starting container ... Container is...

More info. The vlan11 stanza was still in /etc/network/interfaces after removing with ovs-vsctl, so I rebooted the host. Now vlan11 is back, but both tap100 interfaces are gone: -------------- ovs-vsctl show --------------------- 7ab123e0-eb12-4059-83df-2a55452c7075 Bridge "vmbr0"...

I was wondering if this might be easier using a Fake Bridge http://blog.scottlowe.org/2012/10/19/vlans-with-open-vswitch-fake-bridges/ but it looks like Fake Bridges might actually be the same thing as IntPorts. vlan11 was created using the GUI as an OVS IntPort. I added a Fake Bridge called...

Manually adding veth103.0 to the bridge produces a similar result: NETIF="ifname=eth0.11,bridge=vmbr0,mac=1A:51:BD:C6:72:C4,host_ifname=veth103.0,host_mac=1E:B7:F2:56:64:F1" root@pve1:~# ovs-vsctl add-port vmbr0 veth103.0 tag=11 root@pve1:~# vzctl start 103 Starting container ... Container is...

We seem to be in need of better documentation on VLANs. I added a veth named eth0.11 to the CT using the GUI, which resulted in NETIF="ifname=eth0.11,bridge=vmbr0,mac=B2:22:94:55:C5:1A,host_ifname=veth103.0,host_mac=5E:40:2E:73:86:77" When I start that CT from the GUI, I see an 'OK' in the...