similar to: Is there still no easier way to shrink a VM image?

Thanks for letting me know I'm not making myself clear, let me try again with a few more specifics, These are Windows VMs with three disk images for C:, D: and L:. To simplify I'll focus on the image for C: which had grown to 77G physical size on the hypervisor's ssd (I just double-checked that with 'ls -al' because qemu-img below says 70G, this image had two snapshots at one

If you are using XFS - there is mount option "discard|nodiscard" From XFS man page: discard|nodiscard Enable/disable the issuing of commands to let the block device reclaim space freed by the filesystem. This is useful for SSD devices, thinly provisioned LUNs and virtual machine images, but may have a performance impact. Note: It is currently

On Mon, Jul 31, 2017 at 08:28:49AM -0500, Leroy Tennison wrote: > I realize this is wandering off-topic but, if you have found Debian commands, you're doing better than me. What are they? Also, are you allowing dd to totally fill the partition (what I have found on the web as a recommendation)? If so, is the OS surviving acceptably? > > ----- Original Message ----- > From:

Is it possible to insert and eject a USB image in kvm/qemu/libvirt or are the only dynamically changeable devices cdroms and floppies? I've searched the web and I'm either not looking for the right terms or it's obscure. I should mention that I'm not talking about a connecting a physical host USB drive to a guest image, I want to be able to use a qcow image as the source.

I have used virsh snapshot-create-as <VM name> <snapshot name> "<snapshot description>" --diskspec "vda,snapshot=external,file=/path/to/external-snapshot" --disk-only --atomic to create an external snapshot of a running VM. I followed it with virsh blockpull <VM name> --path /path/to/external-snapshot and monitored it until done.

Hi, I ran into a strange behavior with libvirt snapshots. I have some vms running with thin-provisioned qcow2 disk images (libvirt 1.1.3 with fedora 20). * When I create a snapshot on the VM, the qcow file suddenly grows big, somewhat bigger than the maximum size of the disk. * When I delete the snapshot, the allocated disk space is not freed up, the qcow image remains the same size. However, if

You're right, there's a procedure following it, once the space is zeroed qemu-img will recognize it as such and will eliminate it when 'convert' is used. Apparently Fedora qemu has some better capabilities to shrink partitions but they haven't made it to "long term support" distributions yet. For now, what has to be done to shrink qcow[2] partitions (raw works) is

Hi Martin, in the meantime, I've found a solution which I consider at least acceptable: 1. create zfs snapshot of domain disk (/dev/zstore/test-volume) 2. save original XML domain definition 3. create snapshot in libvirt like this: virsh snapshot-create --xmlfile snap.xml --disk-only --no-metadata test-domain snap.xml: <domainsnapshot> <disks> <disk

Hi all, I'm using ZFS on Linux block volumes as my VM storage and want to do live migrations between hypervisors. If I create ZFS snapshot of used volume on source host, send it do destination host (zfs send/recv) and then run live migration with VIR_MIGRATE_NON_SHARED_DISK flag, the migration works OK. But this procedure copies the whole disk twice which is a huge downside. The best

Il 01/07/20 17:13, Leroy Tennison ha scritto: > I realize this shouldn't happen, the file is a tgz and isn't being modified while being transmitted. This has happened maybe three times this year and unfortunately I've just had to deal with it rather than invest the time to do the research. > > > Harriscomputer > > Leroy Tennison > Network Information/Cyber

Hi! Changeset 17913 breaks build on *BSD: block-qcow.c:36:20: error: gcrypt.h: No such file or directory cc1: warnings being treated as errors block-qcow.c: In function ''gen_cksum'': block-qcow.c:160: warning: implicit declaration of function ''gcry_md_hash_buffer'' block-qcow.c:160: error: ''GCRY_MD_MD5'' undeclared (first use in this function)

Hi Leroy, How I can confirm that during rsync transfer corruption are not encountered? Thank you in advance. Il 01/07/20 16:04, Leroy Tennison ha scritto: > I've used rsync (but probably not for the size you're referring to), it works and has enough features to meet most needs. I have had a single situation where corruption occurred during transfer (a few times, have no idea why),

Hi, I?m running a CentOS server in a VPS. Backups of the VPS take quite much space if I don?t claim unused space. Currently I?m using dd if=/dev/zero of=/mytempfile and remove that file to claim that unused space. Any automatic way of doing a similar thing in CentOS? I have googled for it but I have only found Debian commands. Thanks in advance! Miguel

Once upon a time, Leroy Tennison <leroy at datavoiceint.com> said: > The executable could be placed on mounted read-only media That's not as secure as you think. Linux bind mounts can mount a file over another file (plus there's overlay filesystems), so it's possible to replace a binary even on a read-only device. -- Chris Adams <linux at cmadams.net>

Recently we had a try of stubdom, whose general status is good. One issue we found is with aio/sync blktap as backend, disk performance is obviously slower, and there are some IDE kernel error messages (like irq timeout) at boot time. Another issue (not stubdom specific) comes from blktap''s support for QCOW image which is based on a backing file. We never tried this configure

On Mon, Nov 3, 2014 at 4:24 PM, Michal Privoznik <mprivozn@redhat.com> wrote: > On 01.11.2014 05:30, Dennis Jacobfeuerborn wrote: >> >> Hi, >> I'm trying to find out how to enable fstrim support for libvirt/qemu >> guests. Specifically I'm trying to enable this on a CentOS 7 host (qemu >> 1.5). I searched the web but only found very vague information

Hi Is it true that the GPLPV drivers is incompatible with QCOW images? The Windows DomU works fine with raw standard "file:/" images, and paravirtualized Linux DomU works fine with QCOW and raw images. If i use QCOW images with my Windows DomU''s i get a stop error: 0x00000007b (inaccessible boot device). It looks like the blkback.3.hda process, that normally starts with

Attached to this email is a patch containing the (new and improved) blktap Linux driver and associated userspace tools for Xen. In addition to being more flavourful, containing half the fat, and removing stains twice as well as the old driver, this stuff adds a userspace block backend and let you use raw (without loopback), qcow, and vmdk-based image files for your domUs. There''s also a

Il 02/07/20 15:02, Valeri Galtsev ha scritto: > > > On 7/2/20 3:22 AM, Alessandro Baggi wrote: >> Il 01/07/20 17:13, Leroy Tennison ha scritto: >>> I realize this shouldn't happen, the file is a tgz and isn't being >>> modified while being transmitted.? This has happened maybe three >>> times this year and unfortunately I've just had to deal

Hi,guys, During a HVM''s running which take a qcow format image file as its own virtual disk, the qcow image file will be always read.In the situation that its qcow format image is based on a raw format image, if nesethe backingfile ,just that raw format image file,would be read .my purpose is to cache the data that is read from the backingfile when the hvm is running . Now what I concern