April 2015 - Kimchi-devel - oVirt List Archives

[PATCH] Add %Used in header in Storage tab
by Socorro Stoppler 13 Apr '15

13 Apr '15

From: Socorro Stoppler <socorrob(a)us.ibm.com> Socorro Stoppler (1): Add %Used in the header for storage ui/css/theme-default/storage.css | 5 +++++ ui/pages/tabs/storage.html.tmpl | 5 ++++- 2 files changed, 9 insertions(+), 1 deletion(-) -- 1.9.1

2 3

[PATCH] Create empty files on rpm build
by Ramon Medeiros 10 Apr '15

10 Apr '15

Issue #496 - System leftovers after uninstalling Kimchi A rpm does not remove files that are not created by the installation. So, all the files were provided by the package and now they can be uninstalled. Beyond this, the function that creates the proxy conf now accepts empty files to fill the configuration. Signed-off-by: Ramon Medeiros <ramonn(a)linux.vnet.ibm.com> --- contrib/kimchi.spec.fedora.in | 9 +++++++++ src/kimchi/proxy.py | 4 +++- 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/contrib/kimchi.spec.fedora.in b/contrib/kimchi.spec.fedora.in index 9f7bb59..d06c771 100644 --- a/contrib/kimchi.spec.fedora.in +++ b/contrib/kimchi.spec.fedora.in @@ -92,6 +92,12 @@ mkdir -p %{buildroot}/%{_localstatedir}/log/kimchi/ touch %{buildroot}/%{_localstatedir}/log/kimchi/kimchi-access.log touch %{buildroot}/%{_localstatedir}/log/kimchi/kimchi-error.log +# create /etc/kimchi structure +mkdir -p %{buildroot}/%{_sysconfdir}/kimchi/ +touch %{buildroot}/%{_sysconfdir}/kimchi/kimchi-cert.pem +touch %{buildroot}/%{_sysconfdir}/kimchi/kimchi-key.pem +touch %{buildroot}/%{_sysconfdir}/kimchi/nginx_kimchi.conf + # Install the systemd scripts install -Dm 0644 contrib/kimchid.service.fedora %{buildroot}%{_unitdir}/kimchid.service install -Dm 0640 src/firewalld.xml %{buildroot}%{_prefix}/lib/firewalld/services/kimchid.xml @@ -161,6 +167,9 @@ rm -rf $RPM_BUILD_ROOT %{_sysconfdir}/kimchi/distros.d/opensuse.json %{_sysconfdir}/kimchi/distros.d/ubuntu.json %{_sysconfdir}/kimchi/distros.d/gentoo.json +%{_sysconfdir}/kimchi/kimchi-cert.pem +%{_sysconfdir}/kimchi/kimchi-key.pem +%{_sysconfdir}/kimchi/nginx_kimchi.conf %{_sysconfdir}/kimchi/ %{_sharedstatedir}/kimchi/debugreports/ %{_sharedstatedir}/kimchi/screenshots/ diff --git a/src/kimchi/proxy.py b/src/kimchi/proxy.py index fafa5bc..ecf351c 100644 --- a/src/kimchi/proxy.py +++ b/src/kimchi/proxy.py @@ -60,8 +60,10 @@ def _create_proxy_config(options): if not cert or not key: cert = '%s/kimchi-cert.pem' % config_dir key = '%s/kimchi-key.pem' % config_dir + # create cert files if they don't exist - if not os.path.exists(cert) or not os.path.exists(key): + if not (os.path.exists(cert) and len(open(cert).read()) > 0) or \ + not (os.path.exists(key) and len(open(key).read()) > 0): ssl_gen = sslcert.SSLCert() with open(cert, "w") as f: f.write(ssl_gen.cert_pem()) -- 1.8.3.1

1 0

[PATCH] Security: Prevent Bar Mitzvah attacks by disabling RC4
by Aline Manera 07 Apr '15

07 Apr '15

For reference: - http://www.theregister.co.uk/2015/03/27/bar_mitzvah_crypto_attack/ Apparently, Kimchi does not support RC4. $ curl -u <user:password> -H "Content-Type: application/json" -H "Accept: application/json" https://localhost:8001/host --ciphers RC4 --tlsv1.1 curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure But as we've already started some discussion to replace nginx to other reverse proxy, I prefer to have this configuration explicitily done to make us aware about that issue in future. Signed-off-by: Aline Manera <alinefm(a)linux.vnet.ibm.com> --- src/nginx.conf.in | 1 + 1 file changed, 1 insertion(+) diff --git a/src/nginx.conf.in b/src/nginx.conf.in index ed926a3..e308152 100644 --- a/src/nginx.conf.in +++ b/src/nginx.conf.in @@ -53,6 +53,7 @@ http { ssl_certificate ${cert_pem}; ssl_certificate_key ${cert_key}; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; + ssl_ciphers ECDH@STRENGTH:DH@STRENGTH:HIGH:!RC4:!MD5:!DES:!aNULL:!eNULL; add_header Strict-Transport-Security "max-age=31536000; includeSubdomains;"; add_header X-Frame-Options DENY; -- 2.1.0

2 2

[kimchi-devel][RFC][PATCH] Storagepool on existent VG: Update document
by lvroyce＠linux.vnet.ibm.com 06 Apr '15

06 Apr '15

From: Royce Lv <lvroyce(a)linux.vnet.ibm.com> Add interfaces to report existent volume group on host. the returning detail will include what pool this volume group belongs to. If this VG is not used by any storage pool, its storage_pool will be empty string. So the process of creating pool on existent VG will be: 1. List VG not occupied by storage pool: GET /host/vgs?storage_pool='' This will retrieve volume group path and user can choose from one. 2. Create storage pool from chosen VG: POST /storagepools/ {'path':volume_group_path, 'name': storagepool_name, 'type': 'logical', 'devices':[]} Signed-off-by: Royce Lv <lvroyce(a)linux.vnet.ibm.com> --- docs/API.md | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/docs/API.md b/docs/API.md index 3f7925f..ed53d94 100644 --- a/docs/API.md +++ b/docs/API.md @@ -986,6 +986,26 @@ stats history * mountpoint: If the partition is mounted, represents the mountpoint. Otherwise blank. +### Collection: Volume groups + +**URI:** /host/vgs + +**Methods:** + +* **GET**: Retrieves list of volume groups. + +### Resource: Volume group + +**URI:** /host/vgs/*:name* + +**Methods:** + +* **GET**: Retrieve information of a single volume group. + * storage_pool: logical storage pool name which based on this volume group. + * path: path of this storage volume group. + * size: Total size of volume group. + * name: Name of the volume group. + ### Collection: Devices **URI:** /host/devices -- 2.1.0

2 1

[RFC] Do not block operations due to ref_cnt
by Crístian Viana 03 Apr '15

03 Apr '15

Hi, I'd like to propose a change to how Kimchi uses the resource field "ref_cnt". Currently, "ref_cnt" - which stands for "reference count" - is one of the fields returned when looking up a storage volume. Its purpose is to indicate how many times that resource is being used at the moment. For example, if the resource /storagepools/pool/storagevolumes/vol has ref_cnt=1, it means that the disk is attached to 1 VM right now and thus it cannot be attached to another VM. I believe the original idea of this feature is to prevent the same resource from being attached more than once at the same time. However, IMO, that might not always be the desired behavior and there's no way to enforce it completely as those resources can be used outside of Kimchi, where "ref_cnt" doesn't exist. For example, if I have one VM which uses the disk "vol", I'm not able to attach it to another VM via Kimchi; but if I use another libvirt-based VM manager (e.g. virsh), I am able to attach that disk to a different VM. This becomes even trickier when we consider other operations, like snapshots, which can attach/detach disks while they're being reverted to. Also, suppose I might want to inspect one VM's disk from another VM, and then I'd need to attach one disk twice; Kimchi wouldn't allow that by stating that the disk is already in use. I propose Kimchi should stop using "ref_cnt" as a blocking method. The field may still exist for information/warning messages (e.g. "are you sure you want to attach this disk? it's already being used by another VM.") but no operation should be blocked because of it, as it is the case now. As inconsistencies with that value may happen and we have no way to make sure it will always work, we shouldn't annoy the user by stopping them from doing something that may be perfectly valid. Any feedback will be very welcome. Best regards, Crístian.

