[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] libvirt, libxl and QDISKs
Marek Marczykowski wrote: > On 26.04.2013 13:40, Ian Campbell wrote: > >> On Fri, 2013-04-26 at 12:31 +0100, Marek Marczykowski wrote: >> >>> What about old good loop+phy based backend for file disk images? I don't >>> want >>> whole qemu in dom0 for PV domains, only for handling simple disk backend. >>> Additionally sparse images + loop + phy + mount -o discard in domU makes the >>> images "auto shrinking". Don't know if qemu is able to do this. >>> >> IIRC the problem with loop+phy is that loop doesn't do O_DIRECT and >> therefore your data isn't actually on the disk when you might think it >> is, which can lead to filesystem corruption even if the f/s is doing >> correct barriers. >> >> >>> Attached patch, which I currently use for that. If it is close to something >>> that would be accepted, I will send it in new thread. >>> >> I think you can use a block script for this (i.e. it does the loop >> mount) and avoid patching libxl at all. That's what xend did at least... >> > > This also was solution I've evaluated, but libvirt developers don't want to > hear about disk->script setting in official libvirt, so I still need to patch > some library. Good old loop+phy is supported by the legacy libvirt xen driver without libvirt needing <disk><script /></disk>, generally by using <driver name='file' />. > Choosing libxl seems to be more universal. Setting loop in libxl > is also much faster than calling script for that. > Perhaps I can rewrite this patch to allow the choice > (LIBXL_DISK_BACKEND_LOOP)? > With such a patch, libvirt could set the backend to LIBXL_DISK_BACKEND_LOOP when <driver name='file'>, preserving loop+phy backend setup done by the old toolstack. Regards, Jim _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |