With the last update in Debian of qemu-kvm to version 1.6, booting vms via pxe with the e1000 (and ne2k_pci) network cards is no working anymore. I didn't take a deep look of the issue yet, but there is an easy solution (actually 2) for that.
Easiest one:
wget https://github.com/qemu/qemu/raw/master/pc-bios/pxe-e1000.rom -O /usr/lib/ipxe/e1000_82540.rom
Another one:
git clone http://git.ipxe.org/ipxe.git
cd ipxe/src
make bin/8086100e.rom
cp bin/8086100e.rom /usr/lib/ipxe/e1000_82540.rom
Debian Always More!
miércoles, 4 de septiembre de 2013
viernes, 25 de enero de 2013
OpenVswitch and kvm
#virsh edit domain
<interface type='bridge'> <mac address='52:54:00:43:1f:f4'/> <source bridge='br0'/> <virtualport type='openvswitch'/> </virtualport> </interface>
Long live to openvswtich-brcomptt
Now that openvswitch-brcompat is not officially supported with recent kernels (Ubuntu 12.10 with kernel 3.5), the alternative to configure the bridges directly in the interfaces file has change a bit... but is still pretty forward!Simple case with 1 bridge and 1 attached interface:
allow-ovs br99
iface br99 inet dhcp
ovs_type OVSBridge ovs_ports eth0
allow-br99 eth0 iface eth0 inet manual ovs_bridge br0 ovs_type OVSPort And to bring it up and down: ifup --allow=ovs $list_of_bridges ifdown --allow=ovs $list_of_bridges Et voilà! More info at: openvswitch-switch.README.Debian
martes, 29 de mayo de 2012
Debian and OpenStack
In February I wrote:
"The major problem of Debian and OpenStack, is Debian itself. In a so fast moving project like OpenStack, having an "EveryThing-Ready-and-Inclu ded" release every two years is not viable for this scenario. In the case of OpenStack, Squeeze is too old to handle it the way it is right now (Too many things not directly related with OpenStack, like qemu-xen, python-modules, etc., should be backported to make it functional, and with just volunteer packagers, make it a not so viable option). In the other hand, the next release, is planned to 1Q 2013 (Wheezy being frozen in later June), so Essex release will be outdated and Folsom we be the stable release by then, and with G release knocking on the door (Essex is supposed to be a LTS release, supported by Canonical/Ubuntu until around April 2017so is not that bad). Solutions? Forget about Squeeze, focus in Wheezy + Essex as an official release , and Folsom (or G release) as a back-ported option. The other option (not viable in a short term), is change the way Debian makes it releases, and try to have something more "componentized" (like Progeny tried to do some years ago) or "rolling-releases", so trending-topic these days. Neither GNOME, OpenStack, LibreOffice, linux-kernel (just to name some) has a similar release cycle or core necessities to run in a system, so why try to release, prepare, stabilized everything at the same time no matter what's the status the upstream project is? (Just int he case of OpenStack, and supposing everything thing is going according the schedule, with a 6 month release cycle vs. 2 years in Debian + frozen period, when Wheezy is released, we are going to release an outdated version -essex (but LTS thanks to Canonical)- when Folsom is 4 months old! and the new release coming in less than two months!) I agree this needs a lot of more development, but i think it's something that Debian should have to think about."
Re-reading it, the situation is not that bad actually. We were lucky enough that the new Ubuntu LTS was released, and we can use the excuse of Essex being supported until 2017. But the key point is the same: "Debian is huge and slow, while OpenStack (and so many other projects) are really fast-moving"
martes, 14 de junio de 2011
Encrypted filesystems in Debian Squeeze
We need to have cryptsetup installed
root@squeeze:~# apt-get install cryptsetup
The partition can be a whole disk (a pendrive per example), a partition or even a lvm volume. In this case, we are going to use a lvm volume using a hard disk
root@squeeze:~# vgcreate vol0 /dev/sda
No physical volume label read from /dev/sda
Physical volume "/dev/sda" successfully created
Volume group "vol0" successfully created
root@squeeze:~# vgs
VG #PV #LV #SN Attr VSize VFree
vol0 1 0 0 wz--n- 1020.00m 1020.00m
root@squeeze:~# lvcreate -n lv_crypt -L 200M vol0
Logical volume "lv_crypt" created
root@squeeze:~# lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
lv_crypt vol0 -wi-a- 200.00m
After this, the best thing to do is to write random data in the partition to generate noise.
root@squeeze:~# dd if=/dev/urandom of=/dev/mapper/vol0-lv_crypt
dd: writing to `/dev/mapper/vol0-lv_crypt': No space left on device
409601+0 records in
409600+0 records out
209715200 bytes (210 MB) copied, 60.7331 s, 3.5 MB/s
Finally, we create/format the encrypted partition, and open it to have it available to the system
root@squeeze:~# cryptsetup luksFormat /dev/mapper/vol0-lv_crypt
WARNING!
========
This will overwrite data on /dev/mapper/vol0-lv_crypt irrevocably.
Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
root@squeeze:~# cryptsetup luksOpen /dev/mapper/vol0-lv_crypt crypt
Enter passphrase for /dev/mapper/vol0-lv_crypt:
Once opened, we can access it as a non-encrypted partition available under /dev/mapper/crypt (all the names can be changed to something more suitable for you), so we can format and access it like a normal partition.
root@squeeze:~# mkfs.ext4 /dev/mapper/crypt
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
51000 inodes, 203772 blocks
10188 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
25 block groups
8192 blocks per group, 8192 fragments per group
2040 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 36 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
root@squeeze:~# mount /dev/mapper/crypt /media/crypt/
If you are using a graphical desktop, like GNOME, it can manage it automatically with Nautilus, asking you the pass-phrase and root password.
You can avoid to work in the command line using the /etc/crypttab file, to open this filesystem during system boot. The systax of this file is pretty simple:
root@squeeze:~# cryptsetup luksUUID /dev/mapper/vol0-lv_crypt
1495abcf-38b5-4065-9880-4f8512d7c535
root@squeeze:~# cat /etc/crypttab
#
crypt UUID=1495abcf-38b5-4065-9880-4f8512d7c535 none luks
Using the disk UUID we can avoid future problems of the disk not being in the same path (like a pendrive)
At boot time, the system will ask for the passphare to open the encrypted disk
We can also especify a file with the key, to avoid this question. We can have a external usb drive with this file, or we can have this key files locally, to open external usb drives.
jueves, 17 de marzo de 2011
ext4 optimization and throughput (Preview)
Scenario: Debian Stable 6.0 under VmWare ESXi 4.1
Cases:
- 1 core and 497 Mb RAM
- 4 cores and 4Gb RAM
Test used: Phoronix Test Suite
Mount options:
- defaults
- noatime
- long noatime,barrier=0,data=writeback,nobh,commit=100,nouser_xattr
- no_journal - defaults, but fs created with "mkfs.ext4 /dev/sdb1 -O^has_journal" defaults
Results Case1 (1 Core):
Results Case2 (4 Cores):
http://openbenchmarking.org/result/1103166-IV-EXT44CORE94
Results Case1 & Case 2 Mixed:
Results Case1 & Case 2 Mixed:
http://openbenchmarking.org/result/1103160-IV-MERGE353122 (It has some visualization problems)
Comments:
To be update... soon
Improvements to do:
Test in a bare installation, and testing hypervisor overload (vmware Vs. kvm)
jueves, 5 de junio de 2008
Avoiding unnecesary restarts
When you have a lot of servers to manage from a single keyboard/monitor, sometimes is easy to reboot a Linux system when trying to login into a Windows one using the crtl+alt+del keys. To solve this, just comment this line in the /etc/inittab file:
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
Suscribirse a:
Entradas (Atom)