From: "Daniel P. Berrange" <berrange@redhat.com>
To: xen-devel@lists.xensource.com
Subject: HVM guest with file backed disks using loop devices ?
Date: Tue, 21 Nov 2006 14:02:13 +0000 [thread overview]
Message-ID: <20061121140213.GD1951@redhat.com> (raw)
I've been looking at an issue with HVM guests and file backed virtual disks.
A user reported that they were unable to create more than 8 HVM guests as
the hotplug scripts failed to find a free loop device on the 9th guest.
Ignoring the option of increasing max available loop devices in kernel, I'm
confused as to why HVM guests need to allocate loopback devices at all.
The QEMU device model is perfectly happy access plain files directly - it
has no need for them to be bound to a loop device. Indeed if I look at an
active HVM guest, there is nothing using the loop device at all:
# grep disk /etc/xen/demo
disk = [ "file:/xen/demo.img,hda,w", "file:/root/boot.iso,hdc:cdrom,r" ]
# ps -axuwf | grep loop
root 18631 0.0 0.0 0 0 ? S< 13:32 0:00 [loop0]
root 18673 0.0 0.0 0 0 ? S< 13:32 0:00 [loop1]
# lsof /dev/loop0
# lsof /dev/loop1
# lsof /root/boot.iso
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
qemu-dm 18551 root 6u REG 253,0 6711296 1933665 /root/boot.iso
# lsof /xen/demo.img
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
qemu-dm 18551 root 5u REG 253,0 4294967297 1277954 /xen/demo.img
So qemu-dm has the two raw files open & nothing is using the loop devices.
The loop devices are getting created for the HVM guest by the hotplug scripts,
in particular /etc/xen/scripts/block. This script simply looks at the block
device type - either phy: or file: and takes action accordingly - for the
latter it will always create a loop device. There does not appear to be any
logic in the hotplug script to check whether the guest is paravirt or HVM.
If I hack the 'block' hotplug script to rip out creation of the loopback device
for file: disks, then HVM guests can still be created & appear to be able to
access their virtual disks without problems (obviously this isn't an actual
solution since it breaks paravirt file: disks).
I can think of two reasons for the creation of loop devices for HVM:
- This was needed in the past, but is now obsolete & we simply forgot to
turn off loop device code for HVM
- This is an accidental consequence changing the way HVM disks are
configured (ie when we droppped :ioemu tag from disks).
Can anyone who is more familiar with the history of HVM development shed
some light on this behaviour ?
I'd like to update the hotplug scripts to stop the loopback device being
created for HVM, but don't see any obvious data available in the hotplug
scripts which would allow me to distinguish between paravirt & HVM disk
configurations.
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
next reply other threads:[~2006-11-21 14:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-21 14:02 Daniel P. Berrange [this message]
2006-11-22 9:49 ` HVM guest with file backed disks using loop devices ? Ewan Mellor
2006-11-22 17:10 ` Daniel P. Berrange
2006-11-22 18:17 ` Andrew Warfield
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20061121140213.GD1951@redhat.com \
--to=berrange@redhat.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.