qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kashyap Chamarthy <kchamart@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Manjong Han <aksmj8855@gmail.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Using the one disk image file on 2 virtual machines at the same time
Date: Wed, 29 Jul 2015 13:34:05 +0200	[thread overview]
Message-ID: <20150729113405.GB13890@tesla.redhat.com> (raw)
In-Reply-To: <20150729084653.GB10617@stefanha-thinkpad.redhat.com>

On Wed, Jul 29, 2015 at 09:46:53AM +0100, Stefan Hajnoczi wrote:
> On Wed, Jul 29, 2015 at 12:57:30AM +0900, Manjong Han wrote:
> > I was facing a weird behavior when I used the one disk image file on 2
> > virtual machines at the same time.
> > 
> > I made the instance of a virtual machine, using the below command.
> > $ qemu-system-x86_64 -smp 2 -m 1024 -hda 10G.qcow2 -enable-kvm
> > 
> > When the OS(Ubuntu 14.04 64bit) was booted up, I made an another one, using
> > same command.
> > $ qemu-system-x86_64 -smp 2 -m 1024 -hda 10G.qcow2 -enable-kvm
> > 
> > Then, I had 2 virtual machines, using same disk image file.
> 
> This configuration is invalid.  It's similar to using the same physical
> disk or iSCSI LUN from two machines at the same time.
> 
> Standard file systems (ext4, xfs) and volume managers (LVM) are not
> cluster-aware by default.  They must only be accessed from one machine
> at a time.  Otherwise you risk data corruption.
> 
> You should probably use qcow2 backing files instead:
> 
>   10G.qcow2 <-- vm001.qcow2
>             ^-- vm002.qcow2
> 
> The command to create these files is:
> 
>   qemu-img create -f qcow2 -o backing_file=10G.qcow2 vm001.qcow2.
> 
> Both VMs share the data in 10G.qcow2.  All writes go to vm001.qcow2 or
> vm002.qcow2, respectively, so they don't corrupt each other.

As an addendum, when using a management library like libvirt, it
provides a convenient daemon called 'virtlockd'[1] (which uses the POSIX
fcntl(2) mechanism),  which takes care of invalid configs like above.

>From my notes (from a FOSDEM 2014 talk by Dan Berange), virtlockd
operates thus:

    - The QEMU driver inside libvirt daemon, just talks to the virtlockd
      daemon using an RPC mechanism. So, whenever you first start a
      guest, the first thing it does is it talks to the virtlockd daemon
      and acquire locks for all of these disk images -- only if this
      succeeds, will the QEMU process will be started

    - These locks are also released and reaquired whenever you paused
      the virtual machines -- which is the key to make migrations work.


[1] https://libvirt.org/locking-lockd.html

-- 
/kashyap

  reply	other threads:[~2015-07-29 11:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-28 15:57 [Qemu-devel] Using the one disk image file on 2 virtual machines at the same time Manjong Han
2015-07-29  8:46 ` Stefan Hajnoczi
2015-07-29 11:34   ` Kashyap Chamarthy [this message]
2015-07-29 17:29   ` Manjong Han
2015-07-29 17:46     ` John Snow
2015-07-31 12:27       ` Christopher Covington
  -- strict thread matches above, loose matches on Subject: below --
2015-07-28 16:45 Manjong Han
2015-07-28 17:06 한만종
2015-07-28 21:40 ` Eric Blake

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=20150729113405.GB13890@tesla.redhat.com \
    --to=kchamart@redhat.com \
    --cc=aksmj8855@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).