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 _______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users