[libvirt-users] SCSI/IDE Devices in Guest

I'm experimenting with how to attach storage to a guest virtual machine (I sent another message to th elist about that as it's slightly different) Looking in the XML files for my virtual machine, I see this: <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/vm/myvm/tmpeuiVc9.qcow2'/> <target dev='hda' bus='ide'/> <address type='drive' controller='0' bus='0' unit='0'/> </disk> However, /dev/hda is not a device in the guest. It is /dev/sda. It's not really a problem in it's own right, but it's one of several connected things which don't make sense. Is there some explanation for this? I believe this is linked to some weirdness when I attach some extra storage like so: virsh attach-disk myvm /dev/lvm-group1/mystorage sdb --driver qemu --persistent This adds the following stanza: <disk type='block' device='disk'> <driver name='qemu' type='raw'/> <source dev='/dev/lvm-group1/mystorage'/> <target dev='sdb' bus='scsi'/> <address type='drive' controller='0' bus='0' unit='1'/> </disk> Looks about right. In the guest though, it pushes /dev/sda (root and swap are here on sda1 and sda2) upto /dev/sdb (sdb1 and sdb2). Somehow it still boots correctly despite fstab referrencing /dev/sda1 and /dev/sda2 for / and swap. The new /dev/sda is this storage I tried to add as sdb. What could be causing this? Thanks, Douglas

On 10/30/2012 08:46 AM, Douglas Russell wrote:
I'm experimenting with how to attach storage to a guest virtual machine (I sent another message to th elist about that as it's slightly different)
Looking in the XML files for my virtual machine, I see this:
<disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/vm/myvm/tmpeuiVc9.qcow2'/> <target dev='hda' bus='ide'/> <address type='drive' controller='0' bus='0' unit='0'/> </disk>
However, /dev/hda is not a device in the guest. It is /dev/sda. It's not really a problem in it's own right, but it's one of several connected things which don't make sense. Is there some explanation for this?
The <target dev='...'> designation is a hint, and there for you to track things in the host, but does not necessarily reflect the name that the guest will choose for the same device (there is NO way for the host to force what the guest names things). However, for SCSI devices in the guest, you probably want to use <disk type='block' device='lun'> rather than type='file' device='disk'. [Caveat: I haven't used SCSI devices in my guests yet]
I believe this is linked to some weirdness when I attach some extra storage like so:
virsh attach-disk myvm /dev/lvm-group1/mystorage sdb --driver qemu --persistent
This adds the following stanza:
<disk type='block' device='disk'> <driver name='qemu' type='raw'/> <source dev='/dev/lvm-group1/mystorage'/> <target dev='sdb' bus='scsi'/> <address type='drive' controller='0' bus='0' unit='1'/> </disk>
Looks about right. In the guest though, it pushes /dev/sda (root and swap are here on sda1 and sda2) upto /dev/sdb (sdb1 and sdb2). Somehow it still boots correctly despite fstab referrencing /dev/sda1 and /dev/sda2 for / and swap. The new /dev/sda is this storage I tried to add as sdb. What could be causing this?
Again, names in the XML don't have to reflect names chosen by the guest. Beyond that, I don't have quite enough experience in this area of the code to give a definitive answer, but at least wanted to throw out an answer while you wait to see if anyone else also replies. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

On 30 October 2012 20:49, Eric Blake <eblake@redhat.com> wrote:
On 10/30/2012 08:46 AM, Douglas Russell wrote:
I'm experimenting with how to attach storage to a guest virtual machine (I sent another message to th elist about that as it's slightly different)
Looking in the XML files for my virtual machine, I see this:
<disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/vm/myvm/tmpeuiVc9.qcow2'/> <target dev='hda' bus='ide'/> <address type='drive' controller='0' bus='0' unit='0'/> </disk>
However, /dev/hda is not a device in the guest. It is /dev/sda. It's not really a problem in it's own right, but it's one of several connected things which don't make sense. Is there some explanation for this?
The <target dev='...'> designation is a hint, and there for you to track things in the host, but does not necessarily reflect the name that the guest will choose for the same device (there is NO way for the host to force what the guest names things).
Ok, that's fair enough, I was wondering how it would go about influencing the guest.
However, for SCSI devices in the guest, you probably want to use <disk type='block' device='lun'> rather than type='file' device='disk'.
You think I should change the above stanza or are you talking about the second ? The above storage really is a file.
[Caveat: I haven't used SCSI devices in my guests yet]
I believe this is linked to some weirdness when I attach some extra
storage
like so:
virsh attach-disk myvm /dev/lvm-group1/mystorage sdb --driver qemu --persistent
This adds the following stanza:
<disk type='block' device='disk'> <driver name='qemu' type='raw'/> <source dev='/dev/lvm-group1/mystorage'/> <target dev='sdb' bus='scsi'/> <address type='drive' controller='0' bus='0' unit='1'/> </disk>
Looks about right. In the guest though, it pushes /dev/sda (root and swap are here on sda1 and sda2) upto /dev/sdb (sdb1 and sdb2). Somehow it still boots correctly despite fstab referrencing /dev/sda1 and /dev/sda2 for / and swap. The new /dev/sda is this storage I tried to add as sdb. What could be causing this?
Again, names in the XML don't have to reflect names chosen by the guest. Beyond that, I don't have quite enough experience in this area of the code to give a definitive answer, but at least wanted to throw out an answer while you wait to see if anyone else also replies.
Ok, makes sense. I'm still wondering how it's able to start properly though when the fstab is wrong though? It boots up and mounts /dev/sdb1 on /, fstab still says /dev/sda1 is /. I've also started a new thread as hotplug is also not working for some reason. Thanks.
participants (2)
-
Douglas Russell
-
Eric Blake