(Fairly new user of Kimchi, with first impressions) Is there a good location for documentation? It seems difficult to make a new ISO available, or I chose a poor way. - I downloaded from an FTP site requiring non-anonymous authentication - I scp'd it to root@host - I tried to use it from there, but I got permission denied "KCHISO0008E: The hypervisor doesn't have permission to use this ISO /root/..." - the message above recommends copying the file to /var/lib/libvirt, but I think you actually have to copy it to /var/lib/libvirt/images - you also need to "chown qemu" the ISO image After the above steps, it finally became visible and usable. Further feedback: - The above error message appears as a bright pop-over with a nice 'X' for dismissing, but it automatically disappears so quickly, it's impossible to read the entire message - in the "Edit Template" dialog, what is "CPU Number"? I presume that is "number of (virtual) processors"? - in the "Edit Template" dialog, what are the units for "Memory"? It is apparently megabytes, but that should be noted Regards, Paul Clarke, IBM
Welcome to Kimchi and thanks for the feedback! I can answer part of your questions. On 06/05/2014 10:53 AM, Paul Clarke wrote:
(Fairly new user of Kimchi, with first impressions)
Is there a good location for documentation? At the top right corner, clicking your user name and there's a pop-up
menu which contains a "Help" item. It will show help documentation for the current tab where you are.
It seems difficult to make a new ISO available, or I chose a poor way. - I downloaded from an FTP site requiring non-anonymous authentication - I scp'd it to root@host - I tried to use it from there, but I got permission denied "KCHISO0008E: The hypervisor doesn't have permission to use this ISO /root/..."
- the message above recommends copying the file to /var/lib/libvirt, but I think you actually have to copy it to /var/lib/libvirt/images
- you also need to "chown qemu" the ISO image
After the above steps, it finally became visible and usable.
Further feedback: - The above error message appears as a bright pop-over with a nice 'X' for dismissing, but it automatically disappears so quickly, it's impossible to read the entire message ACK. It will disappear automatically after some fixed seconds, which is not good for long messages.
- in the "Edit Template" dialog, what is "CPU Number"? I presume that is "number of (virtual) processors"? Yes. It means number of virtual processor cores e.g. 1-core processor, 2-core processor, 4-core processor, etc.
- in the "Edit Template" dialog, what are the units for "Memory"? It is apparently megabytes, but that should be noted ACK. The unit is lost.
Regards, Paul Clarke, IBM
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
(Fairly new user of Kimchi, with first impressions)
Is there a good location for documentation? Global product 'help' and 'about' should be visible all the time at the
On 6/5/2014 10:53 AM, Paul Clarke wrote: header. Design should be changed as below and move 'help' and 'about' content below help menu.
It seems difficult to make a new ISO available, or I chose a poor way. - I downloaded from an FTP site requiring non-anonymous authentication - I scp'd it to root@host - I tried to use it from there, but I got permission denied "KCHISO0008E: The hypervisor doesn't have permission to use this ISO /root/..."
- the message above recommends copying the file to /var/lib/libvirt, but I think you actually have to copy it to /var/lib/libvirt/images
- you also need to "chown qemu" the ISO image
After the above steps, it finally became visible and usable.
For current kimchi security model design, root users on behalf of console administrator, they are responsible for 1. host setup for virtualization infrastructure and console administration 2. virtualization resources setup I think this process should be streamlined for better user experience. I recommend to make "chown qemu" transparent with kimchi to handle it automatically.
Further feedback: - The above error message appears as a bright pop-over with a nice 'X' for dismissing, but it automatically disappears so quickly, it's impossible to read the entire message
should be controlled by user.
- in the "Edit Template" dialog, what is "CPU Number"? I presume that is "number of (virtual) processors"?
- in the "Edit Template" dialog, what are the units for "Memory"? It is apparently megabytes, but that should be noted
Regards, Paul Clarke, IBM
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
on 2014/06/05 16:10, Yu Xin Huo wrote:
(Fairly new user of Kimchi, with first impressions)
Is there a good location for documentation? Global product 'help' and 'about' should be visible all the time at the header. Design should be changed as below and move 'help' and 'about' content below help
On 6/5/2014 10:53 AM, Paul Clarke wrote: menu.
It seems difficult to make a new ISO available, or I chose a poor way. - I downloaded from an FTP site requiring non-anonymous authentication - I scp'd it to root@host - I tried to use it from there, but I got permission denied "KCHISO0008E: The hypervisor doesn't have permission to use this ISO /root/..."
- the message above recommends copying the file to /var/lib/libvirt, but I think you actually have to copy it to /var/lib/libvirt/images
- you also need to "chown qemu" the ISO image
After the above steps, it finally became visible and usable.
For current kimchi security model design, root users on behalf of console administrator, they are responsible for 1. host setup for virtualization infrastructure and console administration 2. virtualization resources setup
I think this process should be streamlined for better user experience. I recommend to make "chown qemu" transparent with kimchi to handle it automatically.
The user also has to add "x" for QEMU on each level of the directory that contains the ISO image. Though this can be done by Kimchi automatically, it's possible that the user accidentally revokes the "x" from the directory and change the owner of the ISO image. The problem here is that the downloaded ISO is out of backend management. In this case, Kimchi is used as a desktop virtualization management soft. Libvirt already provides a "session" mode to solve desktop virtualization privilege problem. We can have the Kimchi backend create the VM in "session" mode, so that the VM gets the same privilege as the user, and it's able to read the ISO image. Another solution is that we provide an ISO upload interface to allow user to upload the image from his home directory to Kimchi backend. Then Kimchi store the image in /var/lib/libvirt/images and take over the control. This solution keeps Kimchi in the server virtualization way, which is its original orientation, to compete with XXWare server.
Further feedback: - The above error message appears as a bright pop-over with a nice 'X' for dismissing, but it automatically disappears so quickly, it's impossible to read the entire message
should be controlled by user.
- in the "Edit Template" dialog, what is "CPU Number"? I presume that is "number of (virtual) processors"?
- in the "Edit Template" dialog, what are the units for "Memory"? It is apparently megabytes, but that should be noted
Regards, Paul Clarke, IBM
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Zhou Zheng Sheng / 周征晟 E-mail: zhshzhou@linux.vnet.ibm.com Telephone: 86-10-82454397
On 06/05/2014 03:36 AM, Zhou Zheng Sheng wrote:
It seems difficult to make a new ISO available, or I chose a poor way. - I downloaded from an FTP site requiring non-anonymous authentication - I scp'd it to root@host - I tried to use it from there, but I got permission denied "KCHISO0008E: The hypervisor doesn't have permission to use this ISO /root/..."
- the message above recommends copying the file to /var/lib/libvirt, but I think you actually have to copy it to /var/lib/libvirt/images
- you also need to "chown qemu" the ISO image
After the above steps, it finally became visible and usable.
For current kimchi security model design, root users on behalf of console administrator, they are responsible for 1. host setup for virtualization infrastructure and console administration 2. virtualization resources setup
I think this process should be streamlined for better user experience. I recommend to make "chown qemu" transparent with kimchi to handle it automatically.
The user also has to add "x" for QEMU on each level of the directory that contains the ISO image. Though this can be done by Kimchi automatically, it's possible that the user accidentally revokes the "x" from the directory and change the owner of the ISO image. The problem here is that the downloaded ISO is out of backend management.
In this case, Kimchi is used as a desktop virtualization management soft. Libvirt already provides a "session" mode to solve desktop virtualization privilege problem. We can have the Kimchi backend create the VM in "session" mode, so that the VM gets the same privilege as the user, and it's able to read the ISO image.
Another solution is that we provide an ISO upload interface to allow user to upload the image from his home directory to Kimchi backend. Then Kimchi store the image in /var/lib/libvirt/images and take over the control. This solution keeps Kimchi in the server virtualization way, which is its original orientation, to compete with XXWare server.
This may be complicated by limitations of HTTP. There may be some sort of maximum size permitted which is at or below the typical size of an Linux installation ISO image. I'm not knowledgeable in that area, but I've seen issues like that. Regards, Paul Clarke
on 2014/06/06 02:33, Paul Clarke wrote:
On 06/05/2014 03:36 AM, Zhou Zheng Sheng wrote:
It seems difficult to make a new ISO available, or I chose a poor way. - I downloaded from an FTP site requiring non-anonymous authentication - I scp'd it to root@host - I tried to use it from there, but I got permission denied "KCHISO0008E: The hypervisor doesn't have permission to use this ISO /root/..."
- the message above recommends copying the file to /var/lib/libvirt, but I think you actually have to copy it to /var/lib/libvirt/images
- you also need to "chown qemu" the ISO image
After the above steps, it finally became visible and usable.
For current kimchi security model design, root users on behalf of console administrator, they are responsible for 1. host setup for virtualization infrastructure and console administration 2. virtualization resources setup
I think this process should be streamlined for better user experience. I recommend to make "chown qemu" transparent with kimchi to handle it automatically.
The user also has to add "x" for QEMU on each level of the directory that contains the ISO image. Though this can be done by Kimchi automatically, it's possible that the user accidentally revokes the "x" from the directory and change the owner of the ISO image. The problem here is that the downloaded ISO is out of backend management.
In this case, Kimchi is used as a desktop virtualization management soft. Libvirt already provides a "session" mode to solve desktop virtualization privilege problem. We can have the Kimchi backend create the VM in "session" mode, so that the VM gets the same privilege as the user, and it's able to read the ISO image.
Another solution is that we provide an ISO upload interface to allow user to upload the image from his home directory to Kimchi backend. Then Kimchi store the image in /var/lib/libvirt/images and take over the control. This solution keeps Kimchi in the server virtualization way, which is its original orientation, to compete with XXWare server.
This may be complicated by limitations of HTTP. There may be some sort of maximum size permitted which is at or below the typical size of an Linux installation ISO image. I'm not knowledgeable in that area, but I've seen issues like that.
Hi, In vanilla HTTP 1.1 protocol there is no limitation. Usually the limitation is forced by the browser, web server or the application framework. This technical issue can be solved in many ways. The problem I think is that malicious users can perform DoS attack to cause the server runs out of space. If we are to go this way, maybe we have to add some constrains, and only allow the root user to upload ISO files.
Regards, Paul Clarke
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 06/05/2014 03:10 AM, Yu Xin Huo wrote:
Is there a good location for documentation? Global product 'help' and 'about' should be visible all the time at the
On 6/5/2014 10:53 AM, Paul Clarke wrote: header. Design should be changed as below and move 'help' and 'about' content below help menu.
I think that is a good idea, as I would not expect "Help" to be an attribute of the user. Regards, Paul Clarke
On 06/05/2014 10:53 AM, Paul Clarke wrote:
(Fairly new user of Kimchi, with first impressions)
Is there a good location for documentation?
It seems difficult to make a new ISO available, or I chose a poor way. - I downloaded from an FTP site requiring non-anonymous authentication - I scp'd it to root@host you scp it, so I think maybe only root can access this ISO. Actually we can let kimchi set qemu to access this ISO, by "setfacl" command. but on some distro this may fail. kimchi can also set all users to access ISO, but this is not good. only user can decide who can access it.
- I tried to use it from there, but I got permission denied "KCHISO0008E: The hypervisor doesn't have permission to use this ISO /root/..."
- the message above recommends copying the file to /var/lib/libvirt, but I think you actually have to copy it to /var/lib/libvirt/images
yes, you can copy it to /var/lib/libvirt/images or make a new path /var/lib/libvirt/iso, and copy it to this new path. it should OK
- you also need to "chown qemu" the ISO image
After the above steps, it finally became visible and usable.
Further feedback: - The above error message appears as a bright pop-over with a nice 'X' for dismissing, but it automatically disappears so quickly, it's impossible to read the entire message
- in the "Edit Template" dialog, what is "CPU Number"? I presume that is "number of (virtual) processors"?
- in the "Edit Template" dialog, what are the units for "Memory"? It is apparently megabytes, but that should be noted
Patch send. thanks.
Regards, Paul Clarke, IBM
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Thanks and best regards! Sheldon Feng(冯少合)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
Hi Paul, Thanks for feedback of these issues. The issues you mentioned are: 1. There is no convenient way to upload a image. 2. When image is uploaded, too complex to fix its permission and get it work. 3. Warning msg disappear too quickly to see. As 1 and 2 are related to a feature I'm working on, I want to share with you our proposal and see if you like it from view of user: 1. convenient way to upload image: (1) As flow of : ISO server--download-->your laptop--upload-->your server is too long, we will supply with a dialog to let users to fill a web link and kimchi server will downloaded from the ISO server. So the flow becomes: ISO server--download-->your virtualization server number of download sessions will be limited. (2) An upload interface will also be provided if you want to upload ISO from your laptop. also number of sessions will be limited 2. complex permission fix problem: A dedicate directory will created for ISOs, and this directory will be monitored, if an ISO is scp to this directory, monitor will call a script to change permission. and for 3, I think we can add a box to store historical error msg (10 items restored), so that user won't miss the latest ones. Aline, If we are good with my proposal, can I add it to the plan of next print? On 2014年06月05日 10:53, Paul Clarke wrote:
(Fairly new user of Kimchi, with first impressions)
Is there a good location for documentation?
It seems difficult to make a new ISO available, or I chose a poor way. - I downloaded from an FTP site requiring non-anonymous authentication - I scp'd it to root@host - I tried to use it from there, but I got permission denied "KCHISO0008E: The hypervisor doesn't have permission to use this ISO /root/..."
- the message above recommends copying the file to /var/lib/libvirt, but I think you actually have to copy it to /var/lib/libvirt/images
- you also need to "chown qemu" the ISO image
After the above steps, it finally became visible and usable.
Further feedback: - The above error message appears as a bright pop-over with a nice 'X' for dismissing, but it automatically disappears so quickly, it's impossible to read the entire message
- in the "Edit Template" dialog, what is "CPU Number"? I presume that is "number of (virtual) processors"?
- in the "Edit Template" dialog, what are the units for "Memory"? It is apparently megabytes, but that should be noted
Regards, Paul Clarke, IBM
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Royce, thanks for your very helpful reply... On 06/05/2014 10:11 PM, Royce Lv wrote:
The issues you mentioned are: 1. There is no convenient way to upload a image. 2. When image is uploaded, too complex to fix its permission and get it work. 3. Warning msg disappear too quickly to see.
As 1 and 2 are related to a feature I'm working on, I want to share with you our proposal and see if you like it from view of user: 1. convenient way to upload image: (1) As flow of : ISO server--download-->your laptop--upload-->your server is too long, we will supply with a dialog to let users to fill a web link and kimchi server will downloaded from the ISO server. So the flow becomes: ISO server--download-->your virtualization server number of download sessions will be limited.
Will this allow for authenticated access (userid, password) as well? If so, this sounds good to me. Some users may not be willing to give Kimchi their credentials, so they will have to use the upload interface you describe below. I think this is fine, and still better than today.
(2) An upload interface will also be provided if you want to upload ISO from your laptop. also number of sessions will be limited
Is the limit to avoid DoS attacks? Will you make the limit configurable? Regardless, this sounds good.
2. complex permission fix problem: A dedicate directory will created for ISOs, and this directory will be monitored, if an ISO is scp to this directory, monitor will call a script to change permission.
Will the monitoring be done passively, via inotify, or actively via polling? If the latter, I worry about the performance impacts on the system and the time gap between when the file has been completely copied and when the permissions have changed so that the file is usable. This gap needs to be as close to zero as possible.
and for 3, I think we can add a box to store historical error msg (10 items restored), so that user won't miss the latest ones.
I would prefer the message stay on the screen until explicitly dismissed by the user. It already has the 'X' button for dismissal. Is there a good reason _not_ to leave the message displayed indefinitely? This is an error message for a failed action for which remedial action must be taken by the user. Regards, Paul Clarke
On 2014年06月06日 12:41, Paul Clarke wrote:
Royce, thanks for your very helpful reply...
On 06/05/2014 10:11 PM, Royce Lv wrote:
The issues you mentioned are: 1. There is no convenient way to upload a image. 2. When image is uploaded, too complex to fix its permission and get it work. 3. Warning msg disappear too quickly to see.
As 1 and 2 are related to a feature I'm working on, I want to share with you our proposal and see if you like it from view of user: 1. convenient way to upload image: (1) As flow of : ISO server--download-->your laptop--upload-->your server is too long, we will supply with a dialog to let users to fill a web link and kimchi server will downloaded from the ISO server. So the flow becomes: ISO server--download-->your virtualization server number of download sessions will be limited.
Will this allow for authenticated access (userid, password) as well? I think so, and for upload in (2), in the future it will need authentication as well(I assume), because this action is related to system administration.
If so, this sounds good to me. Some users may not be willing to give Kimchi their credentials, so they will have to use the upload interface you describe below. I think this is fine, and still better than today. If you are referring to credential in other website, I think currently we will just cover some well known website without passwd validation, such as fedora official ftp and so on.
(2) An upload interface will also be provided if you want to upload ISO from your laptop. also number of sessions will be limited
Is the limit to avoid DoS attacks? Will you make the limit configurable? True, and we don't want network performance downgrade by too much upload or download. Making it configurable is a great idea.
Regardless, this sounds good.
2. complex permission fix problem: A dedicate directory will created for ISOs, and this directory will be monitored, if an ISO is scp to this directory, monitor will call a script to change permission.
Will the monitoring be done passively, via inotify, or actively via polling? If the latter, I worry about the performance impacts on the system and the time gap between when the file has been completely copied and when the permissions have changed so that the file is usable. This gap needs to be as close to zero as possible. I tend to use inotify hook script to handle this so that we don't need to periodically polling.
and for 3, I think we can add a box to store historical error msg (10 items restored), so that user won't miss the latest ones.
I would prefer the message stay on the screen until explicitly dismissed by the user. It already has the 'X' button for dismissal. Is there a good reason _not_ to leave the message displayed indefinitely? This is an error message for a failed action for which remedial action must be taken by the user. Your suggestion is reasonable, above is just my humble opinion:),and I'm not a UI expert, maybe you and our UI team can take a look at a more nature and comfortable experience.
Regards, Paul Clarke
On 06/06/2014 12:11 AM, Royce Lv wrote:
Hi Paul,
Thanks for feedback of these issues. The issues you mentioned are: 1. There is no convenient way to upload a image. 2. When image is uploaded, too complex to fix its permission and get it work. 3. Warning msg disappear too quickly to see.
As 1 and 2 are related to a feature I'm working on, I want to share with you our proposal and see if you like it from view of user: 1. convenient way to upload image: (1) As flow of : ISO server--download-->your laptop--upload-->your server is too long, we will supply with a dialog to let users to fill a web link and kimchi server will downloaded from the ISO server. So the flow becomes: ISO server--download-->your virtualization server number of download sessions will be limited.
(2) An upload interface will also be provided if you want to upload ISO from your laptop. also number of sessions will be limited
2. complex permission fix problem: A dedicate directory will created for ISOs, and this directory will be monitored, if an ISO is scp to this directory, monitor will call a script to change permission.
and for 3, I think we can add a box to store historical error msg (10 items restored), so that user won't miss the latest ones.
Aline, If we are good with my proposal, can I add it to the plan of next print?
Royce, you can add all your ideas to our Backlog so we can use it during the next release plan. We are in the last sprint before 1.2.1 release, so we should keep focus on 1.2.1 tasks. But of course, your ideas are aligned with what we discussed in the last scrum meeting.
On 2014年06月05日 10:53, Paul Clarke wrote:
(Fairly new user of Kimchi, with first impressions)
Is there a good location for documentation?
It seems difficult to make a new ISO available, or I chose a poor way. - I downloaded from an FTP site requiring non-anonymous authentication - I scp'd it to root@host - I tried to use it from there, but I got permission denied "KCHISO0008E: The hypervisor doesn't have permission to use this ISO /root/..."
- the message above recommends copying the file to /var/lib/libvirt, but I think you actually have to copy it to /var/lib/libvirt/images
- you also need to "chown qemu" the ISO image
After the above steps, it finally became visible and usable.
Further feedback: - The above error message appears as a bright pop-over with a nice 'X' for dismissing, but it automatically disappears so quickly, it's impossible to read the entire message
- in the "Edit Template" dialog, what is "CPU Number"? I presume that is "number of (virtual) processors"?
- in the "Edit Template" dialog, what are the units for "Memory"? It is apparently megabytes, but that should be noted
Regards, Paul Clarke, IBM
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 06/05/2014 10:53 AM, Paul Clarke wrote:
(Fairly new user of Kimchi, with first impressions)
Is there a good location for documentation?
It seems difficult to make a new ISO available, or I chose a poor way. - I downloaded from an FTP site requiring non-anonymous authentication - I scp'd it to root@host - I tried to use it from there, but I got permission denied "KCHISO0008E: The hypervisor doesn't have permission to use this ISO /root/..."
- the message above recommends copying the file to /var/lib/libvirt, but I think you actually have to copy it to /var/lib/libvirt/images
- you also need to "chown qemu" the ISO image Discuss with Royce Lv. We think the error message misleads you. You do not need copy file to /var/lib/libvirt/images. it can in any directory. just set the ISO image permission for qmeu user.
The simply way is just as follow: $ sudo chmod a+xr /yourpatch/youriso -R or $ sudo chmod a+x /yourpatch/ -R $ sudo chmod a+r /yourpatch/youriso # "chown qemu" is also OK or setfacl $ setfacl -R -m u:qemu:rx /yourpatch/youriso To Yu Xin and Hongliang The above error message does dismiss so quickly.
After the above steps, it finally became visible and usable.
Further feedback: - The above error message appears as a bright pop-over with a nice 'X' for dismissing, but it automatically disappears so quickly, it's impossible to read the entire message
- in the "Edit Template" dialog, what is "CPU Number"? I presume that is "number of (virtual) processors"?
- in the "Edit Template" dialog, what are the units for "Memory"? It is apparently megabytes, but that should be noted
Regards, Paul Clarke, IBM
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Thanks and best regards! Sheldon Feng(冯少合)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
On 06/05/2014 10:53 AM, Paul Clarke wrote:
(Fairly new user of Kimchi, with first impressions)
Is there a good location for documentation?
It seems difficult to make a new ISO available, or I chose a poor way. - I downloaded from an FTP site requiring non-anonymous authentication - I scp'd it to root@host - I tried to use it from there, but I got permission denied "KCHISO0008E: The hypervisor doesn't have permission to use this ISO /root/..."
- the message above recommends copying the file to /var/lib/libvirt, but I think you actually have to copy it to /var/lib/libvirt/images
- you also need to "chown qemu" the ISO image Discuss with Royce Lv. We think the error message misleads you. You do not need copy file to /var/lib/libvirt/images. it can in any directory. just set the ISO image permission for qmeu user.
The simply way is just as follow: $ sudo chmod a+xr /yourpatch/youriso -R
or $ sudo chmod a+x /yourpatch/ -R $ sudo chmod a+r /yourpatch/youriso # "chown qemu" is also OK
or setfacl $ setfacl -R -m u:qemu:rx /yourpatch/youriso Once the iso image file is searched out, in UI, we can add label/icon to indicate the permission issue. Also we can add an action in UI for user to add the permission for qmeu
On 6/9/2014 1:11 PM, Sheldon wrote: directly. To me from kimchi security model, only root users who is on behalf of kimchi admin can create template, so when create template, add permission for qemu directly at backend.
To Yu Xin and Hongliang The above error message does dismiss so quickly.
error message is critical for user to troubleshoot the issue, it should be controlled by user rather than dismissed automatically. I am trying to figure out the error notification area, will get a mockup out soon for discussion.
After the above steps, it finally became visible and usable.
Further feedback: - The above error message appears as a bright pop-over with a nice 'X' for dismissing, but it automatically disappears so quickly, it's impossible to read the entire message
- in the "Edit Template" dialog, what is "CPU Number"? I presume that is "number of (virtual) processors"?
- in the "Edit Template" dialog, what are the units for "Memory"? It is apparently megabytes, but that should be noted
Regards, Paul Clarke, IBM
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
participants (7)
-
Aline Manera -
Hongliang Wang -
Paul Clarke -
Royce Lv -
Sheldon -
Yu Xin Huo -
Zhou Zheng Sheng