search for: blkdiscardzeroes

On Fri, Mar 9, 2018 at 4:25 PM Richard W.M. Jones <rjones@redhat.com> wrote: > It has to be said it would be really convenient to have a 'zero' > and/or 'trim' method of some sort. > 'trim' means discard? Currently we cannot support discard on block storage since ovirt may need to wipe lvs when deleting a disk, and discarding may leave unwiped user data.

Hello，everyone I ran virt-resize(v1.30.4) on my CentOS 7.1 to resize win2008r2 and got the warning message (virt-resize: warning: unknown/unavailable method for expanding the ntfs filesystem on /dev/sda2): >/usr/local/libguestfs-1.30.4/run virt-resize --expand /dev/sda2 /images/win2008_src.raw /dev/vg0/win2008_resize_dst [ 0.0] Examining

....finalize does? > Currently we cannot support discard on block storage since ovirt may > need to wipe lvs when deleting a disk, and discarding may leave > unwiped user data. This may change in 4.3 if we switch to wipe on > creation instead of wipe after delete. I think this depends on BLKDISCARDZEROES[1] for the block device? Of course if you're worried about data remanence for someone who has access to the physical device then that wouldn't be enough. [1] https://rwmj.wordpress.com/2014/03/11/blkdiscard-blkzeroout-blkdiscardzeroes-blksecdiscard/ > POST /images/ticket-id ... > ....

This patch is easier to read if you use the 'git show -w' option. Also observe that: fun a -> ( fun () -> (* code *) ) (ie. returning a closure) is identical to: fun a () -> (* code *) Rich.

...rrently we cannot support discard on block storage since ovirt may > > need to wipe lvs when deleting a disk, and discarding may leave > > unwiped user data. This may change in 4.3 if we switch to wipe on > > creation instead of wipe after delete. > > I think this depends on BLKDISCARDZEROES[1] for the block device? Of > course if you're worried about data remanence for someone who has > access to the physical device then that wouldn't be enough. > BLKDISCARDZEROES was never reliable and it was removed from the kernel recently. Please check https://patchwork.kernel.o...

...n, Dec 14, 2015 at 10:46:00AM +0800, Jeffrey wrote: > > > libguestfs-winsupport-7.1-4.el7.x86_64 doesn't work for me either. :( > > > >./run guestfish -a /dev/null run : supported > acl yes > augeas yes > blkdiscard yes > blkdiscardzeroes yes > btrfs yes > extlinux yes > fstrim yes > gdisk yes > grub no > hivex yes > inotify yes > journal yes > ldm no > linuxcaps yes > linuxfsuuid yes > li...

Hi! This question emerged during testing of oVirt sparsify integration. oVirt now is able to run virt-sparsify on VM disks. But virt-sparsify seems to have no effect on iSCSI disks. Does virt-sparsify work on iSCSI disks? Maybe in sum situation, with some configuration of iSCSI server, with some specific virt-sparsify options? Shmuel

This set of patches: - Adds new APIs to support discard in libguestfs. - Adds discard support to virt-format. - Adds discard support to virt-sysprep. - Implements virt-sparsify --in-place. This is now working, after fixing the rather stupid bug in fstrim. I've pushed the ones which were ACKed previously + the fstrim fix. Rich.

On 27/02/16 01:05, Richard W.M. Jones wrote: > On Sat, Feb 27, 2016 at 12:53:51AM +0200, noxdafox wrote: >> On 26/02/16 10:12, Richard W.M. Jones wrote: >>> On Fri, Feb 26, 2016 at 12:16:22AM +0200, noxdafox wrote: >>>> According to autogen.sh output Perl bindings and virt tools seem to >>>> be missing, could it be related to this? Are the tests relying to

...t; ./run guestfish run : supported > > ? That precise command fails with the following message: libguestfs: error: you must call guestfs_add_drive before guestfs_launch If I feed a disk image I get it to work and returns: acl yes augeas yes blkdiscard yes blkdiscardzeroes yes btrfs no extlinux no fstrim yes gdisk yes grub no hivex yes inotify yes journal yes ldm no linuxcaps yes linuxfsuuid yes linuxmodules yes linuxxattrs yes...

This still isn't working at the moment. See: http://marc.info/?t=139457409300003&r=1&w=2 This set of patches: - Adds new APIs to support discard in libguestfs. - Adds discard support to virt-format. - Adds discard support to virt-sysprep. - Implements virt-sparsify --in-place. Rich.

This is a follow-up to the other generator changes in: https://www.redhat.com/archives/libguestfs/2017-February/msg00217.html Rich.

...[]; + style = RErr, [String (Device, "device")], []; optional = Some "blkdiscard"; shortdesc = "discard all blocks on a device"; longdesc = "\ @@ -8849,7 +8849,7 @@ C<guestfs_add_drive_opts>)." }; { defaults with name = "blkdiscardzeroes"; added = (1, 25, 44); - style = RBool "zeroes", [Device "device"], []; + style = RBool "zeroes", [String (Device, "device")], []; optional = Some "blkdiscardzeroes"; shortdesc = "return true if discarded blocks are read as...

Very large but mechanical change to the generator. Rich.

The existing mechanism was clunky, slow and used ~ 10 MB of local disk. Rich.

Split up the huge generator/actions.ml into several smaller files. Rich.

See this bug for background information: https://bugzilla.redhat.com/show_bug.cgi?id=1350465 Thanks: Tomáš Golembiovský --- v2v/virt-v2v.pod | 38 ++++++++++++++++++++++++++------------ 1 file changed, 26 insertions(+), 12 deletions(-) diff --git a/v2v/virt-v2v.pod b/v2v/virt-v2v.pod index e68d75cf8..0943bf305 100644 --- a/v2v/virt-v2v.pod +++ b/v2v/virt-v2v.pod @@ -1909,18 +1909,32 @@ that

See this bug for background information: https://bugzilla.redhat.com/show_bug.cgi?id=1350465 --- v2v/virt-v2v.pod | 39 +++++++++++++++++++++++++++------------ 1 file changed, 27 insertions(+), 12 deletions(-) diff --git a/v2v/virt-v2v.pod b/v2v/virt-v2v.pod index e68d75cf8..93d1a9ecd 100644 --- a/v2v/virt-v2v.pod +++ b/v2v/virt-v2v.pod @@ -1909,18 +1909,33 @@ that guest through the RHV-M UI,

If the connection is not local, paths of disks will refer to the remote host, which were mistakenly handled as local paths (in the best case failing to open a non-existing disk, and in the worst case opening a different disk!). In case the disks are remote resources like ssh or ceph, nothing guarantees that the hostname can be reached from the local machine, or even that it is actually the same on

Hopefully this time ...