Hi all, I would ask for a moment of your time, I'm looking for some suggestions and opinions on some mostly theoretical and moot thing that keeps bugging me nonetheless. I hope this is just what I should carry to -discuss :)
Lets assume some Linux virtual machine that sees it's "OS" storage as a native disk attached from the host system. So, our setup would be like that: * disk0 (sda, xvda): the OS disk * disk1 (sdb, xvdb): the swap disk * disk2 and up: data disks that are not touched by the install process. I wonder if it would be nice to attach the data disks using some networked transport (iSCSI, SRP, Xen PVSCSI) instead of just mapping them through the "current" host. Some reasons of differing relevance that I thought of: Pro: * mistrust of locking in any actual data (i.e. on XenServer this used to be "unsupported" since it gives you freedom of the underlying hypervisor and free switching between real "iron" and virtual. How could they allow customers to decide on their own ;) * Easy clustering for VM users * Online disk resize not blocked by missing support in hypervisors * Assumedly better performance by handling IO outside of dom0 (at least for Xen that is relevant) * "Proper" relation of data consumer (see/zone /mask the VM, not the host) towards storage. Basically, what NPIV was supposed to do, until it failed on most OS by "terminating" in the VM hosts. Con: * Snapshot-based backups might be trickier * PV-ish disk devices are faster for some usage * need to run i.e. iSCSI, CPU overhead * turning disk IO into network IO I should add that I've built and used both scenarios over the last years, but that doesn't mean I'm decided whats better! :) Any opinions? Any poins I missed? Best greetings, Florian -- the purpose of libvirt is to provide an abstraction layer hiding all xen features added since 2006 until they were finally understood and copied by the kvm devs. _______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
