I am proposing a method for VDSM to exploit disk of 'network' type under PosixFS. Altho' I am taking Gluster as the storage backend example, it should apply to any other backends (that support network disk type) as well.

Currently under PosixFS, the design is to mount the 'server:/export' and use that as storage domain.
The libvirt XML generated for such a disk is something like below...

<disk device="disk" snapshot="no" type="file">
<source file="/rhev/data-center/8fe261ea-43c2-4635-a08a-ccbafe0cde0e/4f31ea5c-c01e-4578-8353-8897b2d691b4/images/c94c9cf2-fa1c-4e43-8c77-f222dbfb032d/eff4db09-1fde-43cd-a75b-34054a64182b"/>
<target bus="ide" dev="hda"/>
<driver cache="none" error_policy="stop" io="threads" name="qemu" type="raw"/>

This works well, but does not help exploit the gluster block backend of QEMU, since the QEMU cmdline generated is -drive file='/rhev/data-center/....'

Gluster fits as a network block device in QEMU, similar to ceph and sheepdog backend, QEMU already has.
The proposed libvirt XML for Gluster based disks is ... (WIP)

<disk type='network' device='disk'>
      <driver name='qemu' type='raw'/>
      <source protocol="gluster" name="volname:imgname">
          <host name='server' port='xxx'/>
      <target dev='vda' bus='virtio'/>

This causes libvirt to generate QEMU cmdline like : -drive file=gluster:server@port:volname:imgname. The imgname is relative the gluster mount point.

I am proposing the below to help VDSM exploit disk as a network device under PosixFS. Here is a code snippet (taken from a vdsm standalone script) of how a storage domain & VM are created in VDSM....

# When storage domain is mounted

gluster_conn = "kvmfs01-hs22:dpkvol" # gluster_server:volume_name
vdsOK(s.connectStorageServer(SHAREDFS_DOMAIN, "my gluster mount", [dict(id=1, connection=gluster_conn, vfs_type="glusterfs", mnt_options="")])

# do other things...createStoragePool, SPM start etc...


# Now create a VM

vmId = str(uuid.uuid4())
drives=[dict(poolID=spUUID, domainID=sdUUID, imageID=imgUUID, volumeID=volUUID, disk_type="network", protocol="gluster", connection=gluster_conn)], # Proposed way #drives=[dict(poolID=spUUID, domainID=sdUUID, imageID=imgUUID, volumeID=volUUID)], # Existing way

1) User (engine in ovirt case) passes disk_type, protocol & connection keywords as depicted above. NOTE: disk_type is used instead of just type to avoid confusion with driver_type -- protocol and connection are already available to User as he/she used it as part of connectStorageServer ( connection and vfs_type ) -- disk_type is something that User chooses instead of default (which is file type)

2) Based on these extra keywords passed, the getXML() of 'class Drive' in libvirtvm.py can be modified to generate <disk type='network'...> as shown above. Some parsing would be needed to extract the server, volname. imgname relative to gluster mount point can be extracted from drive['path'] which holds the fully qualified path.

3) Since these keywords are drive specific, User can choose which drives he/she wants to use network protocol Vs file. Not passing these keywords defaults to file, which is what happens today.

This approach would help VDSM to support network disk types under PosixFS and thus provide the ability to the User to choose file or network disk types on a per drive basis.

I will post a RFC patch soon ( awaiting libvirt changes ), comments welcome.


vdsm-devel mailing list

Reply via email to