From: "Daniel P. Berrange" <berrange@redhat.com>
To: Dustin Kirkland <dustin.kirkland@gmail.com>
Cc: libvir-list@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: [Qemu-devel] Re: [libvirt] dynamic scsi disk attach seems to be broken in qemu(-kvm)-0.11, libvirt-0.7.1
Date: Fri, 9 Oct 2009 09:18:22 +0100 [thread overview]
Message-ID: <20091009081822.GB27937@redhat.com> (raw)
In-Reply-To: <d9c105ea0910082057u70523659r6e41539e09921e02@mail.gmail.com>
On Thu, Oct 08, 2009 at 10:57:55PM -0500, Dustin Kirkland wrote:
> Now, all of that said, it is actually possible to hot-add a second
> scsi device. However, as far as I can tell, this method is not yet
> supported by libvirt. It looks to me that with modern qemu, you have
> to do it this way:
>
> Drop to a qemu console with ctrl-alt-2. Get the address of the current scsi bus:
> (qemu) info pci
> Look for "SCSI Controller". In my case, it's on Bus 0, device 4, function 0
>
> Now instead of pci_add, use drive_add
> (qemu) drive_add 0:4 file=/tmp/foo,if=scsi
> OK bus 0, unit 1
That is correct - the SCSI driver hotplug in libvirt is not implemented
in the right way. If you specify multiple SCSI devices at boot, they
all get on one controller, if you hotplug multiple SCSI devices, we're
hotplugging a new SCSI controller per disk. This is clearly not good,
because when you then reboot, all those controllers are merged back into
one.
There is a guy who is working on implementing the correct SCSI hotplug
approach for libvirt, that is still work in progress though. The most
recent patches were here:
http://www.redhat.com/archives/libvir-list/2009-September/msg00551.html
We will ultimately support hotplug of both drives, and drive controllers
independantly, giving apps/users the flexibility they need.
> I would like some advice on how to proceed with this bug, and where
> the solution lies...in qemu or in libvirt. Ultimately, I would like
> the behavior we had in our previous release with kvm-84 and
> libvirt-0.6.1, where we could dynamically add scsi devices without a
> problem, using:
> pci_add 1 storage file=/tmp/foo,if=scsi
>
> Can anyone else reproduce this? Is this considered a regression by
> anyone else? Where should I look to solve this, in libvirt, or in
> qemu?
Independently of what I said about libvirt not implementing SCSI hotplug
with the right apporoach, the pci-add stuff should definitely work, so
if it doesn't then this is a regression that needs to be fixed
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
next prev parent reply other threads:[~2009-10-09 8:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-09 3:57 [Qemu-devel] dynamic scsi disk attach seems to be broken in qemu(-kvm)-0.11, libvirt-0.7.1 Dustin Kirkland
2009-10-09 8:18 ` Daniel P. Berrange [this message]
2009-10-09 14:38 ` [Qemu-devel] Re: [libvirt] " Anthony Liguori
2009-10-09 15:27 ` Dustin Kirkland
2009-10-09 15:38 ` Dustin Kirkland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091009081822.GB27937@redhat.com \
--to=berrange@redhat.com \
--cc=dustin.kirkland@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=libvir-list@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).