|
From: | john cooper |
Subject: | Re: [Qemu-devel] virtio block device and sysfs |
Date: | Mon, 22 Mar 2010 02:26:11 -0400 |
User-agent: | Thunderbird 2.0.0.9 (X11/20071115) |
Jamie Lokier wrote:
Anthony Liguori wrote:On 03/06/2010 04:42 PM, Marc Haber wrote:Hi, I am looking to get in touch with somebody who knows more about the connection between host configuration, qemu, kvm, and the virtio block device driver guest side than I know. My goal is to have a possibility to give a "speaking" name to any block device handed into a guest instance by the host. That name should be visible inside the guest, just as a LV is visible with its name in the system running the LVM. For example I would like to say on the qemu or kvm command line '-drive file=some-file,label=some-label,if=virtio', and have the string "some-label" show up somewhere in /sys/block in the guest, much as /sys/block/sda/device/model shows the hardware vendor and type for a standard SATA disk. The guest could then handle the information passed into it by the host with udev rules, allowing fstab constructs like "mount /dev/virtio/block/by-label/some-label as /usr"
Sorry, I missed Anthony's earlier mail.
You probably would just want to plumb ,serial=X into the virtio-blk config space and have the driver use it. Then you can do /dev/block/by-id/XXXXX
This is a tad ironic as that is how this saga begun. Namely stuffing 20 bytes of serial number string into the virtio-blk PCI config space on qemu's side and pushing it over to the guest driver. I exposed this to the guest app via a new ioctl cmd which itself was the original point of contention. Someone took issue with introducing a new interface citing the existence of ATA and SCSI counterparts. However dragging in the associated baggage in order to emulate those interfaces unintentionally bloated usage of the config space to the point of breakage. To address this I'd moved from using config space to an unused BAR which (understandably) didn't go over too well. Somewhere along the line Rusty posted a minimal alternative version which directly used a virtio request to retrieve the data from qemu which is arguably the right way to do the job. That said we still had a dispute over what interface would be used to pass the S/N back to the guest: a new interface or reuse of an existing interface (eg: ATA IDENTIFY). That's where things fizzled when we couldn't immediately resolve the issue. So publishing the S/N in /sys would seem to side step this snag. I could have swore I sent out a guest-driver-app-interface-less version of the patch using virtio to pass the S/N but didn't find it in the archives. I did however locate it and can bring it forward as a reference for the above if interest exists. -john -- address@hidden
[Prev in Thread] | Current Thread | [Next in Thread] |