Well, the current production build (8.02.1) does.
It gives the lsi_sas.sys file missing message on installation.
Luckily, those bright folks over there fixed it in the nightlies here:
The one I used is 803B.
Those guys are awesome.
http://dev.driverpacks.thesneaky.com/dr … nightlies/
The one I used is 803B.
Those guys are awesome.]]–>
I’m not sure if this is right, so this could be conjecture, wild coincidence, or just total bullshit.
To find out how much memory you really need in a Linux machine, here’s my guess at how to do it. The OS will use about 90-95% of your memory whether or not you need it or not.
So, I figured, the memory that’s not used by applications is cache, so here’s my reasoning ….
when running “vmstat 5 5” I get:
[email protected]:~$ vmstat 5 5
procs ———–memory———- —swap– —–io—- –system– —-cpu—-
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 104 40868 97536 211036 0 0 6 20 53 130 3 5 93 0
0 0 104 40868 97540 211032 0 0 0 14 103 184 0 0 100 0
0 0 104 40852 97540 211032 0 0 0 7 103 200 0 0 100 0
0 0 104 40804 97552 211088 0 0 0 47 112 250 0 1 99 0
0 0 104 40748 97556 211084 0 0 0 33 109 213 0 1 99 0
I have ~200mb for cache, which means my applications probably use the rest – 1gb – 200mb = 800mb. I could probably get away with just running on 800mb opposed to 1gb, right?
[email protected]:~$ cat /proc/meminfo
MemTotal: 1035672 kB
MemFree: 40420 kB
Buffers: 97504 kB
Cached: 211068 kB
SwapCached: 12 kB
Active: 770052 kB
Inactive: 134936 kB
HighTotal: 131008 kB
HighFree: 216 kB
LowTotal: 904664 kB
LowFree: 40204 kB
SwapTotal: 867500 kB
SwapFree: 867396 kB
Dirty: 188 kB
Writeback: 0 kB
Mapped: 636228 kB
Slab: 77832 kB
CommitLimit: 1385336 kB
Committed_AS: 1804444 kB
PageTables: 4280 kB
VmallocTotal: 118776 kB
VmallocUsed: 2984 kB
VmallocChunk: 115412 kB
Mem: 1035672k total, 1001156k used, 34516k free, 89952k buffers
Swap: 867500k total, 104k used, 867396k free, 203864k cached
One thing I don’t want to do is swap.
If I’m wrong, please let me know! Thanks.
OVF is an open-standard for VM distribution. OVF has a number of important benefits, like encapsulating the entire VM in a single file, storing metadata, support for multi-VM configurations, disk compression, and platform independence. VC 2.5 also allows the VI client to import an OVF image from a URL and download it and install it automatically over the
In order to create an OVF image, you can use the OVF tool that VMware provides to convert an existing VM into an OVF image.
You can get more information about OVF from:
Click to access ovf_tool.pdf
You can download the OVF tool from:
In terms of building and packaging the VA, a good starting point is the VA build page: http://www.vmware.com/appliances/build/how.html. I suggest you also take a look at the VA best practices doc (http://www.vmware.com/files/pdf/vam_best_practices_building.pdf), which covers issues about how to package and distribute virtual appliances. A few key suggestions from the paper including using virtual SCSI (and not IDE) drives, disconnecting virtual CDROMs, floppies, etc, and installing VMware tools. If you follow the best practice guidelines, you can request to certify the virtual appliance as well. Those guidelines are at http://www.vmware.com/appliances/build/list.html. I suggest you read and follow the best practices paper whether you plan to certify or not, as it will allow maximum portability for your virtual appliance.