On Tue, Sep 14, 2010 at 09:43:22AM +0200, Marc Haber wrote:
> On Mon, Sep 13, 2010 at 09:34:24AM -0500, Ryan Harper wrote:
> > It'll only be available to guests launched with newer qemu (0.13) as
> > virtio-blk serial support is a new feature.
>
> Thanks for the information, I'll wait for the next
On Mon, Sep 13, 2010 at 09:34:24AM -0500, Ryan Harper wrote:
> It'll only be available to guests launched with newer qemu (0.13) as
> virtio-blk serial support is a new feature.
Thanks for the information, I'll wait for the next release (or the
time to locally build 0.13-rc for testing, whatever h
* Marc Haber [2010-09-13 03:56]:
> Hi John and Ryan,
>
> On Tue, Jun 29, 2010 at 01:33:33PM -0500, Ryan Harper wrote:
> > We've got a sysfs 'serial' attribute for virtio-blk devices upstream[1].
> > I've got udev support for using this attribute to create disk/by-id (and
> > a fix for by-path) sy
Hi John and Ryan,
On Tue, Jun 29, 2010 at 01:33:33PM -0500, Ryan Harper wrote:
> We've got a sysfs 'serial' attribute for virtio-blk devices upstream[1].
> I've got udev support for using this attribute to create disk/by-id (and
> a fix for by-path) symlinks[2]. All that remains is to
> re-spin/p
Ryan Harper writes:
> We've got a sysfs 'serial' attribute for virtio-blk devices upstream[1].
> I've got udev support for using this attribute to create disk/by-id (and
> a fix for by-path) symlinks[2]. All that remains is to
> re-spin/post the qemu virtio-blk serial patches[3] and get that in
Hi,
On Tue, Jun 29, 2010 at 02:03:52PM -0400, john cooper wrote:
> Marc Haber wrote:
> 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
[re-send with correct sender]
Hi,
On Tue, Jun 29, 2010 at 01:33:33PM -0500, Ryan Harper wrote:
> We've got a sysfs 'serial' attribute for virtio-blk devices upstream[1].
> I've got udev support for using this attribute to create disk/by-id (and
> a fix for by-path) symlinks[2]. All that remains
Hi,
On Tue, Jun 29, 2010 at 01:33:33PM -0500, Ryan Harper wrote:
> We've got a sysfs 'serial' attribute for virtio-blk devices upstream[1].
> I've got udev support for using this attribute to create disk/by-id (and
> a fix for by-path) symlinks[2]. All that remains is to
> re-spin/post the qemu v
* Marc Haber [2010-06-29 13:16]:
> Hi,
>
> I had lost this topic for more than a few weeks...
>
> On Mon, Mar 22, 2010 at 10:59:20AM -0400, john cooper wrote:
> > Marc Haber wrote:
> >> On Mon, Mar 22, 2010 at 02:26:11AM -0400, john cooper wrote:
> >>> This is a tad ironic as that is how this sa
Marc Haber wrote:
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.
>>> If it b
Hi,
I had lost this topic for more than a few weeks...
On Mon, Mar 22, 2010 at 10:59:20AM -0400, john cooper wrote:
> Marc Haber wrote:
>> On Mon, Mar 22, 2010 at 02:26:11AM -0400, john cooper wrote:
>>> This is a tad ironic as that is how this saga begun. Namely stuffing
>>> 20 bytes of serial
Marc Haber wrote:
> Hi,
>
> On Mon, Mar 22, 2010 at 10:22:14AM -0400, john cooper wrote:
>> Marc Haber wrote:
>>> It the serial "number" can be alphanumeric, that would be great to have.
>> It is simply a string of 20 characters, which AFAICT has
>> its roots in the ATA S/N convention along with m
Hi,
On Mon, Mar 22, 2010 at 03:14:48PM +, Paul Brook wrote:
> > > John attempted this and it was reverted because the implementation
> > > exhausted the PCI config space.
> >
> > I don't understand that. Existig hardware devices dump much more of
> > their data such as vendor and model type i
Hi,
On Mon, Mar 22, 2010 at 10:22:14AM -0400, john cooper wrote:
> Marc Haber wrote:
> > On Tue, Mar 09, 2010 at 03:34:07PM -0600, Anthony Liguori wrote:
> >> On 03/06/2010 04:42 PM, Marc Haber wrote:
> >>> My goal is to have a possibility to give a "speaking" name to any
> >>> block device handed
john cooper wrote:
> Marc Haber wrote:
>> Hi,
>>
>> On Mon, Mar 22, 2010 at 02:26:11AM -0400, john cooper wrote:
>>> 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
Jamie Lokier wrote:
> john cooper wrote:
>> All that said, I like the alternate choice of adding a
>> special virtio request far better. It is actually simpler
>> (and more maintainable IMO) than going through the
>> gyrations of stuffing the S/N data through PCI config
>> space.
>
> And it needn
john cooper wrote:
> All that said, I like the alternate choice of adding a
> special virtio request far better. It is actually simpler
> (and more maintainable IMO) than going through the
> gyrations of stuffing the S/N data through PCI config
> space.
And it needn't have a 20 character limit.
> > John attempted this and it was reverted because the implementation
> > exhausted the PCI config space.
>
> I don't understand that. Existig hardware devices dump much more of
> their data such as vendor and model type information into the config
> space, how can using a field that real hardwar
Marc Haber wrote:
Hi,
On Mon, Mar 22, 2010 at 02:26:11AM -0400, john cooper wrote:
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
Marc Haber wrote:
> Hi,
>
> On Tue, Mar 09, 2010 at 03:34:07PM -0600, Anthony Liguori wrote:
>> On 03/06/2010 04:42 PM, Marc Haber wrote:
>>> 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
Hi,
On Mon, Mar 22, 2010 at 02:26:11AM -0400, john cooper wrote:
> 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
Hi,
On Tue, Mar 09, 2010 at 03:34:07PM -0600, Anthony Liguori wrote:
> On 03/06/2010 04:42 PM, Marc Haber wrote:
>> 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
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 possib
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 possibi
On Sat, Mar 06, 2010 at 11:42:34PM +0100, Marc Haber wrote:
> 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
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
Hi,
On Tue, Mar 09, 2010 at 12:04:39PM -0800, jvrao wrote:
> Here is the patch for the guest kernel.
>
> http://patchwork.kernel.org/patch/83873/
Thanks, the comment explained it for me.
Are all those relevant patches in git head of qemu, so that I can
actually try? Will it be necessary to ada
jvrao wrote:
> Marc Haber wrote:
>> Hi,
>>
>> thanks for your answer.
>>
>> On Mon, Mar 08, 2010 at 05:17:03PM -0800, jvrao wrote:
>>> Marc Haber wrote:
I am looking to get in touch with somebody who knows more about the
connection between host configuration, qemu, kvm, and the virtio blo
Marc Haber wrote:
> Hi,
>
> thanks for your answer.
>
> On Mon, Mar 08, 2010 at 05:17:03PM -0800, jvrao wrote:
>> Marc Haber wrote:
>>> 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
Hi,
thanks for your answer.
On Mon, Mar 08, 2010 at 05:17:03PM -0800, jvrao wrote:
> Marc Haber wrote:
> > 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.
> >
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.
>
Please check out this patch and follow the "mount_tag" ...it may be helpful
in explain
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 h
32 matches
Mail list logo
