5:54 a.m.
When I use kvm+libvirt as my hypervisor at home, I usually
pass logical volumes as the guests' drives (I probably can do better
but the disk here is just a garden-variety SSD, not NVMe).
<emulator>/usr/libexec/qemu-kvm</emulator>
<disk type='file' device='disk'>
<driver name='qemu' type='raw' cache='none'
io='native'/>
<source file='/dev/vmhost_vg0/desktop'/>
<target dev='vda' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x04'
function='0x0'/>
</disk>
That works fine as local drives, but what about if I want to use the
network storage (can provide nfs and iscsi)? Should I:
1. Create one iscsi target for each guest? Reasoning here is that some
OS can boot off iscsi.
2. Create a local lv with the minimum required disk space to boot, and
then network mount the rest be it as nfs or iscsi?
3. Create a large iscsi target, do not format it, but instead
configure it as a lvm, handing out logical volumes as before? So the
vm guest won't know any better.
I am leaning towards door #3, but I am open for suggestions.
9:31 a.m.
On 12/21/19 12:54 PM, Mauricio Tavares wrote:
When I use kvm+libvirt as my hypervisor at home, I usually
pass logical volumes as the guests' drives (I probably can do better
but the disk here is just a garden-variety SSD, not NVMe).
<emulator>/usr/libexec/qemu-kvm</emulator>
<disk type='file' device='disk'>
<driver name='qemu' type='raw' cache='none'
io='native'/>
<source file='/dev/vmhost_vg0/desktop'/>
<target dev='vda' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x04'
function='0x0'/>
</disk>
That works fine as local drives, but what about if I want to use the
network storage (can provide nfs and iscsi)? Should I:
Remember, a disk consists of frontend and backend. The frontend is how
the disk appears to the guest OS (expressed by <target/> and in your
example the vda disk is attached to a virtio bus). The backend is then
how qemu accesses the data (spressed by <source/> and in your example
qemu reads data from /dev/vmhost_vg0/desktop). Note that the guest has
no idea about the backend. This may change your view on some cases below.
1. Create one iscsi target for each guest? Reasoning here is that some
OS can boot off iscsi.
I can see two ways here actually. One being, you configure the VM to use
iscsi as the backend of the disk but then configure frontend to be
whatever (virtio/scsi/IDE (please don't use IDE)). In this case, the
guest doesn't even know it's actually using iscsi.
If you want the guest to boot from iscsi then you don't even need to
express that in the guest XML at all, because that's guest internal
configuration.
And to complicate things a bit more, libvirt offers two ways of
configuring an iscsi backend: one where iscsi LUNs appear in the host's
/dev and the other where qemu uses libiscsi to connect to the iscsi
target so the host's /dev is left untouched.
2. Create a local lv with the minimum required disk space to boot,
and
then network mount the rest be it as nfs or iscsi?
3. Create a large iscsi target, do not format it, but instead
configure it as a lvm, handing out logical volumes as before? So the
vm guest won't know any better.
I am leaning towards door #3, but I am open for suggestions.
My personal preference probably favors iscsi a bit over NFS because of
my past with NFS. But I'd say it depends on your use case. What's that
btw? Do you plan to migrate VMs? If so, then having VM's disks on a NAS
is better choice than having them locally. But network access is also
slower than a local one.
Michal
1826
days inactive
1828
days old
1 comments
2 participants
participants (2)
-
Mauricio Tavares -
Michal Prívozník