- Users - oVirt List Archives

Re: [Users] ovirt and EqualLogic iSCSI SAN
by Gianluca Cecchi 04 Jan '13

04 Jan '13

On Fri, Jan 4, 2013 at 6:59 AM, Dan Yasny wrote: > BTW, if Dell try for a "not supported" again, you can point them to > > http://en.community.dell.com/techcenter/b/techcenter/archive/2013/01/03/ann… > > They have a similar announcement for 3.0: > > http://en.community.dell.com/techcenter/b/techcenter/archive/2012/07/13/red… worded slightly differently > > Useful links and related documents, but they only talk about support for the Dell server part in RHEV 3.x and related OpenManage sw while they never explicitly cite the storage array part in general, and Equallogic in particular... probably for some reason... Gianluca

1 0

[Users] Missing archives
by Karsten 'quaid' Wade 04 Jan '13

04 Jan '13

This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig87AB028DD52DF6D3A58E2A06 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 21 Dec I fixed the archive for this mailing list at the request of a user. When I did that, I failed to set the permissions and ownership for the changed mailbox file. It remained owned by root, so Mailman was unable to write to the archives. :( :( I think we can fix this if anyone has a copy of all the email sent to this list since 21 Dec. in an .mbox format. Anyone have everything from 21 Dec. to this message I just sent (which should hit the archives)? - Karsten --=20 Karsten 'quaid' Wade, Sr. Analyst - Community Growth http://TheOpenSourceWay.org .^\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 --------------enig87AB028DD52DF6D3A58E2A06 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iD8DBQFQ5yIr2ZIOBq0ODEERAoiHAKDezC4oZtKpa9z4ZSfceO+7eScbXgCgoKdN lOmulECyehwk3RqHkKQQe9Q= =p9Z2 -----END PGP SIGNATURE----- --------------enig87AB028DD52DF6D3A58E2A06--

2 3

[Users] F18 AIO with nightly build I don't find ISO domain
by Gianluca Cecchi 21 Dec '12

21 Dec '12

Hello, during AIO install with ovirt-engine-setup-3.2.0-1.20121217.git1e01c00.fc18.noarch I specified ISO domain not accepting default but setting /ISO Host correctly activated but no ISO domain found. I can see: [g.cecchi@f18aio ~]$ cat /etc/exports /ISO 0.0.0.0/0.0.0.0(rw) #rhev installer [g.cecchi@f18aio ~]$ sudo exportfs -v /ISO 0.0.0.0/0.0.0.0(rw,wdelay,root_squash,no_subtree_check) I cannot add the domain because I get: Error while executing action New Local Storage Domain: Error in creating a Storage Domain. The selected storage path is not empty (probably contains another Storage Domain). Either remove the existing Storage Domain from this path, or change the Storage path). I cannot import that domain because if I specify: Domain Function / Storage Type : ISO/NFS Use Host : local_host Export Path : f18aio:/ISO I get There is no storage domain under the specified path. Check event log for more details. In messages: Dec 20 12:33:03 f18aio rpc.mountd[1576]: authenticated mount request from 192.168.122.160:871 for /ISO (/ISO) Dec 20 12:33:05 f18aio kernel: [ 4748.963964] ata1: soft resetting link Dec 20 12:33:05 f18aio kernel: [ 4749.115677] ata1: EH complete Dec 20 12:33:06 f18aio kernel: [ 4749.966412] ata2: soft resetting link Dec 20 12:33:06 f18aio kernel: [ 4750.120449] ata2.00: configured for MWDMA2 Dec 20 12:33:06 f18aio kernel: [ 4750.120952] ata2: EH complete Dec 20 12:33:08 f18aio kernel: [ 4752.177808] ata1: soft resetting link Dec 20 12:33:08 f18aio kernel: [ 4752.330692] ata1: EH complete Dec 20 12:33:09 f18aio kernel: [ 4753.183308] ata2: soft resetting link Dec 20 12:33:09 f18aio kernel: [ 4753.337768] ata2.00: configured for MWDMA2 Dec 20 12:33:09 f18aio kernel: [ 4753.338555] ata2: EH complete In engine.log 2012-12-20 12:33:03,939 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ValidateStorageServerConnectionVDSCommand] (ajp--127.0.0.1-8702-2) [73e31316] START, ValidateStorageServerConnectionVDSCommand(HostName = local_host, HostId = 6ae6e471-d46b-48f5-8b0f-6f5cc20b251e, storagePoolId = 00000000-0000-0000-0000-000000000000, storageType = NFS, connectionList = [{ id: null, connection: f18aio:/ISO, iqn: null, vfsType: null, mountOptions: null, nfsVersion: null, nfsRetrans: null, nfsTimeo: null };]), log id: f20d993 2012-12-20 12:33:03,944 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ValidateStorageServerConnectionVDSCommand] (ajp--127.0.0.1-8702-2) [73e31316] FINISH, ValidateStorageServerConnectionVDSCommand, return: {00000000-0000-0000-0000-000000000000=0}, log id: f20d993 2012-12-20 12:33:03,952 INFO [org.ovirt.engine.core.bll.storage.AddStorageServerConnectionCommand] (ajp--127.0.0.1-8702-2) [73e31316] Running command: AddStorageServerConnectionCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: System 2012-12-20 12:33:03,954 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] (ajp--127.0.0.1-8702-2) [73e31316] START, ConnectStorageServerVDSCommand(HostName = local_host, HostId = 6ae6e471-d46b-48f5-8b0f-6f5cc20b251e, storagePoolId = 00000000-0000-0000-0000-000000000000, storageType = NFS, connectionList = [{ id: 309f07eb-ae33-4892-9415-a21c774a89e2, connection: f18aio:/ISO, iqn: null, vfsType: null, mountOptions: null, nfsVersion: null, nfsRetrans: null, nfsTimeo: null };]), log id: 3255e846 2012-12-20 12:33:03,996 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] (ajp--127.0.0.1-8702-2) [73e31316] FINISH, ConnectStorageServerVDSCommand, return: {309f07eb-ae33-4892-9415-a21c774a89e2=0}, log id: 3255e846 2012-12-20 12:33:04,021 INFO [org.ovirt.engine.core.bll.storage.GetExistingStorageDomainListQuery] (ajp--127.0.0.1-8702-2) START, GetExistingStorageDomainListQuery(org.ovirt.engine.core.common.queries.GetExistingStorageDomainListParameters@705c0fb1), log id: 6e3f186a 2012-12-20 12:33:04,024 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetStorageDomainsListVDSCommand] (ajp--127.0.0.1-8702-2) START, HSMGetStorageDomainsListVDSCommand(HostName = local_host, HostId = 6ae6e471-d46b-48f5-8b0f-6f5cc20b251e, storagePoolId=00000000-0000-0000-0000-000000000000, storageType=NFS, storageDomainType=ISO, path=f18aio:/ISO), log id: 1eb50b8c 2012-12-20 12:33:07,156 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetStorageDomainsListVDSCommand] (ajp--127.0.0.1-8702-2) FINISH, HSMGetStorageDomainsListVDSCommand, return: [52f15c20-82ef-4fe6-8609-9d43fa6ce72d], log id: 1eb50b8c 2012-12-20 12:33:07,163 INFO [org.ovirt.engine.core.bll.storage.GetExistingStorageDomainListQuery] (ajp--127.0.0.1-8702-2) FINISH, GetExistingStorageDomainListQuery, log id: 6e3f186a 2012-12-20 12:33:07,207 INFO [org.ovirt.engine.core.bll.storage.RemoveStorageServerConnectionCommand] (ajp--127.0.0.1-8702-2) [a59e1de] Running command: RemoveStorageServerConnectionCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: System 2012-12-20 12:33:07,211 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.DisconnectStorageServerVDSCommand] (ajp--127.0.0.1-8702-2) [a59e1de] START, DisconnectStorageServerVDSCommand(HostName = local_host, HostId = 6ae6e471-d46b-48f5-8b0f-6f5cc20b251e, storagePoolId = 00000000-0000-0000-0000-000000000000, storageType = NFS, connectionList = [{ id: null, connection: f18aio:/ISO, iqn: null, vfsType: null, mountOptions: null, nfsVersion: null, nfsRetrans: null, nfsTimeo: null };]), log id: 68961755 2012-12-20 12:33:10,326 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.DisconnectStorageServerVDSCommand] (ajp--127.0.0.1-8702-2) [a59e1de] FINISH, DisconnectStorageServerVDSCommand, return: {00000000-0000-0000-0000-000000000000=0}, log id: 68961755 2012-12-20 12:33:12,729 INFO [org.ovirt.engine.core.bll.LoginUserCommand] (ajp--127.0.0.1-8702-2) Checking if user admin@internal is an admin, result true 2012-12-20 12:33:12,729 INFO [org.ovirt.engine.core.bll.LoginUserCommand] (ajp--127.0.0.1-8702-2) Running command: LoginUserCommand internal: false. 2012-12-20 12:33:12,739 WARN [org.ovirt.engine.core.bll.GetConfigurationValueQuery] (ajp--127.0.0.1-8702-2) calling GetConfigurationValueQuery (ApplicationMode) with null version, using default general for version 2012-12-20 12:33:12,740 WARN [org.ovirt.engine.core.bll.GetConfigurationValueQuery] (ajp--127.0.0.1-8702-2) calling GetConfigurationValueQuery (VdcVersion) with null version, using default general for version Thanks, Gianluca

3 3

[Users] Ovirt Node rebooting +/- every 10 days
by EricD 21 Dec '12

21 Dec '12

I have oVirt 3.1 with two nodes, one of them is running good without restarting the other keep restarting, the maximum uptime that the server can get is 10 days before it restart, I think that it might be something related to the disk. FYI, the disk are 2 disk of 1TB (RAID-0) to get 2TB. # /var/log/messages Dec 21 05:28:44 hypervisor01a ntpd[945]: 0.0.0.0 c61c 0c clock_step +17997.588918 s Dec 21 05:28:44 hypervisor01a ntpd[945]: 0.0.0.0 c614 04 freq_mode Dec 21 05:28:45 hypervisor01a kdump: No crashkernel parameter specified for running kernel Dec 21 05:28:45 hypervisor01a kdumpctl[1366]: Starting kdump: Dec 21 05:28:45 hypervisor01a kdump: failed to start up Dec 21 05:28:45 hypervisor01a systemd[1]: kdump.service: main process exited, code=exited, status=1 Dec 21 05:28:45 hypervisor01a systemd[1]: Unit kdump.service entered failed state. Dec 21 05:28:45 hypervisor01a systemd[1]: Startup finished in 888ms 157us (kernel) + 2s 521ms 289us (initrd) + 15s 577ms 672us (userspace) = 18s 987ms 118us. Dec 21 05:28:45 hypervisor01a ntpd[945]: 0.0.0.0 c618 08 no_sys_peer Dec 21 05:29:04 hypervisor01a vdsm TaskManager.Task ERROR Task=`5f51ff52-f9a4-4854-a41d-d5d33c872458`::Unexpected error Dec 21 05:29:04 hypervisor01a vdsm Storage.Dispatcher.Protect ERROR {'status': {'message': "Unknown pool id, pool not connected: ('dbb49db6-9a24-4395-a8bd-c9f222eaecab',)", 'code': 309}} Dec 21 05:29:04 hypervisor01a vdsm TaskManager.Task ERROR Task=`7b0cf3b0-6d26-4421-a221-29f2ecaaeb1f`::Unexpected error Dec 21 05:29:04 hypervisor01a vdsm Storage.Dispatcher.Protect ERROR {'status': {'message': "Unknown pool id, pool not connected: ('dbb49db6-9a24-4395-a8bd-c9f222eaecab',)", 'code': 309}} Dec 21 05:29:04 hypervisor01a kernel: [ 37.944421] ata1: hard resetting link Dec 21 05:29:04 hypervisor01a kernel: [ 38.247979] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Dec 21 05:29:04 hypervisor01a kernel: [ 38.248802] ata1.00: configured for UDMA/133 Dec 21 05:29:04 hypervisor01a kernel: [ 38.248807] ata1: EH complete Dec 21 05:29:04 hypervisor01a kernel: [ 38.249013] ata2: hard resetting link Dec 21 05:29:04 hypervisor01a kernel: [ 38.553112] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Dec 21 05:29:04 hypervisor01a kernel: [ 38.553881] ata2.00: configured for UDMA/133 Dec 21 05:29:04 hypervisor01a kernel: [ 38.553886] ata2: EH complete Dec 21 05:29:04 hypervisor01a kernel: [ 38.554064] ata3: hard resetting link Dec 21 05:29:05 hypervisor01a kernel: [ 38.858275] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Dec 21 05:29:05 hypervisor01a kernel: [ 38.861154] ata3.00: configured for UDMA/133 Dec 21 05:29:05 hypervisor01a kernel: [ 38.861159] ata3: EH complete Dec 21 05:29:05 hypervisor01a kernel: [ 38.861352] ata4: hard resetting link Dec 21 05:29:05 hypervisor01a kernel: [ 39.165397] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Dec 21 05:29:05 hypervisor01a kernel: [ 39.168223] ata4.00: configured for UDMA/133 Dec 21 05:29:05 hypervisor01a kernel: [ 39.168229] ata4: EH complete Dec 21 05:29:05 hypervisor01a kernel: [ 39.168421] ata5: hard resetting link Dec 21 05:29:05 hypervisor01a kernel: [ 39.472459] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Dec 21 05:29:05 hypervisor01a kernel: [ 39.480040] ata5.00: configured for UDMA/100 Dec 21 05:29:05 hypervisor01a kernel: [ 39.485478] ata5: EH complete Dec 21 05:29:05 hypervisor01a kernel: [ 39.485642] ata6: limiting SATA link speed to 1.5 Gbps Dec 21 05:29:05 hypervisor01a kernel: [ 39.485647] ata6: hard resetting link Dec 21 05:29:06 hypervisor01a kernel: [ 39.790610] ata6: SATA link down (SStatus 0 SControl 310) # RAID-0 mdadm --detail /dev/md127 /dev/md127: Version : 1.2 Creation Time : Sun Nov 18 14:47:15 2012 Raid Level : raid0 Array Size : 1953524736 (1863.03 GiB 2000.41 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Sun Nov 18 14:47:15 2012 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Chunk Size : 512K Name : hypervisor01-a:0 (local to host hypervisor01-a) UUID : 9eb1324d:57eed46d:c23ae815:0666e238 Events : 0 Number Major Minor RaidDevice State 0 253 2 0 active sync /dev/dm-2 1 253 3 1 active sync /dev/dm-3

1 0

[Users] ovirt-shell bug ?
by Alex Leonhardt 21 Dec '12

21 Dec '12

Hi, am trying to use .ovirtshellrc with a set user, pass and url, however, I keep getting this instead: error: invalid literal for int() with base 10: '' and I remain disconnected. Using the same url and creds to connect manually works - is it a bug or just some setting ? Alex

2 4

[Users] ovirt-shell, action vm vmhost start issue ?
by Alex Leonhardt 21 Dec '12

21 Dec '12

Hi, am trying to start a VM with special kernel and initrd options : [oVirt shell (connected)]# action vm cent6 start --vm-os-kernel "/var/www/html/repo/centos/6/os/x86_64/images/pxeboot/vmlinuz" --vm-os-initRd "/var/www/html/repo/centos/6/os/x86_64/images/pxeboot/initrd.img" --vm-os-boot "{ip=x.x.x.x;netmask=x.x.x.x;gateway=x.x.x.x;dns=x.x.x.x}" However, I keep getting this back : error: "initRd" is invalid argument segment. Eventhough, the help says that it's a valid command option : ATTRIBUTE OPTIONS The following attribute options are understood. Note: this lists all available attribute options for action 'start'. [--vm-os-initRd: string] [--vm-domain-name: string] [--vm-placement_policy-host-id|name: string] [--vm-placement_policy-affinity: string] [--async: boolean] [--vm-os-kernel: string] [--grace_period-expiry: long] [--vm-display-type: string] [--vm-stateless: boolean] [--vm-os-cmdline: string] [--vm-domain-user-username: string] [--pause: boolean] [--vm-os-boot: collection] { [boot.dev: string] } [--vm-domain-user-password: string] [--correlation_id: anystring] Alex

2 1

[Users] Bug in ovirt-deploy script
by Joop 21 Dec '12

21 Dec '12

I think I found a bug in a module of the ovirt-host-deploy script. I'm (still) using F17 with the latest nightly being: rpm -aq | grep ovirt ovirt-engine-cli-3.2.0.7-1.20121217.git5eddf58.fc17.noarch ovirt-engine-dbscripts-3.2.0-1.20121219.gitcd0d2cc.fc17.noarch ovirt-iso-uploader-3.1.0-1.fc17.noarch ovirt-engine-userportal-3.2.0-1.20121219.gitcd0d2cc.fc17.noarch ovirt-engine-setup-3.2.0-1.20121219.gitcd0d2cc.fc17.noarch ovirt-engine-tools-common-3.2.0-1.20121219.gitcd0d2cc.fc17.noarch ovirt-engine-backend-3.2.0-1.20121219.gitcd0d2cc.fc17.noarch ovirt-host-deploy-0.0.0-0.0.master.20121219.git817103d.fc17.noarch ovirt-engine-sdk-3.2.0.5-1.20121217.gitc0ab704.fc17.noarch ovirt-engine-restapi-3.2.0-1.20121219.gitcd0d2cc.fc17.noarch ovirt-engine-genericapi-3.2.0-1.20121219.gitcd0d2cc.fc17.noarch ovirt-engine-config-3.2.0-1.20121219.gitcd0d2cc.fc17.noarch ovirt-engine-webadmin-portal-3.2.0-1.20121219.gitcd0d2cc.fc17.noarch ovirt-host-deploy-java-0.0.0-0.0.master.20121219.git817103d.fc17.noarch ovirt-engine-notification-service-3.2.0-1.20121219.gitcd0d2cc.fc17.noarch ovirt-release-fedora-5-2.noarch ovirt-image-uploader-3.1.0-1.fc17.noarch ovirt-engine-3.2.0-1.20121219.gitcd0d2cc.fc17.noarch ovirt-log-collector-3.1.0-1.fc17.noarch I'm using a Cluster with the Gluster bit checked and when adding that host it errors out with a rather annoying error: package 'v' not found. Turns out that the last line of Mgmt01/usr/share/ovirt-host-deploy/plugins/ovirt-host-deploy/gluster/packages.py is wrong, there is a ',' missing. I changed it to: def _packages(self): self.packager.installUpdate(('vdsm-gluster',)) And when I now try to deploy my host in the gluster Cluster it tries to install vdsm-gluster package and dependancies. It now fails in /usr/share/vdsm/addNetwork where it complaines about ConfigNetworkError: (21, 'Both PREFIX and NETMASK supplied') This host has already been an ovirt installed host. I could for testing remove all traces of ovirt but I have another host where I tried that and now it stops its networking when vdsmd starts ;-( Went ahead and removed PREFIX and reran deploy. The bridge ovirtmgmt is correctly created BUT there is an error in the log: INFO:root:Adding network ovirtmgmt with vlan=, bonding=, nics=['em1'], bondingOptions=None, mtu=None, bridged=True, options={'blockingdhcp': 'true', 'UUID': 'e121a99a-994e-479d-8de1-a56c14315545', 'USERCTL': 'no', 'DNS2': '172.19.1.18', 'DNS1': '172.19.1.12', 'bootproto': 'none', 'onboot': 'yes', 'IPV6INIT': 'no'} libvir: Network Driver error : Network not found: no network with matching name 'vdsm-ovirtmgmt' libvir: Network Driver error : Network not found: no network with matching name 'vdsm-ovirtmgmt' libvir: Network Driver error : Requested operation is not valid: cannot set autostart for transient network Looking at /etc/libvirt/qemu/networks/* shows indeed there are references to vdsm-ovirtmgt. Maybe this is because I'm also using fedora-virt-preview-repo because the nightlies need a newer libvirt. Let me know if a slightly lower version of libvirt will fix this. Joop

2 2

[Users] v2v - converting windows VMs
by Alex Leonhardt 21 Dec '12

21 Dec '12

Hi, i've read up about converting Windows VMs and it needs some "Guest Tools CD" - https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Virtualiz… where can one get that CD/iso image and whatever else is required ? Alex

1 2

Re: [Users] [Bug 881579] kernel-3.6.7-4 causes panic on FreeBSD KVM guest with >1 CPU
by Karli Sjöberg 20 Dec '12

20 Dec '12

--_000_5F9E965F5A80BC468BE5F40576769F090E8807ADexchange21_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 b25zIDIwMTItMTItMTkga2xvY2thbiAwMToyOCArMDAwMCBza3JldiBidWd6aWxsYUByZWRoYXQu Y29tOg0KDQoNClByb2R1Y3Q6IEZlZG9yYQ0KaHR0cHM6Ly9idWd6aWxsYS5yZWRoYXQuY29tL3No b3dfYnVnLmNnaT9pZD04ODE1NzkNCg0KLS0tIENvbW1lbnQgIzMgZnJvbSBNYXJjZWxvIFRvc2F0 dGkgPG10b3NhdHRpQHJlZGhhdC5jb208bWFpbHRvOm10b3NhdHRpQHJlZGhhdC5jb20+PiAtLS0N Ckl0cyB2ZXJ5IGxpa2VseSB0aGUgY2F1c2UgZm9yIHRoaXMgYXJlIGluc3RydWN0aW9uIGVtdWxh dGlvbiB1cHN0cmVhbQ0KKGVtdWxhdGlvbiBvZiBpbnZhbGlkIGd1ZXN0IHN0YXRlIGJ5IGRlZmF1 bHQpLg0KDQpUaGVzZSBhcmUgYmVpbmcgZml4ZWQgdXBzdHJlYW0uIE9uY2UgdGhhdCBpcyBjb21w bGV0ZWQsIGl0IHdpbGwgYmUgbmVjZXNzYXJ5IHRvDQpiYWNrcG9ydA0KdG8gRkMxNy4NCg0KSW4g dGhlIG1lYW50aW1lLCBsb2FkaW5nIGt2bS1pbnRlbC5rbyB3aXRoIGVtdWxhdGVfaW52YWxpZF9n dWVzdF9zdGF0ZT0wIHNob3VsZA0Kd29yayBhcm91bmQgdGhlIHByb2JsZW0gKHRlc3RlZCBsb2Nh bGx5IG9uIGt2bS5naXQgYXMgb2YgZGVjLzIwMTIpLg0KDQoNCg0KRm9yIGZ1dHVyZSByZWZlcmVu Y2UsIEkgd2FudCB0byBhZGQgd2hhdCBtZWFzdXJlcyBoYXZlIGJlZW4gdGFrZW46DQoNCkZyb20g b1ZpcnQgV2ViYWRtaW4sIHRoZSBIb3N0IHdhcyBzZXQgaW50byBNYWludGVuYW5jZS4NCg0KVGhl biB0aGlzIGZpbGU6DQovZXRjL3N5c2NvbmZpZy9tb2R1bGVzL2t2bS5tb2R1bGVzOg0KIyEvYmlu L3NoDQoNCmdyZXAgdm14IC9wcm9jL2NwdWluZm8gPi9kZXYvbnVsbCAyPiYxICYmIHZteD0xDQpn cmVwIHN2bSAvcHJvYy9jcHVpbmZvID4vZGV2L251bGwgMj4mMSAmJiBzdm09MQ0KDQppZiBbICIk dm14IiBdIHx8IFsgIiRzdm0iIF07IHRoZW4NCiAgWyAiJHZteCIgXSAmJiBtb2Rwcm9iZSAtYiA+ L2Rldi9udWxsIDI+JjENCiAgWyAiJHN2bSIgXSAmJiBtb2Rwcm9iZSAtYiBrdm0tYW1kID4vZGV2 L251bGwgMj4mMQ0KDQogICMgbm8gcmVhc29uIHdoeSB2aG9zdCBzaG91bGQgbm90IHdvcmsgd2l0 aCBUQ0csIGJ1dCBjdXJyZW50bHkgaXQgZG9lcyBub3QNCiAgbW9kcHJvYmUgLWIgdmhvc3QtbmV0 ID4vZGV2L251bGwgMj4mMQ0KZWxzZQ0KICBleGl0IDANCmZpDQoNCldhcyBtb2RmaWVkIHRvIGxv b2sgbGlrZToNCiMhL2Jpbi9zaA0KDQpncmVwIHZteCAvcHJvYy9jcHVpbmZvID4vZGV2L251bGwg Mj4mMSAmJiB2bXg9MQ0KZ3JlcCBzdm0gL3Byb2MvY3B1aW5mbyA+L2Rldi9udWxsIDI+JjEgJiYg c3ZtPTENCg0KaWYgWyAiJHZteCIgXSB8fCBbICIkc3ZtIiBdOyB0aGVuDQogIFsgIiR2bXgiIF0g JiYgbW9kcHJvYmUgLWIga3ZtLWludGVsIGVtdWxhdGVfaW52YWxpZF9ndWVzdF9zdGF0ZT0wID4v ZGV2L251bGwgMj4mMQ0KICBbICIkc3ZtIiBdICYmIG1vZHByb2JlIC1iIGt2bS1hbWQgPi9kZXYv bnVsbCAyPiYxDQoNCiAgIyBubyByZWFzb24gd2h5IHZob3N0IHNob3VsZCBub3Qgd29yayB3aXRo IFRDRywgYnV0IGN1cnJlbnRseSBpdCBkb2VzIG5vdA0KICBtb2Rwcm9iZSAtYiB2aG9zdC1uZXQg Pi9kZXYvbnVsbCAyPiYxDQplbHNlDQogIGV4aXQgMA0KZmkNCg0KQW5kIGFmdGVyIHR3byByZWJv b3RzKGRpZG7CtHQgZ2V0IHNldCBhZnRlciB0aGUgZmlyc3QgcmVib290LCBzdHJhbmdseSBlbm91 Z2gpIHRoZSBzZXR0aW5nIGhhdmUgYmVlbiBjb25maXJtZWQgcGVyc2lzdGFudCB3aXRoOg0KIyBt b3JlIC9zeXMvbW9kdWxlL2t2bV9pbnRlbC9wYXJhbWV0ZXJzL2VtdWxhdGVfaW52YWxpZF9ndWVz dF9zdGF0ZQ0KTg0KDQpUaGUgSG9zdCB3YXMgYWdhaW4gYWN0aXZhdGVkIGFuZCB0aGUgZ3Vlc3Qg cGFuaWNzIGFyZSBnb25lLg0KDQpUaGFua3MgZm9yIHRoZSBoaW50IQ0KDQovS2FybGkNCg0K --_000_5F9E965F5A80BC468BE5F40576769F090E8807ADexchange21_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUUkFOU0lUSU9OQUwv L0VOIj4NCjxodG1sPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHRU5FUkFUT1Ii IGNvbnRlbnQ9Ikd0a0hUTUwvNC40LjQiPg0KPC9oZWFkPg0KPGJvZHk+DQpvbnMgMjAxMi0xMi0x OSBrbG9ja2FuIDAxOjI4ICYjNDM7MDAwMCBza3JldiBidWd6aWxsYUByZWRoYXQuY29tOg0KPGJs b2NrcXVvdGUgdHlwZT0iQ0lURSI+DQo8cHJlPgpQcm9kdWN0OiBGZWRvcmEKPGEgaHJlZj0iaHR0 cHM6Ly9idWd6aWxsYS5yZWRoYXQuY29tL3Nob3dfYnVnLmNnaT9pZD04ODE1NzkiPmh0dHBzOi8v YnVnemlsbGEucmVkaGF0LmNvbS9zaG93X2J1Zy5jZ2k/aWQ9ODgxNTc5PC9hPgoKLS0tIENvbW1l bnQgIzMgZnJvbSBNYXJjZWxvIFRvc2F0dGkgJmx0OzxhIGhyZWY9Im1haWx0bzptdG9zYXR0aUBy ZWRoYXQuY29tIj5tdG9zYXR0aUByZWRoYXQuY29tPC9hPiZndDsgLS0tCkl0cyB2ZXJ5IGxpa2Vs eSB0aGUgY2F1c2UgZm9yIHRoaXMgYXJlIGluc3RydWN0aW9uIGVtdWxhdGlvbiB1cHN0cmVhbQoo ZW11bGF0aW9uIG9mIGludmFsaWQgZ3Vlc3Qgc3RhdGUgYnkgZGVmYXVsdCkuCgpUaGVzZSBhcmUg YmVpbmcgZml4ZWQgdXBzdHJlYW0uIE9uY2UgdGhhdCBpcyBjb21wbGV0ZWQsIGl0IHdpbGwgYmUg bmVjZXNzYXJ5IHRvCmJhY2twb3J0CnRvIEZDMTcuCgpJbiB0aGUgbWVhbnRpbWUsIGxvYWRpbmcg a3ZtLWludGVsLmtvIHdpdGggZW11bGF0ZV9pbnZhbGlkX2d1ZXN0X3N0YXRlPTAgc2hvdWxkCndv cmsgYXJvdW5kIHRoZSBwcm9ibGVtICh0ZXN0ZWQgbG9jYWxseSBvbiBrdm0uZ2l0IGFzIG9mIGRl Yy8yMDEyKS4KCjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPGJyPg0KRm9yIGZ1dHVyZSByZWZlcmVu Y2UsIEkgd2FudCB0byBhZGQgd2hhdCBtZWFzdXJlcyBoYXZlIGJlZW4gdGFrZW46PGJyPg0KPGJy Pg0KRnJvbSBvVmlydCBXZWJhZG1pbiwgdGhlIEhvc3Qgd2FzIHNldCBpbnRvIE1haW50ZW5hbmNl Ljxicj4NCjxicj4NClRoZW4gdGhpcyBmaWxlOjxicj4NCjxiPi9ldGMvc3lzY29uZmlnL21vZHVs ZXMva3ZtLm1vZHVsZXM8L2I+Ojxicj4NCiMhL2Jpbi9zaDxicj4NCjxicj4NCmdyZXAgdm14IC9w cm9jL2NwdWluZm8gJmd0Oy9kZXYvbnVsbCAyJmd0OyZhbXA7MSAmYW1wOyZhbXA7IHZteD0xPGJy Pg0KZ3JlcCBzdm0gL3Byb2MvY3B1aW5mbyAmZ3Q7L2Rldi9udWxsIDImZ3Q7JmFtcDsxICZhbXA7 JmFtcDsgc3ZtPTE8YnI+DQo8YnI+DQppZiBbICZxdW90OyR2bXgmcXVvdDsgXSB8fCBbICZxdW90 OyRzdm0mcXVvdDsgXTsgdGhlbjxicj4NCiZuYnNwOyBbICZxdW90OyR2bXgmcXVvdDsgXSAmYW1w OyZhbXA7IG1vZHByb2JlIC1iICZndDsvZGV2L251bGwgMiZndDsmYW1wOzE8YnI+DQombmJzcDsg WyAmcXVvdDskc3ZtJnF1b3Q7IF0gJmFtcDsmYW1wOyBtb2Rwcm9iZSAtYiBrdm0tYW1kICZndDsv ZGV2L251bGwgMiZndDsmYW1wOzE8YnI+DQo8YnI+DQombmJzcDsgIyBubyByZWFzb24gd2h5IHZo b3N0IHNob3VsZCBub3Qgd29yayB3aXRoIFRDRywgYnV0IGN1cnJlbnRseSBpdCBkb2VzIG5vdDxi cj4NCiZuYnNwOyBtb2Rwcm9iZSAtYiB2aG9zdC1uZXQgJmd0Oy9kZXYvbnVsbCAyJmd0OyZhbXA7 MTxicj4NCmVsc2U8YnI+DQombmJzcDsgZXhpdCAwPGJyPg0KZmk8YnI+DQo8YnI+DQpXYXMgbW9k ZmllZCB0byBsb29rIGxpa2U6PGJyPg0KIyEvYmluL3NoPGJyPg0KPGJyPg0KZ3JlcCB2bXggL3By b2MvY3B1aW5mbyAmZ3Q7L2Rldi9udWxsIDImZ3Q7JmFtcDsxICZhbXA7JmFtcDsgdm14PTE8YnI+ DQpncmVwIHN2bSAvcHJvYy9jcHVpbmZvICZndDsvZGV2L251bGwgMiZndDsmYW1wOzEgJmFtcDsm YW1wOyBzdm09MTxicj4NCjxicj4NCmlmIFsgJnF1b3Q7JHZteCZxdW90OyBdIHx8IFsgJnF1b3Q7 JHN2bSZxdW90OyBdOyB0aGVuPGJyPg0KJm5ic3A7IFsgJnF1b3Q7JHZteCZxdW90OyBdICZhbXA7 JmFtcDsgbW9kcHJvYmUgLWIga3ZtLWludGVsIDxiPmVtdWxhdGVfaW52YWxpZF9ndWVzdF9zdGF0 ZT0wPC9iPiAmZ3Q7L2Rldi9udWxsIDImZ3Q7JmFtcDsxPGJyPg0KJm5ic3A7IFsgJnF1b3Q7JHN2 bSZxdW90OyBdICZhbXA7JmFtcDsgbW9kcHJvYmUgLWIga3ZtLWFtZCAmZ3Q7L2Rldi9udWxsIDIm Z3Q7JmFtcDsxPGJyPg0KPGJyPg0KJm5ic3A7ICMgbm8gcmVhc29uIHdoeSB2aG9zdCBzaG91bGQg bm90IHdvcmsgd2l0aCBUQ0csIGJ1dCBjdXJyZW50bHkgaXQgZG9lcyBub3Q8YnI+DQombmJzcDsg bW9kcHJvYmUgLWIgdmhvc3QtbmV0ICZndDsvZGV2L251bGwgMiZndDsmYW1wOzE8YnI+DQplbHNl PGJyPg0KJm5ic3A7IGV4aXQgMDxicj4NCmZpPGJyPg0KPGJyPg0KQW5kIGFmdGVyIDxiPnR3bzwv Yj4gcmVib290cyhkaWRuwrR0IGdldCBzZXQgYWZ0ZXIgdGhlIGZpcnN0IHJlYm9vdCwgc3RyYW5n bHkgZW5vdWdoKSB0aGUgc2V0dGluZyBoYXZlIGJlZW4gY29uZmlybWVkIHBlcnNpc3RhbnQgd2l0 aDo8YnI+DQojIG1vcmUgL3N5cy9tb2R1bGUva3ZtX2ludGVsL3BhcmFtZXRlcnMvZW11bGF0ZV9p bnZhbGlkX2d1ZXN0X3N0YXRlPGJyPg0KTjxicj4NCjxicj4NClRoZSBIb3N0IHdhcyBhZ2FpbiBh Y3RpdmF0ZWQgYW5kIHRoZSBndWVzdCBwYW5pY3MgYXJlIGdvbmUuPGJyPg0KPGJyPg0KVGhhbmtz IGZvciB0aGUgaGludCE8YnI+DQo8YnI+DQovS2FybGk8YnI+DQo8YnI+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_5F9E965F5A80BC468BE5F40576769F090E8807ADexchange21_--

3 2

[Users] Thin provisioning extending while "Make template" still a bug?
by Adrian Gibanel 20 Dec '12

20 Dec '12

------=_Part_151_10842021.1356038920441 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I'm going to describe the bug.=20 You create a virtual machine with a thin provisioning hard disk.=20 You select the virtual machine (which it was stopped in my case) and click = on "Make template".=20 You wait so that it ends but then when checking storage domain you notice t= hat your template has the same size as if it was a preallocated image!=20 I suppose that in some of the cases you can run out of space.=20 I've been complaining on the irc about what it seemed Manager to ignore tha= t the "Make template" task had finished, I mean just ignore it for about 30= minutes and then saying everything it's ok. But... that's another history.= =20 Two irc people stated that usually people ran this bug where the virtual ma= chine gets the preallocated size instead of the thin provisioning one.=20 Although they were not quite sure there's supposedly a bug around this subj= ect which I couldn't find on bugzilla.=20 If the bug is as the one as I describe I would be happy to contribute to it= with my setup details and logs so that you can find whatever makes it not = happen in my case while most of the people run accross it.=20 Thank you for any information you can provide.=20 --=20 Adri=C3=A1n Gibanel=20 I.T. Manager=20 +34 675 683 301=20 www.btactic.com=20 Ens podeu seguir a/Nos podeis seguir en:=20 i=20 Abans d=C2=B4imprimir aquest missatge, pensa en el medi ambient. El medi am= bient =C3=A9s cosa de tothom. / Antes de imprimir el mensaje piensa en el m= edio ambiente. El medio ambiente es cosa de todos.=20 AVIS:=20 El contingut d'aquest missatge i els seus annexos =C3=A9s confidencial. Si = no en sou el destinatari, us fem saber que est=C3=A0 prohibit utilitzar-lo,= divulgar-lo i/o copiar-lo sense tenir l'autoritzaci=C3=B3 corresponent. Si= heu rebut aquest missatge per error, us agrairem que ho feu saber immediat= ament al remitent i que procediu a destruir el missatge .=20 AVISO:=20 El contenido de este mensaje y de sus anexos es confidencial. Si no es el d= estinatario, les hacemos saber que est=C3=A1 prohibido utilizarlo, divulgar= lo y/o copiarlo sin tener la autorizaci=C3=B3n correspondiente. Si han reci= bido este mensaje por error, les agradecer=C3=ADamos que lo hagan saber inm= ediatamente al remitente y que procedan a destruir el mensaje .=20 ------=_Part_151_10842021.1356038920441 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><= div style=3D'font-family: arial,helvetica,sans-serif; font-size: 10pt; colo= r: #000000'>I'm going to describe the bug. You create a virtual mach= ine with a thin provisioning hard disk. You select the virtual machi= ne (which it was stopped in my case) and click on "Make template". Y= ou wait so that it ends but then when checking storage domain you notice th= at your template has the same size as if it was a preallocated image! I = suppose that in some of the cases you can run out of space.   I= 've been complaining on the irc about what it seemed Manager to ignore that= the "Make template" task had finished, I mean just ignore it for about 30 = minutes and then saying everything it's ok. But... that's another history.<= br>  Two irc people stated that usually people ran this bug where the = virtual machine gets the preallocated size instead of the thin provisioning= one. Although they were not quite sure there's supposedly a bug aro= und this subject which I couldn't find on bugzilla. If the bug is as= the one as I describe I would be happy to contribute to it with my setup d= etails and logs so that you can find whatever makes it not happen in my cas= e while most of the people run accross it. Thank you for any informa= tion you can provide. -- <div><a style=3D"color: rgb(0, 0, 0);" href= =3D"http://www.btactic.com/"><= /a>Adri=C3=A1n Gibanel I.T. Manag= er +34 675 683 301 <a href=3D"http://btactic.com/">www.btactic.co= m</a> <img src=3D"http://www.btactic.com/signaturabtacticmail/bta= cticsignature.png" style=3D"border-width: 0px;"> <b= r>Ens podeu seguir a/Nos podeis seguir en: <a href=3D"http://www.facebook.com/pages/btactic/118651634826= 400?v=3Dapp_9953271133"><img style=3D"border: 0pt none;" src=3D"http://www.= btactic.com/wp-content/themes/btactic/img/facebookfoot.jpg"></a> i <a href= =3D"http://twitter.com/btactic"><img style=3D"border: 0pt none;" src=3D"htt= p://www.btactic.com/wp-content/themes/btactic/img/twitterfoot.jpg"></a></sp= an> </f= ont><div>Abans d=C2=B4imp= rimir aquest missatge, pensa en el medi ambient. El medi ambient =C3=A9s cosa de= =20 tothom. / Antes de imprimir el mensaje piensa en el medio ambiente. El medio=20 ambiente es cosa de todos. = AVIS: El contingut d'aquest missatge i els seus annexos =C3=A9s confidencial. Si = no en sou el destinatari, us fem saber que est=C3=A0 prohibit utilitzar-lo,=20 divulgar-lo i/o copiar-lo sense tenir l'autoritzaci=C3=B3 corresponent. Si heu rebut=20 aquest missatge per error, us agrairem que ho feu saber immediatament al remitent i que procediu a destruir el missatge. AVISO: El contenido de este mensaje y de sus anexos es confidencial. Si no es el destinatario, les hacemos saber que est=C3=A1 prohibido utilizarlo,=20 divulgarlo y/o copiarlo sin tener la autorizaci=C3=B3n correspondiente. Si han recibid= o este mensaje por error, les agradecer=C3=ADamos que lo hagan saber=20 inmediatamente al remitente y que procedan= a destruir el mensaje. </div> </div></div></body></html> ------=_Part_151_10842021.1356038920441--

1 0