Demeter Tibor píše v Po 17. 11. 2014 v 14:10 +0100:
> Hello,
>
> Thank you for the detailed reply.
>
> Yes, the vms are used an independent network/network interfaces for access the internet.
> So, in this case I could separate the high glusterfs traffic from ovirt management traffic when I disable "vm" network on ovirtmgmt interface.
>
> I will try-out this night this feature.

Hi,

you can try it only if you don't have hosted engine ;)

Cheers,

Luf

>
> Thanks a lot,
>
> Tibor
>
>
>
> ----- Eredeti üzenet -----
> > Hi Tibor,
> >
> > On 13/11/14 13:41, Demeter Tibor wrote:
> > > Hi,
> > >
> > > I have a 3 node gluster based cluster. There are 3x3 Nic with bonding.
> > > Sometimes the management is very slow because high gluster traffic.
> > >
> > > Is it possible to separate ovirtmgmt network from glusterfs traffic?
> > > I have only one interface (ovirtmgmt) for all of services (migration, etc).
> > > I just wondering I will make three VLANs for these services and use the
> > > QoS function. But how can specify glusterfs for use an other vlan for
> > > gluster traffic an a other one for management?
> >
> > This generally sounds like a good plan, but note that QoS on the
> > host-level will only become available in oVirt 3.6 (it might become
> > available soon on master, if you're feeling lucky...).
> >
> > VM-level QoS (available since 3.3) won't help you with "administrative"
> > traffic (i.e. traffic that isn't going into / coming out of the VMs
> > themselves).
> >
> > > Also, I have more questions about this:
> > >
> > > - If I specify a VLAN on ovirtmgmt, then what happend on nodes? I'm
> > > afraid the nodes will lost the connection with each other nodes.
> >
> > If the switch allows this VLAN to reach all hosts, there shouldn't be a
> > problem; since oVirt 3.4 the VLAN tagging should "propagate" to all
> > active hosts. However, see my comment below concerning "VM network".
> >
> > > - Is it possible on a live system? What will happen with the mounted
> > > glustefs based datastores?
> >
> > I'm not knowledgeable about gluster specifics, but let's see if I can
> > help. What's the current situation with the gluster network, is it
> > already VLAN-tagged? If it is and you're not moving it to another
> > interface on the hosts, I *think* things should be fine.
> >
> > > - What does "vm network" mean on ovirtmgmt interface? Can I use this for
> > > seperate network traffic?
> >
> > This means that a bridge is created for this network on hosts. If VMs
> > don't use this network (i.e. virtual interfaces are assigned profiles of
> > ovirtmgmt), you can make it non-VM (with no VLAN tagging) and have it
> > assigned to the same host interface as VLAN-tagged networks (I would say
> > this is less risky than VLAN-tagging ovirtmgmt).
> >
> > >
> > >
> > > My plan is
> > > - vlan.101 ovirtmgmt
> > > - vlan 102 glusterfs
> > > - vlan 103 migration
> > > - vlan 104 display
> > >
> > > What is the recommended procedure of this?
> > >
> > > Thanks in advance,
> > >
> > > Regards,
> > >
> > > Tibor
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Users mailing list
> > > Users@ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/users
> > >
> > _______________________________________________
> > Users mailing list
> > Users@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
> >
> _______________________________________________
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users


NOTICE: This email and any attachments may contain confidential and proprietary information of NetSuite Inc. and is for the sole use of the intended recipient for the stated purpose. Any improper use or distribution is prohibited. If you are not the intended recipient, please notify the sender; do not review, copy or distribute; and promptly delete or destroy all transmitted information. Please note that all communications and information transmitted through this email system may be monitored and retained by NetSuite or its agents and that all incoming email is automatically scanned by a third party spam and filtering service which may result in deletion of a legitimate e-mail before it is read by the intended recipient.