planet.virt-tools.orgBlogging about open source virtualization

News from QEMU , KVM , libvirt , libguestfs , virt-manager and related tools Subscriptions ARM Datacenter Project (feed) Adam Litke (feed) Alberto Garcia (feed) Alex Bennée (feed) Alex Williamson (feed) Chris Lalancette (feed) Christophe Fergeau (feed) Cole Robinson (feed) Cornelia Huck (feed) Cédric Bosdonnat (feed) Daniel Berrange (feed) Eduardo Habkost (feed) Eduardo Otubo (feed) Fabian Deutsch (feed) Fabiano Fidêncio (feed) Gerd Hoffmann (feed) KVM on Z (feed) Kashyap Chamarthy (feed) Ladi Prosek (feed) Marcin Juszkiewicz (feed) Nathan Gauër (feed) Peter Maydell (feed) QEMU project (feed) Richard Jones (feed) Stefan Hajnoczi (feed) Stefano Garzarella (feed) Thomas Huth (feed) Yoni Bettan (feed) Add your blog! Planet Feeds RSS 1.0 RSS 2.0 Atom FOAF May 01, 2020 Daniel Berrange ANNOUNCE: virt-viewer version 9.0 released I am happy to announce a new bugfix release of virt-viewer 9.0 (gpg), including experimental Windows installers for Win x86 MSI (gpg) and Win x64 MSI (gpg). Signatures are created with key DAF3 A6FD B26B 6291 2D0E 8E3F BE86 EBB4 1510 4FDF (4096R) With this release the project has moved over to use GitLab for its hosting needs instead of Pagure . Instead of sending patches to the old mailing list , we have adopted modern best practices and now welcome contributions as merge requests , from where they undergo automated CI testing of the build. Bug reports directed towards upstream maintainers, should also be filed at the GitLab project now instead of the Red Hat Bugzilla All historical releases are available from: http://virt-manager.org/download/ Changes in this release include: Project moved to https://gitlab.com/virt-viewer/virt-viewer Allow toggling shared clipboard in remote-viewer Fix handling when initial spice connection fails Fix check for govirt library Add bash completion of cli args Improve errors in file transfer dialog Fix ovirt foreign menu storage domains query Prefer TLS certs from oVirt instead of CLI Improve USB device cleanup when Ctrl-C is used Remember monitor mappings across restarts Add a default file extension to screenshots Updated translations Fix misc memory leaks by Daniel Berrange at May 01, 2020 05:19 PM April 30, 2020 KVM on Z QEMU v5.0 released QEMU v5.0 is out. For highlights from a KVM on Z perspective see the Release Notes . by Stefan Raspl (noreply@blogger.com) at April 30, 2020 05:28 PM Stefan Hajnoczi How the Linux VFS, block layer, and device drivers fit together The Linux kernel storage stack consists of several components including the Virtual File System (VFS) layer, the block layer, and device drivers. This article gives an overview of the main objects that a device driver interacts with and their relationships to each other. Actual I/O requests are not covered, instead the focus is on the objects representing the disk. Let's start with a diagram of the key data structures and then an explanation of how they work together. The Virtual File System (VFS) layer The VFS layer is where file system concepts like files and directories are handled. The VFS provides an interface that file systems like ext4, XFS, and NFS implement to register themselves with the kernel and participate in file system operations. The struct file_operations interface is the most interesting for device drivers as we are about to see. System calls like open(2) , read(2) , etc are handled by the VFS and dispatched to the appropriate struct file_operations functions. Block device nodes like /dev/sda are implemented in fs/block_dev.c , which forms a bridge between the VFS and the Linux block layer. The block layer handles the actual I/O requests and is aware of disk-specific information like capacity and block size. The main VFS concept that device drivers need to be aware of is struct block_device_operations and the struct block_device instances that represent block devices in Linux. A struct block_device connects the VFS inode and struct file_operations interface with the block layer struct gendisk and struct request_queue . In Linux there are separate device nodes for the whole device ( /dev/sda ) and its partitions ( /dev/sda1 , /dev/sda2 , etc). This is handled by struct block_device so that a partition has a pointer to its parent in bd_contains . The block layer The block layer handles I/O request queues, disk partitions, and other disk-specific functionality. Each disk is represented by a struct gendisk and may have multiple struct hd_struct partitions. There is always part0 , a special "partition" covering the entire block device. I/O requests are placed into queues for processing. Requests can be merged and scheduled by the block layer. Ultimately a device driver receives a request for submission to the physical device. Queues are represented by struct request_queue . The device driver The disk device driver registers a struct genhd with the block layer and sets up the struct request_queue to receive requests that need to be submitted to the physical device. There is one struct genhd for the entire device even though userspace may open struct block_device instances for multiple partitions on the disk. Disk partitions are not visible at the driver level because I/O requests have already had their Logical Block Address (LBA) adjusted with the partition start offset. How it all fits together The VFS is aware of the block layer struct gendisk . The device driver is aware of both the block layer and the VFS struct block_device . The block layer does not have direct connections to the other components but the device driver provides callbacks. One of the interesting aspects is that a device driver may drop its reference to struct gendisk but struct block_device instances may still have their references. In this case no I/O can occur anymore because the driver has stopped the disk and the struct request_queue , but userspace processes can still call into the VFS and struct block_device_operations callbacks in the device driver can still be invoked. Thinking about this case is why I drew the diagram and ended up writing about this topic! by Unknown (noreply@blogger.com) at April 30, 2020 04:21 PM KVM on Z Redbook on KVM on Z A new Redbook titled " Virtualization Cookbook for IBM Z Volume 5 KVM " is available now. Among others, it covers tasks such as installation, host configuration and guest deployments for Linux distributions by Red Hat, SUSE and Ubuntu. by Stefan Raspl (noreply@blogger.com) at April 30, 2020 10:41 AM April 29, 2020 QEMU project QEMU version 5.0.0 released We’d like to announce the availability of the QEMU 5.0.0 release. This release contains 2800+ commits from 232 authors. You can grab the tarball from our download page . The full list of changes are available in the Wiki . Highlights include: Support for passing host filesystem directory to guest via virtiofsd Live migration support for external processes running on QEMU D-Bus Support for using memory backends for main/”built-in” guest RAM block: support for compressed backup images via block jobs block: qemu-img: ‘measure’ command now supports LUKS images, ‘convert’ command now supports skipping zero’ing of target image block: experimental support for qemu-storage-daemon, which provides access to QEMU block-layer/QMP features like blocks jobs or built-in NBD server without starting a full VM ARM: support for the following architecture features: ARMv8.1 VHE/VMID16/PAN/PMU ARMv8.2 UAO/DCPoP/ATS1E1/TTCNP ARMv8.3 RCPC/CCIDX ARMv8.4 PMU/RCPC ARM: support for Cortex-M7 CPU ARM: new board support for tacoma-bmc, Netduino Plus 2, and Orangepi PC ARM: ‘virt’ machine now supports vTPM and virtio-iommu devices HPPA: graphical console support via HP Artist graphics device MIPS: support for GINVT (global TLB invalidation) instruction PowerPC: ‘pseries’ machine no longer requires reboot to negotiate between XIVE/XICS interrupt controllers when ic-mode=dual PowerPC: ‘powernv’ machine can now emulate KVM hardware acceleration to run KVM guests while in TCG mode PowerP...