public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Manfred_Knick <Manfred.Knick@T-Online.de>
To: Ricardo Botelho de Sousa <ricardo.sousa@servismart.net>
Cc: kvm@vger.kernel.org
Subject: Re: KVM and VMware
Date: Thu, 26 Feb 2009 14:43:55 +0100	[thread overview]
Message-ID: <49A69C9B.6020408@T-Online.de> (raw)
In-Reply-To: <200902261203.48577.ricardo.sousa@servismart.net>

Ricardo Botelho de Sousa schrieb:
> On Thursday 26 February 2009 11:34:43 Manfred_Knick wrote:
>> Thus, if one would like to protect any ignorant user from harming
>> himself, the check for exclusiveness would have to be applied
>> dynamically at each try to start-up a VM instead, not at installation time.

> Not necessarly the ignorant. If you, to prepare a migration install on a 
> Ubuntu/Debian machine their KVM package, it will automatically load the 
> adquate module. IF VMware is still running ...  you get a stuck server :(

Sorry for the wording ...

Please, note what I'm looking for, as it seems to be the "easy" case:

IFF - as supposed in this intellectual game - the patch *is* already
applied, the module may well load, indeed; but it will *not* change the
KVM 'hypervisor' to 'root mode' instantaneously;
thus: no stuck server yet.

IFF - as proposed - the other 'hypervisor' rejects to start any VM
(and thus continues to reject switching into 'root mode')
as long as *any* other 'hypervisor' keeps any VM running,
thre still will be no stuck server.

It's the user's responsibility then to react upon the corresponding
error message, shutdown the other VM's, and re-start over again.

Manfred


P.S.:

If one wants to take advantage of VMware's even more comfortable
approach with switching in and out of 'root mode',
that desires a more detailed consideration, defenitely more work
and perhaps some decrease in performance.
Avi pointed out to me that on a 'bare metal' server installation,
KVM might not be prepared to pay this latter sacrifice.

  reply	other threads:[~2009-02-26 13:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-25 13:10 KVM and VMware Manfred_Knick
2009-02-25 13:36 ` Avi Kivity
2009-02-25 14:37   ` Manfred_Knick
2009-02-25 16:03     ` Avi Kivity
2009-02-26  9:25       ` Alexander Graf
2009-02-26 11:34         ` Manfred_Knick
2009-02-26 12:03           ` Ricardo Botelho de Sousa
2009-02-26 13:43             ` Manfred_Knick [this message]
2009-02-25 14:50   ` Manfred_Knick

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=49A69C9B.6020408@T-Online.de \
    --to=manfred.knick@t-online.de \
    --cc=kvm@vger.kernel.org \
    --cc=ricardo.sousa@servismart.net \
    /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