9:53 p.m.
(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
10:06 p.m.
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
3:10 a.m.
On 6/5/2014 10:53 AM, Paul Clarke 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 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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
3:36 a.m.
on 2014/06/05 16:10, Yu Xin Huo wrote:
On 6/5/2014 10:53 AM, Paul Clarke 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
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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
--
Zhou Zheng Sheng / 周征晟
E-mail: zhshzhou(a)linux.vnet.ibm.com
Telephone: 86-10-82454397
1:33 p.m.
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
9:22 p.m.
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
1:33 p.m.
On 06/05/2014 03:10 AM, Yu Xin Huo wrote:
On 6/5/2014 10:53 AM, Paul Clarke wrote:
> 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 menu.
I think that is a good idea, as I would not expect "Help" to be an
attribute of the user.
Regards,
Paul Clarke
3:48 a.m.
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
--
Thanks and best regards!
Sheldon Feng(冯少合)<shaohef(a)linux.vnet.ibm.com>
IBM Linux Technology Center
10:11 p.m.
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
11:41 p.m.
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
2:20 a.m.
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
11:04 a.m.
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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>
12:11 a.m.
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
--
Thanks and best regards!
Sheldon Feng(冯少合)<shaohef(a)linux.vnet.ibm.com>
IBM Linux Technology Center
4:50 a.m.
On 6/9/2014 1:11 PM, Sheldon wrote:
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
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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>
>
>
3849
days inactive
3853
days old
13 comments
7 participants
participants (7)
-
Aline Manera -
Hongliang Wang -
Paul Clarke -
Royce Lv -
Sheldon -
Yu Xin Huo -
Zhou Zheng Sheng