October 2012 - vdsm-devel - Fedora Mailing-Lists

A question about the SPM operation permission in VDSM

by shuming＠linux.vnet.ibm.com

Hi, In the VDSM code about some SPM operations like HSM.deleteImage(), It is found that VDSM doesn't check if the operation will be launched on a SPM host or not. It only checks if the storage pool is already acquired by one SPM host, but not necessary the same host as the SPM operation is delivered to. The code is like this: HSM.deleteImage() { ... HSM._spmSchedule() { self.validateSPM(spUUID) <--- Only check if the storage pool was acquired by one host, but not necessary this host } ... } So it really depends on the node management application AKA ovirt-engine to dispatch the SPM operations to the right VDSM host. And the VDSM host itself doesn't check if it is the SPM host which can execute the operation. To me, it is a bit broken. When the engine query the VDSM host who is the SPM host, it can get the right one. However, the host may be broken for some reason after the engine believes it is the SPM host and the host loses the SPM privilege, another host will take the SPM role. Then the engine continue to send the SPM operations to the broken host. As a result, the SPM operation will be launched on a non-SPM host. So I think there is a small window of racing to corrupt the VDSM hosts meta data. I think VDSM host should check if it is SPM before the SPM job is scheduled. If the host lost the SPM role already, It should fail the RPC call from the engine to let the engine to retry the operation after engine knows the failure of the former call. -- --- 舒明 Shu Ming Open Virtualization Engineerning; CSTL, IBM Corp. Tel: 86-10-82451626 Tieline: 9051626 E-mail: shuming(a)cn.ibm.com or shuming(a)linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC

11 years, 2 months

3
2
0 / 0

[RFC]about the implement of text-based console

by Xu He Jie

Hi, I submited a patch for text-based console http://gerrit.ovirt.org/#/c/7165/ the issue I want to discussing as below: 1. fix port VS dynamic port Use fix port for all VM's console. connect console with 'ssh vmUUID@ip -p port'. Distinguishing VM by vmUUID. The current implement was vdsm will allocated port for console dynamically and spawn sub-process when VM creating. In sub-process the main thread responsible for accept new connection and dispatch output of console to each connection. When new connection is coming, main processing create new thread for each new connection. Dynamic port will allocated port for each VM and use range port. It isn't good for firewall rules. so I got a suggestion that use fix port. and connect console with 'ssh vmuuid@hostip -p fixport'. this is simple for user. We need one process for accept new connection from fix port and when new connection is coming, spawn sub-process for each vm. But because the console only can open by one process, main process need responsible for dispatching console's output of all vms and all connection. So the code will be a little complex then dynamic port. So this is dynamic port VS fix port and simple code VS complex code. Thanks!

11 years, 3 months

15
56
0 / 0

Review needed: 3.2 release feature -- libvdsm

by agl＠us.ibm.com

Hi everyone, libvdsm is listed as a release feature for 3.2 (preview only)[1][2]. There is a set of patches up in gerrit that could use a wide review from the community. The plan is to merge the new json-rpc server[3] first so if you could concentrate your reviews there it would yield the greatest benefit. Thanks! [1] http://wiki.ovirt.org/wiki/OVirt_3.2_release-management [2] http://wiki.ovirt.org/wiki/Features/libvdsm [3] http://gerrit.ovirt.org/#/c/8614/ -- Adam Litke <agl(a)us.ibm.com> IBM Linux Technology Center

11 years, 5 months

3
6
0 / 0

Review Request: Add an option to create a watchdog device.

by shaohef＠linux.vnet.ibm.com

Looking for some review on this patch. http://gerrit.ovirt.org/#/c/7535/ Thanks. -- Sheldon Feng(???)<shaohef(a)linux.vnet.ibm.com> IBM Linux Technology Center

11 years, 5 months

1
1
0 / 0

Re: [vdsm] Review Request: Add an option to create a watchdog device.

by shaohef＠linux.vnet.ibm.com

On 10/30/2012 03:45 PM, Itamar Heim wrote: > On 10/30/2012 07:00 AM, Sheldon wrote: >> Looking for some review on this patch. >> >> http://gerrit.ovirt.org/#/c/7535/ > > Hi Sheldon, > > just wondering - are you planning to close this feature end-to-end > (with ovirt engine)? > > a feature page would be nice (i think your commit message is almost > good enough to explain. > just need to cover how it fits with the engine side. > IMO, It is nice for engine to add UI to let user to decide to add this watchdog device. Like virt-manager, it has a UI option to add watchdog device. And engine just need to add the watchdog device configuration in the parameter when call VM create API, if watchdog device is chosen. > Thanks, > Itamar > > -- Sheldon Feng(冯少合)<shaohef(a)linux.vnet.ibm.com> IBM Linux Technology Center

11 years, 5 months

2
2
0 / 0

When Zombies Attack

by smizrahi＠redhat.com

I'm starting to see more and more flows run a process and leave a thread waiting for it just to prevent a zombie attack. This is wasteful, even more so that this is usually done for process that might get stuck on IO and might take a while to come back. To solve this I implemented this little tidbit. http://gerrit.ovirt.org/#/c/8937/ And you can see it being used here: http://gerrit.ovirt.org/#/c/8907/ specifically: http://gerrit.ovirt.org/#/c/8907/5/vdsm/storage/remoteFileHandler.py That being said, I also want to suggest adding autoreaping to AsyncProc.__del__() with a warning printed to the log notifying about the (maybe) unintentional process leak. Comments and suggestions for improvement are most welcome.

11 years, 5 months

1
0
0 / 0

unmanaged devices thrown into 'custom' feature

by Dan Kenigsberg

I have just noticed that when a VM is started for the second time, Engine issues the "create" vdsm verb with some information regarding "unmanaged" devices (an example is shown below[1]) in the 'custom' propery bag. I'm surprised about this, as I was not aware of this usage of the 'custom' dictionary, and Vdsm is not doing anything with the data. Would anyone elaborate about it? On the face of it, it does not seem like a pleasant API. If Engine wants to tell Vdsm about the location of various devices, we should probably be using the 'devices' property, not the bag of 'custom' property made for user-defined hooks. I hope this API pecularity can be avoided, and very much hope that no one is depending on it. Dan. [1] 'custom': { 'device_e97a9759-1c1b-45ed-9ed9-7136ef538315': 'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c, deviceId=e97a9759-1c1b-45ed-9ed9-7136ef538315, device=ide, type=controller, bootOrder=0, specParams={}, address={bus=0x00, domain=0x0000, type=pci, slot=0x01, function=0x1}, managed=false, plugged=true, readOnly=false, alias=ide0}', 'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709': 'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c, deviceId=7bfffa34-2e27-4b01-b499-6ac79c997709, device=unix, type=channel, bootOrder=0, specParams={}, address={port=1, bus=0, controller=0, type=virtio-serial}, managed=false, plugged=true, readOnly=false, alias=channel0}', 'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6': 'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c, deviceId=133d9bfa-c531-414e-ad20-208d67d5a5e6, device=virtio-serial, type=controller, bootOrder=0, specParams={}, address={bus=0x00, domain=0x0000, type=pci, slot=0x04, function=0x0}, managed=false, plugged=true, readOnly=false, alias=virtio-serial0}', 'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709device_7c107c63-605f-4b21-9893-c052ec211424device_48007de9-467d-46a1-aa84-cc1a6419b5fb': 'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c, deviceId=48007de9-467d-46a1-aa84-cc1a6419b5fb, device=spicevmc, type=channel, bootOrder=0, specParams={}, address={port=3, bus=0, controller=0, type=virtio-serial}, managed=false, plugged=true, readOnly=false, alias=channel2}', 'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709device_7c107c63-605f-4b21-9893-c052ec211424': 'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c, deviceId=7c107c63-605f-4b21-9893-c052ec211424, device=unix, type=channel, bootOrder=0, specParams={}, address={port=2, bus=0, controller=0, type=virtio-serial}, managed=false, plugged=true, readOnly=false, alias=channel1}' }

11 years, 5 months

8
11
0 / 0

New component 'mom' added to Bugzilla

by agl＠us.ibm.com

Hi all, MOM is becoming a bigger part of oVirt and unfortunately it may have bugs at some point :( Thanks to Yaniv we have a new 'mom' component in oVirt's bugzilla where you can report these. To file a new bug against MOM: https://bugzilla.redhat.com/enter_bug.cgi?product=oVirt;component=mom Thanks! -- Adam Litke <agl(a)us.ibm.com> IBM Linux Technology Center

11 years, 5 months

1
0
0 / 0

Cancelled: ovirt network

by lpeer＠redhat.com

A single instance of the following meeting has been cancelled: Subject: ovirt network Organiser: "Livnat Peer" <lpeer(a)redhat.com> Time: Wednesday, 24 October, 2012, 4:00:00 PM - 5:00:00 PM GMT +02:00 Jerusalem Invitees: engine-devel(a)ovirt.org; vdsm-devel(a)lists.fedorahosted.org; GARGYA(a)de.ibm.com; dyasny(a)redhat.com; simon(a)redhat.com; mkolesni(a)redhat.com; atal(a)redhat.com; ilvovsky(a)redhat.com; dfediuck(a)redhat.com; pradipta.banerjee(a)gmail.com; gkotton(a)redhat.com ... *~*~*~*~*~*~*~*~*~* Hi All, Due to day-light saving change in Israel this meeting collides with ovirt sync meeting this week. I am cancelling this instance of the meeting, If there is a specific items you'd like to discuss related to networking please reply and we'll schedule a dedicated meeting. Thanks, Livant

11 years, 6 months

1
0
0 / 0

vdsm API schema

by agl＠us.ibm.com

For the past few weeks I have been working on creating a schema that fully describes the vdsm API. I am mostly finished with that effort and I wanted to share the results with the team. Attached are two files: the raw schema and an html document with cross-linked type information. This should already be useful in its current form, but I have bigger plans. I would first like to get help to correct errors in the schema. Then, I will start the process of writing a code generator that will create C/gObject code that we can compile into a libvdsm with language bindings for python, java, etc. Please take a look at the attached files and let me know what you think? P.S. I tried to attach these to the oVirt Wiki, but they are not permitted file types. -- Adam Litke <agl(a)us.ibm.com> IBM Linux Technology Center

11 years, 6 months

2
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

vdsm-devel October 2012