July 2012 - vdsm-devel - Fedora Mailing-Lists

by abaron＠redhat.com

Hi all, Sorry for cross-posting, but in this case I think it's relevant. The original idea was that every time we wish to discuss a new cross-component feature we should do it over arch list. However, it would appear that de-facto usually engine-devel and vdsm-devel are being used (cross posted). Currently engine-devel has 211 subscribers, arch has 160 and vdsm-devel has 128 so from this perspective again, arch seems less relevant. I propose we ditch arch and keep the other 2 mailing lists. I'm not sure whether new cross-component features should be discussed solely on engine-devel or cross-posted (there are probably people who wouldn't care about engine side but would still like to know about such changes). Thoughts? Regards, Ayal.

11 years, 10 months

7
11
0 / 0

A few notes about lists in Makefiles

by smizrahi＠redhat.com

Hi, I would just like to push a few notes to people modifying autoconf\automake lists Please make sure the lists are sorted. Sorted lists are easier to skim and modify. Also, unsorted lists are known to make Federico sad, and we all want to keep him happy because he is a pretty swell guy and the one that we actually have to thank for the amazing build system. Also please make sure to add the $(NULL) item so when auto sorting you don't need to check if you need to add\remove a backslash. VARIABLE = \ A \ B \ C \ $(NULL) If you are using vim you could just mark all the lines an run ":<>!sort" to sort. Also, when adding a file to the PEP_WHITELIST, check if you can just mark the entire directory instead of the individual file. Remember, cleanliness is next to godliness.

11 years, 10 months

2
1
0 / 0

Meeting minutes

by Dan Kenigsberg

Today we did have a meeting, and discussed the following points: - We need a volunteer to extend vdsm's on-commit hook, so it runs functional tests to. This requires installing vdsm.rpm as well as vdsm-tests.rpm, starting vdsmd service, running the tests, and cleaning the host. Robert M. suggested that we ask infra@ for help in writing and maintaining this test, so here I am, CCing infra(a)ovirt.org. - Saggi is planning a C API library, exposing gobjects, with a rest bridge (or whatever) for client applications. I'm slightly appauled - I prefered the simpler idea of API.py and REST binding, with which C/whatever clients can interact. - Adam documented the current xmlrpc api, with all its pecularities and horrors. Prefers to keep it as a single document; I think it would be easier to maintain if definition that are specific to an API call sit on top the function definition. It would be harder to forget to update one of them when you change the other. Admitedly, it requires some sed preprocessing in order to extract a single human-readable document out of this scattered info. Saggi votes for Adam. - deepakcs: i just posted VDSM hook example for exploiting native qemu-glusterfs options from VDSM. Wanted to know feedback onthe same and alternative approach - Saggi asks to ping qemu folks about the feature of specifying the full qcow chain BZ#750801. We need it to reduce repository complexity (currently we play with symlinks). - Federico: storage domain v 3 , requires bleeding-edge upstream engine and sanlock. http://wiki.ovirt.org/wiki/Storage_Domain_Versions - probably more stuff that I've forgotten... please reply with more info See ya all! Dan.

11 years, 10 months

2
1
0 / 0

Agenda for tomorrow's call

by Dan Kenigsberg

Hi! tomorrow I would like to discuss: - the abysmal review condition of the rest api patches - vdsm status for ovirt-3.1 I know networking requires a heavy cherry-pick from upstream. There is probably more. Everybody invited to care for vdsm bugs that blocks Bug 822145 - Tracker: oVirt 3.1 release. - plenty pep8 patches applied, but there is plenty more. - Patches with pending verification. I see 11 of those now http://gerrit.ovirt.org/#/q/status:open+project:vdsm+verified%253D0+coder... Please do not send your patches out to the cold and desert them there. Pet them, nag folks to review and verify them, and rebase (only!) when required. - Your issue comes here (or above, if it's more urgent). Regards, Dan.

11 years, 10 months

6
13
0 / 0

Repo Engine Initial code drop

by smizrahi＠redhat.com

http://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:... Everything that isn't marked as WIP is ready for same hard-core review and commit action. The WIP parts are a bit rough around the edges expect: * Typos * spelling errors * grammar errors * Functions that are remnants of attempts which proved problematic * Lack of code reuse * Old docstrings that are no longer correct * Dragons A few notes: * I call the new storage domains "image repositories" because I think it creates less confusion and ambiguity. * VirtualDisks are writable entities you can run a VM off, snapshots a read only entities you can make Virtual Disks from. Images are a name for both disks and snapshots. * Only localfs is somewhat supported * The Image manipulation code is working and you can create images and snapshots to your hearts delight. It might even work!. * The check process detects all tree issues but there are only fixes for orphaned tags and volumes meaning you will be able to clean whole tree. * The APIs are not final * Documentation is sparse I'm trying to make all this code separate from the regular VDSM core so we can push it in even though it's not perfect and slowly build up from that. The biggest problem with integration is not having the blockdev feature in qemu and libvirt. This means that running more the one VM which use the same snapshot might corrupt the qcow file. https://bugzilla.redhat.com/show_bug.cgi?id=750801 https://bugzilla.redhat.com/show_bug.cgi?id=760547 If anyone wants to help find me on #VDSM @ freenode and we'll coordinate efforts. My current TODO list: 1. XML-RPC API integration --- Could be pushed in from this point on, as an experimental API 2. nfs repo engine (will introduce sanlock to the mix) 3. clustered-lvm repo engine (Will introduce SRM) 4. Tasks --- I expect to have the Most of the API finalized here 5. Fix operations (merging, conversions) 6. Live snapshot 7. Live Merge 8. Live Storage Migration 9. Profit?

11 years, 10 months

1
0
0 / 0

Q on createVolume(..) filesize.

by deepakcs＠linux.vnet.ibm.com

Hello, I am working on a VDSM standalone script that is using PosixFS inteface to mount gluster volume & trying to create a volume (file) inside the storage domain. Snip of the code is below... ============================================================== sizeGiB = 4 tid = vdsOK(s.createVolume(sdUUID, spUUID, imgUUID, sizeGiB, RAW_FORMAT, PREALLOCATED_VOL, LEAF_VOL, volUUID, "glustervol", BLANK_UUID, BLANK_UUID))['uuid'] waitTask(s, tid) ============================================================== But the file size created is not 4G, its 8K as seen below... qemu-img info /rhev/data-center/mnt/kvmfs01-hs22:dpkvol/f0443ec4-3c94-49c9-a239-797562ee4926/images/073b3309-e4cd-4b6c-978e-5744a9afb8b7/c8c4f92e-818d-433a-b013-b0060cd7cc87 image: /rhev/data-center/mnt/kvmfs01-hs22:dpkvol/f0443ec4-3c94-49c9-a239-797562ee4926/images/073b3309-e4cd-4b6c-978e-5744a9afb8b7/c8c4f92e-818d-433a-b013-b0060cd7cc87 file format: raw virtual size: 2.0K (2048 bytes) disk size: 8.0K It should have created a raw file of size 4G, but its not. Wondering if the sizeGiB argument is not in GB but somethign else ? thanx, deepak

11 years, 10 months

2
2
0 / 0

Creating a new VM with a template

by shuming＠linux.vnet.ibm.com

Hi, I created a VM with from existing template and found that the image of the new VM actually copied the image from the template instead of sharing a base from the template. I am wondering why the new VM doesn't use a new cow image as its image pointing to the base image in template. By that way, all the new VMs will share a common parent image in template and save the space in the storage domain. Is there any other concern not to do this? -- Shu Ming <shuming(a)linux.vnet.ibm.com> IBM China Systems and Technology Laboratory

11 years, 10 months

3
2
0 / 0

Readonly leases error in vdsm log

by deepakcs＠linux.vnet.ibm.com

Hello, I am creating a VM using vdsm standalone script and facing issues when i add cdrom and make it boot from cdrom. .... vdsOK( s.create(dict(vmId=vmId, drives=[dict(poolID=spUUID, domainID=sdUUID, imageID=imgUUID, volumeID=volUUID)], memSize=256, display="vnc", vmName="vm-backed-by-gluster", cdrom="/home/deepakcs/Fedora-16-x86_64-Live-Desktop.iso", boot="d", custom={"dpktry":1}, ) ) When i added cdrom= and boot= lines and ran, i see the below in vdsm.log.... Traceback (most recent call last): File "/usr/share/vdsm/vm.py", line 570, in _startUnderlyingVm self._run() File "/usr/share/vdsm/libvirtvm.py", line 1364, in _run self._connection.createXML(domxml, flags), File "/usr/lib64/python2.7/site-packages/vdsm/libvirtconnection.py", line 82, in wrapper ret = f(*args, **kwargs) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2420, in createXML if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self) libvirtError: internal error unsupported configuration: Readonly leases are not supported Thread-49::DEBUG::2012-07-05 17:35:59,780::vm::920::vm.Vm::(setDownStatus) vmId=`8b400342-2cda-478d-93f6-a36bac8538c8`::Changed state to Down: internal error unsupported configuration: Readonly leases are not supported It looks like its trying to use the cdrom disk device as a disk lease, hence complaining? But the libvirt xml has <disk> tags which looks liek this... <disk device="disk" snapshot="no" type="file"> <source file="/rhev/data-center/98fc6cd9-d857-4735-bc7a-59a289bc0f55/01400276-e3c8-44d9-8353-924ab2183af2/images/95c9f6a4-def1-4300-baf6-db884dc8ccca/9d62e802-859e-4381-8029-7be5a6b1de26"/> <target bus="ide" dev="hda"/> <serial>95c9f6a4-def1-4300-baf6-db884dc8ccca</serial> <driver cache="none" error_policy="stop" io="threads" name="qemu" type="raw"/> </disk> <disk device="cdrom" snapshot="no" type="file"> <source file="/home/deepakcs/Fedora-16-x86_64-Live-Desktop.iso" startupPolicy="optional"/> <target bus="ide" dev="hdc"/> <serial/> </disk> Any idea why it throws "Readonly leases are not supported" ? thanx, deepak

11 years, 11 months

2
1
0 / 0

Agenda for today's call

by deepakcs＠linux.vnet.ibm.com

Stuff I'd like to mention today: - bulk of REST patches unilaterally pushed. I still consider that API preliminary though, since I do not think it has undergone the scrutiny it deserves. The patches were not really verified with current API.py, so they are currently broken. Please review and ack o http://gerrit.ovirt.org/5815/ o http://gerrit.ovirt.org/3757 - Volunteer is needed to write a Jenkins job for running the functional tests. Otherwise, REST (and other stuff) is going to be broken without us even noticing. - State of Saggi's API overhaul - Implementation of "libvdsm" has been discussed on list. I'd like to hear more about its suggested interface. - what else? During the call, please keep an eye on #vdsm(a)irc.freenode.net so that folks who cannot dial into the conference call, can still participate in a way. Regards, Dan.

11 years, 11 months

2
4
0 / 0

Question regarding vds_spm_id

by Amador Pahim

Hello, I'm handling with an oVirt bug, about a race condition during parallel registering hosts: http://gerrit.ovirt.org/#/c/5338/ Message: The vds_spm_id from vds_spm_map table is filled with a code select/increment/insert. Registering many hosts at same time causes a race condition. More than one java thread comes up with the same value for selectedId, since that's just being derived from knowledge about the set of vds_spm_id_map entries already in the database. This patch change the way to obtain the vds_spm_id to be through a database sequence. The reviewer wrote: "... Each pool can have max vds_spm_id equals to 255. So, by using sequence count the problem of parallel registration will be solved, but a number of vdsms at pool will be reduced. ..." Mailing him for details, he added: "a limitation is coming from side of vdsm, if I am correct it is because of using SAN lock, so they just can not accept spm id which is higher than 255." Trying to reproduce the vdsm limitation, no problem was found: engine=# select * from vds_spm_id_map; storage_pool_id | vds_spm_id | vds_id --------------------------------------+------------+-------------------------------------- e32f1e2a-b5bb-11e1-9431-52540038c4e1 | 259 | 13bbf86e-c5da-11e1-a73c-52540038c4e1 My host added with vds_spm_id = 259 is fully functional, with some storage pools attached and so forth. Since I'm not able to reproduce, I'd like to ask you guys if someone could point me to the right direction to reproducing - or clarify where is the mentioned limit. Best, -- Pahim

11 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

vdsm-devel July 2012