3 3

[kimchi-devel][PATCHv3 0/6] Upload storage volume
by lvroyce＠linux.vnet.ibm.com 03 Apr '15

03 Apr '15

From: Royce Lv <lvroyce(a)linux.vnet.ibm.com> known issue: When using api to send requests without setting up session, cherrypy server will report error after hundred of calls, because race condition below: https://bitbucket.org/cherrypy/cherrypy/pull-request/50/fix-race-condition-… But it works well with session setup. v3>v1, Use libvirt upload api instead of r/w file Use lock to synchronize upload to prevent Royce Lv (6): Update docs and json schema of storage volume upload Update controller to make update accept formdata params Add lock facility for storage volume upload Update model for storage volume update Fix incomplete record when uploading update test case for storage volume upload docs/API.md | 7 ++-- src/kimchi/API.json | 19 +++++++++++ src/kimchi/control/base.py | 6 ++-- src/kimchi/i18n.py | 4 +++ src/kimchi/isoinfo.py | 5 ++- src/kimchi/mockmodel.py | 8 ++--- src/kimchi/model/storagevolumes.py | 61 +++++++++++++++------------------- src/kimchi/model/utils.py | 46 ++++++++++++++++++++++++++ tests/test_model.py | 67 ++++++++++++++++++++++++++++++++++++++ 9 files changed, 177 insertions(+), 46 deletions(-) -- 2.1.0

3 20

[PATCH] RFC patch to make nginx proxy optional
by Julien Goodwin 03 Apr '15

03 Apr '15

Sending this as an RFC patch, I expect people will want changes from this. Implements Issue #570. Julien Goodwin (1): Initial prototype, make nginx proxy optional. docs/Makefile.am | 1 + docs/apache.conf.ex | 35 +++++++++++++++++++++++++++++++++++ src/kimchi.conf.in | 3 +++ src/kimchi/config.py.in | 1 + src/kimchi/proxy.py | 6 ++++++ 5 files changed, 46 insertions(+) create mode 100644 docs/apache.conf.ex -- 2.1.4

4 18

[RFC] removing hostname to IP resolve in remote ISO
by Daniel Henrique Barboza 02 Apr '15

02 Apr '15

Hi there, As discussed in our latest scrum meeting and in github bug #436, the use of the IP address instead of the hostname in the URLs are causing issues. This is a workaround due to a limitation of older qemu-io versions that don't resolve hostnames and hangs. The thing is that we have no control of how the remote server will resolve the URL in that format ( http://91.189.92.163:80/14.04/ubuntu-14.04.2-desktop-amd64.iso instead of http://releases.ubuntu.com/14.04/ubuntu-14.04.2-desktop-amd64.iso for example). It can resolve the IP to hostname and work as intended, it can redirect to the home page (as the example I gave), it can give a 403 forbidden and so on. This limitation is not present in newer versions of qemu (tested in RHEL 7.1, Fedora 21, Ubuntu 14.04 and Opensuse 13.2), therefore it is just a code that have a random chance of failing to work. In my opinion, we should get rid of it and let qemu-io handle it alone. If qemu-io can't handle the remote ISO streaming by itself, the user can: - update qemu - use an older version of kimchi - download the ISO and use it as Local ISO Image Thoughts? Daniel

2 1

[RFC] New API to create a random guest console password
by Aline Manera 02 Apr '15

02 Apr '15

