Tóth István wrote:
Hello! I had a hobby project where I needed to manipulate xen disk images on remote systems, that used a model similar to libirt's remote support. Based on what I learnt from it, I came up with a possible model for libvirt's remote storage support. I present it here for discussion. We typically store the images in volumes on LVM, or in dedicated file system folders. The folders and volume groups usable by libvirt can be limited in a config file. It is probably not neccessary to differentiate between defined and created files, as you can not stop and start a file like a domain, you either have it on disk, or not.
Agreed.
Libvirt should not store information on these files, everything should be checked/listed on the fly, so that if you just copy an image to a directory, libvirt can deduct all information (well, all it can) on it, and handle it just as if the file was created by it.
Agreed.
The handle for the file is its path, plus its virConnect object (i.e. the host it is on). For consistency, it may be possible to create an object for it, but as disk images have no persistent properties apart from what is on the disk, and it can always be checked from there, it provides no extra functionality.
Probably the 'handle' is its filename or device name + the virDomain object.For example, here are the domains and their images running on my Xen host at the moment. I got this by writing a simple script which parses the domain XML:
fc6_0:
/var/lib/xen/images/fc6_0.img -> xvda
/var/lib/xen/images/home.disk -> xvdb
fc6_1:
/var/lib/xen/images/fc6_1.img -> xvda
debian32fv:
/var/lib/xen/images/debian32fv.img -> hda
f764pv:
/dev/Images/f764pv -> xvda
freebsd32fv:
/var/lib/xen/images/freebsd32fv.img -> hda
[CD] -> hdc
gentoo32fv:
/var/lib/xen/images/gentoo32fv.img -> hda
I think there is no need to support remote files explicitly, as the domains mount local files/volumes. The file/volume may actually be mounted from a NAS or SAN, of course, but it does not matter because we use the local path names, and AFAIK all virtualization tools use local files or local devices as blockdevs. I have added compression to the mix because it is immensely useful. I have used lzop in my project, and a full backup and restore was much faster when using a compressed backup file, than with and uncrompessed one. It conserves disk space, as well as cpu/bus capacity. Zeroing out newly allocated files, helps with compressed backups, as well as security. It also means that no holey files can be used. The objects we are dealing with are disk images. They have the following properties: -Path: The unix path of the file ( /mnt/images/fc7.img or /dev/VG/fc7) -Compression: Mountable/compressed -Type: Plain file/LVM volume/ What else? -Size -Filesystem: swap/ext3/xfs/.... -Is it mounted?
This is where it gets very complicated. Files or partitions may represent simple filesystems, or partitioned block devices, or LVM PVs, or filesystems or partitions in formats that we have no chance of understanding (eg. NTFS), or snapshots, or dm_crypt, or compressed and so on and so on.
To do this in any feasible way, I'm sure we'll need a library, the obvious one being gparted (http://www.gnu.org/software/parted/). However parted has a lot of problems, and most specifically it doesn't support LVM.
I am aware of a project to make LVM accessible as a library and to include LVM library support in gparted/libparted, but I'm not sure how it is progressing.
We can do the following operations on the images:
[... operations ...]I'd prefer to stick to the minimum set of operations needed now and add to them later. But yes, the mix of operations looks OK.
Much of this work is needed by virt-p2v and virt-df (http://et.redhat.com/~rjones/virt-p2v/ and virt-df to be released soon).
Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list