On Wed, 15 Apr 2015 09:55:10 +0300 Reco <recoverym4n@gmail.com> wrote: > Hi. > > On Wed, Apr 15, 2015 at 08:41:07AM +0200, Petter Adsen wrote: > > > > I just want to try it out to see how it works, it's not > > > > something I need by any stretch of the imagination, so there's > > > > a limit to how far down that rabbit-hole I want to go. > > > > > > As long as you don't forget to run lvscan on partner node after > > > doing basically anything with LV on main node - you should be OK. > > > > > > But just to be on the safe side - don't export PV via iSCSI. > > > Export LVs. > > > > May I ask why, so I don't mess anything up? I was thinking of > > exporting maybe my VM VG, so that all LV's for VM's were available > > to both machines. Or just the device itself. > > That's the main reason. Creating PV-via-iSCSI configuration from the > scratch is simple. It's maintaining it (or worse - changing it) is > complex. > > For example, imagine the need to migrate all LVs from one PV to > another. Without downtime, of course. Is it doable - yes. Is it > simple - no. In my setting, that is quite simply not going to ever happen. I have a separate disk with one PV on it, devoted entirely to VM's. But I do see your point, if I ever were to use it in a production system. Right now, downtime only means that one of my personal toys is broken :) > Besides, there's a *small* matter of backups, and in cases such as :) > this I prefer straightforward approach. I.e. there's "storage" host, > and there are "VM" hosts. "Storage" host provides LVs as /dev/sd* > devices to "VM" hosts *and* manages backups. "VM" hosts merely do > their VM thing. I see, thank you. Well, that sort of fits in with my setup, too, except that the VM disk is not in the storage server, it is in the fastest machine I have, with the most cores available to run VMs. It's just a toy project, anyhow, but it's best to learn good practices. Petter -- "I'm ionized" "Are you sure?" "I'm positive."
Attachment:
pgp83QYHNqkT8.pgp
Description: OpenPGP digital signature