From: Dor Laor <dlaor@redhat.com>
To: Michael Jinks <michael.jinks@gmail.com>
Cc: kvm@vger.kernel.org
Subject: Re: Weird Windows license issue
Date: Mon, 06 Jul 2009 18:43:26 +0300 [thread overview]
Message-ID: <4A521B9E.8070100@redhat.com> (raw)
In-Reply-To: <f02c30210907060833n142ea0c5o8d6f46d169d2ffe1@mail.gmail.com>
On 07/06/2009 06:33 PM, Michael Jinks wrote:
> Sorry for the slow response, mail sorting issue. No, this is a
> license our team purchased for doing large numbers of public lab
> installations.
>
> I've used it successfully with the same ISO image I'm trying now.
> Only difference (that I know of) is that my previous installations
> were on VMware and Xen.
>
> We're supposed to have a new license code on the way, will see if that
> makes a difference. Hooray for welded-shut software!
>
Do you try to use -smp > 1?
Currently we present each vcpu as a separate socket. Some windows OS
have their vcpu disappear. Maybe it hurts installation more.
There is work in progress to optionally represent them as cores.
Also, it worth juggling with some -cpu options.
>
>
> On Fri, Jul 3, 2009 at 1:45 AM, Yaniv Kaul<ykaul@redhat.com> wrote:
>> On 7/3/2009 2:02 AM, Michael Jinks wrote:
>>> On Thu, Jul 2, 2009 at 5:45 PM, Sterling Windmill<sterling@ampx.net>
>>> wrote:
>>>
>>>> What do you mean by "rejected"? Is the installer not taking your key (I
>>>> doubt this would be caused by anything KVM specific),
>>>>
>>> Right, that. I don't have the screen in front of me so I might be
>>> getting the exact word wrong, but it immediately throws back something
>>> to the effect that the key is invalid.
>>>
>>> Since the license key entry stage happens before Windows tries to
>>> bring up networking, I don't think that license exhaustion is a likely
>>> explanation.
>>>
>>> Maybe KVM isn't either (yes, it does strike me as unlikely), but like
>>> I said in my first post I'm having a hard time finding other
>>> explanations.
>>>
>>> But anyhow. If license issues like this one aren't known to occur on
>>> KVM, there must be something else going on, so I'll try again and look
>>> elsewhere for the cause of the problem. Thanks for the info.
>>>
>> Any chance you are using OEM licenses?
>>> Cheers,
>>> -j
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2009-07-06 15:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-02 22:22 Weird Windows license issue Michael Jinks
2009-07-02 22:45 ` Sterling Windmill
2009-07-02 23:02 ` Michael Jinks
2009-07-03 2:14 ` Charles Duffy
2009-07-03 4:09 ` sudhir kumar
2009-07-03 6:45 ` Yaniv Kaul
2009-07-06 15:33 ` Michael Jinks
2009-07-06 15:43 ` Dor Laor [this message]
2009-07-07 6:17 ` Michael Jinks
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=4A521B9E.8070100@redhat.com \
--to=dlaor@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=michael.jinks@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