Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

SQL Anywhere on VMware Server 1.x

3 posts in General Discussion (old) Last posting was on 2008-09-02 14:23:21.0Z
Markus KARG Posted on 2008-09-02 07:43:03.0Z
From: "Markus KARG" <karg@quipsy.de>
Newsgroups: sybase.public.sqlanywhere
Subject: SQL Anywhere on VMware Server 1.x
Lines: 24
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5512
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <48bcee87$1@forums-1-dub>
Date: 2 Sep 2008 00:43:03 -0700
X-Trace: forums-1-dub 1220341383 10.22.241.152 (2 Sep 2008 00:43:03 -0700)
X-Original-Trace: 2 Sep 2008 00:43:03 -0700, vip152.sybase.com
X-Authenticated-User: panorama
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere:144
Article PK: 866590

Guaranteeing ACID behaviour on a virtualized environment is not so easy as
it seems. VMware support engineer just told me as part of a Gold Support
Contract Case that VMware Server 1.x cannot guarantee that write caching is
disabled completely, not even with "secret" options like disabled write
cache! That means, the following scenario is confirmed by VMware that it CAN
happen:
* SQL Anywhere wants to write to a virtualized disk. The disk is marked as
"write cache disabled" in VMware itself, and in the operating system inside
of the VM, and in the operating system hosting that virtual disk's image
file.
* VMware CAN in some circumstances return "WRITE SUCCEEDED!" for a write
action BEFORE the data is physically committed by the actual, physical
drive.
This is not a joke. Again, this is CONFIRMED by VMware.
So if you are running von VMware Server 1.x ACID cannot be guaranteed.

Can SQL Anywhere deal with that?

Any options that must be set to deal with that?

Thanks
Markus


Mike Gould Posted on 2008-09-02 13:31:46.0Z
From: "Mike Gould" <gould-m@hotmail.com>
Newsgroups: sybase.public.sqlanywhere
References: <48bcee87$1@forums-1-dub>
In-Reply-To: <48bcee87$1@forums-1-dub>
Subject: Re: SQL Anywhere on VMware Server 1.x
Lines: 42
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Windows Mail 6.0.6001.18000
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <48bd4042@forums-1-dub>
Date: 2 Sep 2008 06:31:46 -0700
X-Trace: forums-1-dub 1220362306 10.22.241.152 (2 Sep 2008 06:31:46 -0700)
X-Original-Trace: 2 Sep 2008 06:31:46 -0700, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere:145
Article PK: 866591

Markus,

You might want to try the free VMWare ESXi server instead. We run several
ESX servers using Citrix and SQL Anywhere without any issues. ESXi is just a
cut down version of ESX. It essentially only allows you to do a single
physical server. The big difference though is that ESX/i installs at the
hardware level. Additionally version 1 is a old version. Have you looked
to see if version 2 had the same issues? If it doesn't then I would say
it's time to upgrade to version 2. If that has the same issues then you
need to evaluate moving to ESXi instead.

Best Regards

Michael Gould

"Markus KARG" <karg@quipsy.de> wrote in message
news:48bcee87$1@forums-1-dub...
> Guaranteeing ACID behaviour on a virtualized environment is not so easy as
> it seems. VMware support engineer just told me as part of a Gold Support
> Contract Case that VMware Server 1.x cannot guarantee that write caching
> is disabled completely, not even with "secret" options like disabled write
> cache! That means, the following scenario is confirmed by VMware that it
> CAN happen:
> * SQL Anywhere wants to write to a virtualized disk. The disk is marked as
> "write cache disabled" in VMware itself, and in the operating system
> inside of the VM, and in the operating system hosting that virtual disk's
> image file.
> * VMware CAN in some circumstances return "WRITE SUCCEEDED!" for a write
> action BEFORE the data is physically committed by the actual, physical
> drive.
> This is not a joke. Again, this is CONFIRMED by VMware.
> So if you are running von VMware Server 1.x ACID cannot be guaranteed.
>
> Can SQL Anywhere deal with that?
>
> Any options that must be set to deal with that?
>
> Thanks
> Markus
>


Markus KARG Posted on 2008-09-02 14:23:21.0Z
From: "Markus KARG" <karg@quipsy.de>
Newsgroups: sybase.public.sqlanywhere
References: <48bcee87$1@forums-1-dub> <48bd4042@forums-1-dub>
Subject: Re: SQL Anywhere on VMware Server 1.x
Lines: 69
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <48bd4c59@forums-1-dub>
Date: 2 Sep 2008 07:23:21 -0700
X-Trace: forums-1-dub 1220365401 10.22.241.152 (2 Sep 2008 07:23:21 -0700)
X-Original-Trace: 2 Sep 2008 07:23:21 -0700, vip152.sybase.com
X-Authenticated-User: panorama
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere:146
Article PK: 866593

Mike,

thank you for your ideas, but I have to correct your posting:

* We do not suffer from any VMware Server problems. My email talks just
about the possibilty that issued CAN arise according to VMware Engineers.
* VMware Server 2.x is the same virtualisation kernel as VMware Server 1.x,
so the same problems can occur.
* ESXi is NOT a stripped down version of ESX. ESX based on a micro linux and
such has a broad support of hardware, but to the costs of possibly unstable
drivers. ESXi comes with its own kernel (non-linux) and specially developed,
hardened drivers, so is much more stable than ESX but to the costs of very
narrow hardware support. To reduce this problem, ESXi is sold bundled with
"certified" hardware (i. e. drivers have been written for those) as one of
several distribution models. ESX is not free, only ESXi. So if your hardware
is not support by ESXi, you have no other free VMware product than VMware
Server.
* We already know of several customers running in assertion failures on ESX,
so it is not necessarily a better solution.

Regards
Markus

"Mike Gould" <gould-m@hotmail.com> schrieb im Newsbeitrag
news:48bd4042@forums-1-dub...

> Markus,
>
> You might want to try the free VMWare ESXi server instead. We run several
> ESX servers using Citrix and SQL Anywhere without any issues. ESXi is just
> a cut down version of ESX. It essentially only allows you to do a single
> physical server. The big difference though is that ESX/i installs at the
> hardware level. Additionally version 1 is a old version. Have you looked
> to see if version 2 had the same issues? If it doesn't then I would say
> it's time to upgrade to version 2. If that has the same issues then you
> need to evaluate moving to ESXi instead.
>
> Best Regards
>
> Michael Gould
>
>
> "Markus KARG" <karg@quipsy.de> wrote in message
> news:48bcee87$1@forums-1-dub...
>> Guaranteeing ACID behaviour on a virtualized environment is not so easy
>> as it seems. VMware support engineer just told me as part of a Gold
>> Support Contract Case that VMware Server 1.x cannot guarantee that write
>> caching is disabled completely, not even with "secret" options like
>> disabled write cache! That means, the following scenario is confirmed by
>> VMware that it CAN happen:
>> * SQL Anywhere wants to write to a virtualized disk. The disk is marked
>> as "write cache disabled" in VMware itself, and in the operating system
>> inside of the VM, and in the operating system hosting that virtual disk's
>> image file.
>> * VMware CAN in some circumstances return "WRITE SUCCEEDED!" for a write
>> action BEFORE the data is physically committed by the actual, physical
>> drive.
>> This is not a joke. Again, this is CONFIRMED by VMware.
>> So if you are running von VMware Server 1.x ACID cannot be guaranteed.
>>
>> Can SQL Anywhere deal with that?
>>
>> Any options that must be set to deal with that?
>>
>> Thanks
>> Markus
>>
>