Today user may set/change the guest console password and also its expiration time through Kimchi API. When passing an empty password, a random password is automatically generated. curl -u <user:password> -H "Content-Type: application/json" -H "Accept: application/json" http://localhost:8010/vms/blah -X PUT -d'{"graphics": {"passwd": ""}}' That way is difficult to handle when user wants to reset the guest password. We have a similar issue when we automatically change the passwdValidTo when it is expired - increasing it in 30 seconds. My proposal is simple: only change "passwd" and "passwdValidTo" when user wants to do it. curl -u <user:password> -H "Content-Type: application/json" -H "Accept: application/json" http://localhost:8010/vms/blah -X PUT -d'{"graphics": {"passwd": "123456", "passwdValidTo": "<some datetime format>"}}' curl -u <user:password> -H "Content-Type: application/json" -H "Accept: application/json" http://localhost:8010/vms/blah -X PUT -d'{"graphics": {"passwdValidTo": "<some datetime format>"}}' And make sure the passwdValidTo is only acceptable when there is a passwd set. And to reset those values, we only need to send an empty string: curl -u <user:password> -H "Content-Type: application/json" -H "Accept: application/json" http://localhost:8010/vms/blah -X PUT -d'{"graphics": {"password": "", "passwdValidTo": ""}}' And create a new API: POST /vms/blah/ticket to automatically generate a random password valid only for 30 seconds. curl -u <user:password> -H "Content-Type: application/json" -H "Accept: application/json" http://localhost:8010/vms/blah/ticket -X POST -d'{}' What do you think about it? Regards, Aline Manera

2 3

[RFC] Make defaults template configurable
by Aline Manera 02 Apr '15

02 Apr '15

Hi guys, Today when creating a Template all the default values come from Kimchi. But in some cases, the user may want to change and persist them for next interactions. For example: change the disk size to 20G (instead of the default 10G), change disk format, use Spice (instead of VNC), change storage pool and network, etc. My proposal is to have a configuration file (/etc/kimchi/template.defaults) that will override Kimchi defaults values so user can have some control on Template configuration according to him/her proposals. Let me know what you think about it. Regards, Aline Manera

2 1

[RFC] Hotplug a new VM disk
by Crístian Viana 01 Apr '15

01 Apr '15

Hi, I'd like to propose a new feature to hotplug a new disk to a VM. This feature will be implemented only on the UI side. The backend already has the methods needed to make it work. Suppose a user wants to add a new disk to a running VM. Currently, they have to create an empty disk using other tools outside of Kimchi and put it into an existing storage pool. This might be challenging for some users, as it requires the use of other tools, possibly involving the command line (e.g. qemu-img). With this new feature, the user will only select the storage pool and the size of the new disk they want to add; Kimchi will create the disk in the appropriate pool and attach it to the VM. In order to perform this feature, the UI will have to be updated to allow the following steps: 1) Select an existing VM, "Actions" > "Edit". 2) Switch to the tab "Storage". 3) Click on the button "+". 4) On "Device type", select "disk" . 5) On "Storage pool", select any storage pool. *6) On "Storage volume", select "New...".** **7) Enter the desired disk size.* 8) Click on the button "Attach". Steps 6 and 7 are the ones related to this feature and they need to be implemented. The other steps already exist in the current UI. When the user performs step 8, the UI should send the following requests to the server: POST /storagepools/<pool>/storagevolumes {'name': <vol>, 'capacity': <size>} POST /vms/<vm>/storages {'name': <vol>} Those requests already work, they just have to be executed in that order in order to perform this new feature. Any feedback will be very welcome. Best regards, Crístian.

2 1

[RFC] Hotplug a VM network interface
by Crístian Viana 01 Apr '15

01 Apr '15

Hi, I'd like to propose a new feature to hotplug a network interface to a running VM. A similar feature is already available for stopped VMs by selecting a VM and clicking on "Actions" > "Edit", tab "Interface"; the user is able to add or remove a network interface in that dialog. However, if the VM is running, that tab disables the buttons to add and remove network interfaces. This feature will allow those two operations to be performed also on running VMs. The API for adding and removing network interfaces to a VM already exist: POST /vms/<vm>/ifaces {<iface data>} DELETE /vms/<vm>/ifaces/<iface> However, they currently raise an exception when the VM is running. This feature will use those same commands in order to hotplug a network interface, keeping the existing REST interface. Any feedback will be very welcome. Best regards, Crístian.

2 1

[RFC] Add suport for VM suspend/resume
by Crístian Viana 01 Apr '15

01 Apr '15

