INSTALL.rst needs update WRT storage pool

[henn]

Following the directions under Headnode image, it says to add a new storage pool pointing to /var/lib/libvirt/images via pool.xml.

Following this on a default CentOS 6.5 node, I get the following error:

error: Failed to define pool from pool.xml
error: operation failed: Storage source conflict with pool: 'default'

To solve this, I suggest creating a separate directory called /var/lib/livirt/haas-images, which will help to separate the HaaS images from any the system might otherwise be using.

[henn]

Also, the instructions need to be updated to reflect that CentOS does not have a libvirt user by default.

[henn]

... and there should be a reference to the haas.cfg base_imgs in the Headnode section

[zenhack]

This might be an artifact of the fact that there was a previous installation on the MRI node -- I ran through the instructions top to bottom many times and never hit that.

re: libvirt user -- the instructions are fairly clear that you need to create the group, and you don't need the user -- adding the haas user to that group is sufficient.

Adding a reminder re: base_imgs near the image definition bit is a good idea.

[zenhack]

If we just add a thing after the giant chunk of xml example to the effect of "be sure to add the value of <name> to the base_imgs option in haas.cfg", will that be sufficient?

[henn]

Sorry that I didn't see your previous comment.

re: the original issue, it's more of a styling/separation of the headnode VMs from any other libvirt VMs the system might have. Having a separate libvirt images directory allows the admin to maintain separate permissions for the headnodes from the rest of the system, keeping the haas user from being able to modify them. We can take or leave that suggestion since we plan to separate headnodes out of the base haas anyhow.

re: libvirt user, perhaps we should replace user with group then for this line:

The directory specified by path must already exist, and be readable and writable by the libvirt user

re: adding <name> to base_imgs, that sounds good!

[zenhack]

I think I'd rather not bother trying to support nice-to-have enhancements to the headnode subsystem at least until we tease it out into a separate package.

clearly something is amiss with the line you're quoting, since there is no libvirt user (including on our functioning setups). I'll comment again once I've looked at it and regained some context.

[xuhang57]

This would relate to #392
and #908