Re: [libvirt] [PATCHv3 2/2] qemu: add new disk device='lun' for bus='virtio' & type='block'

On 01/05/2012 11:35 AM, Laine Stump wrote: > In the past, generic SCSI commands issued from a guest to a virtio > disk were always passed through to the underlying disk by qemu, and > the kernel would also pass them on. > > v3 changes: > > 1) Add note to docs that the SCSI commands are not only accepted from > the guest, but are passed through to the physical device (I didn't > add anything about the SCSI commands being emulated because I still > don't understand that situation perfectly, and don't want to add > misleading docs about existing behavior. > > 2) Change the logic of qemuDomainSnapshotIsAllowed() to always return > false if a device='lun' disk is encountered, regardless of the > format. In reality, lun disks are always 'raw', so it would return > false anyway, but this makes it clearer. Looks reasonable. > +++ b/docs/formatdomain.html.in > @@ -1001,8 +1001,17 @@ > "block", "dir", or "network" > and refers to the underlying source for the disk. The optional > <code>device</code> attribute indicates how the disk is to be exposed > - to the guest OS. Possible values for this attribute are "floppy", "disk" > - and "cdrom", defaulting to "disk". The > + to the guest OS. Possible values for this attribute are > + "floppy", "disk", "cdrom", and "lun", defaulting to > + "disk". "lun" (<span class="since">since 0.9.10</span>) is only Are we targetting 0.9.9 since this is a CVE mitigation? IIUC, the qemu default is scsi=on, so it is _only_ after this patch is applied that we override that default with scsi=off for device='disk'. If someone upgrades their kernel for the CVE fix, then it doesn't matter. But if someone is running with the old kernel and libvirt 0.9.9, then should they get the scsi=off command line parameter by default to take advantage of the qemu mitigation that prevents SG_IO for scsi=off? That is, I'm arguing that this patch is probably worth applying now, rather than waiting post-release, just so that someone that upgrades libvirt and qemu but not the kernel is at least less vulnerable to the CVE that was fixed by the upgraded kernel. I guess it boils down to how likely it is that someone can't afford the downtime in their host to upgrade their kernel right away, but can live with the downtime of upgrading the user-space libvirt and qemu and reboot guests to take advantage of the new scsi=off for the guest in the window while they wait for the next convenient time where the host kernel can be upgraded. At any rate, I think we have converged; ACK whether we decide this is 0.9.9 material to be pushed now with one tweak, or 0.9.10 material to be delayed to next week.