November 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, 4 months

15
56
0 / 0

Future of Vdsm network configuration - Thread mid-summary

by lpeer＠redhat.com

Hi All, We have been discussing $subject for a while and I'd like to summarized what we agreed and disagreed on thus far. The way I see it there are two related discussions: 1. Getting VDSM networking stack to be distribution agnostic. - We are all in agreement that VDSM API should be generic enough to incorporate multiple implementation. (discussed on this thread: Alon's suggestion, Mark's patch for adding support for netcf etc.) - We would like to maintain at least one implementation as the working/up-to-date implementation for our users, this implementation should be distribution agnostic (as we all acknowledge this is an important goal for VDSM). I also think that with the agreement of this community we can choose to change our focus, from time to time, from one implementation to another as we see fit (today it can be OVS+netcf and in a few months we'll use the quantum based implementation if we agree it is better) 2. The second discussion is about persisting the network configuration on the host vs. dynamically retrieving it from a centralized location like the engine. Danken raised a concern that even if going with the dynamic approach the host should persist the management network configuration. Obviously the second discussion influences the API modeling. Since I think it would be challenging to add support for generic API and change the current implementation to match the dynamic configuration approach simultaneously I suggest we'll focus our efforts on one change at a time. I suggest to have a discussion on the pro's and con's of dynamic configuration and after we get to a consensus around that we can start modeling the generic API. thoughts? comments? Livnat

11 years, 4 months

13
62
0 / 0

RFD: API: Identifying vdsm objects in the next-gen API

by agl＠us.ibm.com

