- openSUSE Virtual

[opensuse-virtual] libvirt packaging have now requires for virtualbox ?
by Bruno Friedmann 09 Dec '13

09 Dec '13

With the new packaging of the virtual stack, libvirt now push dependencies on xen, AND virtualbox. Look like we are getting more and more stuff auto-bad-gically installed. I don't need xen, nor I don't want to have virtualbox (which ask virtualbox-qt, which then ask other things on a server) Is it possible (I didn't dig into packaging spec) to make libvirt smarter. For example if someone want only kvm virtualization he didn't get xen, lxc, virtualbox. In link with yast, there was a time you could choose on virtual system (kvm,xen). So the yast module has to bee re-aligned with new possible choices. Perhaps I've lost track on something. So my assumptions good be wrong, but I would like to hear someone about the benefit over the inconvenient. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

2 2

[opensuse-virtual] QEMU 1.7 package update troubles
by Andreas Färber 08 Dec '13

08 Dec '13

Hello, Here's my status for the pending qemu package update: GitHub opensuse-1.7 branch has been updated to final v1.7.0. Manual rebasing had been necessary for DictZip (only build-tested). qemu-1.7.0.tar.bz2 is now checked in at: home:a_faerber:branches:Virtualization qemu ppc Factory build succeeded but ppc64 was in "unresolvable" state. armv7l didn't get scheduled fast enough. For x86 I'm still facing a problem with the ROM builds. I tried hacking the .spec file to skip SeaBIOS build but then it failed the same way for VGABIOS, so I reverted that again. Somehow a stray "w" ends up in "make w -C ...". Bruce, could you please investigate what is going wrong there? Maybe BdMdesigN can help enlighten us. If you do find a good solution please SR to Virtualization. I won't be at a computer 'til end of next week. For now I have left out %check make check V=1 to avoid an additional source of build failures or delays. opensuse-1.6 branch is left at v1.6.0, The v1.6.1 rebase went fully automatically, but MR for 13.1 is not yet out and with the 1.7 problems I did not want to break the patch queue of the current Virtualization package by pushing my changes. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

2 1

[opensuse-virtual] libvirtd fails to start of NetworkManager is enabled
by Olaf Hering 27 Nov '13

27 Nov '13

Current libvirtd from Virtualization/libvirt fails to start because ncf_init() fails. nc__suse_config_init fails because it expects NETWORKMANAGER=no, so that "network.service" is returned to __netcontrol_enabled. netcontrol was appearently not changed since a long time. So I think for some reason libvirtd changed. Upstream git did appearently not change, netcfStateInitialize always returned some error if ncf_init() fails. What is supposed to happen with libvirt if NM is active on a 11.4 system? This used to work at least two weeks ago. Olaf -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

2 4

[opensuse-virtual] opensuse 13.1 DomU stalls @boot for long time; eventually completes/boots OK ?
by ar16 25 Nov '13

25 Nov '13

I've an Opensuse 13.1 DomU on a 13.1 Dom0. Both host & guest were upgraded from 12.3. The Opensuse 13.1 Xen DomU Guest is booting successfully, but taking a long time (~3 mins; up from ~20sec on 12.3). Where the delay is is clear; here's img output from "systemd-analyze plot" -> http://pbrd.co/17UxVRS which corresponds to: systemd-analyze blame 1min 222ms kmod-static-nodes.service 1min 152ms dev-mqueue.mount 1min 142ms systemd-udev-root-symlink.service 1min 141ms systemd-vconsole-setup.service 1min 140ms systemd-modules-load.service 3.715s network.service 2.242s quotad.service 2.223s autofs.service 2.201s network(a)eth0.service 1.068s nfs.service 625ms nfsserver.service 489ms systemd-udev-settle.service 319ms rsyslog.service 312ms rpcbind.service 285ms systemd-logind.service 234ms lvm2-activation-early.service 213ms systemd-tmpfiles-clean.service 174ms systemd-fsck(a)dev-xvda1.service 107ms lvm2-activation.service 104ms sshd-custom.service 80ms systemd-tmpfiles-setup-dev.service 71ms boot.mount 66ms systemd-sysctl.service 65ms systemd-remount-fs.service 58ms user(a)0.service 56ms systemd-random-seed.service 47ms systemd-udevd.service 44ms systemd-readahead-done.service 41ms systemd-user-sessions.service 38ms systemd-udev-trigger.service 38ms sys-kernel-debug.mount 35ms systemd-update-utmp.service 32ms systemd-tmpfiles-setup.service 32ms systemd-journal-flush.service 27ms systemd-update-utmp-runlevel.service 26ms var-run.mount 22ms dev-xvdb1.swap 12ms rc-local.service 12ms var-lock.mount 5ms sys-fs-fuse-connections.mount WHY, the delay is occurring, isn't clear. Here's `journalctl -xb` -> http://pastebin.com/YGjAMnaP (~ 1700 lines). @ #systemd, this is called out as a possible problem: Nov 25 10:45:31 os131guest systemd[1]: Job dev-xvc-1.device/start finished, result=timeout Nov 25 10:45:31 os131guest systemd[1]: Timed out waiting for device dev-xvc-1.device. Nov 25 10:45:31 os131guest systemd[1]: Job serial-getty(a)xvc-1.service/start finished, result=dependency The .cfg @ Dom0 that launches this Guest contains my usual: cat os131test.cfg name = 'template' builder = 'linux' bootloader = 'pygrub' bootargs = '' disk = [ 'phy:/dev/VG0/vm_os131boot,xvda,w','phy:/dev/VG0/vm_os131swap,xvdb,w','phy:/dev/VG0/vm_os131root,xvdc,w',] root = '/dev/xvdc1' extra = 'textmode=1 xencons=xvc0 noirqdebug elevator=noop' localtime = 0 on_shutdown = 'destroy' on_reboot = 'restart' on_crash = 'destroy' ... There are additional delays/stalls you can see in the log. Atm, I'm only seeing these boot-up delays on Xen Guests. Dom0 has no similar delays, neither do any non-Xen machines. So, something unique to the Guest -- whether it's Xen related, or other, not clear yet. Does anything in logs stand out? -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

1 0

[opensuse-virtual] xen* update DISables `xencommons` and `xendomains` systemd services. should it?
by ar16 30 Aug '13

30 Aug '13

After each xen-libs/tools update, both `xencommons` and `xendomains` systemd services are DISabled, requiring: systemctl enable xencommons.service ln -s '/usr/lib/systemd/system/xencommons.service' '/etc/systemd/system/multi-user.target.wants/xencommons.service' systemctl enable xendomains.service ln -s '/usr/lib/systemd/system/xendomains.service' '/etc/systemd/system/multi-user.target.wants/xendomains.service' to straighten things out. Is that intentional? Are updates typically supposed to modify service state? -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

3 6

[opensuse-virtual] why is usbredirection not enabled in qemu
by Rob Verduijn 23 Aug '13

23 Aug '13

Hello, Does anybody know why qemu is build without usbredirection ? I personally have build it with usbredirection and find the option to use my local usb devices in my remote vm very usefull. Just imagine what the use could be if your local usb-hub would be redirected to the virtual machine that you use as a desktop at home while you are at work via ssh or some other vpn. (or ofcourse the other way around when you need to do stuff at work that you couldn't be bothered to make the journey for :-) I've been using the usbredir with ssh encrypted tunnels for some time now, and am very happy with it. Cheers Rob -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

2 2

[opensuse-virtual] is there a clever way to shrink qcow2 images
by Rob Verduijn 21 Aug '13

21 Aug '13

Hello all, I'm looking for a clever way to shrink qcow2 images. what I do now is : 1 in the vm delete the files I don't need (tempfiles, spoolfiles, junkfiles, etc, etc) 2 fill the empty space with zeros dd if=/dev/zero of=bigfile bs=1024k ; sync ; rm bigfile ; sync 3 shut down the vm 4 convert the qcow2 to a fresh new qcow2 qemu-img convert -c -O qcow2 orig.qcow2 shrunk.qcow2 mv orig.qcow2 orig.qcow2.bak mv shrunk.qcow2 orig.qcow2 5 test the vm 6 delete the backup if it works Now this is fine if you got plenty space and just want to tidy up a bit before it turns bad. But what if there is no space, and adding extra partitions is not that easy. (imagine an offsite, far off location that is a real pain to get into due to serious security hassle) Or if you are me and are seriously annoyed by the cumbersome exercise above and have a gut feeling that there should be a more elegant way (preferably one without downtime) The above exercise requires to be done on all the partitions of the qcow2 image if there is more than one, adding to my irritation of the exercise. Does anybody have any ideas on a more elegant solution ? cheers Rob -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

2 3

Re: [opensuse-virtual] is there a clever way to shrink qcow2 images
by Rob Verduijn 20 Aug '13

20 Aug '13

oops I meant ofcourse online defragmenting filesystem like btrfs. silly me 2013/8/20 Tony Su <tonysu(a)su-networking.com>: > But as I noted you can write zeroes in blocks bigger than 1MB and as you > make your blocks bigger that last unwritten block will also get bigger and > possibly contain data which isn't compressable. > > Tony > > On Tuesday, August 20, 2013, Rob Verduijn <rob.verduijn(a)gmail.com> wrote: >> Hi, >> >> Indeed, you fill up the last blocks that are not big enough for my >> defined blocksize. >> But those blocks are very likely to be empty, also the loss of max >> 1024k - 1 of datastorage isn't really bothering me. >> >> The requirement to fill out the empty space with zeroes and then take >> down the vm to create a new qcow2 image is what bothers me. >> I wish to reclaim the empty space from a qcow2 image in a more >> efficient way, preferably without creating a new qcow2 image. >> (no downtime would be a nice bonus) >> >> Rob >> >> 2013/8/20 Tony Su <tonysu(a)su-networking.com>: >>> Haven't tried the following to zero a virtual disk, but the following >>> should >>> be fast, make the bs as big as you want (maybe 10x for very large disks). >>> Of >>> course, the bigger you make zero.big.file the longer it <might> take to >>> create zero.file. My code zeroes all bytes in 2 steps whereas yours >>> doesn't >>> zero all. >>> >>> dd if=/dev/zero of=zero.big.file bs=1024 count=102400 >>> cat /dev/zero > zero.file >>> rm zero.big.file >>> rm zero.file >>> >>> Tony >>> >>> On Aug 20, 2013 1:39 AM, "Rob Verduijn" <rob.verduijn(a)gmail.com> wrote: >>>> >>>> Hi, >>>> >>>> Using separate images for partitions makes the script a tiny bit less >>>> complex. >>>> >>>> I've already been scripting the exercise, the use off multiple >>>> partition images makes it only a tiny bit more complex. >>>> qemu-nbd simply adds another device for each additional partition. >>>> >>>> #!/binbash >>>> modprobe nbd max_part=16 #number off partitions >>>> qemu-nbd -c --nocache --aio=native /path/to/image.qcow2 >>>> mount /dev/nbd0 /mnt # I didn't partiotion the image, just >>>> formated the image as ext4 >>>> dd if=/dev/zero of=/mnt/bigfile bs=1024k; sync; rm /mnt/bigfile; rm >>>> bigfile; sync; rm /mnt/bigfile; sync >>>> sleep 2 >>>> umount /dev/nbd0 # umount the device >>>> qemu-nbd /dev/nbd0 # clean up nbd devices or they will bite you >>>> qemu-img convert -c -O qcow2 /path/to/image.qcow2 /path/to/shrunk.qcow2 >>>> mv /path/to/image.qcow2 /path/to/image.qcow2.bak >>>> mv /path/to/shrunk.qcow2 /path/to/image.qcow2 >>>> >>>> The performance of qemu-nbd is rather poor, using writeback cache is >>>> not really an option since you always need to wait for the zeroes to >>>> be actually written to the hd. >>>> Also writeback is very hazardous if you use a script to umount and >>>> disconnect the nbd device, image corruption is very likely to happen >>>> since sync doesn't apply to nbd0 devices and blockdev --flushbufs >>>> /dev/nbd0 isn't foolproof either when scripting. >>>> (ctrl-c the script at the wrong time and you are in for a recovery) >>>> >>>> So the script isn't that difficult, neither is the use of multiple >>>> partitions in an image. >>>> The biggest drawback is, downtime, filling the image with zeroes takes >>>> even longer offline than online. >>>> Ok you could have a cronjob in the vm that does that nightly, but I >>>> can imagine issues when the hd of a vm is at filled to the max at >>>> regular intervals (once a month ??), even at expected times and only >>>> for a short moment. >>>> Also that would mean the shrinking cronjob is required on the host (I >>>> want the shrinking done as soon as possible after the zeroing) >>>> This has to be timed properly with the zero cronjob of the guest, this >>>> becomes rather complex with every additional guest. >>>> >>>> Regards >>>> Rob >>>> >>>> >>>> 2013/8/19 Tony Su <tonysu(a)su-networking.com>: >>>> > Not specific to qcow >>>> > In the past if I wanted to partition files I'd deploy multiple disks >>>> > instead >>>> > of partitions. I don't knowi if there a significant overhead diff but >>>> > I >>>> > found performance did not suffer. Once on separate disks, should be >>>> > trivial >>>> > to script the procedure. >>>> > >>>> > You can execute your conversion on any storage, just as fast as >>>> > possible. >>>> > So, for instance can even be cheap temporary attached storage. >>>> > >>>> > And AFAIK has to be done offline although I suppose a fancy live >>>> > migraation >>>> > could be implemented so you're not offline. >>>> > Tony >>>> > >>>> > On Aug 19, 2013 11:50 AM, "Rob Verduijn" <rob.verduijn(a)gmail.com> >>>> > wrote: >>>> >> >>>> >> Hello all, >>>> >> >>>> >> I'm looking for a clever way to shrink qcow2 images. >>>> >> >>>> >> what I do now is : >>>> >> >>>> >> 1 in the vm delete the files I don't need (tempfiles -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

1 0

Re: [opensuse-virtual] is there a clever way to shrink qcow2 images
by Rob Verduijn 20 Aug '13

20 Aug '13

True, Bigger blocks are faster written on a disc, and if the disk is not to heavily fragmented this will save time. However you have to remember that the disk is a virtual disk image on another disc. Fragmentation on the host disk also matters. If the virtual disk image itself is fragmented on the host disk, then your speed gain is lost again with bigger block sizes. I'm not sure if experimenting for the optimal size is worth the time and effort. Maybe using an automatically defragmenting filesystem like btrfs for the host to store the images. However I have no idea what the impact is on an automatically defragmenting filesystem has on the sparse properties of the qcow2 image. Rob 2013/8/20 Tony Su <tonysu(a)su-networking.com>: > But as I noted you can write zeroes in blocks bigger than 1MB and as you > make your blocks bigger that last unwritten block will also get bigger and > possibly contain data which isn't compressable. > > Tony > > On Tuesday, August 20, 2013, Rob Verduijn <rob.verduijn(a)gmail.com> wrote: >> Hi, >> >> Indeed, you fill up the last blocks that are not big enough for my >> defined blocksize. >> But those blocks are very likely to be empty, also the loss of max >> 1024k - 1 of datastorage isn't really bothering me. >> >> The requirement to fill out the empty space with zeroes and then take >> down the vm to create a new qcow2 image is what bothers me. >> I wish to reclaim the empty space from a qcow2 image in a more >> efficient way, preferably without creating a new qcow2 image. >> (no downtime would be a nice bonus) >> >> Rob >> >> 2013/8/20 Tony Su <tonysu(a)su-networking.com>: >>> Haven't tried the following to zero a virtual disk, but the following >>> should >>> be fast, make the bs as big as you want (maybe 10x for very large disks). >>> Of >>> course, the bigger you make zero.big.file the longer it <might> take to >>> create zero.file. My code zeroes all bytes in 2 steps whereas yours >>> doesn't >>> zero all. >>> >>> dd if=/dev/zero of=zero.big.file bs=1024 count=102400 >>> cat /dev/zero > zero.file >>> rm zero.big.file >>> rm zero.file >>> >>> Tony >>> >>> On Aug 20, 2013 1:39 AM, "Rob Verduijn" <rob.verduijn(a)gmail.com> wrote: >>>> >>>> Hi, >>>> >>>> Using separate images for partitions makes the script a tiny bit less >>>> complex. >>>> >>>> I've already been scripting the exercise, the use off multiple >>>> partition images makes it only a tiny bit more complex. >>>> qemu-nbd simply adds another device for each additional partition. >>>> >>>> #!/binbash >>>> modprobe nbd max_part=16 #number off partitions >>>> qemu-nbd -c --nocache --aio=native /path/to/image.qcow2 >>>> mount /dev/nbd0 /mnt # I didn't partiotion the image, just >>>> formated the image as ext4 >>>> dd if=/dev/zero of=/mnt/bigfile bs=1024k; sync; rm /mnt/bigfile; rm >>>> bigfile; sync; rm /mnt/bigfile; sync >>>> sleep 2 >>>> umount /dev/nbd0 # umount the device >>>> qemu-nbd /dev/nbd0 # clean up nbd devices or they will bite you >>>> qemu-img convert -c -O qcow2 /path/to/image.qcow2 /path/to/shrunk.qcow2 >>>> mv /path/to/image.qcow2 /path/to/image.qcow2.bak >>>> mv /path/to/shrunk.qcow2 /path/to/image.qcow2 >>>> >>>> The performance of qemu-nbd is rather poor, using writeback cache is >>>> not really an option since you always need to wait for the zeroes to >>>> be actually written to the hd. >>>> Also writeback is very hazardous if you use a script to umount and >>>> disconnect the nbd device, image corruption is very likely to happen >>>> since sync doesn't apply to nbd0 devices and blockdev --flushbufs >>>> /dev/nbd0 isn't foolproof either when scripting. >>>> (ctrl-c the script at the wrong time and you are in for a recovery) >>>> >>>> So the script isn't that difficult, neither is the use of multiple >>>> partitions in an image. >>>> The biggest drawback is, downtime, filling the image with zeroes takes >>>> even longer offline than online. >>>> Ok you could have a cronjob in the vm that does that nightly, but I >>>> can imagine issues when the hd of a vm is at filled to the max at >>>> regular intervals (once a month ??), even at expected times and only >>>> for a short moment. >>>> Also that would mean the shrinking cronjob is required on the host (I >>>> want the shrinking done as soon as possible after the zeroing) >>>> This has to be timed properly with the zero cronjob of the guest, this >>>> becomes rather complex with every additional guest. >>>> >>>> Regards >>>> Rob >>>> >>>> >>>> 2013/8/19 Tony Su <tonysu(a)su-networking.com>: >>>> > Not specific to qcow >>>> > In the past if I wanted to partition files I'd deploy multiple disks >>>> > instead >>>> > of partitions. I don't knowi if there a significant overhead diff but >>>> > I >>>> > found performance did not suffer. Once on separate disks, should be >>>> > trivial >>>> > to script the procedure. >>>> > >>>> > You can execute your conversion on any storage, just as fast as >>>> > possible. >>>> > So, for instance can even be cheap temporary attached storage. >>>> > >>>> > And AFAIK has to be done offline although I suppose a fancy live >>>> > migraation >>>> > could be implemented so you're not offline. >>>> > Tony >>>> > >>>> > On Aug 19, 2013 11:50 AM, "Rob Verduijn" <rob.verduijn(a)gmail.com> >>>> > wrote: >>>> >> >>>> >> Hello all, >>>> >> >>>> >> I'm looking for a clever way to shrink qcow2 images. >>>> >> >>>> >> what I do now is : >>>> >> >>>> >> 1 in the vm delete the files I don't need (tempfiles -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

1 0

Re: [opensuse-virtual] is there a clever way to shrink qcow2 images
by Rob Verduijn 20 Aug '13

20 Aug '13

Hi, Indeed, you fill up the last blocks that are not big enough for my defined blocksize. But those blocks are very likely to be empty, also the loss of max 1024k - 1 of datastorage isn't really bothering me. The requirement to fill out the empty space with zeroes and then take down the vm to create a new qcow2 image is what bothers me. I wish to reclaim the empty space from a qcow2 image in a more efficient way, preferably without creating a new qcow2 image. (no downtime would be a nice bonus) Rob 2013/8/20 Tony Su <tonysu(a)su-networking.com>: > Haven't tried the following to zero a virtual disk, but the following should > be fast, make the bs as big as you want (maybe 10x for very large disks). Of > course, the bigger you make zero.big.file the longer it <might> take to > create zero.file. My code zeroes all bytes in 2 steps whereas yours doesn't > zero all. > > dd if=/dev/zero of=zero.big.file bs=1024 count=102400 > cat /dev/zero > zero.file > rm zero.big.file > rm zero.file > > Tony > > On Aug 20, 2013 1:39 AM, "Rob Verduijn" <rob.verduijn(a)gmail.com> wrote: >> >> Hi, >> >> Using separate images for partitions makes the script a tiny bit less >> complex. >> >> I've already been scripting the exercise, the use off multiple >> partition images makes it only a tiny bit more complex. >> qemu-nbd simply adds another device for each additional partition. >> >> #!/binbash >> modprobe nbd max_part=16 #number off partitions >> qemu-nbd -c --nocache --aio=native /path/to/image.qcow2 >> mount /dev/nbd0 /mnt # I didn't partiotion the image, just >> formated the image as ext4 >> dd if=/dev/zero of=/mnt/bigfile bs=1024k; sync; rm /mnt/bigfile; rm >> bigfile; sync; rm /mnt/bigfile; sync >> sleep 2 >> umount /dev/nbd0 # umount the device >> qemu-nbd /dev/nbd0 # clean up nbd devices or they will bite you >> qemu-img convert -c -O qcow2 /path/to/image.qcow2 /path/to/shrunk.qcow2 >> mv /path/to/image.qcow2 /path/to/image.qcow2.bak >> mv /path/to/shrunk.qcow2 /path/to/image.qcow2 >> >> The performance of qemu-nbd is rather poor, using writeback cache is >> not really an option since you always need to wait for the zeroes to >> be actually written to the hd. >> Also writeback is very hazardous if you use a script to umount and >> disconnect the nbd device, image corruption is very likely to happen >> since sync doesn't apply to nbd0 devices and blockdev --flushbufs >> /dev/nbd0 isn't foolproof either when scripting. >> (ctrl-c the script at the wrong time and you are in for a recovery) >> >> So the script isn't that difficult, neither is the use of multiple >> partitions in an image. >> The biggest drawback is, downtime, filling the image with zeroes takes >> even longer offline than online. >> Ok you could have a cronjob in the vm that does that nightly, but I >> can imagine issues when the hd of a vm is at filled to the max at >> regular intervals (once a month ??), even at expected times and only >> for a short moment. >> Also that would mean the shrinking cronjob is required on the host (I >> want the shrinking done as soon as possible after the zeroing) >> This has to be timed properly with the zero cronjob of the guest, this >> becomes rather complex with every additional guest. >> >> Regards >> Rob >> >> >> 2013/8/19 Tony Su <tonysu(a)su-networking.com>: >> > Not specific to qcow >> > In the past if I wanted to partition files I'd deploy multiple disks >> > instead >> > of partitions. I don't knowi if there a significant overhead diff but I >> > found performance did not suffer. Once on separate disks, should be >> > trivial >> > to script the procedure. >> > >> > You can execute your conversion on any storage, just as fast as >> > possible. >> > So, for instance can even be cheap temporary attached storage. >> > >> > And AFAIK has to be done offline although I suppose a fancy live >> > migraation >> > could be implemented so you're not offline. >> > Tony >> > >> > On Aug 19, 2013 11:50 AM, "Rob Verduijn" <rob.verduijn(a)gmail.com> wrote: >> >> >> >> Hello all, >> >> >> >> I'm looking for a clever way to shrink qcow2 images. >> >> >> >> what I do now is : >> >> >> >> 1 in the vm delete the files I don't need (tempfiles, spoolfiles, >> >> junkfiles, etc, etc) >> >> 2 fill the empty space with zeros >> >> dd if=/dev/zero of=bigfile bs=1024k ; sync ; rm bigfile ; sync >> >> 3 shut down the vm >> >> 4 convert the qcow2 to a fresh new qcow2 >> >> qemu-img convert -c -O qcow2 orig.qcow2 shrunk.qcow2 >> >> mv orig.qcow2 orig.qcow2.bak >> >> mv shrunk.qcow2 orig.qcow2 >> >> 5 test the vm >> >> 6 delete the backup if it works >> >> >> >> Now this is fine if you got plenty space and just want to tidy up a >> >> bit before it turns bad. >> >> >> >> But what if there is no space, and adding extra partitions is not that >> >> easy. >> >> (imagine an offsite, far off location that is a real pain to get into >> >> due to serious security hassle) >> >> >> >> Or if you are me and are seriously annoyed by the cumbersome exercise >> >> above and have a gut feeling that there should be a more elegant way >> >> (preferably one without downtime) >> >> >> >> The above exercise requires to be done on all the partitions of the >> >> qcow2 image if there is more than one, adding to my irritation of the >> >> exercise. >> >> >> >> Does anybody have any ideas on a more elegant solution ? >> >> >> >> cheers >> >> Rob >> >> -- >> >> To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org >> >> To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org >> >> >> > -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

1 0