Hi, I'd like to propose two new operations on virtual machines: *suspend* and *resume*: Suspend ---------- From libvirt.org: /Suspend an active domain, the process is frozen without further access to CPU resources and I/O but the memory used by the domain at the hypervisor level will stay allocated./ REST syntax: POST /vms/<vm-name>/suspend Return status: 200: OK 4xx: error Return data: None Resume ---------- From libvirt.org: /Resume a suspended domain, the process is restarted from the state where it was frozen by calling "suspend"./ REST syntax: POST /vms/<vm-name>/resume Return status: 200: OK 4xx: error Return data: None -------------------- This feature has been partially implemented in previous patches ("[PATCH 0/3] VM suspend/resume", from Jan 21st), and its progress should be resumed soon. The UI will have to be updated accordingly by adding buttons to suspend and resume a VM, somewhat like the buttons which start and stop a VM. Any feedback will be very welcome. Best regards, Crístian.

2 1

[PATCH v2 0/3] Fix issue #461 (backend)
by Crístian Viana 01 Apr '15

01 Apr '15

This is the changelog between this and the previous patchset: - Don't allow mirrorlist and metalink to be specified at the same time; according to the YUM documentation, that situation is invalid. Crístian Viana (3): Handle empty variables when updating YUM repository Use more generic message in repo mirror list error issue #461: Add 'metalink' support for YUM repositories src/kimchi/API.json | 5 +++++ src/kimchi/i18n.py | 6 ++++-- src/kimchi/repositories.py | 31 +++++++++++++++++++++++++------ 3 files changed, 34 insertions(+), 8 deletions(-) -- 2.1.0

2 4

[PATCH V2] Update host number of cpus and total physical memory
by Jose Ricardo Ziviani 01 Apr '15

01 Apr '15

- The number of cpus and the total physical memory information displayed in the host section can change, so them cannot be static. This commit updates those values whenever a GET request hits the backend looking for host information. --- src/kimchi/model/host.py | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/kimchi/model/host.py b/src/kimchi/model/host.py index 4419bb3..588bb28 100644 --- a/src/kimchi/model/host.py +++ b/src/kimchi/model/host.py @@ -87,8 +87,8 @@ class HostModel(object): res['cpu_model'] = line.split(':')[1].strip() break - res['cpus'] = psutil.NUM_CPUS - res['memory'] = psutil.TOTAL_PHYMEM + res['cpus'] = 0 + res['memory'] = 0L # Include IBM PowerKVM name to supported distro names _sup_distros = platform._supported_dists + ('ibm_powerkvm',) @@ -102,6 +102,8 @@ class HostModel(object): return res def lookup(self, *name): + self.host_info['cpus'] = psutil._psplatform.get_num_cpus() + self.host_info['memory'] = psutil.phymem_usage().total return self.host_info def swupdate(self, *name): -- 1.9.1

3 3

[PATCH V3] Number of CPUs and Physical Memory
by Jose Ricardo Ziviani 01 Apr '15

01 Apr '15

V3: psutil has changed its interface to retrieve the number of CPUs, this new V3 updates the code while supporting the old version (still needed). Jose Ricardo Ziviani (1): Update host number of cpus and total physical memory src/kimchi/model/host.py | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) -- 1.9.1

2 2

[PATCH][RFC] Kimchi and relative URLs
by Frédéric Bonnard 01 Apr '15

01 Apr '15

