Schlagwort-Archive: vmware

Extending an LVM volume on TurnkeyLinux for VMware

Ich hatte das Problem bei meinem MineOS, über die Weboberfläche ließ sich nichts erweitern… Also hier die Lösung!

Logical Volume Management (AKA LVM) is a powerful, robust mechanism for managing storage space.

In TurnKey 11,  instead of installing the root filesystem directly to a fixed size partition, we setup LVM by default, and install the root filesystem to a Logical Volume, which may later be expanded, even across multiple physical devices.

Unfortunately, as with anything powerful, to get the most out of LVM you first have to negotiate a learning curve. From the feedback we’ve been getting it seems that confusion regarding LVM is  common with new users, so here’s a quick „crash course“…

How LVM works

In LVM, there are several layers, each builds on top of the other:

PV[s] (Physical Volumes) -> VG[s] (Volume Groups) -> LV[s] (Logical Volumes) -> Filesystems.

Logical Volumes are allocated/extended within the boundaries of their underlying storage pool which is called a Volume Group in LVM terminology.

For example, in TurnKey the filesystem is installed by default to the /dev/turnkey/root Logical Volume, which is allocated within the turnkey Volume Group:

--- Logical volume ---
  LV Name                /dev/turnkey/root
  VG Name                turnkey
  LV UUID                OzX3fe-aRQa-81XM-0vCV-8aJo-eUL4-6J90XJ
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                17.0 GiB
  Current LE             4502
  Segments               2
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           251:0

Out of the box the turnkey Volume Group doesn’t have too much free space:

# vgdisplay
  --- Volume group ---
  VG Name               turnkey
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  3
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               2
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               18.14 GiB
  PE Size               4.00 MiB
  Total PE              4645
  Alloc PE / Size       4480 / 17.50 GiB
  Free  PE / Size       165 / 660.00 MiB
  VG UUID               IwaFL0-QCi8-iIUE-TWjQ-R906-PYpH-gMPaH9

We can only extend a Logical Volume within the free space of the underlyingVolume Group. How much free space we currently have within the Volume Group can be seen in this part of the output:

Free  PE / Size       165 / 660.00 MiB

In the above example we only have 660 MB to allocate to LVMs within theturnkey Volume Group. So if we want to extend the root LV we’ll have to first extend the VG backs it up.

Volume Groups group together Physical Volumes. That’s why they’re called Volume Groups. This command will show us which Physical Volumes have been registered into LVM, and to which volume groups they have been assigned:

# pvdisplay
  --- Physical volume ---
  PV Name               /dev/sda2
  VG Name               turnkey
  PV Size               18.15 GiB / not usable 4.00 MiB
  Allocatable           yes
  PE Size               4.00 MiB
  Total PE              4645
  Free PE               165
  Allocated PE          4480
  PV UUID               H1Prpv-0VXR-7moE-zsbt-eyVt-m0fQ-GkAT6w

In this example we only have one Physical Volume (the /dev/sda2 partition) in theturnkey Volume Group.

Extending a Logical Volume

Bottom line: if the underlying Volume Group doesn’t have enough free space, to extend the Logical Volume you’ll first have to extend the underlying Volume Groupby adding another Physical Volume to it.

In VMWare you could either create a new virtual hard disk device to add to the volume group, or extend an existing virtual hard disk device, create a new partition with cfdisk, and add the new partition to the Volume Group:

# example #1: you've added to VMWare a new virtual hard disk called /dev/sdb
pvcreate /dev/sdb
vgextend turnkey /dev/sdb

# example #2: you've expanded the existing sda hard disk
cfdisk /dev/sda  # creating /dev/sda3 (you may need to reboot before you can see this)
pvcreate /dev/sda3
vgextend turnkey /dev/sda3

After you’ve extended the Volume Group, you are free to extend the underlyingLogical Volume:

# lvextend -L+10G /dev/turnkey/root
Extending logical volume root to 27.0 GiB
Logical volume root successfully resized

Finally, you’ll have to resize the filesystem within /dev/turnkey/root so it can see that the underlying block device just got 10G bigger:

# resize2fs /dev/turnkey/root
resize2fs 1.41.11 (14-Mar-2010)
Filesystem at /dev/turnkey/root is mounted on /; on-line resizing required
old desc_blocks = 2, new_desc_blocks = 2
Performing an on-line resize of /dev/turnkey/root to  7077888 (4k) blocks.
The filesystem on /dev/turnkey/root is now 7077888 blocks long.


Q
uelle: turnkeylinux.org

Advertisements

