I didn't test bad formats just wanted to know the consistency for file format. I saw that you comment on the bz as well.
Thanks you, Shahar. On Tue, Dec 20, 2016 at 8:41 PM, John Ferlan <jfer...@redhat.com> wrote: > > > On 12/05/2016 05:27 AM, Shahar Havivi wrote: > > Ping > > > > Sorry for the delay... Lots of investigation, patches, and other work. > > > On Wed, Nov 30, 2016 at 3:13 PM, Shahar Havivi <shav...@redhat.com > > <mailto:shav...@redhat.com>> wrote: > > > > Hi, > > > > I am using virStorageVolGetInfo to get the volume size > > virStorageVol.download to download a > > normal file for VDSM project. > > Normal as in a 'raw' fully allocated file? As opposed to a sparse and/or > container (e.g. qcow2) file? > > > > > I want to add support for block devices as well, I was able to see > > the size > > via virDomainBlockInfo and download via virDomain.blockPeek which is > > works > > fine for both file and block device. > > As described in the bz, but for others benefit... While looking into > this I found a commit Eric Blake made: > > http://libvirt.org/git/?p=libvirt.git;a=commit;h= > 0282ca45a0a4c384226d526d4878cacd77936ef4 > > which more or less summarizes to: > > capacity: logical size in bytes of the image (how much storage > the guest will see) > allocation: host storage in bytes occupied by the image (such > as highest allocated extent if there are no holes, > similar to 'du') > physical: host physical size in bytes of the image container > (last offset, similar to 'ls') > > The data virDomainGetBlockInfo gets when the domain is not active is the > same data that virStorageVolGetInfo gets (which I know you couldn't use > because it didn't have <physical>). IOW: In the long run for libvirt, > they use the same API's to get the data. > > For a "file" backed <disk> the API's use 'fstat()' while for a "block" > backed <disk> the API's use 'lseek()' to the end. > > Unfortunately there were some differences that have crept into > virDomainGetBlockInfo for active domain as a result of changes made to > support virConnectGetAllDomainStats. Fortunately those differences are > mostly related to domain disk devices with sources that are sparse > files, containers (qcow2, qed for example), or block devices (perhaps an > iSCSI /dev/sdX device) that's using some sort of container file. > > The virDomainBlockPeek strictly uses the lseek(), which I think should > return the same answer as fstat() - although I could be wrong. > > > > > 1. Can I depend on virDomainBlockInfo for non block devices? > > You should be able to for an inactive domain. If it doesn't provide you > with the right or expected answer, then investigation could be done. > > The API "works" using the <target dev='nnX' bus='$BUS'/> such that > "block" is how the guest is viewing things - e.g. /dev/nnX if nnX were > valid. Typically for bus='virtio', it's dev='vdX' where X is a, b, c, > etc. Still it the <source ...> part of the domain XML which will get > the answer for an inactive domain, while for an active domain there's > matching going on from a qemu call to get the block info from the domain. > > > 2. Does the virDomainBlockInfo return the correct physical size for > > normal file? > > I hope so... It's supposed to. Of course what's normal these days? I > would think sparse files are the norm. After all who wants to require > 15-20G when they could get away with 5G knowing that up to some 15-20G > could be used. > > There's also block devices using a logical backend where we rely on the > logical code to provide the "right answer". > > Again - if something isn't providing the right answer, then more details > would be necessary. > > > 3. Performance wise do we have a difference between > > virStorageVol.download and virDomain.blockPeek? > > > > Well blockPeek is pretty quick - it's looking at lseek() data. Not sure > if you meant to compare vs. GetBlockInfo which uses fstat or lseek. The > download function is a bit different, but IIRC from the bz is your > actual consumer. > > > > > Assuming the VMs are down, this is the code I intend to use for all > > formats: > > > > vm = con.lookupByName(options.vmname) > > info = vm.blockInfo(src) > > physical = info[2] > > > > off = 0 > > size = 0 > > with open(dest, 'w+') as f: > > while off < physical: > > if (physical - off) < bufsize: > > size = physical - off > > else: > > size = bufsize > > buf = vm.blockPeek(src, off, size) > > f.write(buf) > > off += size > > > > > > That would seem to work with the caveat about the <disk type='block' > device='disk'> with "<source dev='/dev/sdX'/> where the /dev/sdX (in my > case) in an iSCSI target that was creating using "qemu-img create -t > qcow2 file.qcow2 1G" and the resulting lseek() is not 1G, but something > quite a bit smaller. For that type of <disk> device, the "capacity" > returns 1G. > > I assume you have a test bed of various formats so you can ensure you > get the "expected" results? > > > John >
_______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