Today in vdsm, every object (StoragePool, StorageDomain, VM, Volume, etc) is identified by a single UUID. On the surface, it seems like this is enough info to properly identify a resource but in practice it's not. For example, when you look at the API's dealing with Volumes, almost all of them require an sdUUID, spUUID, and imgUUID in order to provide proper context for the operation. Needing to provide these extra UUIDs is a burden on the API user because knowing which values to pass requires internal knowledge of the API. For example, the spUUID parameter is almost always just the connected storage pool. Since we know there can currently be only one connected pool, the value is known. I would like to move away from needing to understand all of these relationships from the end user perspective by encapsulating the extra context into new object identifier types as follows: StoragePoolIdentifier: { 'storagepoolID': 'UUID' } StorageDomainIdentifier: { 'storagepoolID*': 'UUID', 'storagedomainID': 'UUID' } ImageIdentifier: { 'storagepoolID*': 'UUID', 'storagedomainID': 'UUID', 'imageID': 'UUID' } VolumeIdentifier: { 'storagepoolID*': 'UUID', 'storagedomainID': 'UUID', 'imageID': 'UUID', 'volumeID': 'UUID' } TaskIdentifier: { 'taskID': 'UUID' } VMIdentifier: { 'vmID': 'UUID' } In the new API, anytime a reference to an object is required, one of the above structures must be passed in place of today's single UUID. In many cases, this will allow us to reduce the number of parameters to the function since the needed contextual parameters (spUUID, etc) will be part of the object's identifier. Similarly, any time the API returns an object reference it would return a *Identifier instead of a bare UUID. These identifier types are basically opaque blobs to the API users and are only ever generated by vdsm itself. Because of this, we can change the internal structure of the identifier to require new information or (before freezing the API) remove fields that no longer make sense. I would greatly appreciate your comments on this proposal. If it seems reasonable, I will revamp the current schema to make the necessary changes and provide the Bridge patch functions to convert between the current implementation and the new schema. --- sample schema patch --- commit 48f6b0f0a111dd0b372d211a4e566ce87f375cee Author: Adam Litke <agl(a)us.ibm.com> Date: Tue Nov 27 14:14:06 2012 -0600 schema: Introduce class identifier types When calling API methods that belong to a particular class, a class instance must be indicated by passing a set of identifiers in the request. The location of these parameters within the request is: 'params' -> '__obj__'. Since this set of identifiers must be used together to correctly instantiate an object, it makes sense to define these as proper types within the API. Then, functions that return an object (or list of objects) can refer to the correct type. Signed-off-by: Adam Litke <agl(a)us.ibm.com> diff --git a/vdsm_api/vdsmapi-schema.json b/vdsm_api/vdsmapi-schema.json index 0418e6e..7e2e851 100644 --- a/vdsm_api/vdsmapi-schema.json +++ b/vdsm_api/vdsmapi-schema.json @@ -937,7 +937,7 @@ # Since: 4.10.0 ## {'command': {'class': 'Host', 'name': 'getConnectedStoragePools'}, - 'returns': ['StoragePool']} + 'returns': ['StoragePoolIdentifier']} ## # @BlockDeviceType: @@ -1572,7 +1572,7 @@ {'command': {'class': 'Host', 'name': 'getStorageDomains'}, 'data': {'*storagepoolID': 'UUID', '*domainClass': 'StorageDomainImageClass', '*storageType': 'StorageDomainType', '*remotePath': 'str'}, - 'returns': ['StorageDomain']} + 'returns': ['StorageDomainIdentifier']} ## # @Host.getStorageRepoStats: @@ -2406,7 +2406,7 @@ ## {'command': {'class': 'Host', 'name': 'getVMList'}, 'data': {'*vmList': ['UUID']}, - 'returns': ['VM']} + 'returns': ['VMIdentifier']} ## # @Host.ping: @@ -2744,10 +2744,11 @@ 'returns': 'ConnectionRefMap'} ## Category: @ISCSIConnection ################################################## + ## -# @ISCSIConnection: +# @ISCSIConnectionIdentifier: # -# ISCSIConnection API object. +# Identifier for an ISCSIConnection object. # # @host: A fully-qualified domain name (FQDN) or IP address # @@ -2757,11 +2758,21 @@ # # @password: #optional The password associated with the given username # -# Since: 4.10.0 +# Since: 4.10.1 +## +{'type': 'ISCSIConnectionIdentifier', + 'data': {'host': 'str', 'port': 'int', '*user': 'str', '*password': 'str'}} + +## +# @ISCSIConnection: +# +# ISCSIConnection API object. +# +# @ident: The object identifier +# +# Since: 4.10.1 ## -{'class': 'ISCSIConnection', - 'data': {'host': 'str', 'port': 'int', '*user': 'str', - '*password': 'str'}} +{'class': 'ISCSIConnection', 'ident': 'ISCSIConnectionIdentifier'} ## # @ISCSIConnection.discoverSendTargets: @@ -2777,10 +2788,11 @@ 'returns': ['str']} ## Category: @Image ############################################################ + ## -# @Image: +# @ImageIdentifier: # -# Image API object. +# Identifier for an Image object. # # @imageID: The UUID of the Image # @@ -2788,13 +2800,24 @@ # # @storagedomainID: The UUID of the Storage Domain associated with the Image # -# Since: 4.10.0 +# Since: 4.10.1 ## -{'class': 'Image', +{'type': 'ImageIdentifier', 'data': {'imageID': 'UUID', 'storagepoolID': 'UUID', 'storagedomainID': 'UUID'}} ## +# @Image: +# +# Image API object. +# +# @ident: The object identifier +# +# Since: 4.10.1 +## +{'class': 'Image', 'ident': 'ImageIdentifier'} + +## # @Image.delete: # # Delete the Image and all of its Volumes. @@ -2843,7 +2866,7 @@ # Since: 4.10.0 ## {'command': {'class': 'Image', 'name': 'getVolumes'}, - 'returns': ['Volume']} + 'returns': ['VolumeIdentifier']} ## # @Image.mergeSnapshots: @@ -2905,17 +2928,26 @@ ## Category: @LVMVolumeGroup ################################################### ## +# @LVMVolumeGroupIdentifier: +# +# An identifier for a LVMVolumeGroup object. +# +# @lvmvolumegroupID: The volume group UUID +# +# Since: 4.10.1 +## +{'type': 'LVMVolumeGroupIdentifier', 'data': {'lvmvolumegroupID': 'UUID'}} + +## # @LVMVolumeGroup: # # LVMVolumeGroup API object. # -# @lvmvolumegroupID: #optional Associate this object with an existing LVM -# Volume Group +# @ident: The object identifier # -# Since: 4.10.0 +# Since: 4.10.1 ## -{'class': 'LVMVolumeGroup', - 'data': {'lvmvolumegroupID': 'UUID'}} +{'class': 'LVMVolumeGroup', 'ident': 'LVMVolumeGroupIdentifier'} ## # @LVMVolumeGroup.create: @@ -2964,21 +2996,32 @@ ## Category: @StorageDomain #################################################### ## -# @StorageDomain: +# @StorageDomainIdentifier: # -# StorageDomain API object. +# An identifier for a StorageDomain object. # # @storagedomainID: Associate this object with a new or existing Storage Domain # # @storagepoolID: #optional The Storage Pool UUID if this Storage Domain is # attached # -# Since: 4.10.0 +# Since: 4.10.1 ## -{'class': 'StorageDomain', +{'type': 'StorageDomainIdentifier', 'data': {'storagedomainID': 'UUID', 'storagepoolID': 'UUID'}} ## +# @StorageDomain: +# +# StorageDomain API object. +# +# @ident: The object identifier +# +# Since: 4.10.1 +## +{'class': 'StorageDomain', 'ident': 'StorageDomainIdentifier'} + +## # @StorageDomain.activate: # # Activate an attached but inactive Storage Domain. @@ -3184,7 +3227,7 @@ # Since: 4.10.0 ## {'command': {'class': 'StorageDomain', 'name': 'getImages'}, - 'returns': ['Image']} + 'returns': ['ImageIdentifier']} ## # @StorageDomainRole: @@ -3295,7 +3338,7 @@ ## {'command': {'class': 'StorageDomain', 'name': 'getVolumes'}, 'data': {'imageID': 'UUID'}, - 'returns': ['Volume']} + 'returns': ['VolumeIdentifier']} ## # @StorageDomain.setDescription: @@ -3355,15 +3398,26 @@ ## Category: @StoragePool ###################################################### ## +# @StoragePoolIdentifier: +# +# An identifier for a StoragePool object. +# +# @storagepoolID: Associate this object with a new or existing Storage Pool +# +# Since: 4.10.1 +## +{'type': 'StoragePoolIdentifier', 'data': {'storagepoolID': 'UUID'}} + +## # @StoragePool: # # StoragePool API object. # -# @storagepoolID: Associate this object with a new or existing Storage Pool +# @ident: The object identifier # -# Since: 4.10.0 +# Since: 4.10.1 ## -{'class': 'StoragePool', 'data': {'storagepoolID': 'UUID'}} +{'class': 'StoragePool', 'ident': 'StoragePoolIdentifier'} ## # @StoragePool.connect: @@ -3629,7 +3683,7 @@ ## {'command': {'class': 'StoragePool', 'name': 'getDomainsContainingImage'}, 'data': {'imageID': 'UUID', '*onlyDataDomains': 'bool'}, - 'returns': ['StorageDomain']} + 'returns': ['StorageDomainIdentifier']} ## # @StoragePool.getIsoList: @@ -4058,15 +4112,27 @@ ## Category: @Task ############################################################# ## +# @TaskIdentifier: +# +# An identifier for a Task object. +# +# @taskID: The task UUID +# +# Since: 4.10.1 +## +{'type': 'TaskIdentifier', 'data': {'taskID': 'UUID'}} + + +## # @Task: # # Task API object. # -# @taskID: Associate this object with an existing Task +# @ident: The object identifier # -# Since: 4.10.0 +# Since: 4.10.1 ## -{'class': 'Task', 'data': {'taskID': 'UUID'}} +{'class': 'Task', 'ident': 'TaskIdentifier'} ## # @Task.clear: @@ -4123,15 +4189,26 @@ ## Category: @VM ############################################################### ## +# @VMIdentifier: +# +# An identifier for a VM object. +# +# @vmID: The task UUID +# +# Since: 4.10.1 +## +{'type': 'VMIdentifier', 'data': {'vmID': 'UUID'}} + +## # @VM: # # VM API object. # -# @vmID: Associate this object with an existing VM +# @ident: The object identifier # -# Since: 4.10.0 +# Since: 4.10.1 ## -{'class': 'VM', 'data': {'vmID': 'UUID'}} +{'class': 'VM', 'ident': 'VMIdentifier'} ## # @DriveSpecVolume: @@ -5161,9 +5238,9 @@ ## Category: @Volume ########################################################### ## -# @Volume: +# @VolumeIdentifier: # -# Volume API object. +# An identifier for a Volume object. # # @volumeID: The UUID of the Volume # @@ -5173,13 +5250,24 @@ # # @imageID: The Image associated with @UUID # -# Since: 4.10.0 +# Since: 4.10.1 ## -{'class': 'Volume', +{'type': 'VolumeIdentifier', 'data': {'volumeID': 'UUID', 'storagepoolID': 'UUID', 'storagedomainID': 'UUID', 'imageID': 'UUID'}} ## +# @Volume: +# +# Volume API object. +# +# @ident: The object identifier +# +# Since: 4.10.1 +## +{'class': 'Volume', 'ident': 'VolumeIdentifier'} + +## # @VolumeRole: # # An enumeration of Volume Roles. -- Adam Litke <agl(a)us.ibm.com> IBM Linux Technology Center

11 years, 4 months

2
8
0 / 0

AUTO: Yih-Herng Chuang/Seattle/IBM is out of the office, (returning 11/30/2012)

by Yih-Herng Chuang

I am out of the office until 11/30/2012. For KVM tech issues, please contact team lead Doug Jans. For others, please contact my manager John Aguiar. I will respond your email when I am back to work. Note: This is an automated response to your message "vdsm-devel Digest, Vol 18, Issue 41" sent on 11/29/2012 5:00:05. This is the only notification you will receive while this person is away.

11 years, 5 months

1
0
0 / 0

[ATTENTION] vdsm-bootstrap/host deployment (pre-3.2)

by Alon Bar-Lev

Hello All, Preparing to ovirt-engine 3.2 the entire "vdsm-bootstrap" bootstrap was re-written from scratch into more pluggable and flexible implementation, available at git master and nightly snapshots. As far as packaging is concerned there are now two more dependencies to ovirt-engine: * otopi -- oVirt Task Oriented Pluggable Installer/Implementation * ovirt-host-deploy -- oVirt host deploy tool These packages replace the legacy vdsm-bootstrap package that was distributed with vdsm. Git repositories are available at at[1][2]. Documentation is available at Git repositories - README*. Builds are available at usual place[3]. Bugzilla components will be available shortly. Change log is attached. There is no change in the way the engine is performing the host deployment process in term of user experience, other than event log messages during deployment were improved. The log of the deployment is fetched from host and stored at engine machine at /var/log/ovirt-engine/host-deploy, on host it is at /tmp/ovirt-host-deploy*.log and deleted when fetched to engine. Among other features, the ovir-host-deploy package can be installed manually on host and executed to prepare host for installation, in future we may be able to add host to engine without performing the deployment process, for now it will be usable for integration tests. The internals are completely different, instead of having 3 different bootstrap sequences: 1. host install 2. ovirt-node install 3. ovirt-node approve We now have single sequence which is common to host and node installation or re-installation, end result is much simpler implementation. Please report any issues even minor issues, so we can stabilize it for 3.2 release. Best Regards, Alon Bar-Lev. [1] http://gerrit.ovirt.org/gitweb?p=otopi.git;a=tree [2] http://gerrit.ovirt.org/gitweb?p=ovirt-host-deploy.git;a=tree [3] http://www.ovirt.org/releases/nightly/rpm/Fedora/17/noarch/ --- Change Log * offline packager feature. * tuned is installed with virtual-host profile. * initial implementation based on otpoi. * implementation is based on legacy vdsm-bootstrap pacakge functionality. * legacy-removed: legacy VDSM (<3.0) config upgrade. * legacy-removed: change machine width core file # echo /var/lib/vdsm/core > /proc/sys/kernel/core_pattern * legacy-removed: kernel version test, package dependency is sufficient. * legacy-removed: do not add kernel parameter processor.max_cstate=1 warn if not have constant_tsc https://bugzilla.redhat.com/show_bug.cgi?id=770153 * legacy-change: io elevator scheduler set in kernel command-line use either udev rule in vdsm package or tuned. * legacy-change: vdsm libvirt reconfigure vdsm is reconfigured with file based trigger instead unsupported systemd init.d parameter. * legacy-change: distribution checks are simpler based on Python platform, minimum: - rhel-6.2 - fedora-17 * legacy-change: minimum vdsm version is taken from engine not hard coded. * legacy-change: pki is now using m2crypto to generate certificate request and parse certificates. * legacy-change: use iproute2 instead of python ethtool to avoid another dependency for host name validation. * legacy-change: use iproute2 instead of reading /proc/net/route for route information and interface information. * legacy-change: do not use vdsm.netinfo for vlan and bonding as it requires /usr/share/vdsm modules, and it is trivial anyway. * legacy-change: use vdsm-store-net-config script to commit network config instead of internal duplicate implementation. * legacy-change: /etc/vdsm/vdsm.conf is overridden unless VDSM/configOverride environment is set to True * legacy-change: /etc/vdsm/vdsm.conf is not read of fake_qemu. set VDSM/checkVirtHardware environment to False to avoid hardware detection. * legacy-change: following gluster packages not installed: - glusterfs-rdma - glusterfs-geo-replication

