[Qemu-discuss] qcow2 external snapshots - backup routine
I want to setup a routine for dailybackups of a qemu/kvm VM (using qcow2) using external snapshots (aka overlay omages, ako copy-on-write images) have been recommended an that makes sense to from the backup point of view (need to backup small files) my problem ... the procedure to setup, apply and start an external snapshot ... 1. virsh shutdown [base_name.qcow2] 2. cd /path/to/image_location 3. qemu-img create -f qcow2 -b [base_name.qcow2) [new_snapshot.qcow2] 4. cd /etc/libvirt/qemu 5. cp base_name.xml new_snapshot.xml 6. vim new_snapshot.xml 7. manually adjust mac address, uuid, image file name, vm name 8. virsh define [new_snapshot.xml] 9. virsh start [new_snapshot] ... is pretty lengthy though(and you can easily make mistakes doing that). Maybe there is ashortcut to do this that I am not seeing yet? Or maybe someone has a script to automate that procedure? making a script seems to be not so difficult ... if there wasn't editing of the xml file (which I find to be tricky). But maybe editing of the xml infos could be done by using virsh commands instead of editing the xml file? any suggestions would be welcome
[Qemu-discuss] Block format 'qcow2' used by device 'drive-virtio0' doesn't support the option 'physical_block_size'
Good day, Anybody able to guide me the combinations, etc. when and where these are supported? I'm having performance issues on 512e advance format/4Kb disks, and the symptoms for me tells me that I'm hitting the read-modify-write problems as the VMs report 512/512 for the virtio block devices, and I want to modify that to 4k sector sizes. Hendrik Visage
Re: [Qemu-discuss] Block format 'qcow2' used by device 'drive-virtio0' doesn't support the option 'physical_block_size'
On 27/01/2015 17:52, Hendrik Visage wrote: Good day, Anybody able to guide me the combinations, etc. when and where these are supported? I'm having performance issues on 512e advance format/4Kb disks, and the symptoms for me tells me that I'm hitting the read-modify-write problems as the VMs report 512/512 for the virtio block devices, and I want to modify that to 4k sector sizes. Hendrik Visage qcow2 cannot store the "physical block size" as an explicit property. But what you can do is the following: 1. Make sure the host physical disk partition system that stores the qcow2 file is aligned to a multiple of 4K (or the RAID block size if on a RAID system). 2. Make sure the host file system that stores the qcow2 file has a block size of 4K or a multiple of 4K. 3. Make sure the internal qcow2 cluster_size is 4K or a multiple of 4K (I think this is the default). Otherwise this is set using the "-o" "cluster_size=4096" option to qemu-img create/convert. 4. Make sure the guest partition on the virtual disk (backed by the qcow2 file) is aligned on a multiple of the qcow2 cluster_size. 5. Make sure the guest file system of the guest partition on the virtual disk has a block size which is a multiple of the qcow2 cluster_size. In other words, the usual "4K issue" procedures, but on both the physical and virtual machine. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
Re: [Qemu-discuss] QEMU: DBT vs. Interpretation
Javier Picorel writes: > We are trying to make QEMU deterministic for > architectural simulation. In the absence of I/O, > let's say only user code or exceptions, is there > any source of indeterminism (e.g., non deterministic > compiler optimizations, TB indeterminism) of > QEMU's DBT versus a canonical interpreter? Thanks! I'm not sure exactly what information you're trying to obtain. Given that most CPU architectures have multiple implementations, and many of those have complex internal operations, it's difficult to make an emulator deterministic in any way other than "its behavior conforms to the architecture specification". If you have an architecture whose implementation is fixed, you could probably add instrumentation to the QEMU code generator to update the counters in accordance with the implementation, so you could count the number of memory cycles or whatever... Dale
