Hi /Jd
Another question about convirt. If I'm shutting down a SLES vm with convirt the green mark persist though the system is already halted. After that i cannot start the vm anymore. I need to start it over cli "xm start <vm name>".
With Windows machines changing the mark correctly. I can start and stop vms as expected.
Do you have any suggestions about this behaviour?
If yes, please let me know.
Regards,
Christian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the tip. But perhaps /Jd knows another workaround. With xm destroy the vm is no more listed in convirt. So I'm not able to start it anyway. I need to recreate the vm with "xm create <VMName>".
Christian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
++++++Update++++++
You are right André. I destroyed the vm (xm destroy) and then I've imported the vm config file in convirt again. And now i can see also the haltet vm which is not listet by xm list. Hope this behavior and workaround is reproducible.
Tanks for help again.
Regards,
Christian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Xen-Host: SLES10SP2
Xen-Version: 3.2.0_16718_18-0.3
VM's: SLES10SP2, Windows Server 2003, Windows XP Pro
Regardless of which OS is running (also Windows) on the VM, as long as the VM is saved in the xend-DB, ConVirt does'nt show VM-State correctly, when VM is in shut-down-mode. I even can't test acpi=1 and apci=1 on a Linux-VM, but on Windows-VM this mode is the default mode and it also doesn't work (at our environment)
I can shutdown VM, but then can't start again, because VM is shown as running and so start-button isn't available.
When VM is saved in xend-DB and I paused them, xm list show that VM in state 'p', what imho is correct ..., also ConVirt shows state correct!
In short: as long as the VM is stored in xend-DB, VM-state isn't shown correctly in ConVirt, when VM is in shut-down-mode
Perhaps you have a solution?
Thx André
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
Host Distro SLES10 SP2, xen 3.2; Guest SLES10 SP2
My workaround is, that I'm shutting down the vm in convirt. Then I'm deleting the vm with "xm delete". After that, convirt don't show the vm anymore. Thats expected. After that I'm importing the vm configfile (not the xml, the other one) in convirt. After these steps, the running state is displayed right (also the stopped state).
One thing i don't know. Why shows xend-DB normaly the vm in stopped state (xm list), and why not after the steps of the workaround above. Why changes xen it's manner for displaying vms. Is it a workaround with "time limit".
With Windows XP vms I've not encountered any problems.
Any other suggestions?
Regards,
Christian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To your question:
...Why shows xend-DB normaly the vm in stopped state (xm list), and why not after the steps of the workaround above...
Because after this procedure, the VM isn't a xend-managed Domain anymore and it is no longer saved in xend-database. Therefore it isn't display after shutdown.
André
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi André
Thats should be true. I'm installing SLES with a script that launches vm-install. So in first case my new machines should be xend managed. After deleting it, it will be convirt managed (after importing the config file).
Until now I'm not able to provision (or provide?) a SLES over convirt. But I'm working on it. Thats why I'm using vm-install.
Christian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi /Jd
Here the vm-install command which is executed after data collection:
vm-install --background -o sles10 -c $vm_cpu -v -n $vm_name -m $vm_msize -M $vm_msize -d $vm_lv,xvda,disk,w -s $installsrv --nic bridge=br1 --graphics none -os-settings $autoyast
Should be PV, but if u ask me like that, I'm not shure if this installation method installs SLES paravirtualized (sorry about that).
Christian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- take a running VM (Windows Server 2008, full-virtualized) that is not saved in xend-DB
- write their configuration in file (xm list -l test-vs-xen2 > test-vs-xen2.sxp)
- stop VM
- write their configuration durable in xend-DB (xm new -F test-vs-xen2.sxp)
- now VM is shown by executing 'xm list' while it is shutdown
- ConVirt also shows VM correctly as shutdown
- config file is saved in /etc/xen/vm/ (unique) on Xen-Host and is imported in ConVirt
- now I try to start VM in ConVirt and the described error occurs
here is output from convirt.log while pressing 'Start VM' in ConVirt:
Traceback (most recent call last):
File "/usr/share/convirt/src/convirt/client/convirt_client.py", line 3560, in startdom
dom._start()
File "/usr/share/convirt/src/convirt/core/platforms/xen/XenDomain.py", line 117, in _start
self._start_vm()
File "/usr/share/convirt/src/convirt/core/platforms/xen/XenDomain.py", line 127, in _start_vm
raise Exception("Domain could not be started: " + output)
Exception: Domain could not be started: Error: VM name 'test-vs-xen2' already exists
Using config file "/etc/xen/vm/test-vs-xen2".
It looks like there is executed a 'xm create vm_name' and this will not be working, because VM is already existing in xend-DB. A 'xm start vm_name' looks better in this case? Or I'am wrong?
Thx André
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- take a running VM (Windows Server 2008, full-virtualized) that is not saved in xend-DB
- write their configuration in file (xm list -l test-vs-xen2 > test-vs-xen2.sxp)
- stop VM
- write their configuration durable in xend-DB (xm new -F test-vs-xen2.sxp)
- now VM is shown by executing 'xm list' while it is shutdown
- ConVirt also shows VM correctly as shutdown
- config file is saved in /etc/xen/vm/ (unique) on Xen-Host and is imported in ConVirt
- now I try to start VM in ConVirt and the described error occurs
here is output from convirt.log while pressing 'Start VM' in ConVirt:
Traceback (most recent call last):
File "/usr/share/convirt/src/convirt/client/convirt_client.py", line 3560, in startdom
dom._start()
File "/usr/share/convirt/src/convirt/core/platforms/xen/XenDomain.py", line 117, in _start
self._start_vm()
File "/usr/share/convirt/src/convirt/core/platforms/xen/XenDomain.py", line 127, in _start_vm
raise Exception("Domain could not be started: " + output)
Exception: Domain could not be started: Error: VM name 'test-vs-xen2' already exists
Using config file "/etc/xen/vm/test-vs-xen2".
It looks like there is executed a 'xm create vm_name' and this will not be working, because VM is already existing in xend-DB. A 'xm start vm_name' looks better in this case? Or I'am wrong?
Thx André
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
now it seems to be working. I just pick the uuid from VM-config (which I get with 'xm list -l vm_name' from xend-managed domU) and put it in VM-startup-file. I can start/stop VM in ConVirt and VM-state is shown correctly.
But in our case I can't use any uuid generated with that util, I have to use the uuid which is already saved in xend-DB, otherwise I get the error I described above!
What is with migration of xend-managed domU's? Does it work?
Thx André
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I even testing a little bit, following I find out:
- when using ConVirt to manage Xen-Hosts (start/stopp/edit VM's) it doesn't make sense to save VM-config in xend-DB, because everytime I start a VM over ConVirt, the VM is new created with is Initial-Startup-File and settings in xend-DB where overwritten.
It's a pity, because Novell advise to use Initial-startup-Files only for creation of VM and then edit VM-settings in xend-DB by do following:
1. read VM-settings from xend-DB
# xm list -l vm_name > vm_name.sxp
2. edit VM-settings by edit vm_name.sxp
3. delete old VM-configuration from xend-DB
# xm delete vm_name
4. store new (edited) configuration in xend-DB
# xm new -F vm_name.sxp
Andre,
If ConVirt config file is the truth, do you see a problem it being overwritten everytime a vm is started. ( I am sure, I am missing something here.)
/Jd
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
From my point of view there is no problem at the moment to manage VM's with their startup file. I use this in that way successfully for about 2 Months, but when I start working with ConVirt, all the VM's where xend-managed and stored in xend-DB (thats standard when creating VM's with the wizard which is integrated SLES10)...
Caused by the problems with the wrong displayed vm-state I removed the VM's from xend-DB and all seems working... The only thing i had to change was creating a symbolic link to the startup file in /etc/xen/auto/ to autostart the VM with the Xen-Host.
What I mean is, that it's good to know, that when VM is stored in xend-DB, changes that made in the above described way (and recommended by Novell) are without effect, when start VM over ConVirt. Then it also doesn't make sense to save VM-config in xend-DB or let them stored there. So imho the problem with the missing uuid also is solved :-)
Isn't it so?
Greets André
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi /Jd
Another question about convirt. If I'm shutting down a SLES vm with convirt the green mark persist though the system is already halted. After that i cannot start the vm anymore. I need to start it over cli "xm start <vm name>".
With Windows machines changing the mark correctly. I can start and stop vms as expected.
Do you have any suggestions about this behaviour?
If yes, please let me know.
Regards,
Christian
I solved that problem by deleting VM from xend-database.
# xm destroy vm_name
ConVirt starts VM from their startup-files (/etc/xen/vm/), that you have imported.
When you shutdown a xend-managed domU and run following command on dom0
# xm list
you will see that also offline-VM where displayed . A non-xend-managed domU wouldn't display there.
IMHO Convirt misinterpret the state of xend-managed domU's...
André
Thanks for the tip. But perhaps /Jd knows another workaround. With xm destroy the vm is no more listed in convirt. So I'm not able to start it anyway. I need to recreate the vm with "xm create <VMName>".
Christian
++++++Update++++++
You are right André. I destroyed the vm (xm destroy) and then I've imported the vm config file in convirt again. And now i can see also the haltet vm which is not listet by xm list. Hope this behavior and workaround is reproducible.
Tanks for help again.
Regards,
Christian
Hi guys
Interesting discussion. Linux Distro, Xen version details please.
change acpi and apci to 1 in the misc tab. Let me know.
-- when the vm is halted, what does xm list show ?
/Jd
Hi,
Xen-Host: SLES10SP2
Xen-Version: 3.2.0_16718_18-0.3
VM's: SLES10SP2, Windows Server 2003, Windows XP Pro
Regardless of which OS is running (also Windows) on the VM, as long as the VM is saved in the xend-DB, ConVirt does'nt show VM-State correctly, when VM is in shut-down-mode. I even can't test acpi=1 and apci=1 on a Linux-VM, but on Windows-VM this mode is the default mode and it also doesn't work (at our environment)
I can shutdown VM, but then can't start again, because VM is shown as running and so start-button isn't available.
When VM is saved in xend-DB and I paused them, xm list show that VM in state 'p', what imho is correct ..., also ConVirt shows state correct!
In short: as long as the VM is stored in xend-DB, VM-state isn't shown correctly in ConVirt, when VM is in shut-down-mode
Perhaps you have a solution?
Thx André
Hi all,
Host Distro SLES10 SP2, xen 3.2; Guest SLES10 SP2
My workaround is, that I'm shutting down the vm in convirt. Then I'm deleting the vm with "xm delete". After that, convirt don't show the vm anymore. Thats expected. After that I'm importing the vm configfile (not the xml, the other one) in convirt. After these steps, the running state is displayed right (also the stopped state).
One thing i don't know. Why shows xend-DB normaly the vm in stopped state (xm list), and why not after the steps of the workaround above. Why changes xen it's manner for displaying vms. Is it a workaround with "time limit".
With Windows XP vms I've not encountered any problems.
Any other suggestions?
Regards,
Christian
To your question:
...Why shows xend-DB normaly the vm in stopped state (xm list), and why not after the steps of the workaround above...
Because after this procedure, the VM isn't a xend-managed Domain anymore and it is no longer saved in xend-database. Therefore it isn't display after shutdown.
André
Hi André
Thats should be true. I'm installing SLES with a script that launches vm-install. So in first case my new machines should be xend managed. After deleting it, it will be convirt managed (after importing the config file).
Until now I'm not able to provision (or provide?) a SLES over convirt. But I'm working on it. Thats why I'm using vm-install.
Christian
SLES10SP2 is HVM or PV ?
Can u give more details on vm-install usage, we can try it out and try to reproduce it here.
/Jd
Hi /Jd
Here the vm-install command which is executed after data collection:
vm-install --background -o sles10 -c $vm_cpu -v -n $vm_name -m $vm_msize -M $vm_msize -d $vm_lv,xvda,disk,w -s $installsrv --nic bridge=br1 --graphics none -os-settings $autoyast
Should be PV, but if u ask me like that, I'm not shure if this installation method installs SLES paravirtualized (sorry about that).
Christian
Interesting...
-- You may be able to tweak the provision.sh and get the vm-install running from ConVirt directly :)
-- Luckily I had an environment to try this out... here is a patch that should fix this problem :)
https://sourceforge.net/tracker/index.php?func=detail&aid=2543853&group_id=168929&atid=848458
Thanks for bringing this to our attention.
/Jd
After I put a Test-VM in xend-DB (xm new -F vm_conf.sxp) and running this patch I can't start the VM from ConVirt. Following error occurs:
"Error starting vm_name. Domain could not be started: Error: VM name 'vm_name' already exists. Using config file "/etc/xen/vm/vm_name".
André
Hi Andre,
I spent some time reproducing this.... but I can not.
Can u please make sure that you do not have two config files having the same "name" in them ?
Send in a stacktrace from /var/log/convirt/convirt.log... might help a bit more.
/Jd
Hi Jd,
following I've done:
- take a running VM (Windows Server 2008, full-virtualized) that is not saved in xend-DB
- write their configuration in file (xm list -l test-vs-xen2 > test-vs-xen2.sxp)
- stop VM
- write their configuration durable in xend-DB (xm new -F test-vs-xen2.sxp)
- now VM is shown by executing 'xm list' while it is shutdown
- ConVirt also shows VM correctly as shutdown
- config file is saved in /etc/xen/vm/ (unique) on Xen-Host and is imported in ConVirt
- now I try to start VM in ConVirt and the described error occurs
here is output from convirt.log while pressing 'Start VM' in ConVirt:
Traceback (most recent call last):
File "/usr/share/convirt/src/convirt/client/convirt_client.py", line 3560, in startdom
dom._start()
File "/usr/share/convirt/src/convirt/core/platforms/xen/XenDomain.py", line 117, in _start
self._start_vm()
File "/usr/share/convirt/src/convirt/core/platforms/xen/XenDomain.py", line 127, in _start_vm
raise Exception("Domain could not be started: " + output)
Exception: Domain could not be started: Error: VM name 'test-vs-xen2' already exists
Using config file "/etc/xen/vm/test-vs-xen2".
It looks like there is executed a 'xm create vm_name' and this will not be working, because VM is already existing in xend-DB. A 'xm start vm_name' looks better in this case? Or I'am wrong?
Thx André
Hi Jd,
following I've done:
- take a running VM (Windows Server 2008, full-virtualized) that is not saved in xend-DB
- write their configuration in file (xm list -l test-vs-xen2 > test-vs-xen2.sxp)
- stop VM
- write their configuration durable in xend-DB (xm new -F test-vs-xen2.sxp)
- now VM is shown by executing 'xm list' while it is shutdown
- ConVirt also shows VM correctly as shutdown
- config file is saved in /etc/xen/vm/ (unique) on Xen-Host and is imported in ConVirt
- now I try to start VM in ConVirt and the described error occurs
here is output from convirt.log while pressing 'Start VM' in ConVirt:
Traceback (most recent call last):
File "/usr/share/convirt/src/convirt/client/convirt_client.py", line 3560, in startdom
dom._start()
File "/usr/share/convirt/src/convirt/core/platforms/xen/XenDomain.py", line 117, in _start
self._start_vm()
File "/usr/share/convirt/src/convirt/core/platforms/xen/XenDomain.py", line 127, in _start_vm
raise Exception("Domain could not be started: " + output)
Exception: Domain could not be started: Error: VM name 'test-vs-xen2' already exists
Using config file "/etc/xen/vm/test-vs-xen2".
It looks like there is executed a 'xm create vm_name' and this will not be working, because VM is already existing in xend-DB. A 'xm start vm_name' looks better in this case? Or I'am wrong?
Thx André
Hi Andre,
Please add uuid to the VM. And try the ops again.
Here is patch that adds a uuid at the time of provisioning.
https://sourceforge.net/tracker/index.php?func=detail&aid=2549736&group_id=168929&atid=848458
also a util to generate new uuids that can be used to add uuid to existing vm.
Let me know if this get u operational.
/Jd
Hi Jd,
thanks for your help! I'll try out the patch on monday, when I'm at work.
So long, thx
André
Hi Jd,
now it seems to be working. I just pick the uuid from VM-config (which I get with 'xm list -l vm_name' from xend-managed domU) and put it in VM-startup-file. I can start/stop VM in ConVirt and VM-state is shown correctly.
But in our case I can't use any uuid generated with that util, I have to use the uuid which is already saved in xend-DB, otherwise I get the error I described above!
What is with migration of xend-managed domU's? Does it work?
Thx André
Hi Jd,
I even testing a little bit, following I find out:
- when using ConVirt to manage Xen-Hosts (start/stopp/edit VM's) it doesn't make sense to save VM-config in xend-DB, because everytime I start a VM over ConVirt, the VM is new created with is Initial-Startup-File and settings in xend-DB where overwritten.
It's a pity, because Novell advise to use Initial-startup-Files only for creation of VM and then edit VM-settings in xend-DB by do following:
1. read VM-settings from xend-DB
# xm list -l vm_name > vm_name.sxp
2. edit VM-settings by edit vm_name.sxp
3. delete old VM-configuration from xend-DB
# xm delete vm_name
4. store new (edited) configuration in xend-DB
# xm new -F vm_name.sxp
(http://www.novell.com/documentation/sles10/xen_admin/index.html?page=/documentation/sles10/xen_admin/data/bookinfo.html)
So long
André
Andre,
If ConVirt config file is the truth, do you see a problem it being overwritten everytime a vm is started. ( I am sure, I am missing something here.)
/Jd
From my point of view there is no problem at the moment to manage VM's with their startup file. I use this in that way successfully for about 2 Months, but when I start working with ConVirt, all the VM's where xend-managed and stored in xend-DB (thats standard when creating VM's with the wizard which is integrated SLES10)...
Caused by the problems with the wrong displayed vm-state I removed the VM's from xend-DB and all seems working... The only thing i had to change was creating a symbolic link to the startup file in /etc/xen/auto/ to autostart the VM with the Xen-Host.
What I mean is, that it's good to know, that when VM is stored in xend-DB, changes that made in the above described way (and recommended by Novell) are without effect, when start VM over ConVirt. Then it also doesn't make sense to save VM-config in xend-DB or let them stored there. So imho the problem with the missing uuid also is solved :-)
Isn't it so?
Greets André