Re: [Qemu-devel] Ubuntu/Debian Installer + Virtio-SCSI - Bad ram pointer
On Tue, Oct 30, 2012 at 10:48 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Tue, Oct 30, 2012 at 10:09 PM, ronnie sahlberg ronniesahlb...@gmail.com wrote: About half a year there was an issue where recent kernels had added support to start using new scsi opcodes, but the qemu functions that determine which transfer direction is used for this opcode had not yet been updated, so that the opcode was sent with the wrong transfer direction. That caused the guests memory to be overwritten and crash. I dont have (easy) access to the git tree right now, but it was a patch for the ATA_PASSTHROUGH command that fixed that. This patch? http://patchwork.ozlabs.org/patch/174946/ Stefan This is the one I was thinking about : 381b634c275ca1a2806e97392527bbfc01bcb333 But that also crashed when using local /dev/sg* devices. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Ubuntu/Debian Installer + Virtio-SCSI - Bad ram pointer
But older distros/kernels work fine?
Can you take a network trace?
About half a year there was an issue where recent kernels had added
support to start using new scsi opcodes, but the qemu functions that
determine which transfer direction is used for this opcode had not
yet been updated, so that the opcode was sent with the wrong transfer
direction.
That caused the guests memory to be overwritten and crash.
I dont have (easy) access to the git tree right now, but it was a
patch for the ATA_PASSTHROUGH command that fixed that.
Could you take a network trace and check maybe this is something
similar ? I.e. does the guest send an unusual scsi opcode just
before the crash ?
regards
ronnie sahlberg
On Tue, Oct 30, 2012 at 12:37 PM, Peter Lieven p...@dlhnet.de wrote:
Am 30.10.2012 19:27, schrieb Stefan Hajnoczi:
On Tue, Oct 30, 2012 at 4:56 PM, Peter Lieven p...@dlhnet.de wrote:
On 30.10.2012 09:32, Stefan Hajnoczi wrote:
On Mon, Oct 29, 2012 at 03:09:37PM +0100, Peter Lieven wrote:
Hi,
Bug subject should be virtio-blk, not virtio-scsi. virtio-scsi is a
different virtio device type from virtoi-blk and is not present in the
backtrace you posted.
Sounds pedantic but I want to make sure this gets chalked up against the
right device :).
If I try to Install Ubuntu 12.04 LTS / 12.10 64-bit on a virtio
storage backend that supports iSCSI
qemu-kvm crashes reliably with the following error:
Are you using vanilla qemu-kvm-1.2.0 or are there patches applied?
Have you tried qemu-kvm.git/master?
Have you tried a local raw disk image to check whether libiscsi is
involved?
Bad ram pointer 0x3039303620008000
This happens directly after the confirmation of the Timezone before
the Disk is partitioned.
If I specify -global virtio-blk-pci.scsi=off in the cmdline this
does not happen.
Here is a stack trace:
Thread 1 (Thread 0x77fee700 (LWP 8226)):
#0 0x763c0a10 in abort () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1 https://github.com/sahlberg/libiscsi/issues/1
0x557b751d in qemu_ram_addr_from_host_nofail (
ptr=0x3039303620008000) at /usr/src/qemu-kvm-1.2.0/exec.c:2835
ram_addr = 0
#2 https://github.com/sahlberg/libiscsi/issues/2
0x557b9177 in cpu_physical_memory_unmap (
buffer=0x3039303620008000, len=4986663671065686081, is_write=1,
access_len=1) at /usr/src/qemu-kvm-1.2.0/exec.c:3645
buffer and len are ASCII junk. It appears to be hex digits and it's not
clear where they come from.
It would be interesting to print *elem one stack frame up in #3
virtqueue_fill() to show the iovecs and in/out counts.
(gdb) print *elem
Great, thanks for providing this info:
$6 = {index = 3, out_num = 2, in_num = 4, in_addr = {1914920960,
1916656688,
2024130072, 2024130088, 0 repeats 508 times, 4129, 93825009696000,
140737328183160, 0 repeats 509 times}, out_addr = {2024130056,
2038414056, 0, 8256, 4128, 93824999311936, 0, 3, 0 repeats 512
times,
12385, 93825009696000, 140737328183160, 0 repeats 501 times},
Up to here everything is fine.
in_sg =
{{
iov_base = 0x3039303620008000, iov_len = 4986663671065686081}, {
iov_base = 0x383038454635, iov_len = 3544389261899019573}, {
The fields are bogus, in_sg has been overwritten with ASCII data.
Unfortunately I don't see any hint of where this ASCII data came from
yet.
The hdr fields you provided in stack frame #6 show that in_sg was
overwritten during or after the bdrv_ioctl() call. We pulled valid
data out of the vring and mapped buffers correctly. But something is
overwriting in_sg and when we complete the request we blow up due to
the bogus values.
Ok. What I have to mention. I've been testing with qemu-kvm 1.2.0
and libiscsi for a few weeks now. Its been very stable. The only thing
it blows up is during the debian/ubuntu installer. Ubuntu itself for
instance is running flawlessly. My guess is that the installer is probing
for something. The installer itself also runs flawlessly when I disable
scsi passthru with scsi=off.
Please post your full qemu-kvm command-line.
/usr/bin/qemu-kvm-1.2.0 -net
tap,vlan=164,script=no,downscript=no,ifname=tap0 -net
nic,vlan=164,model=e1000,macaddr=52:54:00:ff:01:35 -iscsi
initiator-name=iqn.2005-03.org.virtual-core:0025b51f001c -drive
format=iscsi,file=iscsi://172.21.200.56/iqn.2001-05.com.equallogic:0-8a0906-335f4e007-d29001a3355508e8-libiscsi-test-hd0/0,if=virtio,cache=none,aio=native
-m 2048 -smp 2,sockets=1,cores=2,threads=1 -monitor
tcp:0:4002,server,nowait -vnc :2 -qmp tcp:0:3002,server,nowait -name
'libiscsi-debug' -boot order=dc,menu=off -k de -pidfile
/var/run/qemu/vm-280.pid -mem-path /hugepages -mem-prealloc -cpu
host,+x2apic,model_id='Intel(R) Xeon(R) CPU L5640 @ 2.27GHz',-tsc
-rtc base=utc -usb -usbdevice tablet -no-hpet -vga cirrus
Please also post the exact qemu-kvm version you are using. I can see
it's based on qemu
Re: 1.1 release?
List, That patch that is referenced in the bugzilla : ... after reverting bef0fd59 in qemu-kvm, this issue doesn't exist. ... That is the exact same patch I had problems with a few weeks ago in iSCSI. As it turned out, it was NOT that patch that was buggy, but it exposed bugs in the iscsi block driver that made all I/O sudddenly take 55ms when booting from the BIOS, thus making the boot process tkae forever, andd it looked hung with a black screen, doing one i/o at a time 55ms apart. See http://lists.nongnu.org/archive/html/qemu-devel/2012-05/msg02716.html Maybe the backend used here has the same bug that I had in block/iscsi.c which was basically failing to call 'qemu_notify_event()' properly. Would be a weird coincidence otherwise since the symptoms are so similar, and they were both triggered by that same patch. I would check how the events are set up in the backend used here and check if perhaps that backend has the same bug iscsi had. regards ronnie sahlberg On Thu, Jun 7, 2012 at 6:38 PM, Ren, Yongjie yongjie@intel.com wrote: -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Avi Kivity Sent: Thursday, June 07, 2012 3:28 PM To: Michael Tokarev Cc: KVM list Subject: Re: 1.1 release? On 06/07/2012 10:19 AM, Michael Tokarev wrote: On 07.06.2012 11:13, Avi Kivity wrote: On 06/07/2012 10:10 AM, Michael Tokarev wrote: Are there any issues with 1.1 release of qemu-kvm? [] Yes, there is a regression with IDE PIO that can hang a guest on boot. Any pointers on this? See the thread started by Yongjie Ren. This bug is here. https://bugs.launchpad.net/qemu/+bug/1002121 The latest new is: after reverting bef0fd59 in qemu-kvm.git, it can work fine. For detailed info, please look at the thread with below subject. Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560... I were testing 1.1-rc with various guests and it all works more or less okay so far, but I didn't try pio mode. The bios uses it. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: block device type supporting trim or scsi unmap ?
On Thu, May 10, 2012 at 8:19 PM, Alexandre DERUMIER aderum...@odiso.com wrote: Hi, I'm looking to implement a san storage with ssd drive. which block device type support trim or scsi unmap ? I think ide support it (but performance...) scsi ? virtio ? virtio-scsi ? iscsi supports it too but it requires that your iscsi target supports these opcodes, and that the filesystem/storage behind it supports it too. TGTD with EXT4 and a suitable storage device should do the trick. Regards, Alexandre Derumier -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: block device type supporting trim or scsi unmap ?
On Thu, May 10, 2012 at 10:28 PM, Alexandre DERUMIER aderum...@odiso.com wrote: iscsi supports it too but it requires that your iscsi target supports these opcodes, and that the filesystem/storage behind it supports it too. TGTD with EXT4 and a suitable storage device should do the trick. I'm using a iscsi solaris target, with scsi UNMAP support. Drives also support scsi unmap in raid (ocz talos hdd). I'm using direct lun access from host to guest. But my question was, which block device inside guests have trim or scsi unmap implemention ? Guess it depends on how recent kernel your guest runs. If you present it as a SCSI disk to the guest, then I have successfully had Linux Mint 12 guests do UNMAP when accessing /dev/sd* from within the guest. If you present the device as a SCSI disk to the guest, you use a recent 3.x linux kernel for the guest and EXT4 as the filesystem I guess it should work. Dont know about status for IDE emulation. regards ronnie sahlberg -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pe: [PATCH v5 1/3] virtio-scsi: first version
On Tue, Feb 14, 2012 at 12:00 AM, Michael S. Tsirkin m...@redhat.com wrote: On Mon, Feb 13, 2012 at 02:54:03PM +0200, Dor Laor wrote: Only if you use the pci multi-function option but that kills standard hot unplug It doesn't kill it as such, rather you can't unplug luns individually. Isnt that just a consequence of the current implementation rather than a SCSI limitation? A different way to do hoplug could be to flag all devices as removable in the standard inq page then leave the LUN there persistently and what you remove/add is not the LUN device itself but just the media in the device. Instead of hot-plug remove the LUN, hot-plug becomes media eject or media insert. The device remains present all time, you never remove it, but instead hot-plug controls if the media is present or not. This would require implementing at least START_STOP_UNIT and PREVENT_ALLOW_MEDIUM_REMOVAL opcode emulation from SBC. regards ronnie sahlberg -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pe: [PATCH v5 1/3] virtio-scsi: first version
On Tue, Feb 14, 2012 at 2:12 AM, Hannes Reinecke h...@suse.de wrote: On 02/13/2012 02:18 PM, Michael S. Tsirkin wrote: On Tue, Feb 14, 2012 at 12:13:36AM +1100, ronnie sahlberg wrote: On Tue, Feb 14, 2012 at 12:00 AM, Michael S. Tsirkin m...@redhat.com wrote: On Mon, Feb 13, 2012 at 02:54:03PM +0200, Dor Laor wrote: Only if you use the pci multi-function option but that kills standard hot unplug It doesn't kill it as such, rather you can't unplug luns individually. Isnt that just a consequence of the current implementation rather than a SCSI limitation? Yes. A different way to do hoplug could be to flag all devices as removable in the standard inq page then leave the LUN there persistently and what you remove/add is not the LUN device itself but just the media in the device. Instead of hot-plug remove the LUN, hot-plug becomes media eject or media insert. The device remains present all time, you never remove it, but instead hot-plug controls if the media is present or not. This would require implementing at least START_STOP_UNIT and PREVENT_ALLOW_MEDIUM_REMOVAL opcode emulation from SBC. regards ronnie sahlberg That would work. Or we simply use the Peripheral Qualifier that the device is gone; eg we could simply set PQ = 1, return sense code 0x25/00 and be done with ... That is still similar to rip a device out from the guest without notice and can cause the guest to be surprised. Removable media is standard feature in SCSI SBC (and other commandsets). The nice part of removable media is that it activates a contract between the device and the guest to prevent removal of the media when the guest depends on the media not being removed. I.e. If you have a SBC device with the removable-media bit set, this is used to tell the initiator this media can be removed, be prepared that this might happen. So when you mount such a SBC device in the guest, the guest will issue a PREVENT_ALLOW_MEDIUM_REMOVAL to tell the device this medium is in use and may not be removed. This automatically provides you with a mechanism where any guest can signal to qemu when qemu may or may not remove the device/medium. In addition to implementing PREVENT_ALLOW_MEDIUM_REMOVAL emulation, qemu would also need to check the prevent-allow status before it allows the device to be removed. If nothing else, using this approach will automatically provide a channel from the guest kernel to qemu to tell qemu when a device may be unplugged and when it is not safe to unplug the device. regards ronnie sahlberg -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pe: [PATCH v5 1/3] virtio-scsi: first version
On Tue, Feb 14, 2012 at 7:42 AM, ronnie sahlberg ronniesahlb...@gmail.com wrote: On Tue, Feb 14, 2012 at 2:12 AM, Hannes Reinecke h...@suse.de wrote: On 02/13/2012 02:18 PM, Michael S. Tsirkin wrote: On Tue, Feb 14, 2012 at 12:13:36AM +1100, ronnie sahlberg wrote: On Tue, Feb 14, 2012 at 12:00 AM, Michael S. Tsirkin m...@redhat.com wrote: On Mon, Feb 13, 2012 at 02:54:03PM +0200, Dor Laor wrote: Only if you use the pci multi-function option but that kills standard hot unplug It doesn't kill it as such, rather you can't unplug luns individually. Isnt that just a consequence of the current implementation rather than a SCSI limitation? Yes. A different way to do hoplug could be to flag all devices as removable in the standard inq page then leave the LUN there persistently and what you remove/add is not the LUN device itself but just the media in the device. Instead of hot-plug remove the LUN, hot-plug becomes media eject or media insert. The device remains present all time, you never remove it, but instead hot-plug controls if the media is present or not. This would require implementing at least START_STOP_UNIT and PREVENT_ALLOW_MEDIUM_REMOVAL opcode emulation from SBC. regards ronnie sahlberg That would work. Or we simply use the Peripheral Qualifier that the device is gone; eg we could simply set PQ = 1, return sense code 0x25/00 and be done with ... That is still similar to rip a device out from the guest without notice and can cause the guest to be surprised. Removable media is standard feature in SCSI SBC (and other commandsets). The nice part of removable media is that it activates a contract between the device and the guest to prevent removal of the media when the guest depends on the media not being removed. I.e. If you have a SBC device with the removable-media bit set, this is used to tell the initiator this media can be removed, be prepared that this might happen. So when you mount such a SBC device in the guest, the guest will issue a PREVENT_ALLOW_MEDIUM_REMOVAL to tell the device this medium is in use and may not be removed. What I mean is that if /dev/sdb is removable, if you mount this as mount /dev/sdb1 /mnt this will automatically cause the guest kernel to send a PREVENT_ALLOW_MEDIUM_REMOVAL to /dev/sdb to prevent removal. When you umount /dev/sdb1 the kernel/guest will automagically send PREVENT_ALLOW_MEDIUM_REMOVEAL to /dev/sdb and allow removal of the media again. If you capture this command and track the prevent/allow removal status you automatically get a channel where qemu will know when it is safe to unplug the device and when it is not safe to unplug the device. This is a nice feature. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pe: [PATCH v5 1/3] virtio-scsi: first version
On Tue, Feb 14, 2012 at 9:59 AM, Michael S. Tsirkin m...@redhat.com wrote: On Tue, Feb 14, 2012 at 07:53:26AM +1100, ronnie sahlberg wrote: On Tue, Feb 14, 2012 at 7:42 AM, ronnie sahlberg ronniesahlb...@gmail.com wrote: On Tue, Feb 14, 2012 at 2:12 AM, Hannes Reinecke h...@suse.de wrote: On 02/13/2012 02:18 PM, Michael S. Tsirkin wrote: On Tue, Feb 14, 2012 at 12:13:36AM +1100, ronnie sahlberg wrote: On Tue, Feb 14, 2012 at 12:00 AM, Michael S. Tsirkin m...@redhat.com wrote: On Mon, Feb 13, 2012 at 02:54:03PM +0200, Dor Laor wrote: Only if you use the pci multi-function option but that kills standard hot unplug It doesn't kill it as such, rather you can't unplug luns individually. Isnt that just a consequence of the current implementation rather than a SCSI limitation? Yes. A different way to do hoplug could be to flag all devices as removable in the standard inq page then leave the LUN there persistently and what you remove/add is not the LUN device itself but just the media in the device. Instead of hot-plug remove the LUN, hot-plug becomes media eject or media insert. The device remains present all time, you never remove it, but instead hot-plug controls if the media is present or not. This would require implementing at least START_STOP_UNIT and PREVENT_ALLOW_MEDIUM_REMOVAL opcode emulation from SBC. regards ronnie sahlberg That would work. Or we simply use the Peripheral Qualifier that the device is gone; eg we could simply set PQ = 1, return sense code 0x25/00 and be done with ... That is still similar to rip a device out from the guest without notice and can cause the guest to be surprised. Removable media is standard feature in SCSI SBC (and other commandsets). The nice part of removable media is that it activates a contract between the device and the guest to prevent removal of the media when the guest depends on the media not being removed. I.e. If you have a SBC device with the removable-media bit set, this is used to tell the initiator this media can be removed, be prepared that this might happen. So when you mount such a SBC device in the guest, the guest will issue a PREVENT_ALLOW_MEDIUM_REMOVAL to tell the device this medium is in use and may not be removed. What I mean is that if /dev/sdb is removable, if you mount this as mount /dev/sdb1 /mnt this will automatically cause the guest kernel to send a PREVENT_ALLOW_MEDIUM_REMOVAL to /dev/sdb to prevent removal. When you umount /dev/sdb1 the kernel/guest will automagically send PREVENT_ALLOW_MEDIUM_REMOVEAL to /dev/sdb and allow removal of the media again. If you capture this command and track the prevent/allow removal status you automatically get a channel where qemu will know when it is safe to unplug the device and when it is not safe to unplug the device. This is a nice feature. Presumably there's a way for device to notify the OS that user requested removal, as well? I think that is done by responding with sense to one of the commands, like the every few second TEST_UNIT_READY that the initiator/guest-kernel will send. 5Ah 01hDT WROM BK OPERATOR MEDIUM REMOVAL REQUEST This sense code should be the one to use. I dont know if linux scsi initiator honors this or what it will do. I guess something like this could work ? IF device is marked as prevent-removal THEN send OPERATOR SEND MEDIUM REMOVAL REQUEST to the initiator wait xyz seconds IF device is still marked as prevent-removal THEN ask operator guest refused to release the LUN, do you want to forcefully remove it? ELSE unmount the media FI ELSE unmount the media FI -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pe: [PATCH v5 1/3] virtio-scsi: first version
On Tue, Feb 14, 2012 at 10:33 AM, Michael S. Tsirkin m...@redhat.com wrote: On Tue, Feb 14, 2012 at 10:30:59AM +1100, ronnie sahlberg wrote: On Tue, Feb 14, 2012 at 9:59 AM, Michael S. Tsirkin m...@redhat.com wrote: On Tue, Feb 14, 2012 at 07:53:26AM +1100, ronnie sahlberg wrote: On Tue, Feb 14, 2012 at 7:42 AM, ronnie sahlberg ronniesahlb...@gmail.com wrote: On Tue, Feb 14, 2012 at 2:12 AM, Hannes Reinecke h...@suse.de wrote: On 02/13/2012 02:18 PM, Michael S. Tsirkin wrote: On Tue, Feb 14, 2012 at 12:13:36AM +1100, ronnie sahlberg wrote: On Tue, Feb 14, 2012 at 12:00 AM, Michael S. Tsirkin m...@redhat.com wrote: On Mon, Feb 13, 2012 at 02:54:03PM +0200, Dor Laor wrote: Only if you use the pci multi-function option but that kills standard hot unplug It doesn't kill it as such, rather you can't unplug luns individually. Isnt that just a consequence of the current implementation rather than a SCSI limitation? Yes. A different way to do hoplug could be to flag all devices as removable in the standard inq page then leave the LUN there persistently and what you remove/add is not the LUN device itself but just the media in the device. Instead of hot-plug remove the LUN, hot-plug becomes media eject or media insert. The device remains present all time, you never remove it, but instead hot-plug controls if the media is present or not. This would require implementing at least START_STOP_UNIT and PREVENT_ALLOW_MEDIUM_REMOVAL opcode emulation from SBC. regards ronnie sahlberg That would work. Or we simply use the Peripheral Qualifier that the device is gone; eg we could simply set PQ = 1, return sense code 0x25/00 and be done with ... That is still similar to rip a device out from the guest without notice and can cause the guest to be surprised. Removable media is standard feature in SCSI SBC (and other commandsets). The nice part of removable media is that it activates a contract between the device and the guest to prevent removal of the media when the guest depends on the media not being removed. I.e. If you have a SBC device with the removable-media bit set, this is used to tell the initiator this media can be removed, be prepared that this might happen. So when you mount such a SBC device in the guest, the guest will issue a PREVENT_ALLOW_MEDIUM_REMOVAL to tell the device this medium is in use and may not be removed. What I mean is that if /dev/sdb is removable, if you mount this as mount /dev/sdb1 /mnt this will automatically cause the guest kernel to send a PREVENT_ALLOW_MEDIUM_REMOVAL to /dev/sdb to prevent removal. When you umount /dev/sdb1 the kernel/guest will automagically send PREVENT_ALLOW_MEDIUM_REMOVEAL to /dev/sdb and allow removal of the media again. If you capture this command and track the prevent/allow removal status you automatically get a channel where qemu will know when it is safe to unplug the device and when it is not safe to unplug the device. This is a nice feature. Presumably there's a way for device to notify the OS that user requested removal, as well? I think that is done by responding with sense to one of the commands, like the every few second TEST_UNIT_READY that the initiator/guest-kernel will send. Does it do this even for mounted media? I didn't realize ... Yes it does. At least for SBC devices that are flagged as removable. Normal SBC devices that are not removable might trigger different behaviour in the kernel. (endless string of TEST_UNIT_READY is a way to check if something unexpected happens on the device.) I just tested on a 3.0.0 kernel. I have a mediachanger for SBC and the SBC is flagged as removable. /dev/sdd is the iscsi lun with a removable SBC disk. By just exposing this device to the kernel, the kernel keeps sending, or if not the kernel maybe some other process trying to poll the status? every few seconds : PREVENT_ALLOW_MEDIUM_REMOVAL prevent removal PREVENT_ALLOW_MEDIUM_REMOVAL to immediatel change it back to allow removal again TEST_UNIT_READY After I run this mount /dev/sdd1 /mnt The kernel sends a single PREVENT_ALLOW_MEDIUM_REMOVAL to prevent removal then every few seconds a TEST_UNIT_READY This is what it does for removable SBC disks. Maybe it does something differently for permanent SBC disks. regards ronnie sahlberg -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Certain Mac Address doesn't work in KVM virtual NICs.
On Tue, Dec 21, 2010 at 5:27 PM, Yueyu Lin yueyu.li...@gmail.com wrote: Thanks a lot. I got the point and I got the exact warning in the virtual machine indeed. Besides the least significant bit should be 0 for the first byte, should I set the second least significant bit to 1 to enforce it as local administrated instead of OUI enforced? Anytime you change the MAC address of a physical or virtual device away from the (hopefully) globally unique address in the factory settings it is a good idea to set the locally administrated bit as well. It makes it easier when analyzing network traces to see what are from physical and what are from virtual devices. So I say yes, set that bit. regards ronnie sahlberg -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] Initial built-in iSCSI support
Resending since the mail might have been lost... List, Please find attached a patch that add an initial iSCSI client library and support to kvm-qemu. This allows to use iSCSI devices without making them visible to the host (and pollute the page cahce on the host) and allows kvm-qemu to access the devices directly. This works with iscsi resources, both disks and cdrom, make available through TGTD. See this as experimental at this stage. This is a very early implementation but id does works with TGTD. Significant effort is required to add additional features to ensure full interoperability with other initiators. The syntax to describe an iscsi lun is : iscsi://host[:port]/target-name/lun Example : -drive file=iscsi://127.0.0.1:3260/iqn.ronnie.test/1 or -cdrom iscsi://127.0.0.1:3260/iqn.ronnie.test/2 Future work needed : - document this in the manpage - implement target initiated NOP - implement uni- and bi-directional chap - implement a lot of missing iscsi functionality ... - maybe get it hooked into bus=scsi just like it today can hook into /dev/sg* devices and send CDBs directly to the LUN, that part of the code could be enhanced to also provide straight passthrough SCSI to these iscsi-luns too. My long term aim is to convert the ./block/iscsi/ subdirectory into a standalone general purpose iscsi client library why I would want to avoid implementing qemu specific code inside this directory! Please comment and/or apply. Many thanks to anthony l and stefan h that did an initial review so I could eliminate the most obvious flaws and mistakes in the interfacing code. Thanks!. Now since this is open source, there must be other people out there interested in iscsi, so lets work together to build a mature and complete iscsi library for kvm-qemu and others. Have fun, ronnie sahlberg 0001-initial-iscsi-support-for-kvm-qemu.patch.gz Description: GNU Zip compressed data
