Friday, January 22. 2010Block devices in KVM guestsTrackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
kvm-qemu (well qemu really) has support for specifying the index of drives so you can make the guest naming stable from
the host side. You can use something like:
kvm -drive file=/foo/bar,boot=on,if=virtio,index=0 I’m afraid I’ve no idea what libvirt will or won’t allow as I lost interest in it once I discovered it wouldn’t run the guests as a normal user but instead insisted on your running your virtual machines as root. Comments (2)
works, the disk comes up as /dev/vda. But any non-zero value for index= means that the device node does not show up in the guest at all. Doesn’t help. Comments (3)
Libvirt does not run virtual machines as root anymore. In Debian, they’re all run as libvirt-qemu. There’s no reason to expect that emulated PCI addresses would change. They’re emulated, why should they? In fact, patches were posted to the libvirt mailing list lately (and will probably appear in 0.7.6) that will explicitly assign PCI addresses when creating devices, so they are guaranteed stable. If you provide one disk image (which, on the host, is either a block device or a file) to the guest, it will always show up as /dev/vda. This will not change if you change the host filesystem, and it won’t change if you rearrange hard drives on the host. What exactly is the problem? What sorts of operations are you doing on the host that would affect what the guest sees? Using a single LV or unique block device for each guest makes the most sense from a performance standpoint. Using a disk image on a host filesystem is horribly inefficient. You argue against using LVs because of the difficulty of accessing the guest filesystem from the host, but this should be an extremely rare thing that you need to do, so it’s not a big deal. There are also excellent tools like libguestfs that make it trivial. Comment (1)
> addresses would change. They’re emulated, why > should they? In fact, patches were posted to the > libvirt mailing list lately (and will probably appear in > 0.7.6) that will explicitly assign PCI addresses > when creating devices, so they are guaranteed > stable. So I can configure with which PCI address a device will appear in the host? That solves part of the issue, but the PCI addresses are cryptic, names are mnemonic. > If you provide one disk image (which, on the > host, is either a block device or a file) to the > guest, it will always show up as /dev/vda. This will > not change if you change the host filesystem, and > it won’t change if you rearrange hard drives on > the host. What exactly is the problem? When I make a host LV visible in the guest as /dev/vda, I need to first resize the host LV and then the guest’s LV which resides in /dev/vda. That’s one step more than necessary. When I make /dev/mapper/guest1-home visible in the guest as /dev/mapper/home, it’s onle one resize operation. But this gets bulky when it’s root, boot, usr, home and var. > Using a single LV or unique block device for each > guest makes the most sense from a performance > standpoint. I’d rather sacrifice some performance for flexibility, which the single-block-device-per-guest doesn’t have. > You argue against using LVs because of the > difficulty of accessing the guest filesystem from > the host, but this should be an extremely rare > thing that you need to do, so it’s not a big deal. I guess it’s a very handy way for recovery actions, backup/restore et al, so it’s not that exotic. Please note that I’m only arguing against “one-LV-per-guest” and that having “multiple-LVs-per-guest” is actually the way I’d like to go. > There are also excellent tools like libguestfs that > make it trivial. That one is not even in Debian unstable, alas. I just hate the idea to go back to stupidly consecutively numbered block devices after getting rid of them seven years ago. Comments (3)
I lost interest in libvirt a while ago, and from what I saw at the time I didn’t expect the “running as
root” problem to have been fixed by now. Good to know it has.
Comments
(2)
> That one is not even in Debian unstable, alas. You should be able to find it here: http://pkg-libvirt.alioth.debian.org/packages/unstable/ (I am the author of libguestfs) Comment (1)
I have not tried LVM-on-LVM, instead I partition the virtual drive in the old classical way. This means indeed the drive contents cannot be mounted directly in the host, but this is not something that I find extremely useful either. Comments (2)
Comments (3)
That said, an additional layer on top of LVM to be able to delegate block devices to guests while keeping their names, as you proposed, would definitely be better. Comments (2)
On the host I use lvm to manage the pool of real disks. So no problem here. For each guest I create one logical volume for the rootfs and one logical volume for swap. The name of the logical volumes are $GUESTNAME and $GUESTNAME-swap. Because I like redundancy I do this on for each guest on two real servers and transport the block device over iscsi to the other real servers. I also have some udev rules to have consistent naming accross real servers, e.g. /dev/xbd/$GUESTNAME.$REALSERVERNAME on each real server is the same, nevertheless it is a local logical volume or a remote logical volume over iscsi. Inside my guest I do raid1 out of the two $GUESTNAME block devices, so I have a stable /dev/md0 as blockdevice for my rootfs and /dev/md1 for my swapspace. I build my raid1 on boot of the guest with kernel parameters “md=0,/dev/vda,/dev/vdb md=1,/dev/vdc,/dev/vdd”. In my experiences the order in which the disks are configured, this is the order they apear inside the guest. First drive is vda, second vdb and so on. With libvirt config it is possible to say for each block device which device name it should have (vda, vdb, ..) but it seems the kvm/qemu drive option is without index option when running. pros one logical volume on the host for each guest ** to make snapshots ** for backups ** for easy recovery ** to have a meaningful name of the logical volume you can grow the filesystem inside the guest WITHOUT downtime of the guest! (remove one part of the raid1, lvresize on the host, reinsert this part of the raid1, do the same for the other side, grow raid1 and grow fs (i do this since 2006 with xen)) you can also grow the swap space without downtime you only have to monitor one filesystem per guest no partition tables inside the guest (who needs this, if all is managed with lvm on the host?) cons: a few functions for the guest are outside the guest, so this setup is only reasonable if the admin of the host is also a admin of the guest. * only one filesystem (for me, this is a pro, but for other purposes this could be bad) Comment (1)
|
QuicksearchBlog AdministrationCategoriesRecently addedWed, 2010-03-17 16:39Talkline, habt ih [...] Wed, 2010-03-17 11:10von Sales Chats CommentsTue, 2010-03-09 00:10
Thu, 2010-03-04 22:31
Thu, 2010-03-04 11:31
Thu, 2010-03-04 08:54
Mir schießt heute noch das Was
ser in die Augen, wenn ich ein
Bild von meinem Stanislaus fi
nde. Und das ist immerhi [...]Comments ()
Wed, 2010-03-03 20:15
Oh Marc, Sandra,
das tut mir
fürchterlich leid. :-(
Ich
fühle mit Euch, um diesen off
enbar sehr besonderen Katz.Comments ()
Show tagged entries6310
![]() öffnungszeiten ![]() öpnv ![]() admintipp ![]() aide ![]() akku ![]() alice ![]() alpgrüm ![]() alsa ![]() alturo ![]() ansagen ![]() anwalt ![]() apache ![]() arbeit ![]() arbeitsplatzrechner ![]() arcor ![]() artikelreihe ![]() augenarzt ![]() auto ![]() bahn ![]() bahnhof ![]() bank ![]() baumarkt ![]() berlin ![]() best-of-mailing-list ![]() bilder ![]() blasenentzündung ![]() blog ![]() blogsignal ![]() bluetooth ![]() blutzuckermessung ![]() bohrmaschine ![]() boot ![]() booten ![]() brille ![]() browser ![]() bts ![]() bugs ![]() bus ![]() callcenter ![]() chat ![]() citynightline ![]() clamav ![]() cnl ![]() cold call ![]() computer ![]() console ![]() cookies ![]() cron-apt ![]() dänemark ![]() datenschutz ![]() db ![]() dbag ![]() debian ![]() debian-english ![]() debugging ![]() deppen ![]() deutsche bahn ![]() deutschland ![]() dhl ![]() dienstleistung ![]() disco ![]() dns ![]() domain ![]() drivers ![]() dsl ![]() durchhilfe ![]() dvb-s ![]() ![]() e90 ![]() einkauf ![]() elektrik ![]() elektro ![]() englisch ![]() english ![]() essen ![]() ethernet ![]() exchange ![]() exim ![]() exim4 ![]() exploit ![]() föhr ![]() fahrkarten ![]() fahrrad ![]() fdi ![]() fernsehen ![]() fernseher ![]() firewall ![]() firewalls ![]() firstdedicated ![]() flitterwoche ![]() foto ![]() fotos ![]() freenet ![]() freizeit ![]() fremdblog ![]() freunde ![]() fundsache ![]() geburtstag ![]() geschenk ![]() Template dropdownTechnorati |