On Thu, Sep 14, 2017 at 12:56:30PM +0200, Peter Krempa wrote: > On Thu, Sep 14, 2017 at 16:37:03 +0800, Liu Qing wrote: > > On Thu, Sep 14, 2017 at 10:02:40AM +0200, Peter Krempa wrote: > > > On Thu, Sep 14, 2017 at 09:29:28 +0200, Peter Krempa wrote: > > [...] > > > > One more thing. The design you've proposed is really not user friendly. > > > The user has to read a lenghty document, then inquire the parameters for > > > every single qcow2 image, do the calculations and set it in the XML. > > > This might be okay for higher level management tools, but not for users > > > who use libvirt directly. > > I agree this is not user friendly. I only give the user a choice, maybe > > not the best, right now. Any suggestion will be greatly appreicated. > > For our company, this feature will be an add-on to Openstack. > > This means that you will have to deal with everything that I've pointed > out. How are you planning to expose this to the user? And which > calculations are you going to use? We will not expose this to the user on Openstack level. We have different volume types like performance and capacity. For performance volumes we will cache as much space as possible. Free memory left in the host will be counted in. For capacity volume we will set a max cache size. The cache setting strategy be implemented in a higher level management tool seems much resaonable to me. As this will be much more flexible. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