From: Frederic Bonnard <frediz(a)linux.vnet.ibm.com> Hi, many people and distros use a subdirectory in the configuration of the system's webserver to configure different websites. The usual way to setup a website is thus to : 1. use the distro's webserver to serve all the websites 2. have a subdirectory to copy the configuration file that makes available a website by only restarting the webserver (and removing the website is just done by removing the configuration file and restart). Concerning this point, the classical configurations can be : a) a sub web location : https://website.org/webapp b) a virtual host : http://webapp.website.org a) and b) correspond each to different configuration files that are just dropped into : - Ubuntu/Debian : /etc/{apache,nginx,..}/sites-available/{webapp_subweb,webapp_virthost}.conf - Fedora/Opensuse : /etc/{httpd,nginx,..}/conf.d/ At the moment kimchi is launched with a private instance of nginx, not the system's installed one and it would be nice to have this improved and this is covered in another thread : http://lists.ovirt.org/pipermail/kimchi-devel/2015-February/009642.html Provided that previous patch, one can use the distro's webserver to run proxy kimchi and that fullfills 1. Then for 2. one need a configuration file for either b) (provided for apache in the link above ; I have also one for nginx ) and a), which I provide in this patch. But this nginx configuration file is not enough for a sub web location configuration as kimchi relies on absolute path based on / from the http://server/. I tried to make URLs paths relative so that kimchi doesn't have to know where it has been placed on the webserver, for example https://server/kimchi/ which will probably be the URL used in distros. I'm not a web developer and I tried to modify all failing requests with a a) configuration with relative paths in mind. So I'd like comments on the way this is done, and this may need more extensive testing (paths I didn't test). Though I used that code back on a virtualhost configuration and it worked as well. Thanks for your help, F. Frederic Bonnard (1): Making urls relative docs/Makefile.am | 1 + docs/nginx.conf.subsite.ex | 37 +++++++ src/kimchi/screenshot.py | 2 +- ui/css/theme-default/template_add.css | 20 ++-- ui/css/theme-default/topbar.css | 2 +- ui/js/src/kimchi.api.js | 176 +++++++++++++++++----------------- ui/js/src/kimchi.login.js | 2 +- ui/pages/guest.html.tmpl | 2 +- ui/pages/help/dita-help.xsl | 4 +- ui/pages/kimchi-ui.html.tmpl | 4 +- ui/pages/storagepool-add.html.tmpl | 2 +- ui/pages/tabs/storage.html.tmpl | 2 +- ui/pages/template-add.html.tmpl | 2 +- 13 files changed, 147 insertions(+), 109 deletions(-) create mode 100644 docs/nginx.conf.subsite.ex -- 1.9.1

4 9

[PATCH v3] test_model: Power arch fixes
by Daniel Henrique Barboza 01 Apr '15

01 Apr '15

changes in v3: - rebase to latest master changes in v2: - changed iso_path to reflect the new ISO being created (Ubuntu 14.04) Daniel Henrique Barboza (1): test/test_model: Power architecture fixes tests/iso_gen.py | 3 ++- tests/test_model.py | 12 +++++++----- 2 files changed, 9 insertions(+), 6 deletions(-) -- 1.9.3

2 3

[kimchi-devel][PATCH] Issue #623: Fix mismatch in host device details query
by lvroyce＠linux.vnet.ibm.com 01 Apr '15

01 Apr '15

From: Royce Lv <lvroyce(a)linux.vnet.ibm.com> Commit #902d2957 began to use splitted devices names, while get detailed device still use original names. Mismatched name results in error raised when listing host devices. Fix it by using splitted device name as well. Signed-off-by: Royce Lv <lvroyce(a)linux.vnet.ibm.com> --- src/kimchi/disks.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/kimchi/disks.py b/src/kimchi/disks.py index a092c17..5cf6885 100644 --- a/src/kimchi/disks.py +++ b/src/kimchi/disks.py @@ -64,7 +64,7 @@ def _get_dev_major_min(name): dev_list = _get_lsblk_devs(keys) for dev in dev_list: - if dev['name'] == name: + if dev['name'].split()[0] == name: maj_min = dev['maj:min'] break else: -- 1.9.1

2 2

[PATCH 0/3] Fix backend VM, POOL, NETWORK naming validation
by Rodrigo Trujillo 01 Apr '15

01 Apr '15

This patchset fixes the backend JSON name checkings when user creates a new VM, POOL or NETWORK. Rodrigo Trujillo (3): Prohibits slashes '/' in VM name Move slash checking in storagepool name from UI to backend Fix Network create name checking in backend (slashes and quotes) src/kimchi/API.json | 4 ++++ src/kimchi/i18n.py | 6 +++--- src/kimchi/model/utils.py | 3 ++- ui/js/src/kimchi.storagepool_add_main.js | 5 ----- ui/pages/i18n.json.tmpl | 1 - 5 files changed, 9 insertions(+), 10 deletions(-) -- 2.1.0

2 7