11 years, 5 months

5
14
0 / 0

ovirt network

by lpeer＠redhat.com

A single instance of the following meeting has been modified: Subject: ovirt network Organiser: "Livnat Peer" <lpeer(a)redhat.com> Time: Wednesday, 5 December, 2012, 4:00:00 PM - 5:00:00 PM GMT +02:00 Jerusalem [MODIFIED] 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, As discussed previously on the list, I am adding a monthly discussion on Networking in oVirt. In this meeting we'll discuss general status of networking and features that we're missing. Thanks, Livnat Bridge ID: 972506565679 Dial-in information: Reservationless-Plus Toll Free Dial-In Number (US & Canada): (800) 451-8679 Reservationless-Plus International Dial-In Number: (212) 729-5016 Conference code: 8425973915 Global Access Numbers Local: Australia, Sydney Dial-In #: 0289852326 Austria, Vienna Dial-In #: 012534978196 Belgium, Brussels Dial-In #: 027920405 China Dial-In #: 4006205013 Denmark, Copenhagen Dial-In #: 32729215 Finland, Helsinki Dial-In #: 0923194436 France, Paris Dial-In #: 0170377140 Germany, Berlin Dial-In #: 030300190579 Ireland, Dublin Dial-In #: 014367793 Italy, Milan Dial-In #: 0236269529 Netherlands, Amsterdam Dial-In #: 0207975872 Norway, Oslo Dial-In #: 21033188 Singapore Dial-In #: 64840858 Spain, Barcelona Dial-In #: 935452328 Sweden, Stockholm Dial-In #: 0850513770 Switzerland, Geneva Dial-In #: 0225927881 United Kingdom Dial-In #: 02078970515 United Kingdom Dial-In #: 08445790676 United Kingdom, LocalCall Dial-In #: 08445790678 United States Dial-In #: 2127295016 Global Access Numbers Tollfree: Argentina Dial-In #: 8004441016 Australia Dial-In #: 1800337169 Austria Dial-In #: 0800005898 Bahamas Dial-In #: 18002054776 Bahrain Dial-In #: 80004377 Belgium Dial-In #: 080048325 Brazil Dial-In #: 08008921002 Bulgaria Dial-In #: 008001100236 Chile Dial-In #: 800370228 Colombia Dial-In #: 018009134033 Costa Rica Dial-In #: 08000131048 Cyprus Dial-In #: 80095297 Czech Republic Dial-In #: 800700318 Denmark Dial-In #: 80887114 Dominican Republic Dial-In #: 18887512313 Estonia Dial-In #: 8000100232 Finland Dial-In #: 0800117116 France Dial-In #: 0805632867 Germany Dial-In #: 8006647541 Greece Dial-In #: 00800127562 Hong Kong Dial-In #: 800930349 Hungary Dial-In #: 0680016796 Iceland Dial-In #: 8008967 India Dial-In #: 0008006501533 Indonesia Dial-In #: 0018030179162 Ireland Dial-In #: 1800932401 Israel Dial-In #: 1809462557 Italy Dial-In #: 800985897 Jamaica Dial-In #: 18002050328 Japan Dial-In #: 0120934453 Korea (South) Dial-In #: 007986517393 Latvia Dial-In #: 80003339 Lithuania Dial-In #: 880030479 Luxembourg Dial-In #: 80026595 Malaysia Dial-In #: 1800814451 Mexico Dial-In #: 0018664590915 New Zealand Dial-In #: 0800888167 Norway Dial-In #: 80012994 Panama Dial-In #: 008002269184 Philippines Dial-In #: 180011100991 Poland Dial-In #: 008001210187 Portugal Dial-In #: 800814625 Russian Federation Dial-In #: 81080028341012 Saint Kitts and Nevis Dial-In #: 18002059252 Singapore Dial-In #: 8006162235 Slovak Republic Dial-In #: 0800001441 South Africa Dial-In #: 0800981148 Spain Dial-In #: 800300524 Sweden Dial-In #: 200896860 Switzerland Dial-In #: 800650077 Taiwan Dial-In #: 00801127141 Thailand Dial-In #: 001800656966 Trinidad and Tobago Dial-In #: 18002024615 United Arab Emirates Dial-In #: 8000650591 United Kingdom Dial-In #: 08006948057 United States Dial-In #: 8004518679 Uruguay Dial-In #: 00040190315 Venezuela Dial-In #: 08001627182

