Hello,
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"/>
<serial>c94c9cf2-fa1c-4e43-8c77-f222dbfb032d</serial>
<driver cache="none" error_policy="stop" io="threads" name="qemu"
type="raw"/>
</disk>
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'/>
</source>
<target dev='vda' bus='virtio'/>
</disk>
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())
vdsOK(
s.create(dict(vmId=vmId,
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
memSize=256,
display="vnc",
vmName="vm-backed-by-gluster",
)
)
)
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.
thanx,
deepak
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel
