We only have about 200 VMs, but we’ve run into this bug [1] because we use a high number of direct attach luns on our VMs. It takes about 5 minutes to scan all the fibre channel luns (same issues exists with iSCSI) and used times out before completing (until we changed the value of vdsTimeout higher).
Also because of the way our FC storage is presented, we have about 1,400 multipath devices presented to each host. This contributes to really long scan times and I think causes some general slowness in administration side and “Bad Request” 500 Errors when running some storage commands from the API. VMs themselves still run just fine with no noticeable performance issues though. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1217401 From: Patrick Russell [mailto:patrick_russ...@volusion.com] Sent: Tuesday, August 18, 2015 3:07 PM To: Matthew Lagoe Cc: Groten, Ryan; users@ovirt.org Subject: Re: [ovirt-users] Benefits of Cluster separation Can I ask at what scale you’re running into issues? We’ve got about 500 VM’s running now in a single cluster. -Patrick On Aug 18, 2015, at 4:03 PM, Matthew Lagoe <matthew.la...@subrigo.net<mailto:matthew.la...@subrigo.net>> wrote: You can have different cluster policy’s at least, don’t know what other benefits there are however as I haven’t noticed any. From: users-boun...@ovirt.org<mailto:users-boun...@ovirt.org> [mailto:users-boun...@ovirt.org] On Behalf Of Groten, Ryan Sent: Tuesday, August 18, 2015 01:59 PM To: users@ovirt.org<mailto:users@ovirt.org> Subject: [ovirt-users] Benefits of Cluster separation We’re running into some performance problems stemming from having too many Hosts/VMs/Disks running from the same Datacenter/Cluster. Because of that I’m looking into splitting the DC into multiple separate ones with different Hosts/Storage. But I’m a little confused what the benefit of separating hosts into clusters achieves. Can someone please explain what the common use cases are? Since all the clusters in a DC seem to need to see the same storage, I don’t think it would help my situation anyway. Thanks, Ryan _______________________________________________ Users mailing list Users@ovirt.org<mailto:Users@ovirt.org> http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