11 years, 5 months

1
0
0 / 0

ovirt network monthly sync meeting - Agenda

by lpeer＠redhat.com

Hi All, We have a scheduled sync meeting on oVirt network today. We did not set an agenda for this meeting yet so I'll postpone it for next week. Please respond to this note with agenda items. If there are no agenda items by December 5th, I'll cancel the call. Thanks, Livnat

11 years, 5 months

1
0
0 / 0

Proposal to add Adam Litke as maintainer to vdsm

by iheim＠redhat.com

Adam has been submitting numerous patches for VDSM for more than a year, most noticeably on improving VDSM API into, well, an API... I'd like to propose Adam as a maintainer for vdsm. Thanks, Itamar

11 years, 5 months

9
9
0 / 0

Getting information about a disk image through the VDSM API

by Morrissey, Christopher

Hi All, I'm looking into adding a capability in oVirt to register a disk that has been cloned using NetApp cloning utilities. Right now, I see that once the disk images have been cloned to new UUIDs for the disk image directory and the underlying disk image files, the new disk image UUID will be seen by VDSM through the "getImagesList" command. At this point, if possible, I'd like to get the rest of the information that's on the file system so I can reconstruct the disk information in the oVirt DB through the VDSM API. Is this approach the best way to go or is it even possible to do this? Any thoughts would be helpful. Thanks! -Chris Chris Morrissey Software Engineer NetApp Inc. 919.476.4428

11 years, 5 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

vdsm-devel November 2012