Hinterlasse einen Kommentar

Eingeordnet unter Linux, VMware

vSphere Client auf DC installieren

Problem

Der vmware vSphere Client ab Version 5.1u1 lässt sich nicht mehr freiwillig auf einem Domänencontroller installieren. Versucht man das, erhält man folgende Ferhlermeldung:

“vSphere Client erfordert Windows XP XP2 oder höher. vSphere Client kann auf dem Domänencontroller nicht installiert.”

vsphere-client-auf-dc-installieren

Lösung

Aufgrund der Microsoft-Vorgabe “Always Isolate DC Role”, der auch grundsätzliche zuzustimmen ist, hat vmWare den OS-Check in den MSI-Wrapper eingebaut. Selbstverständlich lässt sich das (auf eigene Gefahr) auch umgehen. Der Client läuft auch stressfrei auf einem DC.

  • Plattform-Installer (~100mb) aus dem Globalen Installert (~350MB) befreien. Dazu einfach das Paket ganz normal aufrufen un den “viclient-setup.exe” aus %temp%\{langeinummer} wegkopieren. Danach den Installer nach der Fehlermeldung wieder schliessen.
  • Den Installer aufrufen mit: viclient-setup.exe /VSKIP_OS_CHECKS=”1″

Update: Ein vmware Engineer sagt zu diesem Installer folgendes (Zitat):

We did this deliberately to enforce a Microsoft standard that our guys agree with – don’t install software on a DC, but they made that decision in isolation. Nothing more than that.  So use the workaround safely and hopefully we can undo this in the future.

Quelle: Ugg.li

2 Kommentare

Eingeordnet unter Microsoft, VMware

VMware ESXi-5.X Warnung: “Systemprotokolle auf dem host XXXX werden in einem nicht beständigen Speicher gespeichert”

Frische Neuinstallationen des ESXi 5.1/5.5 auf einem USB-Stick oder einer SD-Karte behaupten gerne mal “Systemprotokolle auf dem host XXXX werden in einem nicht beständigen Speicher gespeichert“. Das ist auch fast korrekt – USB-Speicher und Sd-Karten sind nach VMWare-denke “volatil”. Nur Festplatten (respektive Datastores) sind beständig.

Lösung (bessere Lösung):

Einen Speicherort für die Scratch-Files für jeden betroffenen ESX(i)-Host auf einem Datastore erstellen. Das geht direkt im vSphere Client und im laufenden Betrieb – die Änderung wird nur erst bei einem Neustart des Hosts aktiv.

  1. Auf dem jeweiligen ESX(i)-Host unter Konfiguration/Speicher den passenden Datastore Durchsuchen und einen Ordner erstellen. VMWare schlägt einen Namen wie .locker-ESXHOSTNAME vor, denn Ordner die mit einem “.” beginnen werden im Browser nicht angezeigt. Jeder Host braucht einen eigenen Scratch-Ordner.
  2. Diesen neuen Ort dann in die ESX(i) Konfiguration der Hosts eintragen: Unter Konfiguration -> Software -> Erweiterte Einstellungen -> ScratchConfig -> ScratchConfig.ConfiguredScratchLocation auf den neuen Pfad setzen, z.B. /vmfs/volumes/DATASTORENAME/.locker-ESXHOSTNAME

Der Defaultwert ist /tmp/scratch, was in einer Standartinstallation auf der Ramdisk liegt. Eine Möglichkeit diese Warnung ohne die solche Anpassung des Setups auszuschalten ist (mir) nicht bekannt.

Quelle: Ugg.li

Hinterlasse einen Kommentar

Eingeordnet unter VMware

VMware View Security Server konfigurieren für PCoIP (Internet Zugriff)

Einleitung
Meiner Meinung nach das beste neue Feature von View 4,6. Es erlaubt uns, ohne ein VPN, eine Verbindung über PCoIP zu den View Maschinen über das Internet herzustellen. Viele Mitarbeiter arbeiten heute auch Abends oder am Wochenende von zu Hause aus (wessen Arbeitszeit liegt schon noch zwischen 9 und 17 Uhr).Noch dazu gibts es in eigentlich jedem Unternehmen Aussendienstmitarbeiter. Bisher mußte man für View immer erst eine VPN Verbindung in die Firma aufbauen.
Vom Ipad aus nicht immer so einfach, hier und da hängt sich auch Windows oder Mac OSx beim VPN Stup auf oder es muß erst spezielle Software eingespielt werden.Mit diesem Howto konfiguriert man einen VMware Security Server so das man von unterwegs per Ipad oder Notebook einfach mal schnell auf seine View Maschine in der Firma connecten kann.

