7:52 a.m.
Hello,
anyone succeeding in doing what in subject?
F18 node with 3.2 final. ANother server with f18 and engine (3.2 also)
Tried with a Win 7 VM and a CentOS 5 VM.
I successfully create a snapshot.
Then I right-click the snapshot line and select "clone"
I get this window that remains there without exiting....
See here:
https://docs.google.com/file/d/0BwoPbcrMv8mvRFVsQ1J3QVk1TGM/edit?usp=sharing
WHat kind of log to provide?
Thanks,
Gianluca
9 a.m.
On Tue, Feb 26, 2013 at 3:26 PM, Liron Aravot wrote:
Hi, can you please provide engine/vdsm logs?
does the snapshot has disks?
Here they are.
Snapshot has been taken around 14:45. Clone of the snapshot attempted
around 14:47
engine.log:
https://docs.google.com/file/d/0BwoPbcrMv8mvY3J4Vk10aVpiRzg/edit?usp=sharing
vdsm.log:
https://docs.google.com/file/d/0BwoPbcrMv8mvQlo0QzNVWVoxVkE/edit?usp=sharing
What you mean with "does the snapshot has disks?" ? I hope so.... ;-)
But if I select the snapshot line and go atthe right panel, the disk
columns seems empty....
See here:
https://docs.google.com/file/d/0BwoPbcrMv8mvZDdhTG9LQXg3UFk/edit?usp=sharing
Gianluca
9:18 a.m.
On Tue, Feb 26, 2013 at 4:00 PM, Gianluca Cecchi wrote:
BTW: nothing changes if the VM is powered off when I take the
snapshot. A following clone operation remains with the white window I
sent before...
NOTE: On February 5th on this same infra I was with engine and node at
nightly repo as of vdsm-4.10.3-0.78.gitb005b54.fc18.x86_64 and I was
able to successfully complete this kind of operation. It was done with
the VM powered off.
Gianluca
9:52 a.m.
Gianluca,
please try to refresh the UI, you should see the snapshot disks.
regarding the clone issue, it was solved by this patch:
http://gerrit.ovirt.org/#/c/11254/
so if you'll use the latest it should be fine.
----- Original Message -----
10:33 a.m.
What do you mean with "latest"?
Latest stable, so 3.2 as I'm running right now?
In that case it doesn't work for me.. I'm going to check the files
referred...
Even with refresh and using both ie and Firefox I see the disk, network
columns of the snapshot empty...the ones in the square box at bottom right
when selecting the line relative to the snapshot itself... as in the image
I posted before..
1:10 p.m.
Latest build (not release), as in from:
http://resources.ovirt.org/releases/nightly/rpm/Fedora/18/
Good luck,
Vered
----- Original Message -----
12:27 a.m.
On Tue, Feb 26, 2013 at 8:10 PM, Vered Volansky wrote:
Yes but now I'm on an ovirt- stable environment.
Also, nightly is now at 3.3 code version, while I would like to stay
on 3.2 for now for this test environment.
I think this is a serious bug, is there anything in the air to be
proposed as a patch/update for 3.2 stable?
Otherwise in release notes you should notice that you are unable to
create clones.... or is there any other way to create a clone?
Gianluca
6:14 a.m.
----- Original Message -----
Hi Gianluca,
I've built 3.2 and had success in reproducing your issue, I've also tested the fix
and after it the clone window shows fine - so this should solve your issue
(http://gerrit.ovirt.org/#/c/11254/).
Thanks, Liron.
11:07 a.m.
On Wed, Feb 27, 2013 at 1:21 PM, Liron Aravot wrote:
Hello,
so I rebuilt with the patch.
I built as in this thread:
http://lists.ovirt.org/pipermail/users/2013-February/012702.html
directly on engine server and with engine stopped:
sudo rpm -Uvh --force $(ls -1|grep -v all)
with
$ ls -1|grep -v all
ovirt-engine-3.2.0-4.fc18.noarch.rpm
ovirt-engine-backend-3.2.0-4.fc18.noarch.rpm
ovirt-engine-config-3.2.0-4.fc18.noarch.rpm
ovirt-engine-dbscripts-3.2.0-4.fc18.noarch.rpm
ovirt-engine-genericapi-3.2.0-4.fc18.noarch.rpm
ovirt-engine-notification-service-3.2.0-4.fc18.noarch.rpm
ovirt-engine-restapi-3.2.0-4.fc18.noarch.rpm
ovirt-engine-setup-3.2.0-4.fc18.noarch.rpm
ovirt-engine-tools-common-3.2.0-4.fc18.noarch.rpm
ovirt-engine-userportal-3.2.0-4.fc18.noarch.rpm
ovirt-engine-webadmin-portal-3.2.0-4.fc18.noarch.rpm
and then reboot the engine
Results:
OK, for the snapshot details pane. It seem the patch fixes this too.
Until now I was never able to see snapshot details,
Instead now I can see disk and nic details. See:
https://docs.google.com/file/d/0BwoPbcrMv8mvQmlCZTZBYjBadmc/edit?usp=sharing
OK, if I clone a VM from a snapshot of a running VM (CentOS 5.6)
I start the clone and no problem at all.
well done!
Corner cases and problems
1)
OK, if I clone a powered on VM from a snapshot with two disks and here
you can find clone in action with webadmin gui and iotop on node that
shows they are cloning in parallel.. well!
https://docs.google.com/file/d/0BwoPbcrMv8mvZ3lzY0l1MDc5OVE/edit?usp=sharing
The VM is a slackware 14 32bit with virtio disk that I obtained from a
virt-v2v from CentOS 6.3+Qemu/KVM
The problem is that the cloned VM recognizes the disks in reversed order
See these images where sl1432 is master slcone is the clone
disk layout in details pane seems equal with boot disk the one that
appears as the second, but the master boots ok, the slave no.
Disks are swapped
Master VM disk details:
https://docs.google.com/file/d/0BwoPbcrMv8mvSWNVNFI4bHg4Umc/edit?usp=sharing
Clone VM disks details:
https://docs.google.com/file/d/0BwoPbcrMv8mvM1N0bVcyNlFPS1U/edit?usp=sharing
Page with the two consoles where you can see that vda of master
becomes vdb of clone and vice-versa:
https://docs.google.com/file/d/0BwoPbcrMv8mveFpESEs5V1dUTFE/edit?usp=sharing
Can I swap again in some way? In VMware for example you can see and
edit SCSI IDs of disks...
2)
KO, if I clone a windows 7 VM from a snapshot (time 17:09) I get this on gui
https://docs.google.com/file/d/0BwoPbcrMv8mvaW9OVW84WVI1dkU/edit?usp=sharing
You can find the engine.log from server restart (at 17:06) here:
https://docs.google.com/file/d/0BwoPbcrMv8mvTDQzRTFfbFgxX0E/edit?usp=sharing
Are there any restrictions?
The VM was powered off when taking the snapshot and making the clone.
Gianluca
8:33 a.m.
On Mon, Mar 4, 2013 at 1:19 PM, Alissa Bonas wrote:
OK.
here it is:
https://docs.google.com/file/d/0BwoPbcrMv8mva2Z2dUNJTWlCWHM/edit?usp=sharing
Starting point 15:16 both powered off.
First message with 15:17 is boot of sl1432b that is the master and boots ok.
First message with 15:21 is boot of slclone that is the clone.
The slackware OS uses lilo as boot loader and on master it is
configured this way at the moment:
root@sl1432b:~# grep -v ^# /etc/lilo.conf
append=" vt.default_utf8=0"
boot = /dev/vda
bitmap = /boot/slack.bmp
bmp-colors = 255,0,255,0,255,0
bmp-table = 60,6,1,16
bmp-timer = 65,27,0,255
prompt
timeout = 50
change-rules
reset
vga = normal
disk=/dev/vda bios=0x80 max-partitions=7
image = /boot/vmlinuz
root = /dev/vda2
initrd = /boot/initrd.gz
label = Linux
read-only
The "disk=..." entry was added to be able to support boot from device
of type vda in slackware, that doesn't support it ootb..
Gianluca
6:48 a.m.
----- Original Message -----
Hi,
Thanks for additional information.
The engine log actually shows that slclone started ok:
"VM slclone c6c56d41-d70d-4b9b-a1cb-8b0c097b89a0 moved from PoweringUp -->
Up"
Can you explain what problem are you experiencing in that VM?
Also, could provide the vdsm log from the same timeframe?
Gianluca
9:31 a.m.
On Tue, Mar 5, 2013 at 1:48 PM, Alissa Bonas wrote:
The Vm doesn't boot.
As I wrote in the other e-mail:
"
The problem is that the cloned VM recognizes the disks in reversed order
See these images where sl1432 is master slcone is the clone
disk layout in details pane seems equal with boot disk the one that
appears as the second, but the master boots ok, the slave no.
Disks are swapped
Master VM disk details:
https://docs.google.com/file/d/0BwoPbcrMv8mvSWNVNFI4bHg4Umc/edit?usp=sharing
Clone VM disks details:
https://docs.google.com/file/d/0BwoPbcrMv8mvM1N0bVcyNlFPS1U/edit?usp=sharing
Page with the two consoles where you can see that vda of master
becomes vdb of clone and vice-versa:
https://docs.google.com/file/d/0BwoPbcrMv8mveFpESEs5V1dUTFE/edit?usp=sharing
Can I swap again in some way? In VMware for example you can see and
edit SCSI IDs of disks...
"
Gianluca
2:24 a.m.
----- Original Message -----
What is important here is to check the boot properties of both devices as
they are configured for the master and clone.
They might not be swapped, the order in the console is not necessarily the issue here.
Please attach vdsm.log with times of both machines boot. the properties of the devices
boot should be part of the startup command so it should help to investigate the issue.
Thanks
Gianluca
3:46 a.m.
On Wed, Mar 6, 2013 at 9:24 AM, Alissa Bonas <abonas(a)redhat.com> wrote:
qemu command line is
1) sl1432b
qemu 23481 1 0 Mar04 ? 00:35:07 /usr/bin/qemu-kvm
-name sl1432b -S -M pc-0.14 -cpu Opteron_G2 -enable-kvm -m 4096 -smp
2,sockets=2,cores=1,threads=1 -uuid
b66ccc4b-0e31-42e5-ba6c-04075a85880c -smbios
type=1,manufacturer=oVirt,product=oVirt
Node,version=18-1,serial=34353439-3036-435A-4A38-303330393338,uuid=b66ccc4b-0e31-42e5-ba6c-04075a85880c
-no-user-config -nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/sl1432b.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc
base=2013-03-04T15:16:38,driftfix=slew -no-shutdown -device
piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive
if=none,id=drive-ide0-1-0,readonly=on,format=raw,serial= -device
ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive
file=/rhev/data-center/5849b030-626e-47cb-ad90-3ce782d831b3/596a3408-67d7-4b26-b482-e3a7554a5897/images/b2c274d8-7948-4fd3-b20a-8e802776b0a9/e2b6ad99-860c-4ef3-b4f7-bd5f2803cf2e,if=none,id=drive-virtio-disk0,format=qcow2,serial=b2c274d8-7948-4fd3-b20a-8e802776b0a9,cache=none,werror=stop,rerror=stop,aio=native
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
-drive
file=/rhev/data-center/5849b030-626e-47cb-ad90-3ce782d831b3/596a3408-67d7-4b26-b482-e3a7554a5897/images/fb9380ce-3e61-4a0a-8d9b-98fea9c2456c/03aba9bd-8863-4a1b-bb66-ae0a856ec61e,if=none,id=drive-virtio-disk1,format=qcow2,serial=fb9380ce-3e61-4a0a-8d9b-98fea9c2456c,cache=none,werror=stop,rerror=stop,aio=native
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk1,id=virtio-disk1
-netdev tap,fd=29,id=hostnet0,vhost=on,vhostfd=30 -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:47:d7:53,bus=pci.0,addr=0x3
-chardev
socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/sl1432b.com.redhat.rhevm.vdsm,server,nowait
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm
-chardev
socket,id=charchannel1,path=/var/lib/libvirt/qemu/channels/sl1432b.org.qemu.guest_agent.0,server,nowait
-device
virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0
-chardev spicevmc,id=charchannel2,name=vdagent -device
virtserialport,bus=virtio-serial0.0,nr=3,chardev=charchannel2,id=channel2,name=com.redhat.spice.0
-spice
port=5901,tls-port=5902,addr=0,x509-dir=/etc/pki/vdsm/libvirt-spice,tls-channel=main,tls-channel=display,tls-channel=inputs,tls-channel=cursor,tls-channel=playback,tls-channel=record,tls-channel=smartcard,tls-channel=usbredir
-k en-us -vga qxl -global qxl-vga.vram_size=67108864 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7
2) slclone
qemu 24712 1 0 Mar04 ? 00:18:20 /usr/bin/qemu-kvm
-name slclone -S -M pc-0.14 -cpu Opteron_G2 -enable-kvm -m 4096 -smp
2,sockets=2,cores=1,threads=1 -uuid
c6c56d41-d70d-4b9b-a1cb-8b0c097b89a0 -smbios
type=1,manufacturer=oVirt,product=oVirt
Node,version=18-1,serial=34353439-3036-435A-4A38-303330393338,uuid=c6c56d41-d70d-4b9b-a1cb-8b0c097b89a0
-no-user-config -nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/slclone.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc
base=2013-03-04T02:21:34,driftfix=slew -no-shutdown -device
piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive
if=none,id=drive-ide0-1-0,readonly=on,format=raw,serial= -device
ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive
file=/rhev/data-center/5849b030-626e-47cb-ad90-3ce782d831b3/596a3408-67d7-4b26-b482-e3a7554a5897/images/adca6016-0706-4d11-aa3f-bbe1894608d9/377a0622-80c9-4fd4-bde9-4ef22a30d379,if=none,id=drive-virtio-disk0,format=qcow2,serial=adca6016-0706-4d11-aa3f-bbe1894608d9,cache=none,werror=stop,rerror=stop,aio=native
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
-drive
file=/rhev/data-center/5849b030-626e-47cb-ad90-3ce782d831b3/596a3408-67d7-4b26-b482-e3a7554a5897/images/bd8d1847-ba90-42ef-90f1-836f14a6e67e/d46c7d31-e53d-4ea2-82b9-7c74bdbae18e,if=none,id=drive-virtio-disk1,format=qcow2,serial=bd8d1847-ba90-42ef-90f1-836f14a6e67e,cache=none,werror=stop,rerror=stop,aio=native
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,id=virtio-disk1
-netdev tap,fd=30,id=hostnet0,vhost=on,vhostfd=34 -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:04:04:dd,bus=pci.0,addr=0x3
-chardev
socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/slclone.com.redhat.rhevm.vdsm,server,nowait
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm
-chardev
socket,id=charchannel1,path=/var/lib/libvirt/qemu/channels/slclone.org.qemu.guest_agent.0,server,nowait
-device
virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0
-chardev spicevmc,id=charchannel2,name=vdagent -device
virtserialport,bus=virtio-serial0.0,nr=3,chardev=charchannel2,id=channel2,name=com.redhat.spice.0
-spice
port=5903,tls-port=5904,addr=0,x509-dir=/etc/pki/vdsm/libvirt-spice,tls-channel=main,tls-channel=display,tls-channel=inputs,tls-channel=cursor,tls-channel=playback,tls-channel=record,tls-channel=smartcard,tls-channel=usbredir
-k en-us -vga qxl -global qxl-vga.vram_size=67108864 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7
note
1) disks of sl1432b
-drive
file=/rhev/data-center/5849b030-626e-47cb-ad90-3ce782d831b3/596a3408-67d7-4b26-b482-e3a7554a5897/images/b2c274d8-7948-4fd3-b20a-8e802776b0a9/e2b6ad99-860c-4ef3-b4f7-bd5f2803cf2e,if=none,id=drive-virtio-disk0,format=qcow2,serial=b2c274d8-7948-4fd3-b20a-8e802776b0a9,cache=none,werror=stop,rerror=stop,aio=native
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
and
-drive
file=/rhev/data-center/5849b030-626e-47cb-ad90-3ce782d831b3/596a3408-67d7-4b26-b482-e3a7554a5897/images/fb9380ce-3e61-4a0a-8d9b-98fea9c2456c/03aba9bd-8863-4a1b-bb66-ae0a856ec61e,if=none,id=drive-virtio-disk1,format=qcow2,serial=fb9380ce-3e61-4a0a-8d9b-98fea9c2456c,cache=none,werror=stop,rerror=stop,aio=native
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk1,id=virtio-disk1
2) disks of slclone
-drive
file=/rhev/data-center/5849b030-626e-47cb-ad90-3ce782d831b3/596a3408-67d7-4b26-b482-e3a7554a5897/images/adca6016-0706-4d11-aa3f-bbe1894608d9/377a0622-80c9-4fd4-bde9-4ef22a30d379,if=none,id=drive-virtio-disk0,format=qcow2,serial=adca6016-0706-4d11-aa3f-bbe1894608d9,cache=none,werror=stop,rerror=stop,aio=native
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
and
-drive
file=/rhev/data-center/5849b030-626e-47cb-ad90-3ce782d831b3/596a3408-67d7-4b26-b482-e3a7554a5897/images/bd8d1847-ba90-42ef-90f1-836f14a6e67e/d46c7d31-e53d-4ea2-82b9-7c74bdbae18e,if=none,id=drive-virtio-disk1,format=qcow2,serial=bd8d1847-ba90-42ef-90f1-836f14a6e67e,cache=none,werror=stop,rerror=stop,aio=native
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,id=virtio-disk1
boot disk (so what should be mapped as vda) seems equal between the two:
1) for boot disk of sl1432b (bootindex=1)
# qemu-img info
/rhev/data-center/5849b030-626e-47cb-ad90-3ce782d831b3/596a3408-67d7-4b26-b482-e3a7554a5897/images/b2c274d8-7948-4fd3-b20a-8e802776b0a9/e2b6ad99-860c-4ef3-b4f7-bd5f2803cf2e
image:
/rhev/data-center/5849b030-626e-47cb-ad90-3ce782d831b3/596a3408-67d7-4b26-b482-e3a7554a5897/images/b2c274d8-7948-4fd3-b20a-8e802776b0a9/e2b6ad99-860c-4ef3-b4f7-bd5f2803cf2e
file format: qcow2
virtual size: 10G (10737418240 bytes)
disk size: 0
cluster_size: 65536
backing file:
../b2c274d8-7948-4fd3-b20a-8e802776b0a9/a0e68178-1821-4784-8d3d-e4fdcb56cc26
(actual path:
/rhev/data-center/5849b030-626e-47cb-ad90-3ce782d831b3/596a3408-67d7-4b26-b482-e3a7554a5897/images/b2c274d8-7948-4fd3-b20a-8e802776b0a9/../b2c274d8-7948-4fd3-b20a-8e802776b0a9/a0e68178-1821-4784-8d3d-e4fdcb56cc26)
2) for boot disk of slclone (bootindex=1)
# qemu-img info
/rhev/data-center/5849b030-626e-47cb-ad90-3ce782d831b3/596a3408-67d7-4b26-b482-e3a7554a5897/images/adca6016-0706-4d11-aa3f-bbe1894608d9/377a0622-80c9-4fd4-bde9-4ef22a30d379
image:
/rhev/data-center/5849b030-626e-47cb-ad90-3ce782d831b3/596a3408-67d7-4b26-b482-e3a7554a5897/images/adca6016-0706-4d11-aa3f-bbe1894608d9/377a0622-80c9-4fd4-bde9-4ef22a30d379
file format: qcow2
virtual size: 10G (10737418240 bytes)
disk size: 0
cluster_size: 65536
But as you can see in the two-consoles image, for slclone vda appears
as the 4Gb disk, that doesn't contain anything in the MBR and so is
actually unable to boot....
Possibly a way to view/edit scsi order of disks could be an
enhancement in oVirt.
See the vdsm log requested here:
https://docs.google.com/file/d/0BwoPbcrMv8mvbHV1Y1BULXdKY1k/edit?usp=sharing
As I wrote before,
sl1432b starts at 15:17
slclone starts at 15:21
8:13 a.m.
On Sun, Mar 3, 2013 at 5:30 PM, Alissa Bonas wrote:
Yes, you are right. I thought I had selected a storage domain with
sufficient free space but probably it was not so.
I just repeated the operation, creating a snapshot and then a clone of
the same VM and selecting an SD with sufficient free space, and it
completed correctly with the cloned VM able to boot.
I take the occasion to suggest oVirt to at least behave this way:
1) pre-calculate necessary space and in case of problems don't start
the clone operations but send a warning message impeding it
If during 1) all was ok and in the mean time went KO (unexpected new
storage allocated that made impossible clone completion)
2) notify the user with the actual problem (insufficient space) and
not those crypic messages....
see the already pointed link:
https://docs.google.com/file/d/0BwoPbcrMv8mvaW9OVW84WVI1dkU/edit?usp=sharing
Thanks,
Gianluca
8:34 a.m.
----- Original Message -----
Those are indeed great improvement suggestions for a better user experience.
It will be great if you could add it in bugzilla (as RFE) so it can be followed and
managed there:
https://bugzilla.redhat.com/enter_bug.cgi?product=oVirt
Thank you!
Thanks,
Gianluca
8:53 a.m.
On Mon, Mar 4, 2013 at 3:34 PM, Alissa Bonas wrote:
OK. Done
https://bugzilla.redhat.com/show_bug.cgi?id=917682
I didn't know how to post an rfe bug, so I chose "unspecified" as
severity and put "RFE:" at the beginning of subject.
Feel free to modify it if this is the wrong way to submit RFE bug...
Gianluca
12:27 p.m.
New subject: [Users] how to notate a bug as a feature (was clone vm from snapshot problem in 3.2)
On Fri, Mar 15, 2013 at 10:43 AM, Itamar Heim wrote:
aha, ok.
Possibly a dropdown list in that field would be better, instead of
click on "keyword" hyperlink to see possible values and their
explanation... lso to cover mistyping
Thanks anyway
Gianluca
3:16 a.m.
Hi all,
I am facing the same problem regarding the VM clone & viewing the
details from snapshot as Gianluca has described in this current thread.
The single problem I am facing now, is that your thread is from 3 months
old, I am using el6 stable repository on a CentOS 6.3 installation and
my rpm list below looks like:
ovirt-engine-sdk-3.2.0.10-1.el6.noarch
ovirt-engine-webadmin-portal-3.2.1-1.beta1.el6.noarch
ovirt-engine-setup-3.2.1-1.beta1.el6.noarch
ovirt-engine-userportal-3.2.1-1.beta1.el6.noarch
ovirt-engine-dbscripts-3.2.1-1.beta1.el6.noarch
ovirt-engine-3.2.1-1.beta1.el6.noarch
ovirt-engine-cli-3.2.0.11-1.el6.noarch
ovirt-engine-tools-3.2.1-1.beta1.el6.noarch
ovirt-engine-genericapi-3.2.1-1.beta1.el6.noarch
ovirt-engine-backend-3.2.1-1.beta1.el6.noarch
ovirt-engine-restapi-3.2.1-1.beta1.el6.noarch
As I can see, there were some revision set updates on the ovirt engine
core rpms, that I suppose, it should include this as well:
http://gerrit.ovirt.org/#/c/11254/
Can someone provide me some piece of advice on how to fix things ?
Thanks you.
Alex. Vladulescu
On 02/28/2013 07:07 PM, Gianluca Cecchi wrote:
3:30 a.m.
On Thu, May 16, 2013 at 10:16 AM, Alexandru Vladulescu wrote:
As far as I understood, the upcoming 3.2.2 should have the problem
directly fixed in it without need of recompiling, also for EL6 repo.
I think that you could enable updates-testing repo for your ovirt and
then your update would access the packages here:
http://resources.ovirt.org/releases/updates-testing/rpm/EL/6/noarch/
such as
ovirt-engine-3.2.2-1.1.el6.noarch.rpm
or you can wait for the final push in stable repo....
HIH,
Gianluca
4343
days inactive
4422
days old
24 comments
6 participants
participants (6)
-
Alexandru Vladulescu -
Alissa Bonas -
Gianluca Cecchi -
Itamar Heim -
Liron Aravot -
Vered Volansky