Damit man auf den View Desktop verbinden kann, muss über das öffentliche Internet geroutet werden. Das bedeutet das man bestimmte Ports von außen durch die Firewall auf den Security Server routet.

VMware View Konfigurieren
– Öffne die VMware View Administrator GUI klicke „View Configuration“ und wähle den Menüpunkt „Servers“ aus
– Markiere den View Connection Server und klicke auf die Schaltfläche „Edit“

030211 1726 VMwareView46

– Nun unter dem Tab „General“ die Häkchen bei „Use Secure Tunnel Connection to Desktop“ und „Use PCoIP Secure Gateway for PCoIP connections to Desktop“
– Die restlichen Tabs einfach auf den Default werden stehen lassen genau wie die Eingabe Felder

030211 1726 VMwareView47

Jetzt muss die Externe IP Adresse noch in den Security Server eingepflegt werden. Dazu klicken wir auf den „Security Server“ und danach auf „Edit“.
Im folgenden Fenster ist es wichtig das im unteren Feld „PCoIP External URL“ die externe Adresse inkl des „Ports 4172“ steht.
(Im Bsp. 12.249.15.181:4172)

030211 1726 VMwareView48

Firewall Setup
In der Firewall oder dem Router muss jetzt die Externe IP (WAN) in Richtung des Security Servers (LAN) geroutet/gemappt werden. Dabei ist es wichtig das das sowohl TCP als auch UDP weitergeleitet werden. Die Ports die frei gemacht werden müssen sind „443“ und „4172“.

Beispiel

Externe IP = 12.49.15.181

View Connection Server IP = 192.168.1.138

View Security Server IP = 192.168.1.250

Beispiel NAT Rule

Destination (WAN) 12.49.15.181 auf TCP/UDP 443,4172 (LAN) 192.168.1.250 auf TCP/UDP 443,4172

Unten ist ein Beispiel von der NAT-Regel auf meiner Firewall, in Der der TCP/UDP-Verkehr auf Port 4172 von (WAN) 12.49.15.181 in Richtung (LAN) 192.168.1.250 (View Security Server) geroutet wird.
In meinem Fall muss ich jede Regel einzeln anlegen.

UDP

030211 1726 VMwareView49

030211 1726 VMwareView411

TCP

030211 1726 VMwareView412

030211 1726 VMwareView414

Firewall-Regeln
PCoIP Verkehr zwischen View Security Server und dem Virtual Desktop (intern)
TCP 4172 vom Security Server auf Virtual Desktop
UDP 4172 vom Security Server auf Virtual Desktop in beide Richtungen

PCoIP zwischen View Client und Security Server (extern)
TCP 4172 vom Client zum Security Server
UDP 4172 zwischen Client und Security-Server in beide Richtungen

Um zu überprüfen, ob die TCP-Ports korrekt geöffnet sind kann man auf der Seite http://www.yougetsignal.com/tools/open-ports/ einen PortCheck ausführen. Er Checkt aber nur TCP kein UDP…

Verbindungsaufbau
So und nun einfach den Ipad View Client oder den PC/Mac View Client starten. Die Externe IP Adresse der Firewall eingeben (WAN) und verbinden. Wenn alles richtig konfiguriert wurde dann kann man View nun ganz einfach von Unterwegs oder zu Hause aus Nutzen.

Viel Spaß 🙂

Hinterlasse einen Kommentar

Eingeordnet unter VMware

OSx Lion auf VMware Workstation

mac-os-x-lion-2

So hier mal eine kleine Anleitung wie man OSx LION unter VMware Workstation ans laufen bringt:

1. Auf der Seite http://iMZDL.com läd man das File „OS X Lion Pre-Installed VMware Image.zip“ herunter.

2. In dem File wird man unter anderem einen Ordner „VMware Workstation v.7x“ finden. Aus diesem installieren wir nun Workstation auf dem Rechner. (Standart Installation inkl. Neustart des Rechners)

3. Nach dem Neustart finden wir im Ordner „VMware Patch OS X Lion“ verschiedene Dateien, die das VMware Workstation um die Funktion „OSx Lion“ erweitert. In diesem Fall einfach die Batch Datei für Windows „als Administrator“ ausführen.

4. So noch nach einem letzten Neustart kann man nun VMware Workstation öffnen und das VMware Image das im Ordner „OS X Lion FINAL VMware“ liegt einbinden.

5. Starten und freuen 🙂

4 Kommentare

Eingeordnet unter VMware